Data migration checklist: every step, owner and go/no-go gate

A data migration checklist covers six phases: scope and inventory, mapping and cleansing, test migrations, reconciliation, cutover with a rollback plan, and post-go-live sign-off and decommissioning. Each step needs a named owner and a go/no-go gate, so nobody discovers on cutover night that the data doesn't match or that there's no way back.

Most published checklists stop at "test and go live". They skip the parts that actually save migrations: proving the data matches, freezing changes before cutover, deciding in advance what triggers a rollback, and switching off the old system safely. This checklist adds them, and anchors each one in AWS, Google Cloud and Microsoft documentation. It works for database moves, application replatforms, ERP and CRM changes and warehouse consolidations. For website and CMS moves, see the section near the end.

What does a data migration checklist include?

Write names in the owner column, not just job titles. A gate without a named decision-maker tends to get waved through.

What should you do before you start?

Inventory

• List every source system, database, schema and file store in scope, with row counts and data volumes.
• List every consumer of the data: applications, reports, integrations, exports and scheduled jobs.
• Record data owners for each data set, and any legal, regulatory or retention requirements.
• Note sensitive data (personal, financial, health) and how it must be protected in transit and in test environments.
• Decide what not to migrate: obsolete records, duplicates and data past its retention period.

Strategy

AWS's guidance on migration strategies says: "There are seven migration strategies for moving applications to the cloud, known as the 7 Rs". They are retire, retain, rehost, relocate, repurchase, replatform and refactor. AWS adds a warning worth taking seriously: "Refactor is not recommended for large migrations because it involves modernizing the application during the migration." Move first, modernise second, unless the business case says otherwise.

Then choose how the data moves:

Gate: scope, strategy, owners and a target window signed off by the business owner.

How do you map, cleanse and transform the data?

• Build a field-level mapping: source table and field, target table and field, data type, transformation rule, default for missing values and owner.
• Profile the source data: nulls, duplicates, orphaned records, invalid formats, out-of-range values and inconsistent codes.
• Agree who fixes what. Fix in the source when the old system stays in use; fix in transformation when it doesn't.
• Map reference data and code lists (statuses, countries, currencies, product codes) explicitly.
• Decide how history is handled: full history, a cut-off date, or summarised balances.
• Record every rule in version control alongside the migration code.

Data quality is where migrations most often slow down. In dbt Labs' State of Analytics Engineering 2025 summary, "56% of survey respondents identified data quality as a problem." Budget time for cleansing as its own work stream.

Gate: mapping approved by data owners; quality thresholds (for example, zero orphaned records in key tables) met on the latest profile.

How do you test a data migration?

• Run the full migration end to end on a production-sized copy, not a sample.
• Time every step. The full rehearsal has to fit the cutover window with a margin.
• Run at least one rehearsal that ends in a rollback, so you know the way back works.
• Test applications, reports and integrations against the migrated data, not just the data itself.
• Log every defect with an owner and fix it in the migration code, never by hand in the target.
• Mask or protect sensitive data in non-production environments.
• Repeat until a rehearsal finishes within the window with no blocking defects.

Gate: a clean full rehearsal within the window, and signed-off test results from the application owners.

Reconciliation: how do you prove the data matches?

A migration job that finishes without errors has only proved it ran. Reconciliation proves the data is complete and correct.

Agree tolerances in advance. Most tables should match exactly; if any difference is acceptable (for example, records deliberately archived), document it and get the data owner's sign-off. Automate the checks so they run after every rehearsal and again at cutover.

Gate: every check within tolerance, signed by QA and the business data owner.

How do you plan cutover and rollback?

Plan for a short, rehearsed outage rather than none. Google Cloud's database migration principles say: "In a migration, achieving truly zero downtime for clients is impossible". With continuous replication, the outage shrinks to the switch itself; Microsoft's Azure DMS online migration tutorial notes: "Application downtime is limited to duration for the cutover at the end of migration."

Cutover runbook

• Announce the change freeze: no schema changes, releases or bulk updates in source systems from an agreed time.
• Take and verify your own backups. Don't assume the tool does it: Microsoft's tutorial states plainly that "Azure DMS doesn't take database backups".
• Stop writes to the source, or switch it to read-only.
• Run the final sync or final load.
• Run the automated reconciliation checks.
• Switch applications, connection strings, integrations and DNS to the target.
• Run smoke tests on the critical business journeys.
• Hold the go/no-go call at a fixed time with the named decision-maker.

Rollback plan

Keep the source intact. Google notes that "Sometimes you keep the source databases as a fallback measure if you encounter unforeseen issues with the target databases." Agree the triggers before cutover:

Decide how you'd handle data written to the target after go-live if you roll back later. The longer you run on the new system, the harder rollback becomes, so the rollback window should be short and explicit.

Gate: go/no-go decision recorded with time and decision-maker.

What happens after go-live?

• Run critical reports from both systems for an agreed period and compare them (a parallel run), especially finance and regulatory reports.
• Monitor errors, performance and data quality daily during the first weeks.
• Get formal sign-off from each data owner once the parallel run is clean.
• Keep the source read-only until sign-off, then archive it according to retention and legal-hold requirements.
• Turn off old integrations, scheduled jobs and credentials so nothing writes to the old system.
• Decommission infrastructure and licences on a set date, so you stop paying for two systems.
• Hand over runbooks and data pipelines to the team that will run them.

That last step matters more than it looks. Fivetran's 2025 research found that "67% of centralized enterprises allocate over 80 percent of their engineering resources to maintaining data pipelines". A migration is the best moment to replace fragile pipelines with tested, monitored ones, rather than copying old problems to a new platform.

Gate: signed acceptance from the business owner; source decommissioned or archived.

What about website and CMS migrations?

Moving a website or CMS adds a search layer on top of the data: every old URL must redirect to its new address, and content, metadata and structured data must arrive intact. Use our website migration checklist for that side, and our website migration team if you want it run for you. Moving servers and applications as well as data? See our cloud migration checklist.

Who should be on the migration team?

On small projects one person may hold several roles, but the business owner and the person who builds the migration should not be the same: the gate only works if someone independent of the build makes the call.

What are the most common data migration mistakes?

• Migrating everything, including data nobody needs, instead of cleaning and archiving first.
• Testing on a small sample, then discovering at cutover that the full load takes three times longer.
• Fixing defects by hand in the target, so the next rehearsal reintroduces them.
• No reconciliation beyond "the row counts look right".
• Rollback triggers decided during the outage, under pressure.
• Switching off the source before the parallel run and sign-off.

How long does a data migration take?

It depends on volume, the number of systems and how clean the data is. A single database moving to a managed service can take weeks; an ERP or multi-system consolidation can take months, mostly in mapping, cleansing and rehearsals. The cutover itself should be the shortest part. Size the project from the inventory and the first rehearsal, not from a guess.

How can Elgrith help?

Elgrith has delivered 1,000+ projects for 250+ clients since 2015, from our New Delhi headquarters and client centers in New York, London and Shanghai. Our data engineering team plans and runs data migrations with automated reconciliation, and builds the pipelines that run afterwards, often in Python. We also handle cloud migration and ERP development projects, and connect the migrated data to dashboards through data visualization. We don't claim partner status with any cloud or data platform. You get a fixed written quote after a free call. Book a call or start a project.