Only 28% of Teams Are Happy With Their ATS. Here Is What to Check Before You Migrate to a New One.
You have already decided the current tool is not working. The part that keeps you renewing it anyway is the migration: years of candidate history, notes, and pipeline data that you are afraid of losing on the way out. That fear is reasonable, and it is also the exact place most switches go wrong. Here is what to check first, so the move costs you a weekend rather than your history.
Deciding to leave an applicant tracking system is the easy part. Most teams get there honestly: the tool stores candidates but never reduces the work, hiring managers never open it, and the real pipeline has quietly moved into a spreadsheet on the side. You have read the signs and made the call. Then you open the question of actually moving, and you stop.
This piece is for the recruiter or HR lead who already has an ATS and is planning to change it. It is not about whether to switch, which we covered in the seven signs your ATS has stopped keeping up. It is about the migration itself: what to audit before you sign anything, which data actually has to survive the move, and how to run the switch without your hiring going dark for a month.
Why Teams Stall at the Migration, Not the Decision
Wanting a better tool is not the rare part. Aptitude Research, which tracks the talent-acquisition software market, found that 82% of companies say their ATS has significant gaps and only 28% are satisfied with their current system. So the dissatisfaction is close to universal. What holds teams in place is not doubt about the new tool; it is the cost of getting there.
That cost is almost always the data. A small team that has hired for three or four years is sitting on thousands of candidate records, past conversations, and interview notes, and the worry is simple: if the export is messy, all of that turns into a folder nobody can use. The fear is not irrational. When migrations go wrong, notes and feedback tend to arrive incomplete, duplicated, or flattened into a single field, and the history that made the old tool worth keeping is exactly what does not survive a careless import.
The good news is that this is a planning problem, not a luck problem. Teams that migrate cleanly do the same unglamorous work up front: they audit what they actually have, decide what genuinely needs to move, and pin down who owns the export before they commit. The three sections below are that work, in order.
What to Audit in Your Old ATS First
Before you look at a single new vendor, spend an hour with the tool you have. You are answering one question: what can you actually get out of it, and in what shape? A surprising number of migration surprises are hiding in that answer.
- Can you export at all, and how. Some systems give you a clean CSV or an API; others only let you print or pull one record at a time. Confirm the path exists before anything else, because it decides how much of the rest is even possible.
- What comes with each record. A candidate is more than a name and a CV. Check whether your export carries the notes, interview feedback, tags, sources, and pipeline stage, or just the top-line fields. The parts most likely to be dropped are the ones you would most miss.
- How much of it you still need. Not every record earns a move. A pile of applicants from a role you filled two years ago is archive, not active pipeline. Separating the two now makes the migration smaller and the new system cleaner from day one.
- Your compliance clock. Under GDPR you are expected to hold candidate data only as long as you have a lawful reason to. A migration is a natural moment to delete what you should no longer keep, rather than faithfully copying years of stale records into a fresh tool.
The point of the audit is leverage. Walk into vendor conversations knowing exactly what you have and what you need to keep, and you stop being at the mercy of whatever a generic importer happens to support.
The Data That Has to Survive the Move
Not all candidate data is equal, and not all of it moves the same way. It helps to name each type, why it matters, and where it tends to get lost, so you can check for it deliberately instead of discovering the gap three weeks later.
| Data type | Why it matters | Where it gets lost |
|---|---|---|
| Candidate profiles and CVs | The core of your pipeline and your talent pool | Attachments and parsed fields often import as plain text, or not at all |
| Notes and interview feedback | The reasoning behind every past decision | Frequently flattened into one field or dropped entirely |
| Pipeline stage and status | Who is live, who was rejected, and why | Stages rarely map one to one between two systems |
| Email and message history | Context for candidates you may re-engage later | Threads often arrive detached from the candidate |
| Tags, sources, and custom fields | How you segment, filter, and report | Custom fields are the first thing a generic import skips |
| Consent and compliance records | Your lawful basis to hold the data at all | Consent dates and retention flags are easy to lose in transit |
You will not fight equally hard for every row. Active candidates and the reasoning behind recent decisions are worth protecting closely; a silver-medalist finalist from last quarter is often your strongest next hire, and losing the note that says so quietly erases that advantage. Long-closed roles, on the other hand, can usually be archived rather than migrated. Deciding that split in advance is most of the job.
What to Ask the New Vendor Before You Commit
Once you know what you have, the migration becomes a set of direct questions for anyone selling you a replacement. Vague reassurance is not an answer; ask for specifics on each of these before you sign.
- Who actually does the migration? Do they import your data for you, or hand you a template and wish you luck? A vendor that has done this many times will have a real process; one that leaves it entirely to you is telling you how the next few years will feel.
- What maps cleanly, and what does not? Ask them, in plain terms, which of the data types above come across intact and which get simplified. An honest answer names the trade-offs; a dishonest one says everything is fine.
- Can we run a test import first? A sample of a few hundred records shows you the real result before you are committed. If they will not let you see a trial migration, that is its own answer.
- Where does the data live, and under what rules? For a team hiring in Europe, data residency and GDPR handling are not a footnote. Hosted in Europe, deleted on a clear schedule, and never used to train someone else’s model is a far simpler story than the alternative.
- Does the new tool remove work, or just store data again? The whole reason you are moving is that filing candidates was never the problem. The gap Aptitude keeps measuring, with scheduling the single most common one, is that the old tool automated almost nothing. Make sure the new one does more than hold your records in a nicer layout. We drew out that difference in an ATS versus an AI recruitment assistant.
How to Run the Switch Without Freezing Hiring
The last fear is practical: that hiring stops while you swap tools. It does not have to. A small team can move without a blackout by sequencing the switch instead of flipping it.
- Pick a quieter window. Start the migration when your open roles are at their lowest, not in the middle of your busiest hiring push. A gap of a week or two in low season costs almost nothing.
- Move the active pipeline first. Your live candidates and open roles go across first and get verified by hand. The old archive can follow later, or stay read-only where it is.
- Run both in parallel for a short overlap. Keep the old system readable while the new one becomes the source of truth. You get a safety net and a reference without paying for two tools forever.
- Verify a real sample. Open twenty migrated candidates and check that the notes, stages, and CVs actually came through. Finding a mapping problem on twenty records is a fix; finding it on two thousand is a crisis.
This is also where a small team can turn a migration into a consolidation. If the reason you are leaving is that hiring lived across an ATS, a sourcing tab, a scheduling tool, and a spreadsheet, the win is not just a better database; it is one place that sources, screens, scores, and schedules so the stitching between tools disappears. That is the ground Kynto is built on, and you can see how it fits a small hiring team on our product overview. The tool matters less than the principle: migrate to something that removes work, not just something newer.
Key Takeaways
- Dissatisfaction is near-universal: 82% of companies say their ATS has significant gaps and only 28% are satisfied, so the hard part is the migration, not the decision.
- Audit your old ATS before you shop: confirm you can export, check what comes with each record, and separate active pipeline from archive you no longer need.
- Notes, interview feedback, pipeline stage, and custom fields are the data most likely to be flattened or dropped. Name what has to survive and check for it on purpose.
- Sequence the switch instead of flipping it: quieter window, active pipeline first, a short parallel overlap, and a verified sample before you trust the import.
FAQ
Should I migrate all of my old candidate data, or start fresh?
Neither extreme is right. Copying everything drags years of stale records into a clean tool and can breach your retention obligations; starting from zero throws away a talent pool you already paid to build. Move your active pipeline and the recent candidates worth re-engaging, archive or delete the rest, and let the migration double as the cleanup you have been putting off.
How long does an ATS migration take for a small team?
For a team hiring across a handful of roles, the data move itself is usually days rather than weeks once the export is clean and the field mapping is agreed. Most of the calendar time goes to the preparation, the audit, the mapping, and the sample check, which is exactly the part worth not rushing. A good vendor should be able to give you a concrete timeline for your volume before you sign.
Will we have to stop hiring during the switch?
No, if you sequence it. Move the active pipeline first, run the old and new systems in parallel for a short overlap, and keep the old one readable until you trust the new source of truth. Starting in a quieter hiring week means even the brief handover lands when the fewest candidates are waiting on you.
Leaving an ATS you have outgrown is not the risky move. Renewing one you already know is failing, for another year, because the migration felt daunting is the costlier one. Audit what you have, decide what truly needs to move, and run the switch in sequence, and the change becomes a weekend of careful work rather than a loss of everything you built.
If you would rather see what your pipeline looks like in one place, sourcing, screening, scoring, and scheduling together instead of scattered across tools, you can walk through it with us.
See Kynto in a short demo