ATS Migration for Recruitment Firms: What Actually Moves (And What You Lose)

Migration quotes are priced on records. Two hundred thousand candidates, forty thousand companies, a number per thousand.

But the records are not what makes your database valuable. What makes it valuable is the layer nobody counts: the note explaining why a candidate turned down an offer in 2021, the call log showing which client contact actually decides, the thread where someone learned that a firm will never sponsor a visa.

That layer is the first thing a migration loses, and the loss does not show up on any checklist.

This post covers ATS migration for recruitment firms: what moves cleanly, what arrives broken, what to establish before signing, and the sequence that keeps a switch from costing you a decade of accumulated context.

What actually moves

Structured fields move cleanly

Names, emails, phone numbers, job titles, company records, application dates, stage history. These live in defined fields with defined types, and every vendor can map them.

When a migration is described as taking four weeks, this is usually what is being described. It is the easy 70%, and it is genuinely fine.

Notes and attachments move badly

Notes usually arrive as one undifferentiated block of text per record, stripped of who wrote them, when, and against which job. A note that read as a clear timeline in the old system becomes a wall with no structure in the new one.

Attachments are worse. CVs often survive; the version history rarely does, so you keep the file and lose the fact that it was the third version and the second one was the one the client saw.

Email and call history frequently does not move at all

Most migrations do not carry the communication record, because it lives in an integration rather than in the database. The thread where terms were agreed, the call where a candidate explained what they actually wanted, the chain proving you introduced a candidate first: none of it is in the export.

That last one is not just knowledge. It is the evidence behind a fee dispute.

Why the loss stays invisible

Nobody notices on day one, because day one is spent checking that candidates and jobs are there. They are.

The loss surfaces three months later, when a recruiter searches for someone they remember placing, finds the record, and cannot work out what happened. Or when a client asks why you are approaching a candidate you agreed not to approach, and the note recording that agreement is gone.

The stakes are worth being precise about, because around 71% of placements come from candidates already in the database before the job opened (Source: The Economics of Recruiting). A migration is not a technical project. It is surgery on where most of your revenue comes from.

What to establish before you sign

• Ask to see a migration that included notes and call logs. Not a reference, a sample. Vendors who move structured data well will say yes quickly; the four-week claim usually applies to structured data only, and this question surfaces that distinction in about a minute.
• Ask about field mapping, not field count. “We migrate 300 fields” means nothing. What matters is whether your custom fields arrive as fields you can filter and report on, or as text appended to a note.
• Agree who cleans the data. Migration is the one moment when deduplication and field standardisation are cheap. Decide explicitly whether the vendor is doing it, you are doing it, or nobody is, because “nobody” is the default answer.
• Agree what rollback means. Not whether the old system stays available, but for how long, in what state, and who pays for it.

A sequence that works

1. Audit before you export. Run a database audit and find out what proportion of records have a reliable current employer, current title, and owner. Migrating badly populated fields produces a badly populated new system, and this is the only moment when fixing it costs nothing extra.
2. Freeze the schema. Stop adding custom fields a month before the move. Late additions are the most common cause of mapping errors.
3. Pilot one desk. Migrate a single team’s data first, and have those recruiters work it for a week against real searches. They will find in three days what a checklist misses entirely.
4. Run in parallel, briefly. Two weeks with both systems live, new activity in the new one only. Long parallel runs sound safer and are not, because data starts accumulating in two places.
5. Cut over on a quiet week. Not month end, not the week a large search is closing.

The knowledge that has no field

Even a clean migration leaves the same underlying problem, which is that the most valuable thing your firm knows was never in a field to begin with.

Why a candidate said no. Which hiring manager actually signs off. The market intelligence sitting in a consultant’s call notes from eighteen months ago. In most systems that material is technically stored and practically unreachable, which is why it feels lost after a migration even when it transferred.

AIRA Search reads across the notes, calls and transcripts your team has recorded rather than only the extracted fields, so that layer becomes searchable rather than archival. Every result cites the roles, companies and dates behind it.

That changes the question worth asking a vendor. Not just whether your notes will arrive, but whether anyone will be able to find anything in them afterwards.

Before you commit to a migration date

Pull fifty records at random and check what a recruiter could actually reconstruct from them: current role, why they were last rejected, who owns the relationship. Whatever you cannot reconstruct today will not improve by moving it.

Bring that sample to a demo and we will show you what the same records look like when the search reads the notes as well as the fields.

FAQs

How long does an ATS migration take?

Structured data usually moves in two to six weeks depending on volume and field complexity. Notes, attachments and communication history take considerably longer and are often quoted separately, so a single headline timeline is worth breaking down before you agree to it.

What data is lost when switching ATS?

Most commonly email and call history, note authorship and timestamps, attachment version history, and custom fields that arrive as unstructured text. Core candidate, job and company records almost always transfer intact.

Can you migrate notes and call logs to a new ATS?

Often yes, but rarely by default and rarely with structure preserved. Ask the vendor to show a completed migration that included them rather than accepting a general assurance.

Should you clean your database before or after migration?

Before. Migration is the only point where deduplication and field standardisation are effectively free, and moving unreliable records simply reproduces them in a new system.

How do you avoid disruption when changing ATS?

Pilot one desk before the full move, run both systems in parallel for no more than two weeks with new activity in the new system only, and cut over during a quiet trading week rather than at month end.

What should you ask an ATS vendor about migration?

Ask to see a sample migration including notes and call logs, how custom fields map and whether they remain reportable, who is responsible for data cleanup, and what rollback looks like in practice including duration and cost.