How to Migrate Your ATS Without Losing Candidate Data

A mid-sized recruitment agency lost eleven months of candidate history during a rushed ATS migration in early 2026, discovered only when a client asked for a shortlist the team had supposedly already screened the year before. That story is common enough that it deserves a proper how to migrate your ats playbook, not a weekend of exporting spreadsheets and hoping for the best. Done properly, an ats migration protects every CV, note and hiring decision a team has ever made.

Quick Answer

Migrating an ATS without losing candidate data means auditing and cleaning existing records before export, mapping every field to its new home, running both systems in parallel for at least one full hiring cycle, and verifying record counts before decommissioning the old system. Rushing any of these four steps is the single biggest cause of lost or corrupted candidate data.

What You'll Learn in This Guide

• How to audit existing candidate records before touching the export button
• The exact field-mapping process that prevents silent data loss
• Why a parallel-run period matters more than the migration date itself
• How to verify data integrity once the new system is live
• What to do if something goes wrong mid-migration

Why ATS Migration Matters

Candidate data is not just historical record-keeping; it is the evidence a hiring team relies on to avoid re-contacting candidates who already turned down an offer, to prove compliance with data retention rules, and to give recruiters the context they need to move quickly on a re-opened role. According to CIPD's Resourcing and Talent Planning research, 41% of organisations that hired in the past year reported new recruits resigning within the first twelve weeks, and teams without reliable historical data on why previous hires from a similar pool did not work out end up repeating avoidable mistakes. A poorly executed migration does not just cost time; it quietly erases the institutional memory a hiring team has built up over years.

The financial stakes are real too. SHRM's benchmarking work puts the average cost per hire at $4,129, and losing the historical data that helps a team avoid repeating a bad hiring decision effectively erodes that investment retroactively. McKinsey's HR Monitor has also tracked offer acceptance rates improving by roughly three percentage points and overall hiring success by around four percentage points year over year, gains that are considerably harder to sustain when a migration wipes out the pipeline history recruiters use to calibrate their approach with each new role.

Step 1: Audit Every Data Source Before You Touch Export

Before any export begins, list every place candidate data actually lives, not just the obvious CV records inside the current ATS. This usually includes interview scorecards, recruiter notes stored in email threads, offer letters generated outside the system, reference check documents, and any spreadsheet a hurried hiring manager built on the side during a busy quarter. Most data loss during migration happens not because the ATS export failed, but because nobody realised a chunk of relevant data was never inside the ATS at all.

Build a simple inventory: source system, record type, approximate volume, and who owns it. For a company with a few hundred historical candidates this might take half a day; for a recruitment agency with tens of thousands of records across several years, budget closer to a full week. What good looks like here is a written inventory that a second person on the team can review and sign off on, not a mental list held by whoever happens to run the export. LinkedIn's own research into hiring trends, which draws on survey data from more than 14,000 global professionals, has repeatedly found that recruiters underestimate how much day-to-day context lives outside the core system of record, which is exactly the blind spot this inventory step is designed to close.

Step 2: Map Every Field Before You Export a Single Record

Field mapping is where most ats migration projects quietly go wrong. Every ATS structures candidate data slightly differently: some store a candidate's stage as free text, others as a fixed pipeline value; some keep notes as a single long field, others as timestamped entries tied to individual users. Before exporting anything, build a mapping table listing every field in the old system, its data type, and exactly where it will land in the new one, flagging any field that has no clean home in the destination system.

Fields with no obvious destination are the ones that get silently dropped, so decide deliberately whether to keep them as custom fields, fold them into notes, or archive them separately rather than letting the migration tool make that decision by default. What good looks like: a completed mapping table reviewed against a small sample export before the full migration runs, catching mismatches while they are still cheap to fix.

Step 3: Run a Test Migration on a Small, Representative Sample

Never run a full migration as the first attempt. Select a representative sample, ideally 50 to 100 candidate records spanning different pipeline stages, data ages and completeness levels, and migrate that sample first. This surfaces edge cases a clean full-data test would hide: candidates with special characters in their names, records missing a required field in the new system, or duplicate entries the old ATS tolerated that the new one rejects outright.

Compare the sample's record count, field values and attachments line by line against the source system. What good looks like: zero unexplained discrepancies in the sample, or a documented reason for every single one before scaling up to the full dataset.

Step 4: Migrate in Batches, Not One Giant Export

Once the sample test passes, migrate the full dataset in batches rather than a single massive transfer, ordering batches by data age or business priority so that the most actively used records land first and get the earliest verification attention. Batching also makes it dramatically easier to isolate a problem if something goes wrong partway through; a failed batch of 500 records is a manageable rollback, whereas a failed transfer of 50,000 records is a genuine crisis.

Keep a migration log recording batch number, record count attempted, record count confirmed, and any errors thrown, so the whole process is auditable after the fact. What good looks like: every batch logged with a matching before-and-after count, no batch left unverified.

Step 5: Run Both Systems in Parallel for a Full Hiring Cycle

This is the step teams are most tempted to skip under deadline pressure, and it is the one that catches the problems batch verification cannot. Keep the old ATS accessible in read-only mode and run live hiring activity through the new system for at least one complete hiring cycle, ideally two, so that recruiters using the new system in real conditions surface any gaps the technical migration missed: a broken email template, a missing custom field a specific team relied on, or a report nobody thought to test until month-end. Best-in-class ATS migrations budget six to twelve weeks between the first data audit and full cutover, and treating that timeline as a compressible afterthought is where most avoidable data loss actually happens. SHRM's benchmarking research has repeatedly placed average time-to-fill at around 42 days industry-wide, which gives a useful reference point: a single hiring cycle for parallel-run purposes should be measured against that real-world figure rather than an artificially shortened internal target.

What good looks like: recruiters confirming, in writing, that they can perform every task they previously did in the old system using only the new one, before the old system is switched off.

Step 6: Verify Data Integrity With Independent Spot Checks

Once the parallel-run period ends, run an independent verification rather than trusting the migration tool's own success report. Pick a random sample of records across different ages and pipeline stages and manually confirm that CVs, notes, stage history and attachments all match the source system exactly. It is worth having someone who was not involved in building the migration perform this check, since a person too close to the process is more likely to overlook the exact gap they inadvertently created.

A parallel-run period long enough to cover two full hiring cycles is generally what it takes to catch the intermittent issues that a single spot check right after cutover would miss entirely. What good looks like: a signed-off verification report, not a verbal assurance that "it all looks fine."

Step 7: Keep the Old System Live in Read-Only Mode Before Decommissioning

Do not delete or cancel the old ATS the moment the new one goes live, however tempting that is for cost or tidiness reasons. Keep it accessible in read-only mode for a defined retention window, typically three to six months, so that any gap discovered after cutover can still be checked against the original source. Cancelling the old contract too early is one of the few migration mistakes that genuinely cannot be undone once the vendor deletes the underlying data.

What good looks like: a written decommissioning date agreed in advance, tied to a specific verification milestone rather than an arbitrary calendar date chosen for budget reasons.

Step 8: Document the Whole Process for the Next Migration

Every detail of the migration, from the initial data inventory through field mapping decisions to the final verification report, should be written down somewhere the next person doing this will actually find it. HR technology moves fast enough that most companies will migrate systems again within a few years, and a well-documented playbook turns a stressful multi-week project into a far more predictable one the second time around. Include the reasoning behind each judgement call, not just the outcome; a mapping decision that made obvious sense at the time is rarely obvious to whoever inherits the same job in three years without that context attached.

Common Pitfalls

Treating the export button as the whole migration. Exporting data is the easy ten percent of the job; mapping, verifying and running parallel systems is the other ninety percent that actually protects candidate data.

Skipping the parallel-run period to hit an arbitrary go-live date. A migration that looks complete technically but has not been used by real recruiters under real conditions has not actually been tested.

Assuming the migration vendor's success report is sufficient verification. Vendor tools report what they successfully transferred, not what silently failed to map at all; independent spot checks catch the difference.

Cancelling the old system's contract immediately after cutover. Keeping read-only access for a few months costs far less than losing access to source data the moment an unnoticed gap surfaces.

Not inventorying data that lives outside the ATS itself. Recruiter notes in email, offline scorecards and side spreadsheets are exactly the records most likely to be forgotten and never migrated at all.

Tools That Help

A clean ATS migration is mostly a process discipline problem rather than a tooling problem, but a few tools make it considerably easier. Most modern ATS platforms include a native import tool that handles standard CSV field mapping, which is sufficient for smaller migrations under a few thousand records. CIPD's research found that 78% of organisations increased their use of recruitment technology in the past year, with 31% now using some form of AI or machine learning, up from 16% in 2022, so a migration is often the moment a team also adds a screening tool it had been putting off.

For CV-heavy migrations specifically, Klearskill can re-screen an entire migrated CV database against current role requirements once the migration completes, which is a useful independent verification step in its own right: if Klearskill's AI screening produces sensible, consistent rankings against the migrated data, that is a strong signal the underlying CV content and structure survived the move intact. Worth noting: Gartner's 2025 research found that only 26% of job applicants currently trust that AI will fairly evaluate them, which is exactly why any AI re-screening used to verify a migration should produce explainable, reviewable rankings rather than an opaque score nobody on the team can defend.

Frequently Asked Questions

How long does an ATS migration usually take?

Most ats migration projects take between six and twelve weeks from the initial data audit through to full cutover, depending on data volume and how many external sources need to be folded in. Rushing this timeline to hit an arbitrary deadline is the most common cause of lost or corrupted candidate records.

What is the biggest risk of migrating ATS systems?

The biggest risk is silent data loss: fields that do not map cleanly between systems simply disappear without an error message, and nobody notices until months later when a recruiter goes looking for a record that is no longer there. A thorough field-mapping review before export is the single best defence against this.

Should I run the old and new ATS at the same time?

Yes. Running both systems in parallel for at least one full hiring cycle, ideally two, is the most reliable way to catch gaps that a technical export test alone would miss, since real recruiters using the new system under live conditions surface problems automated checks cannot.

Can I migrate candidate data myself without a specialist?

Smaller migrations, under a few thousand records with a single data source, are often manageable in-house by following a disciplined audit, map, test, verify process. Larger or messier migrations, particularly ones spanning several systems and years of data, usually benefit from a specialist who has handled the specific systems involved before.

What happens to candidate data if I do nothing and let the old ATS contract lapse?

Most vendors delete underlying data within a defined window after a contract ends, and that deletion is typically irreversible. If a migration has not been fully verified before the contract lapses, any gaps discovered afterwards cannot be fixed because the source data is simply gone.

Do I need to tell candidates their data is being migrated?

Depending on the jurisdiction and how the original data was collected, updating a privacy notice or informing candidates of a change in data processor may be a compliance requirement rather than an optional courtesy. It is worth checking this against local data protection rules before migration rather than after.

How do I know the migration actually worked?

The clearest sign is a completed independent verification: a random sample of records checked field by field against the source system, plus a full hiring cycle of real recruiter use with no missing functionality reported. A migration tool's own completion report is a starting point, not proof.

Stop Screening CVs Manually in 2026

Once candidate data survives the move, Klearskill turns that migrated CV database into a working asset again, delivering 97% AI screening accuracy and a 92% reduction in manual review time. Two plans, both unlimited on jobs and candidates: Starter at $10 a month with your own AI key, or Pro at $50 a month with AI included. Start free at Klearskill with 1 job and 25 CVs screened, no card needed.