Checking Your ERP Data Migration. Verify records, values, relationships and the work they support.
A migration can load the expected number of records and still leave the business unable to operate. Amounts can be assigned to the wrong customer, order lines can lose their relationship to a header, and valid-looking statuses can prevent the next transaction from completing.
Reconciliation should therefore establish several business assertions independently: the required population is present, important values are preserved or correctly transformed, relationships remain meaningful, and the resulting records support the intended work. A successful load is useful technical evidence, but it addresses only part of acceptance.
Build a reconciliation pack around those assertions before the final migration. That gives business owners a defined basis for approval and gives the technical team a way to distinguish an expected transformation from an unexplained discrepancy.
Start with the operating purpose of the data. Open receivables need to support collection and application of cash. Open orders need to support the remaining fulfillment steps. Inventory records need to preserve the relevant quantity, location, status, and valuation meaning under the approved design.
For each population, write the assertions the business needs to accept. Examples include every eligible open document appearing once in the expected destination, amounts agreeing within approved transformation rules, and each line retaining its valid relationship to the correct account or document.
Name an owner for each assertion. The migration lead can establish how the load ran. A finance owner should accept financial meaning within their responsibility. An operations owner should accept whether migrated work can continue. One broad signature from a project manager should not conceal these different decisions.
Resolve transformation rules early. Records may be split, combined, reclassified, or represented differently in the new design. In those cases, a direct source-to-target count comparison may be inappropriate. The reconciliation needs an expected target derived from the approved transformation, plus traceability back to the source.
Document the source extract, selection criteria, effective cutoff, environment, and version of the transformation rules. Identify which records qualify and which are intentionally excluded. The business owner should accept the population definition before reviewing totals.
The target evidence must refer to the corresponding load and comparison point. Comparing a source extract from one time with a target population that already contains later transactions can create apparent differences unrelated to migration quality. Conversely, allowing normal activity to obscure the load can make real differences hard to isolate.
If the migration includes a later delta, define how changes after the initial extraction are captured and reconciled. Address additions, corrections, cancellations, and deletions or status changes as applicable. The design must fit the actual source and target capabilities; no generic delta approach guarantees completeness.
Keep a clear sequence of extract, transform, load, reconcile, correct, and recheck evidence. When a correction changes the baseline or transformation, preserve the earlier result and explain the change. Repeatedly replacing files without version context makes sign-off difficult to defend.
Compare the intended population with what arrived. Examine counts by useful business dimensions and identify missing, duplicated, rejected, and intentionally excluded records. A total count can conceal a missing record offset by a duplicate.
Where transformations legitimately change the count, reconcile through the mapping. If one source record becomes multiple target records, the pack should explain the rule and show how the expected target population was calculated. The question is whether the intended information survived, not whether two totals happen to match.
Check amounts, quantities, dates, and other important values at the level needed to reveal material errors. Group amounts by currency and relevant business dimensions rather than combining unlike measures. Check signs, decimal treatment, units, and approved rounding behavior.
Net agreement can hide offsetting errors. A debit overstated in one place and a credit overstated elsewhere may leave a total unchanged. Consider gross components and meaningful subgroups where the consequence warrants it. The responsible owner should define acceptance criteria and any justified tolerance before seeing the final result.
Verify that records point to the correct customers, suppliers, items, locations, parent documents, and other required references. A relationship can exist technically while pointing to the wrong business entity. Existence checks and business mapping checks serve different purposes.
Review the links needed for future actions. A migrated credit may need its original invoice reference. An order line may depend on an allocation or delivery state. A disconnected record can remain invisible until someone attempts the next step in the process.
Ask authorized users to perform representative work using migrated data in the approved test environment. Can they continue an open order, investigate a balance, process a permitted correction, or produce the required operating view?
Choose scenarios that exercise the migration risks, including unusual but consequential records. Representative tests do not prove every record is correct; population-level checks do not prove every workflow is usable. The two forms of evidence complement each other.
Suppose a hypothetical receivables migration contains two customer balances in the same currency: 400 for Customer A and 600 for Customer B. The target contains two balances totaling 1,000, so the record count and overall amount agree.
A mapping error has assigned 600 to Customer A and 400 to Customer B. Nothing is missing from the headline total, but the business cannot rely on either account. Reconciliation by customer exposes differences of positive 200 and negative 200 that cancel at the overall level.
The team traces the error to an identifier mapping and corrects it. It then reruns the affected checks and assesses whether other records used the same mapping. Restricting the repair to the two observed rows would leave the broader error population unexamined.
Now consider the usability test. The corrected balance is visible, but the collection team cannot identify which open documents make up Customer A's amount. The migration design loaded a summary where the approved operating requirement expected document-level detail. This is a design or scope issue, not a numerical variance to waive.
The finance owner decides whether the planned collection process requires document-level migration or whether an explicitly designed alternative is acceptable. The migration lead implements the approved treatment, and the business repeats the relevant test. All amounts and customer labels in this example are illustrative; they demonstrate why independent assertions are necessary.
For each assertion and population, record the source baseline, approved transformations, expected target result, actual target result, difference, explanation, evidence reference, responsible owner, and acceptance decision.
An explanation should be reproducible. “Rounding” is insufficient unless the defined rounding rule and affected population account for the difference. “Excluded records” should point to the approved eligibility rule and the actual excluded population. “Timing” should identify the cutoff mismatch or later activity involved.
Separate explained differences from unresolved exceptions. An explanation does not automatically make a difference acceptable. It may reveal an approved transformation, a mistake that needs correction, or a business decision that has not yet been made.
Where detailed evidence is large, summarize it in the worksheet and preserve an accessible reference to the underlying results. Reviewers need enough information to challenge the conclusion without receiving an unreadable collection of raw files.
Each unresolved exception needs an affected population, consequence, owner, proposed action, and evidence required for closure. Distinguish correction before acceptance, an approved operating workaround, exclusion under an agreed rule, and an explicitly accepted residual issue.
Assess both individual and cumulative effects. Several small differences may share a systemic cause. A single record may be operationally critical even when its amount is small. Acceptance should follow the business consequence and applicable control requirements, not only a monetary threshold.
A workaround needs to be usable by the operating team. Identify who will perform it, how exceptions are detected, how the work is tracked, and when the arrangement ends. If it relies on project specialists remaining indefinitely, its feasibility has not been established.
Avoid accepting a discrepancy solely because the planned transition date is close. Leadership may decide to alter the release, add a controlled interim process, or change timing. The reconciliation pack should give them the evidence needed to make that choice explicitly.
After a repair or reload, rerun the checks affected by the change and assess possible effects on other populations. A corrected mapping may influence more than the record that revealed it. The testing scope should follow that dependency.
Also verify how reruns interact with existing target data. Depending on the design, another load can duplicate, replace, update, or reject records. The migration procedure should demonstrate its behavior in the relevant environment rather than assuming a rerun is harmless.
Retain the final accepted result alongside the source and transformation references used to produce it. Record who approved which assertion and the specific exceptions accepted. “Migration approved” is a weak record when nobody can determine what was reviewed.
Before transition, review the four lenses together. Identify any assertion lacking evidence, any unexplained difference, and any workaround without an operating owner. The release authority should receive those findings in business language, with the consequence and decision required.
Start now by selecting one critical data population and writing its acceptance assertions before the next rehearsal. Ask the business owner what could be wrong even if counts and totals match. Those answers will identify the relationships and operating scenarios the reconciliation must test. The strongest migration sign-off is a set of specific claims the evidence supports, with the remaining limits plainly understood.