ERP data migration: reconciliation and go-live sign-off

Approve an ERP data migration only when business owners can trace the agreed source records into the target, explain every material difference, and demonstrate that the migrated data supports real work. Define the reconciliation rules, permitted exceptions, evidence and sign-off owners before the first trial load. A successful import is one input to that decision.

For an implementation in Lebanon or across MENA, the acceptance plan should distinguish legal entities, currencies, operational locations and Arabic/English data requirements. This article provides a reconciliation framework to adapt to your project. The broader ERP migration and integration guide covers scope and ownership; the focus here is the evidence needed to approve the final data.

What exactly are you accepting?

Write one acceptance record for each dataset and rollout wave. “Customer data checked” leaves too much open. A useful record identifies:

• The source extract, extraction time, cutoff and time zone.
• The entities, date range and record statuses included or excluded.
• The approved mapping and transformation version.
• The target environment, import run and reconciliation report.
• The checks, pass conditions, reviewer and decision deadline.

Preserve the source snapshot used for comparison under the project's approved access and retention rules. If the source keeps changing, comparing today's target with yesterday's extract can produce differences that reflect timing rather than an incorrect load. Define how changes after the cutoff are captured and when the final comparison becomes valid.

Microsoft's migration guidance distinguishes configuration data from migrated master data and open transactions, and calls for explicit sequencing and dependencies. Apply that distinction to acceptance: a correctly transferred supplier record may still be unusable if its required target configuration is missing.

Build a reconciliation matrix around business risk

The following is an illustrative planning matrix, not a universal accounting policy or a report of a Blue LED project. Finance and operational owners must approve the checks for the selected platform and scope.

Keep the tests reproducible. Record the query or report definition and filters with the output. For financial comparisons, document transaction currency, reporting currency, conversion basis and decimal treatment separately where relevant. Adding different currencies into a single unqualified total does not establish a meaningful match.

For inventory, separate quantity validation from valuation validation. A correct item count does not demonstrate correct quantities, units, locations or values. Any finance-specific interpretation belongs with the customer's finance team and advisers.

Use four layers of acceptance evidence

1. Coverage and record accounting

Start with the source population, remove explicitly approved exclusions, and establish the eligible set. Account for that set through accepted records and named unresolved exceptions. If records are merged, split or summarized, retain a crosswalk that explains why source and target counts differ.

Avoid a single “migration success percentage.” Record which objects were checked and which remain pending, rejected or outside the tool's validation coverage. A small failure rate can still contain the records needed to operate on the first day.

2. Business totals and dimensions

Compare at the level where someone can make a decision: entity and currency for balances, item and warehouse for stock, or order and line for remaining quantities. Investigate differences before relying on a grand total.

Document how open-item imports relate to ledger opening balances, including which steps create postings. Ask finance to confirm the intended result and include checks for duplicate effects. Do not let separate load teams approve connected balances without reviewing the combined outcome.

3. Relationships and critical attributes

Test identifiers and links between records: invoice to customer, order line to product, supplier to payment terms, and stock to location. Include status, due date, unit, account and other fields that change how a record behaves.

For bilingual operations, select representative Arabic and English names, addresses and descriptions. Check full text, mixed-script identifiers, display, search and document output. Preserve the original value where transformations are intentional, and have the responsible business reviewer approve the result.

4. Real workflows with migrated records

Use migrated records in the agreed user acceptance scenarios with actual role profiles. Demonstrate the next business step, including relevant exceptions. Examples might include allocating a receipt to an open invoice or continuing a partially fulfilled order in a test environment.

Microsoft's go-live checklist calls for UAT with migrated data and correct security roles, repeated migration testing, and business sign-off. These checks connect data quality to the ability to operate.

Why matching totals can still hide a failed migration

Hypothetical example: a trial load contains 10,000 eligible open invoices. The target accepts 9,992 and rejects eight. The import log accounts for every attempted record, but the eight rejected invoices remain unresolved acceptance exceptions.

In a separate hypothetical test, all invoices are loaded and the combined outstanding balance matches. However, a balance of 5,000 in the same currency was assigned to Entity B instead of Entity A: Entity A is 5,000 short and Entity B is 5,000 high. The grand total hides the allocation error.

The decision should therefore use both record-level exceptions and totals grouped by the approved business dimensions. Resolve the source-to-target mapping, reload or correct through the supported procedure, and repeat the affected checks. Keep the original failure and the retest result together.

What can automated validation prove?

Database comparison can provide useful technical evidence when the migration path supports it. AWS DMS documentation describes source-to-target row comparisons, additional validation time and resource use, and distinct states for pending, mismatched or suspended records.

That is a product-specific example. It does not establish that AWS DMS can validate a particular SaaS ERP migration or that a copied value is appropriate for the business. Confirm the tool, endpoint support, transformations and coverage in your own design.

Ask the team to state which checks run automatically, which require reports or business review, and what cannot be checked by the chosen tool. A validation result should identify its scope and completion state, not merely show that the migration job ended.

Set tolerances before seeing the results

Agree the expected result and permitted variance for each check before rehearsal. A blanket “99% accurate” rule does not say which missing records or incorrect relationships the business can accept.

Use explicit rules instead. An identifier relationship might require an exact match. A rounding difference might be allowed only under a documented conversion rule, with a per-record limit and an aggregate cap approved by finance. An optional descriptive field might have a time-bound correction plan if its absence does not block an agreed process.

These are design examples, not recommended numerical thresholds. Never choose a tolerance after seeing a failure simply to make the report pass. Record each accepted exception, business impact, owner, corrective action, due date and approving authority.

Microsoft's data-management guidance assigns an important role to data stewardship and knowledgeable business users in cleansing decisions. The migration operator can produce evidence; the accountable business owner decides whether the data is fit for the agreed use.

Make the go/no-go pack easy to review

Prepare a short decision summary with links to the underlying evidence:

1. Scope: accepted dataset versions, entities, cutoff and exclusions.
2. Results: coverage, balances, relationships and workflow checks, with pass/fail status.
3. Exceptions: unresolved issues and separately documented, authorized acceptances.
4. Timing: measured extract, load and validation durations, plus remaining cutover capacity.
5. Recovery: decision owner, last safe stop point and tested recovery procedure.
6. Sign-off: named business and technical reviewers, decision and timestamp.
7. First-day checks: who will reconcile the first live transactions and handle new exceptions.

Microsoft's cutover guidance includes task owners, verification steps, rehearsal, rollback planning and a final go/no-go authority. Use that structure to make data acceptance an explicit checkpoint in the transition.

Clarify recovery after production activity begins. Returning to an earlier database state may leave new transactions or downstream systems inconsistent. Define the supported approach and decision boundaries with the platform and integration owners before opening the system to users.

What should you bring to a migration assessment?

Bring sample extracts, existing reconciliation reports, entity and currency lists, known quality issues, proposed historical scope and the planned cutover window. Name the people who can approve financial and operational results.

The Blue LED Global's integration and data migration service covers mapping, trial loads, reconciliation and cutover responsibilities. Its ERP implementation service connects migrated data and opening balances to configured business processes. The testing, training and support service connects acceptance evidence, issue retesting and support ownership.

Discuss these inputs with The Blue LED Global to define the migration checks and deliverables for your implementation. Scope, platform capabilities and customer responsibilities are agreed during discovery.

Practical questions

Is an import log enough to approve migration?

No. It shows processing outcomes within the tool's scope. Add business reconciliation, relationship checks, workflow tests and accountable sign-off.

Must source and target record counts always be identical?

No. Approved deduplication, splitting or summarization can change counts. Retain the mapping and prove that the intended records and business values are accounted for.

Can a rehearsal approval replace the final production check?

No. Rehearsal establishes readiness of the method. The final extract, load and configuration still need evidence against the agreed acceptance rules before release.

By Sawsan Sayad. Sources checked on 5 October 2026. The frameworks and examples above are planning recommendations to adapt to the agreed implementation.