Migration and data quality
How to plan an ATS migration without losing relationship history
The records migrate easily. What gets lost is the context: why a candidate withdrew, what a client said, who owned the relationship. That loss is usually discovered three months later when somebody needs it.
Start with the export, not the destination
The most common migration failure is choosing a new system, signing, and only then discovering that the old one cannot export the thing you most needed. Reverse the order: get the export first, look at what is genuinely in it, and evaluate destinations against that reality.
Every major system exports candidates, companies, contacts, jobs and applications. What varies enormously is notes and activities, email bodies, attachments, stage history, ownership and custom fields. Those are the relationship history. Get a real sample export, not the documentation about one.
Audit what you actually have
Count the records per category and write the numbers down. This becomes your reconciliation baseline. Without it you cannot tell whether a migration succeeded; you can only tell whether it appeared to.
Then sample for quality: how many candidates have no email, how many companies are duplicates with different spellings, how many notes are attached to a record nobody can identify. A migration does not clean data. It moves it, faithfully, including the mess.
Decide deliberately what not to bring. Ten-year-old candidates with no contact details and no activity are not history, they are weight. Under the Australian Privacy Principles, holding personal information you no longer need is itself a decision worth making consciously.
Map before you move
Field mapping is where the meaning is preserved or lost. The mechanical parts (name, email, phone) map themselves. The judgement is in the rest: which of your six status values map to which stages, what happens to a custom field with no equivalent, whether a "consultant" is an owner or a note.
Insist on seeing the mapping before anything is created, and insist that rows land in a staging table first. A migration that writes directly into live records cannot be reviewed, only undone, and undoing it is rarely as clean as promised.
Ask how re-running works. If every importable record carries its source system and source id with a unique index on the pair, a re-run updates rather than duplicates, and "import, look, fix, import again" is a safe loop. Without that, every correction is a cleanup.
The dry run is the whole point
A dry run should produce two things: an exception report listing every row that could not be mapped and why, and reconciliation totals comparing records in the export against records created, per category.
Ask for the rows, not a count. "412 exceptions" is not reviewable. Four hundred and twelve rows with reasons attached are, and about half of them will turn out to be one mapping problem.
Then sample by hand. Pick twenty records you know well (a difficult client, a candidate with a long history, a placement that went wrong) and open each one next to its source. That is how you find the silent losses, and a totals match will not.
Cut over deliberately
Pick a date, freeze changes in the old system, run the final import, reconcile again, and go. A parallel-running period sounds prudent and in practice means the team maintains two systems badly and trusts neither.
Keep the old system readable for an agreed period. Not to work in: to check against. And keep your own copy of the source export files, independently of both vendors.
Agree in writing what happens to staged data afterwards, on what schedule, and ask for evidence of the deletion rather than an assurance about it.
What you should refuse to accept
A promise about a data category without a sample proving the source can produce it. Vendors are usually promising in good faith about their importer; the constraint is nearly always the export.
A migration that requires handing over your current system’s login credentials. A file export is enough, and credentials are not something to share.
A cutover with no reconciliation numbers, or numbers produced only after go-live. By then the disagreement is unwinnable.
Any arrangement where your data can be used for anything other than delivering your migration. Get that in writing, including that it will not be used to train models across customers.