How to Reconcile a Data Migration (Row- and Column-Level)

“The load ran” is not the same as “the data is correct.” Reconciliation is what proves a migration actually moved everything, intact — and it’s the evidence auditors, finance and the business will ask for. Here’s how to reconcile an ERP data migration properly, at row and column level.

Count reconciliation: source → staged → target

The baseline check is record counts at every stage: how many rows left the source, how many passed validation into staging, and how many landed in the target. Any drop should be explained, per object. This catches silent losses — rows filtered out, rejected on import, or deduplicated away.

Column- (value-) level reconciliation

Counts alone can hide corruption: the right number of rows with the wrong values. Column-level reconciliation validates the individual fields — key amounts, dates, identifiers, statuses — against the source, so you prove not just completeness but content.

Control totals

For financial objects, reconcile control totals: debits and credits, GL balances, open AP/AR, asset cost and accumulated depreciation. If the migrated trial balance ties to the source to the cent, you have a strong, business-facing proof point.

Technical vs business validation

Keep two things separate: load-readiness / technical reconciliation (did every row arrive intact — the migration team’s job) and business validation (is the data business-correct — the customer’s job). Separating them means every discrepancy has a clear owner.

Evidence and thresholds

• Produce a per-object reconciliation pack (source vs staged vs target).
• Log every exception with its resolution in an error tracker.
• Set a variance threshold (e.g. anything over a set percentage blocks sign-off) and a rollback rule for cutover.