Data Migration Checklist: Moving Systems Without Losing Data

Why migrations go wrong

Software projects often budget carefully for the new system and treat the data as an afterthought. Then the surprises arrive: customers recorded twice, dates stored in three formats, fields used for something other than their name, and reports that depend on quirks of the old database. A structured checklist turns those surprises into planned work. It also applies when you replace a system in stages, as in our strangler fig guide.

Before you start

1. Define the scope. Which data moves, which is archived and which is left behind?
2. Name an owner from the business, not only IT, who can decide what is correct.
3. Back up everything and test that you can restore it.
4. Check legal and privacy obligations for the data you hold, including retention and deletion rules.

Audit and map

5. Inventory the sources. Databases, spreadsheets, files, email attachments and third-party tools.
6. Profile the data. Count records, find empty fields, duplicates and odd values.
7. Map old fields to new. Document each field, its meaning, its format and how it will be transformed.
8. Capture the hidden rules. Calculations, statuses and workflows that live in the old software or in people's heads.

Clean and prepare

9. Remove or merge duplicates with agreed rules about which record wins.
10. Standardise formats for dates, phone numbers, addresses and currencies.
11. Fix or flag bad records instead of silently dropping them.
12. Archive what you do not need. Smaller, cleaner migrations are safer.

Rehearse, cut over and verify

13. Run a trial migration on a copy, then compare counts, totals and sampled records against the source.
14. Repeat the rehearsal until results are clean and the timing is known.
15. Let real users test the migrated data and their key workflows.
16. Plan the cutover. Freeze changes in the old system, set a time window, assign roles and write the rollback steps.
17. Migrate, then verify again with the same counts, totals and sampled checks.
18. Keep the old system read-only for a defined period, then archive it properly.

After the move

• Monitor errors and user feedback closely for the first weeks.
• Reconcile key reports, such as finance totals, between old and new.
• Update documentation, integrations and any scheduled jobs that referenced the old system.
• Pay down remaining technical debt so the new system stays clean.

If you are weighing whether to replace a system at all, see build versus buy. Our legacy modernization team plans and runs migrations with rehearsals, reconciliation and rollback built in.