Data Migration Checklist: What to Plan Before You Move

A data migration plan should answer five things before anything moves: what data you actually have, how it maps to the new model, how you’ll cut over, how you’ll roll back, and how you’ll prove it worked. Copying records is the easy part. Most migrations go wrong in the gaps between those five.

I wrote about the messy reality of this in Leaving a Third-Party System? Plan the Data Migration First. This is the checklist I wish existed before that one started.

1. Understand the source data

You can’t plan a migration around data you haven’t looked at. Documentation and data catalogues describe what the data should look like. The export tells you what it actually looks like.

• Do you have a full export, or only a sample? Samples hide the weird records.
• Is there a real data definition for every field, including allowed values and formats?
• Which fields are free text that other systems treat as structured (names, addresses, statuses)?
• How much of the data is duplicated, orphaned, or incomplete?
• Are there records that only make sense with context that lives outside the system, like in someone’s head or a spreadsheet?
• How large is it, and how long does a full export take?

2. Decide what you are actually migrating

Not everything needs to come across, and not everything needs to come across in the same shape.

• Which data does the business need day one, and which can follow later?
• Is there historical data you only need to keep for reference or compliance, rather than in the live system?
• Are you rebuilding the old system’s limitations in the new model just because the data arrived that way?
• Who signs off on what gets left behind?

That third question matters more than it looks. Moving off a third-party platform is one of the few moments you get to rethink the data model. Use it.

3. Map source to target

This is where most of the hidden work lives.

• Is there a field-by-field mapping document, and has someone who knows the business reviewed it?
• For every field that doesn’t map one-to-one, what’s the transformation rule? (The classic: a single “full name” field feeding separate first and last name columns.)
• What happens to records that fail a transformation: reject, quarantine, or fix by hand?
• Are IDs preserved, or do you need a lookup table from old IDs to new ones?
• How are relationships between records rebuilt, and in what order?
• Are dates, time zones, currencies, and encodings consistent between the two systems?

4. Plan the cutover

• Big bang or phased? Can you migrate one customer group, region, or data type at a time?
• Will both systems run in parallel for a period, and if so, which one is the source of truth?
• How much downtime is acceptable, and who needs to agree to it?
• What happens to data created in the old system during the migration window?
• Who needs to know, and when: customers, support, finance, partners?

5. Plan the rollback

A rollback plan you haven’t tested is a hope, not a plan.

• What’s the exact trigger for rolling back, and who makes that call?
• Can you restore the target database to its pre-migration state, and how long does that take?
• If you roll back after users have created new data, what happens to it?
• Have you rehearsed the rollback at least once?

6. Rehearse

• Have you run the full migration end to end against a copy of production data?
• How long did it take, and does that fit inside your cutover window?
• Did you compare record counts and spot-check real records, not just check that the scripts finished?
• Did the people who use the data every day look at the result?

7. Validate after go-live

“Migration completed” is the start of the critical phase, not the end.

• What checks prove the data is correct: record counts, totals, key reports matching the old system?
• Who is watching production closely in the first days, and for how long?
• Is there a simple way for users to report data that looks wrong?
• Is there time and budget reserved for the fixes you will need? There are always some.
• When is the old system switched off, and what’s archived before it is?

The short version

If you only have time for a few of these, answer these five questions first:

1. Have we looked at the real export, not just the documentation?
2. Does every field have a mapping and a transformation rule?
3. What do we do with records that don’t fit?
4. How exactly do we roll back, and have we tried it?
5. How will we know the data is right after go-live?

A migration like this is really a solution architecture problem: several systems, a data model, and decisions that are expensive to undo. If you’re planning one and want a second pair of eyes, here’s how I work, and you can see a similar project in my migration case study.