Migration is a data project, not a software purchase

Teams budget weeks for choosing an ATS and an afternoon for moving into it. It's backwards. The choice is reversible; the migration is where reqs go dark, candidates get dropped mid-pipeline, and recruiters quietly keep using the old system in parallel because the new one "doesn't have my people in it." If you've already done the hard part of choosing an ATS for a small team, this is the work that decides whether that choice pays off.

The good news: a clean migration is mostly checklist discipline. Here's the one that works.

Step 1 — Inventory what you actually have

Before you export anything, list every place candidate data lives. It's never just the old ATS:

  • The ATS itself (candidates, applications, stage history, notes, attachments).
  • Recruiter inboxes and a shared "resumes" folder or drive.
  • A spreadsheet someone maintains "because the ATS doesn't do X."
  • LinkedIn Recruiter projects and saved searches.
  • Offer letters and signed docs in e-signature tools.

You don't have to migrate all of it. You have to decide about all of it, on purpose, so nothing important is discovered missing in month two.

Step 2 — Export and triage, ruthlessly

Pull a full export from the old system — CSV for structured data, plus the attachments. Then triage. Migrating five years of dead candidates just imports five years of clutter and slows every future search. A defensible cut:

  • Migrate: anyone active in a pipeline now, anyone hired in the last ~24 months, and your genuine silver-medalists.
  • Archive (export and store, don't import): everyone else, so you keep the record without polluting the working system.
  • Drop: true duplicates and spam applications.

This is also the moment to honor data-retention and consent obligations. Some candidates' data you are required to purge after a window; migration day is when those rules get enforced or quietly broken.

Step 3 — Map the fields before you touch the importer

The boring step that prevents most disasters. Build a mapping table: old field → new field → transform. The ones that always bite:

  • Stages. Your old "Phone Screen / Onsite / Offer" rarely maps 1:1. Decide the target stages first, then map every legacy stage into one of them. Don't recreate the old mess.
  • Status and disposition codes. "Rejected" vs. "Withdrew" vs. "Not a fit" carry compliance meaning — preserve the distinction.
  • Dates. Application date and source date drive your time-to-hire metrics; lose them and your reporting resets to zero.
  • Resumes. Plan to re-parse on import rather than trusting old structured fields. A modern resume parser will extract cleaner data than a five-year-old one did, and re-parsing on the way in means your new search index is actually good.

Step 4 — Dedupe on the way in

Duplicate candidate records are the silent killer of a new ATS: two recruiters work "the same" person in two records and step on each other. Dedupe on a stable key — email first, then phone, then normalized name — and decide a merge rule (newest application wins, keep all notes). Do this during import. Deduping a live system after the fact is far harder than getting it right at the door. A CSV import flow that flags likely duplicates before committing, like the bulk candidate import in Hosting HR, turns this from a manual grind into a review step.

Step 5 — Pick the cutover window and make it real

The failure mode here is the indefinite "soft launch" where both systems run forever. Pick a date. Around it:

  • Freeze the old system to read-only for a short window so no data is created mid-migration.
  • Run a verification pass: spot-check that active reqs, their candidates, and current stages came across intact. Pull a record you know well and confirm every field.
  • Announce a hard cutover. New applications, notes, and offers happen only in the new system as of the date. Dual-entry is how data integrity dies.

Step 6 — Don't migrate recruiters' trust by accident

The last 20% is human. A technically perfect migration fails if recruiters don't believe their candidates are really in there. So: migrate the active pipelines first and most carefully, get one recruiter to verify their own reqs before you announce, and keep the old system available read-only for 30–60 days as a safety net — long enough to build trust, short enough to force the switch. Pair the cutover with a short walkthrough of where things moved, and your first-week ramp instinct applies to your own team too: people adopt a system fast when day one works and slowly when it doesn't.

The one-line test for a successful migration

A week after cutover, can a recruiter open the new ATS, find any active candidate by name, see their correct stage and full history, and move them forward — without checking the old system? If yes, you migrated. If they're still cross-referencing the spreadsheet, you copied data but didn't migrate the work. Aim for the first.