Data Migration Best Practices: A Phase-Gate Checklist

Section 01

What should you decide before moving any data?

Before data moves, the migration team should define the business outcome, inventory every dataset and dependency, classify sensitivity and retention, document mappings and transformations, and set measurable acceptance criteria. These decisions determine what to migrate, which controls apply, and what evidence each later gate requires.

1. Define the migration contract

Write down the answers that will govern engineering and business decisions:

• Business outcome: What becomes possible or safer after the move? Examples include consolidating databases, leaving a data center, reducing a batch dependency, or enabling a new reporting workflow.
• Scope boundary: Which datasets, tables, files, objects, schemas, reports, applications, and integrations are in scope? Name the systems that are explicitly out of scope.
• Service requirements: Set the allowed downtime, Recovery Point Objective (RPO), Recovery Time Objective (RTO), performance baseline, and security requirements for each critical workload. Do not copy a universal “zero downtime” or “five-second recovery” target into a project that has not defined its business need.
• Acceptance owners: Assign a data owner, application owner, security or privacy owner, and final go/no-go decision maker. The data, application, and business owners should approve the migration alongside infrastructure.

The data modernization hub provides the broader context for choosing a modernization path. This article stays focused on the controls that make the transfer itself verifiable.

2. Build an inventory that supports a decision

For every data set, record its owner, source location, format, size, update rate, dependencies, sensitivity, retention requirement, target, transformation owner, and disposition. The disposition must be explicit: migrate, archive, delete under an approved policy, or retain in place.

Inventory the relationships around the data as well as the data itself. Include applications, APIs, ETL jobs, reports, service accounts, event streams, backups, and downstream consumers. A table can pass a row-count check while a dependent report or integration still reads from the old location.

For sensitive or regulated data, document the target region, encryption, access roles, audit logging, masking rules, and retention controls before selecting a transfer method. NIST’s data-classification guidance starts from the same practical requirement: an organization must know what data it has and what characteristics affect its protection.

3. Version the mapping and transformation specification

The mapping specification is the contract between the source and target. It should define:

• source-to-target field mappings and excluded fields;
• data-type, encoding, timezone, currency, precision, and unit conversions;
• default and null-handling rules;
• primary-key, foreign-key, and deduplication behavior;
• filters and the records intentionally excluded from the target;
• rejected-record handling, retry behavior, and an audit trail for every transformation.

Test each non-trivial rule against representative records before the first full load. A successful migration also preserves business meaning; a byte-level transfer alone cannot prove that.

Section 02

Which migration pattern fits the workload?

Choose a quiesced export or backup when the source can stop accepting writes; choose continuous replication or Change Data Capture (CDC) when the source must remain online; choose phased waves when dependencies or blast radius require smaller releases. Every pattern needs a reconciliation and fallback plan.

Source note: This pattern summary synthesizes the export/import, replication, ordering, and dual-write trade-offs described in Google Cloud’s database migration principles and the near-zero-downtime sequence in Microsoft’s Cloud Adoption Framework. Review the provider documentation for the source and target engines before selecting an implementation.

Treat dual-write as an exception

Dual-write sounds simple because the application writes to both systems. The writes are still separate transactions. Google Cloud notes that a failure between those transactions can leave the systems inconsistent, and uncoordinated clients can break source transaction order. Prefer a replication mechanism with a recoverable position when the source platform supports it. If dual-write is unavoidable, make reconciliation and repair part of the design rather than a post-cutover task.

Select tools after the pattern

Migration products, native replication, CDC platforms, ETL/ELT systems, and object-transfer utilities solve different parts of the problem. Evaluate them against the selected source-target pair:

1. Can the tool capture the required data changes and preserve ordering?
2. Can it express the mapping and transformation rules without hiding rejected records?
3. Can the team resume after a network or platform failure from a known consistent position?
4. Can it expose lag, counts, errors, validation results, and audit records to the people who approve the cutover?
5. Can security and privacy owners verify the transfer path, credentials, encryption, and target location?

The source and target, transformation complexity, write rate, and downtime requirement should determine the tool.

Section 03

How do you validate a migration without hiding errors?

Validate in layers: completeness and rejected records first, record fidelity next, business meaning after that, and application behavior last. Row counts are a useful quick check, but they cannot prove that transformations, relationships, calculations, permissions, or critical workflows survived.

Source note: AWS DMS documents row-level source-to-target comparisons for full-load and CDC tasks, including validation states and mismatches. Microsoft recommends row counts for a quick check, with checksums or hashes for deeper validation and end-to-end workload tests. Both sources warn that validation adds work or load; size the validation window accordingly. See AWS DMS data validation and Microsoft’s migration execution guidance.

Before the first full load

Run a dry run with a representative slice of data and exercise the actual mapping rules. Compare:

• schema and constraint definitions;
• key uniqueness and relationship counts;
• null, default, and rejected-record behavior;
• data types, precision, encodings, timezones, and units;
• source records intentionally filtered out;
• baseline results for the highest-value reports and transactions.

The data quality in migration projects guide covers profiling and remediation in depth. This page’s gate is simpler: the migration cannot advance until the team knows which quality issues are accepted, fixed, filtered, or blocked.

During extraction and replication

Track the migration as a stateful process. A copy command alone cannot show what was extracted, filtered, rejected, or safely replayed. Persist a batch identifier, source position or change marker, extracted count, target count, rejected count, filtered count, retry count, and validation result. Google Cloud’s migration principles emphasize tracking in-transit items and resuming from the last consistent transfer after failure.

For CDC, monitor lag and ordering. A fast initial load does not make the target ready if ongoing changes are accumulating faster than the replication process can apply them. Investigate mismatches instead of resetting the task and losing the evidence trail.

At cutover and after

Run the final synchronization, freeze or drain writes when the chosen pattern requires it, and execute the same validation suite against the final target state. Then test critical business functions with application owners. The database migration testing strategies guide covers the deeper testing catalog; this article treats those tests as a cutover gate.

Section 04

What must be true before cutover?

Cutover is ready when the source and target are synchronized or the source is safely quiesced, validation evidence meets pre-agreed thresholds, critical workflows pass, owners approve the decision, and the fallback path has been rehearsed. A snapshot alone is not a systems rollback plan.

Write go/no-go criteria before the rehearsal

Use criteria that map to business risk. Examples include:

• no unexplained missing, duplicate, or rejected records in critical datasets;
• reconciled financial, inventory, entitlement, or operational totals within an agreed tolerance;
• critical workflows and integrations pass with migrated data;
• replication lag is at or below the approved cutover threshold, or the source is confirmed read-only;
• access controls, encryption, masking, audit logging, backups, and target-region requirements pass review;
• rollback triggers, decision authority, communication paths, and stop conditions are documented.

Do not invent a universal error-rate or performance threshold. A 0.5% application-error trigger may be unacceptable for payments and too strict for a low-criticality internal report. The service owner should set the threshold from the workload’s baseline and business impact.

Rehearse the switch and the fallback

1. Run the migration in a production-like environment with representative volume and concurrency.
2. Perform the final synchronization and traffic switch using the same automation planned for production.
3. Intentionally trigger at least one failure condition, such as a validation mismatch, a dependency failure, a permission error, or an unhealthy target.
4. Measure the actual time to stop writes, restore service, reconcile post-cutover changes, and communicate status.
5. Record the gaps, update the runbook, and repeat the rehearsal until the decision maker accepts the evidence.

For command-level runbooks, recovery patterns, and RTO/RPO design, use data migration rollback planning. This page only requires the readiness gate: the fallback exists, the team can execute it, and the evidence is current.

Keep the source available during stabilization

Retain the source environment as a fallback until the agreed stabilization criteria are met. Microsoft’s Cloud Adoption Framework recommends keeping the source available for quick reversion, checking data integrity with counts and hashes, and monitoring workload performance, error rates, and user access patterns for the first 24–48 hours after cutover. Decommissioning the source is a later decision, not part of the traffic switch.

Section 05

What should the team monitor after go-live?

Post-migration monitoring should connect data fidelity to business behavior. Watch replication or reconciliation deltas, rejected records, critical transaction success, latency, access patterns, alerts, and support signals until the new system meets the stabilization criteria signed off before cutover.

Monitor four groups of signals:

• Data: mismatches, missing or duplicated records, rejected batches, CDC lag, late-arriving data, and failed transformations.
• Application: success rate and latency for critical transactions, report freshness, API errors, queue depth, and downstream integration failures.
• Security and governance: unexpected access, privilege changes, audit-log gaps, encryption or masking failures, data in the wrong region, and retention violations.
• Operations: backup completion, restore evidence, capacity, incident volume, and the on-call team’s ability to use the runbook.

Set an explicit exit condition for the stabilization period. It should include owner signoff, resolved critical incidents, completed post-cutover reconciliation, a verified backup, updated inventories and runbooks, and a documented decision about whether to decommission the source or retain it for a longer period.

For the policy and control layer around classification, access, and retention, see the data governance strategy.

Section 06

What is the practical data migration checklist?

Use this checklist as a release gate alongside the project plan. Every checked item should point to an artifact, test result, or owner decision that another person can review.

Before build

• Business outcome, scope boundary, downtime, RPO, RTO, security, and acceptance owners are documented.
• Every dataset, dependency, owner, sensitivity class, retention requirement, target, and disposition is inventoried.
• Field mappings, transformation rules, filters, rejected-record handling, and lineage are version-controlled.
• Source baselines exist for critical totals, workflows, reports, latency, and throughput.

Before cutover

• A representative dry run has completed with production-like data volume and failure handling.
• Counts, filtered records, rejected records, checksums or hashes, semantic reconciliations, and functional tests have named owners and results.
• The target’s access controls, encryption, masking, audit logging, backups, and integrations have passed review.
• Go/no-go thresholds and rollback triggers are approved before the production window.
• The final synchronization procedure, write pause or drain, traffic switch, and fallback steps have been rehearsed.

After cutover

• Application and data owners confirm critical workflows and reconciliations.
• The source remains available for the agreed stabilization period.
• Data, application, security, and operational signals are monitored and incidents are tracked.
• The source-decommissioning decision is documented only after stabilization evidence and backup/restore checks are complete.

Section 07

Which adjacent guides cover the deeper work?

Use this page for lifecycle gates and cutover decisions. Use the sibling guides for the specialized work: data quality profiling and remediation, database migration testing strategies, rollback architecture, and mainframe-specific migration strategies.

Sources and scope

This playbook was refreshed on August 6, 2026 using official guidance from AWS DMS, Google Cloud, and Microsoft Learn. Provider documentation describes capabilities and recommended controls; it does not establish a universal success rate, downtime target, cost, or performance improvement for every migration.