Data migration testing checks whether a target population satisfies the agreed requirements after data moves or changes form. It should cover source readiness, mapping, full and incremental loads, business calculations, and the evidence needed for a cutover decision.
A completed migration job establishes that processing finished. Cutover readiness requires a separate conclusion about the expected data and the business process that will use it.
Establish a comparison baseline
Inventory critical tables, interfaces, and reports. Identify the relevant owners and define which failures would prevent cutover. Record the source version or snapshot, target population, extraction cutoff, timezone, and treatment of changes during testing.
Do not assume the source is correct because it is the system being replaced. Profile known issues and distinguish defects carried from the source from defects introduced by migration. Both can matter, but they may have different owners and treatment.
Translate mappings into expected outcomes
Document keys, data types, transformations, reference lookups, exclusions, and aggregation grain. Test representative cases before attempting a large reconciliation. Include nulls, missing references, boundary dates, and values near numeric limits where relevant.
For Snowflake or Databricks migrations, review the current platform-specific migration and validation documentation as part of technical planning. For example, Snowflake documents a migration validation workflow. Its documented checks and prerequisites should be evaluated for the actual migration scope rather than assumed to cover every business requirement.
Build a migration test plan around business risk
Group the migration scope by the consequence of a failed result. An incorrect settlement amount may require individual record evidence, while an archived reference table may need a different review depth. Ask business owners to approve these distinctions before the team allocates its testing window. Otherwise, easy comparisons can consume time while critical calculations remain untested.
Give each requirement an expected result, responsible reviewer, and evidence location. For a customer migration, specify how identifiers, account relationships, contact restrictions, and inactive records should appear in the target. Add negative cases such as a missing reference or an unsupported status. The plan should explain whether those cases are rejected, quarantined, or migrated with a documented exception.
Use independent expected values for material transformations. Copying the production expression into the test can reproduce the same error twice. A reviewer can calculate selected examples from the approved business specification and compare those expectations with the migrated output. Broader automated tests can then apply the reviewed interpretation to the eligible population.
Use a cutover control matrix
| Control | Before full load | Before cutover | After cutover |
|---|---|---|---|
| Source baseline | Record known issues and expected population | Confirm the final cutoff | Preserve the baseline references |
| Schema and keys | Test types, keys, and null rules | Verify final deployed mapping | Check changes introduced during stabilization |
| Population | Establish eligible source keys | Reconcile full and final delta populations | Review late arrivals and missed changes |
| Values | Test transformations and reference behavior | Reconcile critical fields and aggregates | Repeat high-risk comparisons |
| Business outputs | Define expected report behavior | Review critical reports and workflows | Confirm consumers use the intended target |
| Decision evidence | Assign owners and acceptance rules | Record failures, approvals, and rollback decision | Retain incidents and final resolution |
The matrix is a planning example. Owners should adapt it to the actual migration and approved acceptance requirements.
Test the final delta explicitly
Consider an illustrative migration baseline with 10,000 customer records. After the initial extract, the source receives 40 inserts, 12 updates, and 3 deletes. If those operations affect distinct existing keys and deletes remove records physically, the expected final count is 10,037. Updates do not increase the count.
Count reconciliation is only the first check. Verify the inserted keys, updated values, and agreed deletion behavior. A target that contains the right count but misses an update is still incorrect. If the target uses soft deletion, adapt the expected population and status checks accordingly.
Rehearse the execution window and reconciliation workload
Run a rehearsal using representative volume, permissions, and concurrency. Measure extraction, loading, comparison, and investigation separately. A migration that completes within its window can still leave too little time to review exceptions before the decision deadline. Record that constraint in the cutover plan rather than assuming faster infrastructure will resolve it.
For cloud targets such as Snowflake or Databricks, test the actual source-to-target path proposed for deployment. Confirm handling of numeric precision, timestamps, identifiers, and source-specific values. Passing a test against a simplified export does not establish that the production connection and transformation path behave identically.
If validation must be partitioned, document the partition key and confirm that the partitions cover the eligible population without gaps or duplication. Preserve a result for each partition and a clear overall status. A failed partition must remain visible even when other partitions finish successfully.
Define sign off and rollback conditions
Record which results block cutover, who can approve an exception, and when the decision must be made. “No major issues” is not a testable acceptance rule. A useful rule identifies the critical controls, permitted differences, and unresolved conditions requiring a decision.
Define rollback or recovery triggers with the operational owners. Consider the point at which transactions begin in the new system and whether reversing the change creates another data movement requirement. Do not improvise rollback only after a reconciliation fails.
Test a recovery rehearsal as well as a successful cutover. Restore the agreed state in a controlled environment and verify how transactions created during the attempted transition are handled. Record the reconciliation needed afterward. A recovery plan needs evidence that the resulting business population can be explained, not merely that infrastructure can restart.
Continue validation during stabilization
After cutover, review late changes, consumer reports, scheduled controls, and unresolved exceptions. Preserve the source and target references required to interpret the result. A clean migration snapshot does not establish indefinite production quality.
DataTrust supports migration validation and source to target reconciliation requirements. Use a demonstration to verify supported connections, comparison behavior, execution window, and evidence for the proposed migration. Read the SAP specialist reconciliation guide when SAP is part of the source landscape.
Keep the cutover decision understandable after the event
Assemble a short decision record that links the final scope, failed controls, accepted differences, and accountable approvals. Include the last delta cutoff and any business activity that occurred afterward. This record lets a later reviewer distinguish an approved limitation from a defect discovered during stabilization.
Agree on responsibility for late arrivals before retiring the old environment. A record created before cutover but delivered afterward still needs a defined destination and validation route. Keep unresolved items assigned until their outcome is documented, even when the wider migration program has formally closed.
Frequently asked questions
Do matching row counts establish migration success
No. Counts do not establish correct keys, transformed values, relationships, or business outcomes. Use them alongside more specific controls.
How are full and delta validation different
Full validation establishes the migrated baseline. Delta validation checks subsequent inserts, updates, deletes, and timing behavior under the agreed change-processing model.
What should a cutover sign off retain
Retain the scoped requirements, tested versions, results, unresolved exceptions, accountable approvals, and the agreed recovery decision. The exact record depends on the business process.
Request a Demo to review a migration validation scenario before selecting the cutover acceptance process.