Applicant tracking system migration checklist

Who this is for

Use this Applicant tracking system migration checklist if you own hiring operations at a small or mid sized company. You may be an HR lead, a recruiter who also runs the systems, or an IT manager handed the project because the old ATS is being retired. You hire often enough that candidate records matter, and you cannot afford to lose interview notes or break an active offer.

It also fits teams moving off spreadsheets and shared inboxes. That move is smaller, but the same question applies: what do we keep, and what do we leave behind? If you already ran a CRM migration, do not copy that plan word for word. An ATS holds resumes, application answers, interview scorecards, disposition reasons and offer approvals. Those records have a different shape and a different audience.

Hiring managers and finance leads should read the checklist too. They are the people who notice missing interview feedback or an approval step that no longer fires.

Before you begin

Pick one owner and one cutover date. The owner makes the call when two systems disagree. The date gives everyone a target and a freeze window. Put both in writing and send them to recruiters, hiring managers and anyone who touches offers.

Map the current system before you export anything. List the stages a candidate can pass through, the fields you actually use, the disposition reasons, the interview kits, the email templates and the integrations. Mark which items are required and which are nice to have. This map becomes your migration spec and your test plan.

Check your export options and your retention settings. Some systems export candidate profiles as CSV but leave resumes in a separate archive. Some keep email history only through an admin export. Confirm file formats and whether attachments come with the record. Decide what to do with rejected candidates and old applications before you copy them.

Tell candidates about the change only if their experience changes. A new apply link and a new sender address are worth a short notice on the careers page. Internal users need more: a demo, a quick reference, and a clear date when the old system becomes read only.

The checklist

Work through this list in order. The early items define scope. The later items protect the cutover. If you skip a step, write down why and who accepted the risk.

Treat the old ATS as the source of truth until the new one passes a live hiring cycle. That means one system of record at a time. Split routing is how duplicate candidate records and lost emails happen.

Keep a migration log with dates, owners and open issues. When a recruiter says an interview note is missing, the log tells you whether it was never exported, failed to import, or landed under the wrong candidate.

• Export every active candidate with profile fields, resume files, attachments and application answers.
• Export closed candidates separately and decide which ones you will keep, archive or delete under your retention policy.
• Map each old stage to a new stage and write down the exit criteria so stage history stays readable.
• Carry over disposition reasons and rejection codes so reports on stage conversion still mean something.
• Move interview scorecards, interview notes and reviewer names with the candidate record.
• Copy offer records and approval history, then test that the new approval flow reaches the same approvers.
• List every integration: job boards, careers page, calendar, background check, electronic signature, HRIS and single sign on.
• Export email and message templates, then check that merge fields match the new system's field names.
• Set up user roles, hiring team permissions and single sign on before you invite recruiters.
• Rebuild application forms, screening questions and any voluntary self identification questions in the new system.
• Run a test import with a small cohort that includes active, rejected and hired records.
• Post a test job to each job board and confirm that applications land in the new ATS with the right source.
• Set the old system to read only after cutover and keep access for a defined period.

What good looks like

A clean migration has one system of record and no mystery records. Recruiters open a candidate and see the resume, the application answers, every stage change, interview feedback and the latest message. Nothing is stored in a personal drive or an inbox folder.

Reports still tell the same story. Time to hire, source and stage conversion should be comparable to the old numbers once you account for the cutover date. If a report depends on a field you did not migrate, say so in the admin guide instead of letting people guess.

Hiring managers can schedule interviews, submit scorecards and approve offers without asking a recruiter for a workaround. Candidates get a working apply link and replies from a monitored address. The old system stays available for reference but stops sending mail. Access is limited, and someone owns the decision to retire it.

What to do next

Start with the data map. Spend a day listing stages, fields, integrations and reports. That document will expose the hard parts before you touch an import tool.

Then run a pilot with one open role. Import a small cohort, post the job, schedule an interview, move a candidate to offer and check the reports. Fix what breaks before you migrate the full database.

If you want the setup done for you, Cloudverg's Recruiting system implementation package is $9,500 at a fixed price. It runs three to four weeks, starts within 10 business days, and covers pipeline stages, interview scorecards, job board feeds, scheduling, offer approval, reports, recruiter training and a written admin guide. Compare that with your team's time and pick the path that fits.

Whichever path you choose, keep the checklist open until the first hire made in the new system has passed through every stage.

Frequently asked questions