An enterprise data migration checklist covers five things before any data moves: profile what you actually have, trace every system that depends on the source, identify the logic that gives values their meaning, define reconciliation and what counts as success, and agree how you would roll back. Migrations fail on those, not on the copy itself.
Know what you actually have
Before planning a move, profile the source. How many records, what date range, which fields are populated in practice rather than in theory, what values appear that the documentation does not mention. Almost every migration uncovers data the current owners did not know was there.
Decide explicitly what is not coming. Archived records, superseded structures and abandoned fields are cheaper to leave behind than to carry, but that has to be a decision someone signs, not an omission discovered later.
Find what depends on the source
The system being replaced usually has consumers nobody has listed: a report, an integration, a scheduled export, a spreadsheet a team rebuilt around it. Each is a dependency that will break silently at cutover.
Trace them before designing the target. It is common for this step alone to change the plan, because a dependency turns out to rely on behaviour the new platform does not reproduce.
Preserve meaning, not just values
Field-by-field mapping is the easy half. The harder half is the logic that lived around the data — the rule that made a status valid, the calculation applied on read, the relationship enforced by the application rather than the database.
If that logic does not move, the values arrive intact and mean something different. Identify it early, because rebuilding it is often the largest piece of work in the project.
Plan reconciliation before you move
Decide in advance what will be compared and what result counts as success: row counts by segment, financial totals, distinct key counts, spot checks on records chosen for their awkwardness. Write it down while nobody is under pressure.
Run it against a full-volume rehearsal, not a sample. Volume exposes timeouts, memory limits and duplicate keys that a subset will never surface.
Know how you would go back
A rollback plan is not a sign of low confidence; it is what allows a decision to be made calmly at two in the morning. Define the point of no return, what is preserved until then, and who decides. Teams that have this rarely need it, and teams that need it rarely have it.
