// Recruitment Technology, Migrations
Migrate Every Candidate Record, or Draw a Line?
Published: 15 September 2026,
9 min to read
The bottom line
Neither default survives contact with a real database. Importing twenty-five years of untouched records fills a new system with noise nobody will work. Starting clean deletes the client relationship history that makes your agency worth hiring.
Scope the move on four signals: contact recency, contactability, niche relevance, and attached commercial history.
Deciding what your agency carries into a new system
Every agency that has run an ATS data migration has sat through the same meeting. Someone asks how far back the export should go, and the room goes quiet.
The question gets deferred, then deferred again. It is finally answered by whoever holds the CSV that week. That is a strange way to decide what your agency remembers.
121 recruitment agencies have raised this with us on recorded calls, and the split is consistent. Half want every record moved on principle. The other half want a clean start and a database they can trust from day one.
Both positions are defensible. Applied literally, both produce a system the team stops trusting inside a quarter.
Why does migrating every candidate record hurt more than it helps?
Because record count and record value stopped correlating years ago. A full import from your current ATS carries the sediment across with the asset. The sediment is usually the larger share.
Candidate data ages faster than most agency owners assume. Consider that median US job tenure now sits at 3.9 years. A profile last touched in 2016 usually describes a job the person left two employers ago.
The cost is not storage. It shows up in every search your team runs afterward. A database is only worth what the search running across it can surface.
Recruiters work it out fast. When a search returns fifty names and forty are unreachable, they stop trusting the database. They go back to LinkedIn, which is the outcome the move was supposed to prevent.
That matters now that 56.16% of agency recruiters describe their tech stack as functional but fragmented. A migration is usually the moment an agency sets out to fix that.
A literal full migration carries the following into a brand new applicant tracking system:
- Duplicate person records stacked up by a decade of job board feeds and bulk imports
- Contact details that predate a phone change and a company acquisition
- Custom fields nobody can define without asking the one person who built them
- Candidate notes written against a workflow the agency retired years ago
What does a clean start destroy that you cannot rebuild?
Client relationship history, almost entirely. Candidate data decays on its own. Client history compounds, and none of it can be reconstructed from a CV.
Every agency has one spreadsheet that a single person understands and nobody is allowed to delete. A legacy ATS works the same way. There are four hundred thousand rows of it, and the person left in 2021.
Agencies lose least when their system was already capturing calls, emails, meetings and notes automatically. The relationship history then survives as structured records rather than inside a departed consultant’s inbox.
A candidate record going cold costs you one possible placement. A binned client record costs you the reason you won the account. What disappears with it:
- Which consultant owned the relationship, and what was agreed on fee and exclusivity
- Rebate periods, contract terms, fee splits, and the paper trail behind every placement
- Why a retained search stalled, and which hiring manager killed it
- Where those hiring managers moved next, which is your warmest business development list
- Every finisher on the contractor book and the week they came available
Which decision rules should scope your ATS data migration?
Score every record against four tests before anyone touches an export. Each is answerable from data you already hold. The pass runs during data discovery instead of becoming a six week debate.
Old data is not automatically dead weight. Globus Search ran an internal database for more than twenty years before moving to Atlas. The team now reports sourcing and updating candidates 4x faster, with placements up 22%. The history was the asset. The system holding it was what needed replacing.
Rebate and contract records also carry obligations that outlive the software holding them. Deleting those to tidy a migration is a decision your finance director should be in the room for.
Most of this is better run as a managed process than an internal project. In an enterprise database migration with Atlas, you review and sign off the field mapping yourself. The dataset then passes 30 to 40 automated tests per table, roughly 300 checks in total, before reaching production.
Atlas is an AI-powered CRM and recruitment platform that uses agentic AI to strip admin out of recruitment workflows. Records surviving your cut arrive indexed and searchable rather than dumped.
Run the scoring before data mapping rather than after it. Once you are mapping custom fields and candidate statuses, a new record filter means redoing signed-off work. Fold the pass into your ATS migration checklist at the discovery stage. These are the four tests:
- Last contact recency. A genuine two-way interaction inside 36 months migrates without debate. Between 36 and 60 months, the record needs a second qualifier. Past 60 months, it needs a reason.
- Contactability. At least one channel that plausibly still reaches a human. A personal email address outranks a work address at a company the person left in 2019.
- Niche relevance. Does the person sit in a vertical you still bill in? Candidates from a desk you closed are someone else’s asset now.
- Commercial history. Placed, interviewed, sent on spec, or attached to a live client record. These migrate regardless of age, because they carry context the record itself never shows.
How should you treat the records that fail every test?
Archive them rather than delete them. A cold tier sitting outside search and outreach gives you the clean database without the irreversible decision. Both camps can live with that compromise.
The purists keep their history. The recruiters get a database where opening a search result is worth the click.
Holding less live data also shrinks your compliance surface. Fewer records means fewer subject access requests to service and less sensitive data to defend.
The harder discipline starts the day after go live, because a clean database degrades from the first bulk import. Keeping it clean is a workflow problem more than a migration problem. Atlas grades every applicant against the role criteria, holding them outside the main database until a recruiter approves.
Worth reading how data decay quietly costs agencies their easiest placements before deciding the archive tier is optional. Four rules keep an archive useful rather than a graveyard:
- Export failing records to a flat archive your ATS provider does not need to index
- Keep placement, rebate, contract and fee records live regardless of candidate recency
- Set a review date instead of a delete date, then revisit it after two quarters
- Document what was excluded and why, so nobody relitigates it in month three
Frequently asked questions (FAQs) on ATS data migration
There is no universal cut-off. A workable default migrates anything with genuine two-way contact in the last 36 months. Add any record carrying placement, interview, client or contract history, regardless of age. Everything older should earn its place through contactability or niche relevance.
Migrate the notes and the correspondence. Structured fields tell you what a candidate is. Candidate notes and email history tell you what happened between you, and that cannot be re-derived from a CV. Modern platforms index free text and attachments, so historical data stays searchable.
A competent migration process catches duplicates during testing rather than after go live. Automated checks look for repeated email addresses, matching phone numbers, name plus employer combinations and near-identical CVs. Flagged records are merged before the data reaches production. Ask any ATS vendor to walk you through that step, because it is where most data quality problems begin.
Yes, and phasing is common for large datasets. A typical approach moves active roles, live clients, open shortlists and recent candidates first. Historical data follows in later passes once the team is working in the new system. The risk is running two systems in parallel for longer than planned, which doubles admin.
For most agencies the end-to-end process runs two to three weeks. That covers data discovery, mapping sign-off, transformation, automated testing and a staging review. Larger or heavily customized datasets take longer, usually because of custom fields and non-standard candidate statuses. Scoping decisions made early tend to save more time than they cost.
In practice it usually improves it. Search quality depends on the share of results that are reachable and relevant, not on total record count. Removing unreachable records raises the hit rate on every query. Keeping the excluded data in an archive means you can restore anything you later need.
The database you carry over decides your first quarter on the new system
Scoping an ATS data migration is a commercial decision wearing a technical costume. Records that pass on recency, contactability, niche relevance or commercial history earn their place. The rest can sit in an archive, costing you nothing and staying recoverable.
What makes that discipline pay is where the surviving records land. Candidate history, client history, call transcripts, email threads and live BD activity belong in one place. Split across a legacy ATS, an outreach tool, a reporting sheet and two inboxes, that history goes unused. One system turns a migrated database into something your team opens daily. That is what Atlas is built to be for agency recruiters.
Worth scoring your own database against the four tests before you ask any provider for an export.
You may also like
See all
// Recruitment Technology, Migrations
Why Most ATS Migrations Fail (and How to Avoid It)
From bad data to downtime, discover what causes ATS migrations to go wrong – and how Atlas helps recruiters avoid it all.
09/16/2025
10 MIN
// Recruitment Technology, Migrations
ATS Migration: 12 Costly Mistakes Recruitment Agencies Still Make (and the Fixes)
Moving ATS? Learn the 12 pitfalls that stall agencies—from data mapping to comms—and avoid them when migrating to a new system.
08/19/2025
12 MIN
