How to migrate your ATS without losing your database

Ask an agency owner why they are still on a system they complain about weekly and the answer is almost never price. It is the database. Fifteen years of candidate records, client history, notes, and relationships live in there, and the fear of losing any of it is enough to outweigh a great deal of daily friction.

That fear is rational. Migrations do go wrong. But they go wrong in a small number of predictable ways, and none of them are mysterious. What follows is the sequence that works, in the order it needs to happen.

Start by deciding what not to bring

The instinct is to move everything. It is the wrong instinct, and indulging it is the single most common cause of a migration that drags on for months and lands in a state nobody trusts.

Most agency databases are substantially dead weight. Candidates who have not been contacted in six years, whose email addresses bounce and whose phone numbers belong to someone else. Companies that no longer exist. Job orders from 2018 that were never closed out. Duplicate records — often three or four versions of the same person, created by different consultants from different CV uploads.

Bringing all of that across achieves two bad outcomes: you pay to migrate data with no value, and you import the mess into a clean system, where it immediately degrades search quality and matching accuracy. Every stale duplicate is a record that will surface in a shortlist and waste someone's time.

So the first task is a data inventory, and the honest version of it:

• Candidate records, bucketed by last meaningful activity — contacted, placed, or updated within 12 months, 12–36 months, and older.
• Companies and contacts, flagged by whether there is a live relationship.
• Open job orders, which must all migrate, and closed ones, which mostly need only summary retention.
• Placements, which you almost always keep in full — they are your commercial history and your rebate liability.
• Notes and attachments, which are usually the largest volume and the hardest to map.

The decision on the oldest bucket is a business one, not a technical one. There is a strong case for archiving rather than migrating anything with no activity in three years, and a compliance case too — see the retention section below.

Clean before you move, not after

Every migration guide says this and almost nobody does it, because cleaning is boring and the new system looks exciting. But the sequencing genuinely matters: it is far easier to standardise data while you still have one system, one set of conventions, and full institutional memory of what the odd values mean.

The work is unglamorous. Consistent formats for phone numbers and locations. Category values reconciled — if three consultants used "Snr Developer", "Senior Dev", and "Sr. Software Engineer", pick one. Legacy status codes that no longer mean anything, retired. Free-text fields that were used as de facto structured fields, extracted properly.

Deduplication deserves its own pass. Duplicates in a recruitment database are rarely exact matches — the same person appears under a personal and a work email, or with a maiden name, or with a nickname. Naive matching on email address alone will miss most of them. Whichever tool you use, run the dedup pass, review a sample of the proposed merges by hand, and only then run it at scale. Merging two people who happen to share a name is much worse than leaving a duplicate.

Map the fields before anyone touches an export

Field mapping is where migrations quietly break. The source system has fields the target does not, the target has fields the source never populated, and both have fields with the same name and different meanings.

Build the mapping as an explicit document, field by field: source field, target field, transformation rule, and what happens when the source is empty. Have someone who actually uses the system daily review it, because they will spot the field that nominally holds "availability" but that the perm team has been using for notice periods and the contract team for start dates.

The fields that cause the most pain are almost always the same ones. Ownership — which consultant a candidate or client "belongs" to — because the models differ between systems and the answer has commission implications. Custom fields, which are frequently undocumented. And the relationship between candidates, applications, and job orders, where systems differ in whether a person can be linked to a role more than once.

Attachments and notes: the volume problem

CVs, contracts, right-to-work documents, and interview notes usually account for most of the storage and most of the migration time. Two questions decide how hard this is.

First, does the target system re-parse CVs on import, or does it carry the source system's parsed data across? Re-parsing generally produces better structured data — parsers have improved enormously — but it also means the structured record may differ from what your team remembers, which is worth flagging before go-live rather than after.

Second, do notes carry their author and timestamp? A migrated note that reads "spoke to candidate, keen on the role" with no date and no author is close to worthless. If the target cannot preserve attribution, that is a material limitation and you should know about it before you sign.

Retention is a decision you are already making

Migration forces a data-protection question that most agencies have been deferring. Under GDPR and equivalent regimes you should not hold personal data indefinitely without a basis, and "we might place them one day" weakens the longer the record sits untouched.

The practical upshot is that a migration is the natural moment to implement a retention policy — because you are already segmenting the database by activity to decide what to bring. Archive or delete what you cannot justify holding, document the rule you applied, and start the new system clean. Doing it now is far cheaper than doing it later across a live system, and it makes the migration itself smaller.

Run both systems in parallel — briefly

The riskiest go-live is a hard cut-over on a Monday morning. The safest is a short overlap with a clear rule about which system is authoritative for what.

A pattern that works: migrate everything, then run a validation period of one to two weeks where the new system is authoritative for all new activity and the old one stays available read-only for reference. Do not run dual entry — it will not survive contact with a busy week, and the moment one system is stale, nobody trusts either.

During validation, check the things that will actually be used:

1. Pull up ten candidates you know well. Is the history there, attributed, and readable?
2. Open every live job order and confirm the pipeline, the submitted candidates, and their stages are correct.
3. Run the searches your team runs daily and compare the results to what the old system returned.
4. Check that placements, rebate dates, and invoicing data reconcile against your finance records.
5. Have each consultant sign off on their own accounts and candidates. They will spot problems a project manager never could.

Only after sign-off should the old system be decommissioned — and export a full archive before you switch it off, regardless of how confident everyone is.

The mistakes that cause the horror stories

Almost every migration failure traces to one of five things: migrating before cleaning, skipping the field mapping and letting the vendor guess, assuming live roles will survive automatically, giving nobody clear ownership of validation, or going live in a peak week with no fallback.

The fifth is the most avoidable and the most damaging. Do not migrate in your busiest month. The team will be too stretched to validate properly, and problems will be discovered by a client rather than by you.

What to ask a vendor before you commit

Migration quality varies enormously between vendors, and the difference rarely shows up in a demo. Ask specifically: who performs the migration, and is it included or charged? What is the field-mapping process and who signs it off? Are notes migrated with author and timestamp intact? How are duplicates handled, and do you get to review merges? What happens to attachments? Is there a trial import you can inspect before the real one? And what is the rollback plan if validation fails?

A vendor who handles migration as a structured part of onboarding, with a named owner and a validation step, is offering something materially different from one who sends you a CSV template. That difference is worth more than a discount.

Placr handles migration as part of onboarding for exactly this reason — the switch from Vincere page walks through the sequence for one common source system, and the comparison pages cover how the established platforms differ on data export. If you are still deciding whether to move at all, ATS vs recruitment CRM is the better place to start.