Practical guide
Data migration is a validation program
Profile, map, cleanse, rehearse, reconcile and recover before transferring authority to the new system.
Page purpose
Use Data migration is a validation program to resolve a specific decision, not as a generic information list.
Data migration is a validation program because a technically successful transfer can still change meaning, omit history, break relationships, or move unresolved defects. Acceptance must be tied to the business use and control importance of the data.
Controls should be proportional to volume, criticality, source condition, transformation complexity, and recovery options. No single reconciliation percentage or test sequence is universally sufficient.
Decision trap
The ambiguity this guide is designed to remove.
- Migration estimates are set before source condition and business meaning are profiled.
- Field mapping documents syntax but not ownership, semantics, or transformation rationale.
- Teams reconcile row counts while missing relationships, balances, and usable history.
- Cutover plans do not define exception authority or a tested recovery point.
Comparison criteria
Comparison criteria that should be recorded.
- Which records, history, attachments, and relationships are required in the target?
- Which defects are corrected, carried, quarantined, or rejected, and by whom?
- What reconciliations prove fitness for each data class?
- At what point is rollback no longer safe, and what recovery path replaces it?
Apply the framework
Apply the framework to a real situation.
- Define in-scope records, business use, authority, history, retention, and acceptance owners.
- Profile source values, relationships, duplicates, missingness, and encoding.
- Specify mappings and transformations with testable rules and exception handling.
- Rehearse repeatedly using controlled snapshots and compare evidence between runs.
- Authorize cutover only with accepted reconciliation, recovery readiness, and residual exceptions.
Reader output
The output the reader should produce.
- Source inventory, profiling results, and data-criticality classification
- Mapping, transformation, lineage, and ownership specification
- Data-quality issue and exception register
- Rehearsal plan with reconciliation evidence
- Cutover, recovery, retention, and acceptance record
Decision clarity
A clearer decision, not merely more information.
- A migration scope classified by data purpose, owner, and criticality.
- Traceable mappings and transformation rules with accepted exceptions.
- Rehearsed migration runs producing repeatable reconciliation evidence.
- A cutover and recovery decision owned by accountable business and technical roles.
Misapplication
When can the framework create false confidence?
- Cleaning during migration may alter records without accountable approval.
- Source and target may change during rehearsal, making comparisons unreliable.
- Aggregate totals can reconcile while individual relationships are wrong.
- A prolonged rollback window may create an unmanageable volume of divergent transactions.
Decision questions
Test the interpretation before applying the guide.
Are matching record counts enough to accept a migration?
Counts are one check. Meaning, relationships, balances, history, permissions, and downstream use may require separate reconciliation.
Should all source data be cleaned before migration?
Not automatically. The owner must decide whether to correct, carry, quarantine, archive, or reject each defect class while preserving traceability.
How many rehearsals are required?
The required number follows the evidence: continue until scope, timing, reconciliation, exception handling, and recovery results are stable enough for accountable acceptance.