No. Equal row counts do not establish that customers, orders, stock and cancellation states still mean the same thing. Acceptance should confirm that data from an agreed baseline supports the same business meaning in the new system, not simply that an import completed.
In brief: agree on scope and a baseline, then check counts, identifiers, business totals, references and representative workflows separately. Track differences explicitly and define the approver and stop conditions before cutover. Adapt the checklist for spreadsheet-to-CRM or inventory migrations as well as ERP replacement.
[01]Agree on scope and a comparison baseline
Replace 'migrate everything' with explicit scope: customer master data, open orders, stock balances, historical records and attachments. Choose stable IDs rather than matching by customer name. If several sources are combined, keep a mapping that identifies both the source system and its original ID.
- Baseline: record extraction time, time zone, filters and included or excluded statuses.
- Transformations: agree on dates, currencies, units, blanks versus zero, status mapping and rounding points.
- Ownership: name the source extractor, transformation owner, business reviewer and final approver.
Comparing a changing source with yesterday's extract makes differences hard to interpret. AWS DMS distinguishes full-load and ongoing-change validation, with pending, failed and suspended states. Validation also takes time and adds load; reserve capacity and a validation window rather than treating it as free work.
[02]Check counts and business meaning separately
The following is a BOYD editorial starting point for an acceptance matrix. Choose measures the business team can reconcile rather than applying one total to every table. Aggregate totals can conceal offsetting differences, so match important records by identifier and compare relevant fields too.
| Check | What to compare | Investigate differences |
|---|---|---|
| Scope and counts | Counts by status, period and location | Omissions, duplicates, filters and exclusions |
| Identifiers | Old-to-new ID mapping and required values | Duplicate codes, blank keys and missing mappings |
| Business totals | Order values by currency; stock by item and warehouse | Units, tax inclusion, cancellation and rounding rules |
| References | Order to customer; line to item; history to owner | Deleted master records, changed codes and broken links |
| Workflows | Search, partial dispatch, cancellation, approval and attachments | Mismatch between visible state and stored data |
AWS DMS row comparison identifies mismatches between source and target records. It does not by itself accept the new ERP's discount rules, approval workflow or screen permissions. Request separate evidence for data reconciliation and business-scenario testing.
[03]Make relationships and exceptions explicit
In PostgreSQL, a primary key identifies rows and must be unique and non-null. A foreign key checks for a corresponding record in another table to preserve referential integrity. These constraints are valuable safeguards, but do not establish that an order was linked to the correct customer in business terms.
Consider a hypothetical example: swapping the customer IDs on two orders can leave counts and totals unchanged. If both customer IDs exist, foreign-key checks may pass too. Compare customer, status and amount against the original order ID, not just totals. This illustrates a failure mode; it is not a reported client incident.
- Include exceptions such as partial dispatch, cancellation, returns, inactive customers and customers sharing a name.
- Track source ID, target ID, expected value, actual value, cause, owner and retest result for each difference.
- Keep pending or uncomparable items separate from passed checks and resolve their disposition before approval.
[04]Define cutover and recovery before switching
AWS pre-cutover guidance recommends a runbook with task order, owners and timing, plus rehearsal. For an ERP project, BOYD recommends making baseline extraction, final-change migration, validation, business approval and the start of writes in the new system explicit steps.
Recovery is not simply switching an address back. AWS guidance distinguishes rollback after new data has been written and explains the need to handle those changes. Decide who will preserve and reconcile orders and stock updates made in the new system; otherwise the application may return while the business data diverges.
- Go criteria: the approver reviews agreed checks and the disposition of exceptions.
- Stop criteria: define blocking discrepancies or workflow failures and a decision deadline.
- Recovery criteria: verify a restore rehearsal, preservation of new writes and reconciliation ownership, not just backup location.
[05]Include acceptance evidence in the deliverables
Turn 'migration included' into the deliverables below. Do not apply one tolerance to every data type: document the business basis and approver. Record intentionally excluded or merged records with their rationale and mapping so exclusions cannot silently hide failures.
- Scope, exclusions, baseline, transformation rules and ID mapping
- Count, total, field and relationship checks, plus unresolved differences
- Expected and actual results for representative and exceptional workflows
- Cutover sequence, owners, approval record, stop conditions and recovery steps
- Post-cutover support contact, revalidation schedule and operating-team handover
For an initial discussion, a de-identified sample from your spreadsheet or ERP and one workflow are useful starting inputs. Agree on what must move and why, then scope validation and integration together. This checklist needs adaptation to the project; it is not a guarantee of completeness for every system.
- Data migration
- ERP acceptance
- Data reconciliation
- Cutover planning
