Migrations rarely fail on the technical move. Extracting records, mapping fields and loading them is scripted, repeatable and testable. What derails a go-live is arriving at migration week with decisions nobody has made — and they are the same four decisions almost every time.
Decide what not to bring
The instinct is to move everything. It feels safer and it postpones an argument. It is also how a new system inherits a decade of decay on day one: leads that went cold in 2019, fields three people filled in once, notes nobody has opened since they were written.
Decide the cut-off before anyone writes a mapping. A workable default is to bring every open record, every customer with activity in the last two or three years, and the master data behind them — and to archive the rest somewhere retrievable rather than loading it. Someone senior has to own that line, because the person who asks for "everything, just in case" is never the person who then works in the result.
Agree who settles a duplicate
Every migration surfaces the same customer three times — once from sales, once from finance, once from an old spreadsheet, each with a different spelling and a different phone number. The technical part is easy. The question that stalls projects is who decides which one survives.
Settle two things in advance: the matching rule, and the arbiter. The rule might be a registration number, a domain or a phone; whatever it is, write it down and test it against a sample before the full run. The arbiter is a named person with the authority to say which record wins when the rule cannot decide. Without that name, duplicates sit in a spreadsheet waiting for a meeting while the go-live date moves.
Attachments and history
This is the one that surprises people in go-live week. Records migrate cleanly, and then somebody asks where the signed contract went, or why an opportunity shows no history before the switch.
Attachments, notes, emails and audit history are usually separate problems from the records themselves — different volumes, different limits, sometimes different tools. Decide early what must come across, what can live in document storage with a link, and what is genuinely finished with. The volume is often larger than the record data by an order of magnitude, which is a timing problem as much as a technical one.
Reconcile before anyone logs in
A migration is not done when the load finishes. It is done when someone has proved it landed correctly, and that proof should exist before the team sees the system at all — because the first day of use is the worst possible time to discover a mapping error.
We reconcile on counts and on content. Counts: records by type, by owner and by stage, compared against the source. Content: a sample pulled by the client's own people, not by us, checking that the right values ended up in the right fields on records they recognise. Then the open pipeline is checked in full, because a wrong stage or a wrong owner on a live deal costs more than a wrong address on a dormant one.
It is also worth keeping the old system readable for a while after cutover. Not as a fallback to work in — that guarantees two systems in use — but so a question can be answered without an argument.
The short version
- Name the cut-off for what moves, and who owns that decision.
- Write the matching rule, and name the person who settles what it cannot.
- Decide what happens to attachments, notes and history, and size it early.
- Reconcile counts and content, with the client checking a sample, before anyone logs in.
Planning a move? Send us what you are migrating from and we will tell you where the effort actually sits — usually not where people expect.