On this page▾
- Why ATS migrations have such a bad reputation
- First decide whether you should migrate at all
- Map your data before you trust any export
- Pull a real export early and read it like a skeptic
- Clean and transform in a staging copy, never in production
- Plan the cutover like a launch, with a freeze and a fallback
- Migrate the integrations, not just the records
- Bring your team along or the whole thing fails
- A realistic timeline and where modern tools help
Almost every recruiting leader I talk to is using a system they quietly hate, and almost none of them will switch. The reason is rarely the price or the features. It is fear. Somewhere in their past, or in a peer's war story, there was a migration that went sideways: candidates vanished, two systems ran in parallel for three months, a hiring manager sent an offer from the old tool while a recruiter worked the new one, and the whole quarter felt like a tax audit.
That fear is rational, but it is also exploited. Legacy ATS vendors know that switching costs are their best retention strategy, so they make export awkward, they bury your historical data behind support tickets, and they price annual contracts to auto-renew before you can plan an exit. The dirty secret is that a migration is mostly a project management problem, not a technical one. Done with a real plan, you can move in a few weeks with zero lost records. Done by improvising on a Friday afternoon, you can absolutely create the disaster everyone fears.
This is the playbook I wish someone had handed me. It is opinionated, it assumes you have a real pipeline of active candidates, and it is built to protect the two things that actually matter: your data and your team's sanity.
Before you touch an export button, be honest about why you are leaving. There are good reasons and bad reasons. Good reasons: your tool cannot support a workflow you genuinely need, your cost per hire is inflated by per-seat pricing you have outgrown, your team avoids the system so your data is already garbage, or you are adopting AI-native workflows the incumbent simply cannot do. Bad reasons: a single feature complaint that a configuration change would fix, a shiny demo, or one loud internal champion who will leave in six months.
Write down the three workflows that are broken today and the measurable outcome you expect from the new system. Maybe it is cutting time-to-schedule from four days to one, or eliminating the twelve hours a week your coordinator spends copying data between tools. If you cannot name the outcome, you are not ready, and you will end up rebuilding the same mess in a new interface. A migration is a chance to fix process debt, not just relocate it.
The single biggest cause of painful migrations is treating data as one undifferentiated blob. It is not. Your ATS holds at least five distinct kinds of records, and each migrates differently. There are jobs and requisitions with their states and approval history. There are candidates and their contact details and resumes. There are applications, which are the join between a candidate and a job at a moment in time, carrying the stage and disposition. There are activities: notes, emails, scorecards, interview feedback. And there is structured configuration: your stages, your scorecard templates, your user roles, your email templates.
Spend a day building a simple spreadsheet that lists every object, its approximate record count, and how critical it is to move. Candidates and active applications are non-negotiable. Five years of cold rejected applicants probably are not, and dragging them along will slow everything down and pollute your new system's search. Be ruthless. A migration is the cheapest time you will ever have to delete the junk you have been hoarding. I generally recommend migrating active pipelines fully, migrating the last twelve to eighteen months of closed records, and archiving everything older as a flat export you keep in cold storage in case you ever need it.
Do not wait until migration week to discover what your export actually contains. Request a full data export in the first few days, ideally in CSV or JSON, and open it. You are looking for the gaps the sales process never mentions. Common ones: resumes that export as broken links instead of files, email threads that come as a single concatenated text field with no sender or timestamp, custom fields that export by internal ID instead of label, and interview feedback that simply is not in the export at all because the vendor considers it part of a premium tier.
If your vendor will not give you a clean export, that is itself a finding, and you should escalate it in writing while you still have leverage as a paying customer. Pull the export through the API if one exists, because API exports are usually more complete and more structured than the dashboard download. Reconcile the record counts in your export against what the live system reports. If the system says you have 14,000 candidates and your export has 11,200, stop and find the missing 2,800 before you go any further. That gap is exactly where lost data hides.
Once you have an export you trust, do the messy work of transformation in a separate staging environment. This is where you map old stage names to new ones, normalize phone formats, deduplicate the same candidate who applied four times under three email addresses, and decide how owner assignments translate when your team structure has changed. Keep a transformation log so every change is reversible and explainable. When a hiring manager later asks why a candidate's stage looks different, you want an answer, not a shrug.
Run a test migration into a sandbox of the new system with a representative slice of data, maybe 200 candidates across a few jobs in different states. Then audit the result by hand. Pick ten candidates and trace them end to end: did the resume come across, are the notes attached to the right person, is the application on the right job at the right stage, did the interview feedback survive. Ten careful manual traces will teach you more than any automated validation report. Fix what broke, run the test again, and only schedule the real cutover when a test slice comes through clean.
The cutover is the moment of maximum risk, so treat it like a product launch. Pick a low-volume window, often a Friday afternoon into the weekend. Announce a data freeze: for a defined period, no one touches candidate records in the old system. This is the step teams skip and regret, because if recruiters keep working the old tool during migration, you create a moving target and you will lose every change made during the window.
Run the full migration, then run your reconciliation checks again at full scale before you let anyone in. Have a written rollback plan even if you never use it, because the existence of the plan is what lets your team stay calm. Keep the old system in read-only mode for at least thirty days. Do not cancel the old contract the day you go live. The few hundred dollars of overlap is the cheapest insurance you will ever buy, and it means that if someone insists a candidate is missing, you can go look rather than panic.
Your ATS is rarely an island. It is wired into your job boards, your calendar, your HRIS or payroll for new hires, your background-check vendor, your e-signature tool for offers, and probably a Slack or email notification flow. A migration that moves the data perfectly but leaves these connections broken still feels like a failure to the people using it every day. Inventory every integration before cutover and assign an owner to re-establish each one.
Pay special attention to anything candidate-facing. If you have job postings indexed by Google for Jobs or live on aggregators, a careless migration can break those URLs and silently kill your inbound applications for weeks. Set up redirects from old application URLs to new ones, and confirm your careers page and any embedded apply widgets point at the new system before you announce go-live. Test the apply flow yourself as a fake candidate, on mobile, the morning of launch.
I have watched technically flawless migrations fail because the recruiters quietly kept using spreadsheets, or because a hiring manager refused to learn one more tool and just emailed the recruiter instead. Data integrity is a people problem as much as a technical one. The new system only holds the truth if the team actually works inside it.
Train before cutover, not after. Run a live session walking through the three workflows you identified at the start, using real jobs the team recognizes. Designate one internal owner who knows the new system well enough to answer questions in the first two weeks, so people get unblocked in minutes instead of giving up. And resist the urge to perfectly replicate your old configuration in the new tool. If you rebuild a fourteen-stage pipeline that nobody followed, you have just migrated your dysfunction. Use the move as the forcing function to simplify.
For a 20 to 200 person company with a handful of recruiters, a clean migration is realistically three to five weeks: a week to decide and map, a week to export and clean, a week to test, then cutover and a stabilization period. It is not a single weekend, and anyone who promises you it is has not reconciled record counts before. But it is also not the six-month nightmare the legacy vendors want you to fear.
The reason migrations are getting easier is that newer systems are built knowing they have to win against an incumbent. When we built VScout, assisted import was a first-class feature rather than a support ticket, precisely because we expect customers to arrive carrying years of history from Greenhouse or Lever. The deeper shift, though, is what you migrate into. Moving from one static database to another just relocates your data. Moving into a system where an AI agent can actually read that history, screen new applicants against it, and answer questions about your pipeline in plain language is when the migration starts paying for itself. Pick the destination for what it lets your team stop doing, not just for a cleaner interface. The migration is a few weeks of discomfort. The system you choose is what you live in for the next several years.