ATS Migration Checklist: 30 Steps for Switching Recruitment Systems

Phase 1: Scope the migration before choosing a go-live date

1. 1Name one migration owner with authority to resolve data and workflow decisions.
2. 2Define which entities move: candidates, contacts, clients, jobs, submissions, placements, notes, activities, attachments, consent records and custom objects.
3. 3List every integration connected to the old system.
4. 4Map every report or downstream process that depends on ATS data.
5. 5Decide how much historical data must remain operational versus archived.

Phase 2: Audit and clean legacy data

Migration is a rare chance to remove years of taxonomy debt. Recreating every broken status, free-text field and duplicate record in the new system preserves the very problem the project is supposed to fix.

• Measure duplicate candidate and contact records.
• Identify fields nobody uses and custom fields whose meaning has drifted.
• Find invalid emails, missing ownership and orphaned records.
• Review retention, consent and deletion obligations before copying old data forward.
• Decide which status values should be normalised instead of recreated one-for-one.
• Sample attachments and activity history rather than assuming exports contain them.

Phase 3: Secure a complete export from the old vendor

• Request a test export before the final migration window.
• Confirm data format, encoding and stable identifiers.
• Verify notes, emails, call logs, activity history and attachments separately.
• Export configuration metadata or screenshots for workflows, templates and reports you may need to reproduce.
• Store an immutable archive copy under your own control.
• Document what the old vendor cannot or will not export.

Phase 4: Map the old data model to the new one

Atlas is a useful example here because its agency proposition includes richer relationship context than a minimal ATS. If you migrate into Atlas, verify how legacy call notes and client history map into the new context model. If you later leave Atlas, verify how that automatically captured context can be exported in a usable form.

Phase 5: Rebuild integrations deliberately

• Do not reconnect every legacy integration automatically; confirm it is still needed.
• Revalidate calendar, email, job boards, sourcing tools, assessments, e-signature and BI connections.
• Confirm field mappings and ownership when data flows both directions.
• Test failure handling: logging, retries, alerts and operational ownership.
• For agency stacks, include telephony, WhatsApp/business messaging and contractor-finance integrations where relevant.

Phase 6: Test with real workflows and representative data

1. 1Load a representative data subset including clean and messy records.
2. 2Run recruiter, hiring-manager and admin workflows end to end.
3. 3Compare record counts and sample histories against the old system.
4. 4Validate reports against known historical numbers.
5. 5Test permissions with real user-role combinations.
6. 6Run a migration rehearsal and measure how long cutover actually takes.

Phase 7: Plan parallel run, training, cutover and rollback

• Define a data freeze or delta-sync approach so records do not diverge during cutover.
• Keep the old system accessible long enough to resolve exceptions.
• Train users on the new workflow, not only on menu navigation.
• Publish one source of truth for go-live support and known issues.
• Define the rollback condition before launch, including who can trigger it.
• Only terminate the old contract once archive, data validation and operational sign-off are complete.

Phase 8: Audit the new system 30 and 90 days after go-live

• Check adoption and workarounds: where are spreadsheets or shadow systems returning?
• Review data-quality metrics and duplicate creation.
• Compare expected versus actual integration reliability.
• Review reports and fields that nobody uses.
• Capture configuration changes before local workarounds become permanent architecture.
• Document the exit/export process while implementation knowledge is still fresh.