The Data Migration Checklist: Switch Systems Without Losing Data

A data migration is one of those projects that looks finished long before it actually is. The records appear in the new system, everyone celebrates, and three weeks later someone notices half the historical notes are missing or the dates are a month out. By then it's painful to fix. Here's the checklist we work through to stop that happening.

Before you move anything

1. Profile the source data first. You can't migrate data you don't understand. Count the records, check the formats, find the blanks, spot the duplicates. Surprises found now are cheap; surprises found after go-live are not.

2. Agree what "done" looks like. Define the success criteria up front: which fields must come across, what counts as a complete record, and how you'll prove it worked. A migration without an agreed definition of done never really ends.

3. Build a field-level mapping document. Every source field should map explicitly to a target field, with the transformation rules written down. This is the single most valuable artefact of the whole project — and the one most often skipped.

During the move

4. Transform deliberately, not on the fly. Date formats, phone numbers, picklist values, currencies — these rarely match between systems. Decide the rules in advance and apply them consistently, rather than fixing things ad hoc as they break.

5. Handle the awkward cases on purpose. Records with missing required fields, duplicates, and "orphaned" data with no obvious home will exist. Decide what happens to them before the migration, not in a panic during it.

6. Run a trial migration. Always do a full dress rehearsal into a test environment first. The first run always teaches you something the planning didn't.

The goal of a migration isn't to move data. It's to move data you can prove is complete and correct.

After the move — the part people skip

7. Reconcile, don't eyeball. Compare source and target systematically: row counts, totals, spot-checks of high-value records, field-by-field validation. "It looks fine" is not validation.

8. Produce a discrepancy report. Document every check you ran and every exception found, with a severity rating. This is your sign-off evidence — and your protection if a question comes up later.

9. Keep the source data accessible. Don't decommission the old system the moment the new one is live. Keep a verified export until you're genuinely confident nothing was lost.

Why migrations go wrong

Most failed migrations don't fail because the data was hard to move. They fail because nobody validated the result, the mapping lived in someone's head, or the timeline didn't allow for the inevitable second run. The technical part is rarely the risk — the discipline is.

This is methodical, unglamorous work, and it's exactly where an independent pair of hands earns its keep: someone whose job is to be sceptical, document everything, and prove the result before you commit. We've run migrations across CRMs, finance systems, legacy databases and sensitive clinical records, and the process stays the same — careful, documented, verified.

Planning a system change? Email us a description of what you're moving from and to, and we'll map out the safest approach and where the real risks sit.