The ERP Data Migration Guide

A real migration scope typically includes master data (customers, suppliers, items, bills of materials, chart of accounts) and open transactions (unpaid invoices, open purchase orders, in-progress work orders) — closed, historical transactions are sometimes migrated in summary form rather than record-by-record, since the operational need to act on them has passed. Decide this scope explicitly and early; it's a real cost/completeness tradeoff, not an oversight to gloss over.

Static master data (an item's name, unit of measure, a customer's billing address) is comparatively straightforward to migrate and validate. Open transactions are harder: an in-progress purchase order has to land in the new system at the correct lifecycle stage, not just as a flat record, or the receiving and invoicing process breaks when someone tries to act on it. Give open-transaction migration extra scrutiny and a dedicated reconciliation pass.

A migration script completing without an error is not the same as a migration being correct — record counts matching, sample records spot-checked field by field against the source system, and financial totals (like accounts receivable aging) tying out are what actually confirm a migration succeeded. Budget real time and a named owner for this step; it is not optional busywork.

Be skeptical of any vendor claiming a fully automated, zero-manual-verification migration — real source systems have real inconsistencies (duplicate customer records, inconsistent unit-of-measure conventions, stale supplier data) that automated tooling can flag but rarely resolves correctly without a human decision. A credible migration process names the manual verification steps explicitly rather than implying they don't exist.