Migrating a Candidate Database Without Losing What Makes It Valuable
Your database isn't the contact details. It's the years of notes about who's good, who's difficult and who's ready to move. Most migrations move the first and lose the second.
The reason agencies stay on software they dislike for years is the database. Everyone knows the current system is bad. Nobody wants to be responsible for the migration.
That fear is rational. A botched migration doesn't announce itself — it shows up six months later when a recruiter can't find out why a candidate was marked unsuitable in 2023, and the note is gone.
What's actually valuable in there
Not the contact details. Those are replaceable and half of them are stale anyway.
The value is the accumulated judgment:
- Notes. Ten years of "great on the phone, terrible in interviews," "will only take contract," "left the last place badly, check references carefully."
- Assignment and submission history. Who went where, at what rate, and what happened.
- Rejection reasons. Why a client passed. Enormously useful and almost never migrated properly.
- Relationship ownership. Which recruiter knows this person.
- Compliance records. Right-to-work documentation, certifications with expiry dates, background check dates.
- Do-not-contact flags. Opt-outs, people who asked not to be called, candidates you won't work with again. Losing these ranges from embarrassing to a legal problem.
A migration that moves names, emails and CVs while flattening the rest has technically succeeded and actually destroyed the asset.
The five things that go wrong
Notes get concatenated. The old system had dated, attributed, threaded notes. The new one gets one text blob per candidate with the dates run together. Still there, unusable.
History collapses to current state. Candidate shows as "placed" with no record of the four submissions before it, or which client, or when.
Duplicates multiply. Most old databases have the same person three times from different sources. A migration that doesn't dedupe carries all three across, and now a recruiter sees three records with different notes on each. Deduping badly is worse — merge two people who share a name and you've corrupted both.
Custom fields don't map. Every agency has fields it invented. Some matter enormously and some are dead. Nobody works out which before migration day, so either everything comes across as unusable extra columns or things get dropped that shouldn't.
Compliance data loses its dates. A certification without an expiry date is not a certification. Right-to-work with no check date can't be audited.
How to do it properly
Audit before you move anything. Export what you have and look at it. How many records? How many with an email? How many touched in the last two years? How many duplicates? Agencies routinely discover that a "50,000 candidate database" is 18,000 real people, most untouched since 2019. That's not bad news — it's the difference between a hard migration and an easy one.
Decide what's dead. Records with no contact in five years, no email, no notes. Archive rather than delete, and don't let them dilute the working database. Search results full of ghosts is how recruiters lose trust in a new system in week one.
Map fields deliberately, with a recruiter in the room. Not the office manager and not the vendor. Someone who uses the data daily, going field by field, deciding what maps where and what gets dropped. Half a day, and it prevents most of the failures above.
Preserve notes as notes. Individual, dated, attributed. If the new system supports a notes collection, use it. If your only option is a single text field, at least keep the dates and authors legible.
Dedupe conservatively. Match on email first — highest confidence. Then phone. Name-only matches get flagged for a human, never merged automatically. Better to carry a few duplicates than to fuse two people.
Migrate twice. A test run into a sandbox, checked properly, before the real one. In the test, pull twenty records you know well and confirm the story is intact — not that the fields are populated, that a recruiter reading it would understand the history.
Run parallel briefly. Old system read-only for a few weeks. When something looks wrong, you can check. That safety net is what lets a team commit to the new system instead of hedging.
The consent piece
Migration is when suppression lists get lost, and that's the one with actual consequences.
Opt-outs, do-not-contact requests and deletion requests all have to survive. If someone asked not to be contacted in 2024 and gets a marketing email the week after your migration, that's a complaint and potentially a regulatory issue.
Move these first, verify them separately, and don't switch on any outreach until you've confirmed the suppression list is intact.
Sequence that works
- Export and audit
- Decide the archive cut
- Field mapping with a real recruiter
- Migrate suppression and compliance data, verify independently
- Test migration into a sandbox
- Twenty-record read-through by someone who knows the data
- Fix, re-run
- Real migration, old system read-only
- Two to four weeks parallel
- Decommission
Two to three weeks of elapsed time for most agencies. The temptation is to skip five through seven. Those are the steps that make the difference between a migration and an incident.
The honest caveat
Some loss is unavoidable. Old systems store things in ways that don't map cleanly, and chasing 100% fidelity on a database that's 40% dead records is a bad use of a fortnight.
Get the working core across perfectly — active candidates, recent history, all compliance, all suppression. Accept some degradation in the archive. Know which is which, and tell the team, so nobody discovers it on their own and stops trusting the whole thing.
We migrate candidate databases into custom-built systems for US recruiting agencies, history intact. See how it fits together, or tell us what you're on now.