A migration needs reconciled records, not just a completed transfer

The migration dashboard reports 9,500 rows loaded. The approved scope also contains 9,500 memberships. The totals match, yet one member cannot be found and another appears twice.

Data migration reconciliation needs to establish which business records arrived, how they relate to one another, and which changes belong to the comparison period. A completed transfer job answers only part of that question.

Freeze a comparison basis before comparing totals

Consider a fictional membership service moving records to a new system. At the agreed cut-off, the source contains 10,000 unique membership identities. The business owner has approved 500 exclusions, leaving 9,500 eligible identities.

Preserve the exclusion list and its reason. An exclusion is not simply a record the migration failed to load. Someone must be able to show that it was deliberately outside the agreed scope.

Also establish how changes after the cut-off will be handled. If the source keeps receiving updates while the target is compared with an earlier extract, different values may reflect different observation times. Record the snapshot or equivalent comparison basis, then reconcile subsequent changes separately.

Compare identities, then relationships and values

In this example, the target has 9,500 rows but only 9,499 distinct eligible membership identities. One eligible identity appears twice and a different one is missing.

These are synthetic figures. The example demonstrates why equal totals cannot establish identity completeness.

Next, examine the relationships needed by the service. Can an active membership be associated with the correct person and current entitlement? Are required values mapped consistently? Are dates and statuses interpreted the same way? Select checks from the actual business model rather than treating every column as equally meaningful.

AWS DMS provides row-level validation under supported conditions, with distinct pending and failed states and documented limitations. Such tooling can supply valuable comparison evidence, but its supported keys, data types and workload conditions matter. It does not independently establish that the receiving service can perform the required business task. AWS DMS data validation.

Give each discrepancy a disposition

Keep missing, duplicate, mismatched, excluded and not-yet-compared records separate. Combining them into “exceptions” can conceal whether the team understands the cause.

For each material discrepancy, name the business identity, affected relationship or field, source evidence, proposed correction and authorized owner. Restrict access to the detailed record where it contains personal information.

A fix should be followed by the relevant comparison again. If the mapping itself changes, earlier passes that depended on that mapping need reassessment. Preserve the original result so the receiving team can understand what changed.

Use the reconciled records in the receiving service

Choose business scenarios that exercise the migrated relationships. In the membership example, locate an eligible member, inspect the correct entitlement and perform a permitted service action. Check an approved exclusion separately so the team can explain why it is absent.

These scenarios complement the record comparison; neither replaces the other. A sample transaction can succeed while thousands of other records remain unexamined. A complete set comparison can pass while the application interprets a status incorrectly.

The service handover should retain the comparison basis, unresolved dispositions and operating owner. Evidence for a successful load does not authorize deleting the source or closing the reconciliation work. Those are separate decisions under the organisation's retention and transition controls.

For the missing member in the opening example, the useful answer is a traceable disposition and a verified correction. “The row count matched” cannot explain where that person's record went.