Switching ATS without losing anything that matters
A vendor-neutral checklist: what actually survives an export, what does not, a realistic six-week timeline, and the contract questions to settle before you give notice.
Six weeks, honestly scoped
Most of this is data discipline rather than software. The teams that finish on time are the ones that did the inventory before they started.
Inventory and export
List everything living in your current system, request a full export, and actually open it. This is the phase teams skip, and it is the phase that determines whether the rest goes well.
Configure the new system
Build pipelines, custom fields, application forms, user roles, message templates and automation triggers. Do this before importing anything - importing into a half-built structure creates work you will redo.
Import and run parallel
Import candidate and job data, then open new requisitions in the new system while in-flight candidates finish in the old one. Both systems readable, only one taking new work.
Validate and cut over
Run the week-one validation list below, confirm messaging and reply routing behave correctly, then retire write access to the old system while keeping it readable for a defined period.
What survives the move, and what does not
Generic guidance for any ATS-to-ATS migration. Confirm the specifics with your current vendor - and test an export before you rely on any of it.
Five things to settle first
Every one of these is easier to resolve while you are still a paying customer of the system you are leaving.
Contract end date and notice period
Find the exact notice window in your current contract. Discovering a 90-day notice requirement after you have signed with a new vendor means paying for both systems for a quarter.
Data ownership and export rights
Confirm in writing what you can export, in what format, and whether export is self-service or a paid request. Ask before you give notice, while you still have leverage.
Who owns your phone numbers
Candidates reply to the number they recognise. Establish whether your SMS numbers are portable, and to where. This is the single most commonly missed item on this list.
Consent and opt-in records
Recruiting SMS is regulated. Opt-out state must transfer or be re-established before you send a single message from the new platform - texting someone who previously opted out is a compliance failure regardless of which system did it.
In-flight candidates
Decide the rule up front: candidates past a certain stage finish in the old system, everyone else moves. Ambiguity here is how people fall through the gap between two platforms.
Ten checks before you retire the old system
Run every one of these against real records. A migration that looks complete and a migration that is complete diverge in exactly these places.
- 01 Record counts match the export: candidates, jobs, placements
- 02 Spot-check 20 random candidates for resume attachment and field accuracy
- 03 Consent and opt-out flags are correct on a sample of previously opted-out candidates
- 04 Inbound SMS replies route to the right person and thread onto the right record
- 05 Outbound email passes authentication and is not landing in spam
- 06 Permissions are correct: log in as each role and confirm what is visible
- 07 Automation triggers fire as expected on a test candidate
- 08 Reports return sensible numbers against a period you already know
- 09 Career site links and job board postings point at the new system
- 10 Every integration has been tested end to end, not just connected
Migration questions, answered.
How long does an ATS migration actually take?
Four to six weeks is realistic for a small to mid-size organisation, and the timeline above breaks that down week by week. The variable that moves it most is not the software - it is how much historical data you insist on bringing and how clean it is. Teams that migrate three years of history rather than everything they have ever stored consistently finish faster and with fewer surprises.
What data usually does not survive a migration?
Threaded email and SMS history is the most common casualty in any platform-to-platform move, because systems model message threads very differently. Recruiter notes often arrive as a single text blob per candidate rather than a dated timeline. Users, roles and integrations are almost always rebuilt by hand rather than imported. Core records - candidates, resumes, jobs, placements - typically transfer cleanly. The table above sets out what to expect field by field.
Should we migrate all our historical data?
Usually not, and this is the most useful advice on this page. Ask what you would actually search or report on. Most teams find three years of candidate history covers essentially every real query, while the older material adds migration time, cost and clutter without adding value. Archive the rest from your old system as a flat export and keep it somewhere retrievable - you almost certainly will not need it, and if you do, you have it.
Can we run both systems at once?
Yes, and you should. Running parallel for one to two weeks is the single best risk reduction available: new requisitions open in the new system while in-flight candidates finish where they started. The rule that matters is that only one system takes new work at any moment. Two systems both accepting new candidates is not a parallel run - it is a data reconciliation problem you are creating on purpose.
What does migration cost?
It varies by vendor and by volume, and it is frequently quoted separately from the licence - which is why it belongs on your RFP. Ask specifically what is included, what is billed hourly, and what simply cannot be migrated at any price. The larger cost is usually not the invoice: it is recruiter attention during the changeover, which is why a tight scope on historical data pays for itself.
What happens to our SMS consent records?
Treat this as the highest-risk item in the whole migration. Opt-out state must transfer, or be re-established before you message anyone from the new platform. Sending to a candidate who previously opted out is a compliance failure regardless of which system holds the record. Confirm with both vendors - the one you are leaving and the one you are joining - exactly how consent state moves, and validate it on a sample in week one before any bulk send.
Planning a move?
Book a demo and we will walk your data inventory honestly - including the parts that will not transfer cleanly from anywhere.
30-day free trial · No setup fees · No long-term contracts