ATS data migration checklist for recruiting firms

What should an ATS data migration checklist cover?#

An ATS data migration checklist should cover 25 concrete items, from reading the outgoing contract to closing the old account, grouped into six phases with a named owner and a done-when test for each. Recruiting firms that treat migration as an IT import tend to lose history, because the hardest calls concern scope, rights and retention rather than file formats.

Use the phases as the spine of the project plan and the numbered items as its tasks. Items that need counsel or a vendor answer sit at the start so they begin first; most of the rest can run in parallel once scope is agreed.

Phase 1: contract review (items 1-5)#

Contract review comes first because the outgoing agreement sets the deadline and the incoming agreement sets the terms of your next exit. Read the new vendor's paper as if you were already planning to leave it.

Ask both vendors to confirm key answers in writing. What a sales representative says on a call is not a contract term, and migrations go wrong when nobody can find the clause that was promised.

• 11. Confirm the outgoing ATS term end date, auto-renewal language and non-renewal notice deadline, and put that deadline at the top of the plan.
• 22. Confirm export rights in the outgoing agreement: which record types, which formats, whether attachments are covered and what assisted extracts cost.
• 33. Confirm what happens after termination: any read-only access and its price, the vendor's deletion duties and whether it will confirm deletion in writing.
• 44. Before signing the incoming ATS, confirm who controls the records you load, whether the vendor may use them to train or improve its own AI features, and how to opt out.
• 55. Confirm exit rights in the incoming agreement, and check client, MSP and job board terms that limit where candidate or program data may be moved.

Phase 2: inventory and scope (items 6-9)#

Inventory and scope turn a vague database into a list of record types, each with a decision attached. The ATS is rarely the only system involved, so the inventory starts wider than the migration itself.

Records marked for deletion should be deleted on schedule, not carried into the new system out of caution. Importing stale personal data adds cost and exposure without helping recruiters find anyone.

• 16. List every system that holds part of the candidate or client journey: the ATS, email and calendar sync, back-office payroll, e-signature, assessments, texting tools and shared drives.
• 27. Mark every record type move, archive or delete, using the table below as a starting point.
• 38. Agree retention periods with counsel for records marked archive or delete, and flag records under legal hold so they are neither deleted nor lost.
• 49. Name one owner who can approve scope and mapping decisions, plus a reviewer on each desk.

Phase 3: export and field mapping (items 10-14)#

Export and field mapping decide whether the old system's history survives or flattens into a few vague fields. Every field and status value needs a destination, or an explicit decision to leave it in the archive, before the first test import.

The people who use a custom field should define it. An operations analyst can map a field called specialty, but only the desk that created it knows whether it holds a skill, a client requirement or a pay band.

• 110. Run a full extract with stable record IDs, created and modified dates, owner fields and any archived or deleted flags.
• 211. Export attachments as files, with an index that maps each file to its parent record.
• 312. Write a data dictionary for custom fields, with definitions supplied by the desks that use them.
• 413. Map every pipeline status, from submitted through placed or rejected, to a status in the new ATS.
• 514. Set rules for merging duplicate candidates and contacts, and for records owned by departed recruiters, so original ownership stays visible.

Phase 4: test import and cutover (items 15-19)#

A test import on one desk exposes problems that a field map on paper never will, so it comes before any firm-wide date is announced. Pick a desk with active jobs, long candidate histories and plenty of attachments, because that mix breaks weak mappings fastest.

Cutover is a sequence rather than a single day. The freeze, the delta extract and the integration switch each need an owner, and the old ATS stays open read-only until Phase 5 is signed off.

• 115. Load one pilot desk and have its recruiters run real searches, pipelines and attachment checks in the new ATS.
• 216. Fix the mapping and duplicate rules the pilot exposes, and rerun a full trial if the changes were large.
• 317. Announce a data freeze date to every desk, after which new activity goes into the new ATS only.
• 418. Take a final delta extract of records created or changed since the full extract, and load it.
• 519. Switch integrations, including job boards, email sync, e-signature, background checks, VMS connectors and payroll feeds, then set the old ATS to read-only.

Phase 5: post-import validation (items 20-23)#

Post-import validation proves that the new ATS holds the same records and relationships as the old one, and it must finish while the old system can still be opened for comparison. Explicit pass rules keep sign-off from depending on anyone's impression.

• 120. Reconcile record counts by type across the source, the extract and the new ATS, and explain every gap.
• 221. Sample placements and submissions to confirm their candidate, job and contact links survived.
• 322. Read sample candidate timelines side by side and open sample attachments from each record type.
• 423. Collect written sign-off from each desk head, and from counsel on retention and privacy decisions.

Phase 6: the legacy archive (items 24-25)#

The legacy archive is the last phase and the one most often skipped, usually because the project team is worn out by go-live. It should hold every record you did not import in a form your firm can open, search and delete on schedule without the old vendor.

Test the archive the way a future reader will use it. Ask someone outside the project to answer a real question from it, such as who placed a given contractor and at what rate, before the old account is closed.

• 124. Store every unimported record read-only in open formats, with record IDs, the data dictionary, the file index and an export log.
• 225. Give the archive an owner, a retention rule and a deletion date, and confirm it opens without the old vendor before closing the account.

Illustrative: an executive search firm changes ATS and keeps its search history#

Illustrative: a fictional executive search firm has run a legacy ATS for many years, with search reports and candidate assessments stored partly in the ATS and partly on a shared drive. Working through item 6, its COO finds that the shared drive folders have no reliable link back to search records.

The firm builds an index linking each search folder to its search ID before export, moves active searches and recent placements into the new ATS, and archives completed searches in a read-only store. Dormant candidate profiles past the firm's retention period are reviewed and deleted rather than migrated. Item 4 changes the new vendor contract: it is signed only after it includes clear export rights and an opt-out from vendor AI training on the firm's records.

Where SourceX fits once the archive exists#

SourceX fits after the migration, when a recruiting firm decides to review its legacy archive for licensing. It treats the archive as separate record families, such as job orders, submission workflows and placement outcomes, rather than as one database.

Any review follows the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. Candidate personal data is removed or excluded during Preparation, client and MSP restrictions are settled during Rights, and the initial assessment uses metadata only, so no records leave the firm to find out whether the archive is a fit.