Accept a data migration when agreed records are complete, correctly related and usable in the destination workflow. Record counts are a starting point, not proof of correctness. A useful acceptance plan also checks transformations, balances, attachments, permissions and exceptions, with named owners for unresolved differences.
Let’s plan your data migration checks.
Bring your workflow, constraints and open questions. We’ll help you define the scope and work through the next decision.
Define the population before comparing totals
Specify source systems, extraction time, included entities and exclusion rules. If cancelled orders or inactive customers are excluded, record why and confirm whether their relationships must remain available. Otherwise a count mismatch may represent a deliberate filter or a genuine loss, with no way to tell which.
Keep a reference to the source snapshot and transformation version used for each migration run. When the source remains active, define how later changes and deletes enter the destination. A successful rehearsal on yesterday's snapshot does not establish that final cutover data will match.
Use an acceptance worksheet
| Check | What to compare | Evidence to retain |
|---|---|---|
| Completeness | Eligible source and destination counts by entity | Counts with filters and extraction time |
| Uniqueness | Business identifiers and duplicate rules | Duplicate report and approved merges |
| Relationships | Orders, customers, lines and attachments | Orphan report and traced sample |
| Values | Amounts, units, currencies and transformed fields | Reconciliation totals and mapping version |
| Usability | Search, edit, report and transaction behaviour | Representative workflow results |
| Access | Roles and record visibility | Authorised role checks |
| Exceptions | Rejected, ambiguous or deferred records | Owner and agreed treatment |
Make high-impact discrepancies visible separately from harmless formatting differences. An incorrect invoice association and a changed display capitalisation should not receive the same severity.
Choose samples that expose difficult records
Include more than recent, tidy records. Review old records, unusually large orders, missing optional fields, merged customers, archived attachments and boundary dates. The selection should reflect known data risks.
In a hypothetical stock migration, identical item counts can conceal a conversion from boxes to individual units. Compare quantity meaning and valuation alongside row counts. Ask business users to explain how they would use migrated records in a real task, rather than only confirming that a screen opens.
Agree who can accept exceptions
The migration provider can report a mismatch; the business data owner must decide whether the proposed treatment is acceptable. Keep rejected rows available for review and avoid destructive changes to the source while discrepancies remain unresolved.
Specify a sign-off process with open issues, impact, responsible owner and follow-up date. Do not make every minor exception a blocker, but do not hide material gaps inside a statement that the migration is almost complete.
Data migration questions
Is a 100 percent row-count match sufficient?
No. Rows can match in number while values, ownership or relationships are incorrect. Use the checks that define the business meaning of the dataset.
Can we clean data after migration?
Some cleanup can be deferred, but required identifiers, relationships and operational fields need an agreed treatment before dependent workflows use them.
Use the cutover checklist for the transition itself. Share the entity list and acceptance worksheet when discussing migration and cloud services.