Data migration / Cutover checklist
Data migration and cutover: the evidence to accept
Accept the records and business workflows before switching over.
Download worksheetEditable CSV · Open in your spreadsheet app
Download article in MarkdownA data migration is complete when the receiving system can support the business with the right records and relationships. An import success message is one piece of evidence. Reconciliation, user acceptance, and a workable cutover plan establish whether the business is ready to depend on the result.
Decide what moves and what remains available
Inventory the data needed for current operations, history, reporting, and support. Specify which records move into the new system, which remain in a controlled archive, and which will be excluded under agreed retention requirements.
Document field mappings, identifiers, status translations, units, dates, and currency treatment. Preserve the relationship between source and target identifiers where necessary for support and reconciliation. Transformation rules should be reviewable before a full migration run.
Open transactions deserve a separate plan. An order, return, purchase, or customer request may start in one system and finish after cutover. Assign ownership of that remaining work rather than assuming a historical import will make it operable.
Reconcile at several levels
Counts can reveal missing records but cannot prove their contents are right. Compare important totals, selected fields, relationships, and business behavior. Segment checks where a global total could conceal offsetting errors.
AWS DMS data-validation documentation illustrates source-to-target validation and reporting of mismatches, with documented limits. Whatever tooling you choose, agree what it actually checks and what needs an additional business-level test.
Use a cutover evidence sheet
| Gate | Evidence required | Decision to record |
|---|---|---|
| Scope | Included records, archive access, and exclusions | Business owner accepts the boundary |
| Mapping | Field rules and source-to-target identifiers | Exceptions are resolved or explicitly accepted |
| Reconciliation | Counts, totals, samples, and relationships | Differences are explained within agreed tolerances |
| Rehearsal | Timed import and critical workflow tests | The operating window is feasible |
| Final changes | Method for capturing changes after the initial copy | The final data position is known |
| Cutover | Named approver, communication, and system ownership | Proceed, pause, or recover |
| Recovery | Tested restoration or forward-repair procedure | New transactions can be accounted for |
Rehearse with the difficult records
Include duplicate customer details, unusual characters, missing fields, old product identifiers, partial refunds, and split shipments where they exist. A representative sample should cover the cases that affect the business, not only the cleanest rows.
Use realistic volumes when estimating the migration window. The first import may be fast while validation, indexing, and reconciliation take longer. Record the whole sequence and the work required from operators, vendors, and approvers.
Devekko's anonymized commerce case describes résumé-reported migration of two million historical orders. That is evidence of prior-role scope, not a forecast of how long another migration will take. Your source quality, target rules, and acceptance work determine the plan.
Make the final change window explicit
Decide whether the source stops accepting changes, continues with a controlled final synchronization, or uses another agreed transition method. Record the cutoff, outstanding changes, and the moment each system becomes authoritative.
If the new system starts accepting orders, rollback becomes more involved. Restoring an old snapshot without accounting for those new transactions can lose business activity. The recovery plan must explain how post-cutover changes are preserved and reconciled. Some situations call for forward repair instead of reversal.
Keep ownership after launch
Monitor the first relevant operating cycles: fulfillment, returns, invoice processing, reporting, or another task in scope. Give discrepancies an owner and an escalation route. Retain the migration evidence and mapping decisions where the operating team can find them.
Agree when the old system can be retired and what access must remain. Subscription cancellation, archive access, retention, and deletion are separate decisions with their own owners.
Use the ecommerce integration guide for cross-system order checks and the operating-foundations guide for recovery and handover readiness.
Your next step
Discuss your modernization
Share the task, your current systems, and the decision you need to make. We’ll discuss a useful first scope.
Discuss your modernization