// Recruitment Technology, Migrations

Nine Things That Break Silently When You Import Candidate Data

What breaks quietly when you move candidate records

A migration that loses records is obvious within a day. A migration that keeps every record and changes what it means is the expensive one. It can run for months before anyone links a missed placement to the import.

That second outcome is the common one. An ats data migration clears its own tests because import tooling checks structure. Row counts, required fields, unique keys, file types: all present, all correct. The report then says every record transferred. That is technically true. It is also close to useless as a measure of whether your database still works.

Migration and data mapping came up in recorded conversations with 75 different recruitment agencies. The pattern held. Nobody reported losing their database. They reported searches that returned too few people, client contacts sitting in candidate pools, dates that made no sense, and CVs nobody could open. The damage was granular and expensive.

What follows is the nine failure modes behind most of that damage. Each one comes with the test that catches it while a fix is still free.

Nine candidate data import failures to test before you cut over

1. Dates that default to January 1
2. Full names that never split
3. Phone numbers rejected on import
4. Location fields dropped or flattened
5. Opt-outs and consent flags lost
6. Candidates that should have been contacts
7. Notes stripped of author and date
8. Attachments orphaned from their records
9. Custom fields and statuses flattened

1. Dates that default to January 1

Empty or unreadable date values rarely arrive empty. They arrive as January 1, either of the record’s creation year or of the year the import ran.

The cause is format rather than corruption. Your old ATS exported DD/MM/YYYY and the new one read MM/DD/YYYY, or the reverse. ISO 8601 exists because 01/05/22 can mean January 5 or May 1. A script has no way to know which one your data meant. Values above the twelfth day of a month throw an error and get skipped. Values below it convert quietly into the wrong month.

The cost lands on the fields tied to revenue: availability, contract end dates, rebate period expiry, last contacted. Say every assignment now appears to have ended on January 1. Your contractor book cannot tell you who finishes next month. Nobody calls them, and a finisher you already placed goes back to market through a competitor.

Test it by sorting every date field ascending and descending in staging. Count the records sitting on January 1 and on the import date. Compare that number against the count of blanks in the source system. If the target holds fewer blanks, the difference became fiction.

2. Full names that never split

Older systems often store a single display name. Newer platforms want a first name and a last name. The split usually happens on the first space in the string.

That works for Jane Smith. It fails for compound surnames, middle names, titles, post-nominals, and anything exported as Surname, First. It also fails without complaint. A last name field containing FCIPD is a populated field, and it passes every required-field check.

Then outreach runs. The first name token is what personalizes a campaign. A merge field opening with Hi Dr. Sarah Whitfield-Obi FCIPD is the kind of message a candidate screenshots and forwards. Name parsing also feeds deduplication. A system that cannot split names holds four versions of the same person and matches none of them.

Test it by querying every candidate record where the last name is blank, holds a comma, or holds a space. Read 50 across the alphabet, weighted toward placed candidates. Then generate one outreach preview per segment and read the greeting line before anything sends.

3. Phone numbers rejected on import

Phone fields validate on entry, and a strict validator drops the value rather than repairing it. The record still lands. The number does not.

Four things reliably break numbers on the way across. Leading zeros vanish when a column is read as numeric. Country codes written as +44 (0)20 parse as two separate numbers. Extensions share a cell with the main line. Two numbers sit in one field, divided by a slash, and the international numbering plan does not anticipate that.

A candidate with no working mobile is not a workable candidate. Candidate control starts with reaching someone before the counter-offer does. Lose 8% of your mobile numbers across 90,000 records, and several thousand conversations leave your pipeline.

Test it by counting non-null mobile values in the source export and in staging. Then dial 20 at random from the migrated set. Search the target for values in scientific notation as well. That is what a phone number becomes after somebody opens the export in a spreadsheet to check it.

4. Location fields dropped or flattened

Free-text location has no structured equivalent in most modern platforms. It lands in a notes field, or nowhere at all.

This failure hides better than the others. A radius search that should return 340 candidates near Manchester returns 40. The system reports success both times, because an empty result set is a valid result set. Recruiters then conclude the market is thin and go sourcing for people they already own.

Location also anchors market mapping and every talent pool you rebuild after cutover. Postcode data, remote flags, right-to-work status, and travel radius often live in custom fields. A default mapping treats those as optional. Agencies then find they cannot search their recruitment database by the attribute clients care about most.

Test it by choosing five locations that carry your busiest desks. Run identical radius searches in the current ATS and in staging, then compare counts. A gap of a few percent is normal drift. Anything larger is a mapping problem you can still fix.

5. Opt-outs and consent flags lost

Opt-out status usually lives as a row in a communications or preferences table. It is rarely a field on the person record. Those tables are the first thing cut from a core data migration, so the record arrives marketable and wrong.

The exposure here is legal rather than cosmetic. Under FTC guidance, you must honor a recipient’s opt-out request within 10 business days. Each non-compliant commercial email carries penalties of up to $53,088. An import that revives a suppressed contact and adds them to a nurture sequence has a per-message price.

Consent records for sensitive data carry the same risk in reverse. Some candidates agreed to contract work only. Others asked to be kept out of one client’s pipeline. Both instructions vanish the moment the preferences table is skipped.

Test it by exporting the suppression list yourself before you leave the old system. Keep your own copy of that file. Reconcile it line by line against the unsubscribed count in staging. Then run your first outreach campaign against a segment of 200 rather than the whole database.

6. Candidates that should have been contacts

Most exports contain one people table. Record type is inferred from a column the mapping treats as optional. Client contacts then arrive as candidates.

Nothing errors. The count is right and the fields are populated. The record simply means something different than it did on Friday.

Consequences surface on the desk within weeks. Key account contacts sit inside candidate pools. BD lists come back short of people you have known for years. Eventually a hiring manager receives a spec CV addressed to them as a candidate. Reporting compounds it, because your database looks larger and your contact book smaller than either really is. Forecasting off a distorted AI-powered CRM is guesswork with better formatting.

Test it by reconciling record counts by type on both sides before sign-off. Then walk your top 20 key accounts. Confirm each company has its contacts attached, with the right owner and the right link to live roles.

7. Notes stripped of author and date

Notes usually survive an import. The metadata wrapped around them often does not. Ten years of activity then arrives as one undated block of text per record.

The words survive and the sequence does not. You lose sight of which consultant owns the relationship. You lose the date anyone last spoke to the candidate. You lose the call that produced the salary expectation you are about to quote. Ownership questions then get settled from memory, which is a poor system of record.

Last-contacted dates carry a second cost. When they reset to the import date, a dormant database reports itself as freshly worked. Data decay stays hidden until a recruiter dials a number that stopped working two years ago. Interview notes lose their anchor in time too, which matters when a candidate reappears on a new brief.

Test it by opening 20 long-tenure candidate records side by side in both systems. Compare the note count, the authors, the timestamps, and the linked roles. If authorship has collapsed into a single service account, raise it before cutover.

8. Attachments orphaned from their records

Documents move as a separate job, keyed on record IDs. Any ID that changes along the way leaves the file in storage with nothing pointing at it.

The CV still exists somewhere. No recruiter can reach it. For the purpose of sending a shortlist on Thursday afternoon, that amounts to the same thing.

Version order is the other half of this failure. When upload dates do not carry across, the 2019 CV can become the primary document. It then goes to a client under your agency’s brand. Signed terms and contractor paperwork deserve the same scrutiny. Those are the documents you need on the day a fee gets disputed.

Test it by comparing attachment counts per record type on both sides. Open the newest document on 25 records chosen at random. Check separately that signed terms are still attached to the client records behind your PSL positions.

9. Custom fields and statuses flattened

Custom fields and status labels are where your process lives. They are also the least portable part of any dataset.

Placed, in rebate period collapses into Placed. Do not use, client request collapses into a generic rejected value. Both mappings are defensible in isolation and useless on a live desk. The distinction they erased was the reason the field existed.

Owner fields are the expensive case. When consultant ownership defaults to whoever ran the import, billing attribution starts from zero. Every dashboard built on it then reports a team of one, which makes for an interesting commission conversation. Reliable analytics and dashboards depend on ownership and candidate status values surviving intact.

Test it by pulling a distinct count of every status and owner value on both sides. Values present in the source and absent in the target were mapped away. Values present in the target and absent in the source were invented by the import.

Why does an ATS data migration break quietly instead of failing loudly?

Because import tooling validates structure and never meaning. Keys, counts, formats, and file types all pass their checks. Nothing in that stack knows 01/02/2024 meant February 1. Nothing knows the person in row 4,812 is a hiring manager at your second-largest account.

Fragmented tooling makes it worse. 56.16% of agency recruiters describe their technology setup as functional but fragmented. Another 19.18% name poor system integration as their biggest operational drag. Data spread across several tools carries several formats. Every migration is then a merge as well as a move, and data integrity questions multiply with each source.

The other reason is who does the checking. Data review lands on whoever has capacity, usually an operations lead with a spreadsheet and two weeks. The recruiters who would spot a missing availability date instantly are billing. Sign-off happens on totals, because totals are what the report offers.

Some agencies decide the honest answer is to carry less. Attis moved to an AI-first platform after a market pivot. They chose to rebuild rather than migrate, brought across only what mattered, and won 35% more clients. Carrying nine years of unverified historical data into a new ATS system is a decision. It should not be one you inherit from a default mapping.

How do you test a migration before your team officially transitions?

In a staging environment that behaves like production, with counts reconciled field by field. Then the recruiters who use those records daily open a sample of them. Verification by the people whose billings depend on the data finds what a totals report never will.

The sequence below is what a defensible data review looks like on a mid-to-large agency database.

Hundreds of automated checks before anything reaches production is what a serious migration process looks like from the vendor’s side. That is how it runs at Atlas, an AI-powered recruitment platform that uses agentic AI to take admin off recruiters. Between 30 and 40 tests run per table, adding up to 300 or more across a full dataset. You review and sign off the mapping yourself before any transformation begins. Staging then looks and behaves exactly like the live product. Attached files, including CVs and contracts, are linked back to the right records so nothing is orphaned.

For the full process, our migration walkthrough for agencies covers what happens at each stage. The shorter ATS migration checklist is a reference to work through with your current ATS provider.

1. Take a row count per table from the source system before anything moves, and keep that file yourself.
2. Reconcile counts field by field in staging, not record by record in production after go-live.
3. Have two recruiters from different desks each open 25 records they know personally.
4. Re-run four saved searches your team uses daily and compare result counts against the legacy ATS.
5. Reconcile the suppression list, then send the first campaign to a small segment.
6. Sign off table by table in writing, with a named owner for every open question.

What should you ask a migration vendor before you commit?

Ask questions whose answers are numbers or documents. A vendor who shows you the mapping and the test results is describing a repeatable process. One who answers with reassurance is describing a hope.

Work through these with any ATS vendor you shortlist. Ask for the answers in writing rather than on a call, and share them with your key stakeholders before sign-off.

• Which tables are in scope, and which are excluded by default?
• How are ambiguous dates parsed, and which format does the script assume?
• How are single-field names split, and what happens to titles, suffixes, compound surnames, and names entered in reverse?
• Where do opt-outs, consent records, hard bounces, and communication preferences land in the new system?
• How is record type decided for someone who is both a candidate and a client contact?
• Do notes keep their original author and timestamp, or the import date?
• How are attachments relinked, and what is the plan for files whose parent record ID changes?
• Which custom fields and status values are being merged, and can we see that mapping before it runs?
• How many automated tests run per table, and do we receive the results?
• Who signs off, on what document, and what is the remedy if we find a problem after go-live?

Frequently asked questions (FAQs) on ATS data migration

Why the cheapest migration is the one you tested

Every failure on this list is cheap to catch in staging and expensive to find in production. Dates, names, numbers, locations, opt-outs, record types, notes, files, and status values are all testable in advance. None of them announce themselves once your team is live.

So the choice is a commercial one. Two weeks of structured verification sits on one side. On the other sits a year of quiet losses: searches that under-return, contacts nobody calls, finishers who go back to market, and opt-outs you cannot prove you honored. One cost is scheduled and visible. The other compounds while everyone assumes the database is fine.

Agencies choosing a platform this year are pricing that difference, whether they name it or not. A provider’s approach to an ats data migration tells you which side of it you land on. At Atlas, the mapping, the automated checks, the staging sign-off, and the file relinking are part of the product rather than a project you survive. Teams arrive on the new system with their history, contacts, consent records, and documents intact. Worth a look before a renewal date makes the decision for you.