Migration Reconciliation and Rollback Checklist
A buyer-facing checklist for proving a migration is ready: record mapping, reconciliation, cutover ownership, and a rollback decision that can actually be executed.
A buyer-facing checklist for proving a migration is ready: record mapping, reconciliation, cutover ownership, and a rollback decision that can actually be executed.
Define the cutover boundary
Write down exactly what changes at cutover: workflows, record types, integrations, users, permissions, URLs, reports, and systems that remain in place. Give every item a business owner and a technical owner. A migration is not ready when the team cannot state which system is authoritative for each critical record during the parallel-run period.
Map records and decisions
For each record, document the source identifier, target identifier, required fields, transformation, validation rule, and whether the operation adds or updates data. Preserve a reversible reference where the platform permits it. For websites, create an old-to-new URL map and test direct server redirects to relevant destinations; for operational systems, map the fields and approval decisions that affect downstream work.
Reconcile before cutover
Run a representative migration into a safe environment and compare counts, key totals, status distributions, and a sample of high-risk records with the source system. Record exceptions with an owner and disposition. Repeat the checks after the final data load and before allowing the new workflow to make irreversible changes. Reconciliation means showing why a difference exists, not just matching a headline total.
Make rollback executable
Set the rollback trigger before cutover: for example, a required reconciliation cannot be explained, a critical integration cannot process a defined test case, or the accountable owner does not sign off. Name the person who can pause the change, identify the previous version or operating path, preserve the required data export or backup, and rehearse the recovery steps in a non-production environment. Do not assume a database restore is a routine application rollback.
Illustrative checklist example
A team moving an order-exception workflow starts with 100 sampled source records. Before cutover it verifies that each target record links to its source ID, that the status and approver match, and that exceptions have an assigned owner. During a limited parallel run, the old system stays authoritative while the new workflow produces a comparison report. A mismatch in an approval status pauses expansion until the mapping is corrected and the sample is rerun. The team proceeds only after the named operational owner accepts the reconciled result and the rollback path is still available.
Limitations. This checklist is a planning aid, not a substitute for an organization’s accounting, security, legal, or operational controls. The system of record and qualified owners determine the required checks.