Define transfer acceptance and recovery
Validate objects, identities, relationships and the customer workflow before deciding that the transfer is complete. Name the canonical system at each stage and the owner who can stop or reverse cutover. Count reconciliation is necessary but cannot show whether an older request remains meaningfully usable in the new product.
Worked example — illustrative data.
| Step | Acceptance evidence | Rollback decision |
|---|---|---|
| Inventory | Objects, relationships and exclusions listed | Resolve missing scope before import |
| Sample transfer | Synthetic records preserve identities and links | Correct mapping before full transfer |
| Validate | Counts plus meaningful record checks agree | Investigate unmatched records |
| Cutover | Owners accept data and workflow | Proceed only with approved decision |
| Recover | Known source and recovery procedure retained | Use defined trigger and responsible owner |
List source and destination objects, field mappings and relationships before planning dates. Identify data that cannot or should not move, and explain the customer action required. Rehearse with synthetic data, then use permissioned samples only under an approved plan. Check records through a real downstream task, such as reviewing an older request, rather than relying solely on totals. State which system becomes canonical at each stage.
Decision: Hold the migration when a required relationship or recovery route remains unproven. The checklist describes a method and makes no promise of a lossless or zero-downtime transfer.
Records created during transfer need reconciliation: New records may arrive in the old system during migration. Define a freeze, incremental transfer or reconciliation approach before cutover so the team does not accept matching counts that exclude recent activity.
Continue with Guides for stores, software teams and local businesses, SaaS marketing website migration and Check ecommerce exports before migrating.