ERP data migration: reconcile before you switch

Choose what needs to move

Separate master data, opening balances, open transactions and historical records. Not every old record needs to enter the live system. Agree a retention and access approach with the relevant business owners. Preserve original extracts so transformations can be reproduced and reconciled.

Resolve identity and units

Clean duplicate customers, suppliers and item codes before importing. Establish stable identifiers and an explicit unit-of-measure conversion map. For manufacturing, validate BOM revisions, effectivity dates and substitute components. A successful file import can still produce unusable planning if these relationships are wrong.

Reconcile quantities and values

Compare stock by item, location and tracking identifier, then reconcile valuation to the intended opening ledger. Review customer and supplier balances and the status of open orders. Document tolerances and investigate differences instead of forcing totals to match without explanation.

Use AI mapping with a review trail

AI can propose column mappings or identify anomalies, but the business still needs an accountable approval step. Retain the source field, target field, transformation rule and exceptions. Repeat the process with a final cutover extract and prevent transactions from being counted twice. Treat migration acceptance as a business control, not only an IT milestone.

Create a dependency order, not a folder of files

List each object and what must already exist before it loads. An open purchase order may depend on the supplier, item, unit, warehouse, currency and payment terms. A production order adds BOM, routing and revision dependencies. Draw these relationships and give each an accountable owner. Preserve legacy keys in a cross-reference map even when the new code differs. Load a small chain end to end before expanding volume. Record rejected records as work to resolve, not disposable noise. A migration dashboard showing only the count of imported rows can look successful while crucial relationships remain absent or point to the wrong master record.

Treat units as arithmetic with consequences

Illustrative example: one supplier sells boxes of 24, the warehouse counts individual pieces and production consumes sets of six. A receipt of ten boxes should create 240 pieces or 40 sets under the approved conversion rules. These are fictional test quantities. Repeat with a partial box, a return and a cost expressed per thousand pieces. Check precision, rounding and whether conversions are item-specific. Do not allow a single global conversion to stand in for different pack sizes. Have purchasing, warehousing and finance approve the result together. A unit error can leave the ledger balanced while physical availability, demand and unit margin are all wrong.

Preserve the meaning of open transactions

An open order is more than its unfulfilled quantity. Capture received but uninvoiced goods, deposits, allocations, promised dates, partial shipments, discounts and canceled lines where relevant. Decide whether historical documents remain in the archive or are reconstructed as opening transactions. Avoid importing a prior shipment and also reducing the opening stock for it a second time. Document the exact cutoff rule for every object. Have customer service process an amendment and finance apply a credit against a migrated order. If the new system cannot continue the transaction naturally, define the approved bridge and its reconciliation. A readable document image alone is not an operationally usable open order.

Make reconciliation explain differences

Reconcile at several levels: record counts, quantities by item and location, tracking identifiers, currency balances and general-ledger control totals. Investigate both aggregate and detail differences. Equal grand totals can hide one item overstated and another understated. Keep excluded and rejected records in an exception register containing source key, reason, owner and disposition. Do not use an unexplained balancing entry to make the check green. Where a deliberate policy change changes opening values, retain a signed bridge from the old basis to the approved new basis. Business Central's configuration-package documentation identifies a particular migration mechanism and its initial-setup context; choose tools for the actual lifecycle stage rather than assuming any successful import is appropriate.

Rehearse the final delta

A rehearsal proves transformations against a snapshot, but the business continues to trade afterward. Identify which changes must be captured between that snapshot and the final freeze: new masters, amended orders, receipts, shipments and corrected balances. Decide whether the final load replaces the rehearsal dataset or applies a controlled delta. Test the process twice to expose duplicates and nonrepeatable transformations. Save the script version, mapping version and source-file checksums used for each run. Give users a clear transaction freeze and restart message. Reopening the legacy system without a reconciliation plan can invalidate an otherwise accurate final load within minutes.

Build an archive people can actually use

Ask finance, service and quality teams which historical questions they need to answer after launch. Test retrieval by legacy order number, item, date and tracking identifier. Retain attachments and relationships where they are necessary to interpret a record. Set access, retention and deletion decisions with the responsible owners and advisers; this guide supplies no legal retention schedule. Price the archive separately from live-system migration so the tradeoff is visible. Before acceptance, have an ordinary authorized user retrieve a selected historical transaction without help from the migration specialist. Deliver the cross-reference map, transformation log, exception register and reconciliation pack to the operational team, not just to the implementation consultant.

Common questions

Continue your research

The following profiles provide a starting point for checking vendor-described scope. Inclusion is not a ranking or a statement that every requirement is supported.