ERP migrations involve moving some of the most critical, complex, and interdependent data in the enterprise: chart of accounts, customer master, vendor master, open transactions, and historical financial data. The risks are high; the business disruption from a failed ERP data migration is severe; the planning requirements are correspondingly intensive.
ERP migrations involve moving some of the most critical, complex, and interdependent data in the enterprise: chart of accounts, customer master, vendor master, open transactions, and historical financial data. The risks are high; the business disruption from a failed ERP data migration is severe; the planning requirements are correspondingly intensive. ERP data migrations have derailed more transformation programmes than any other category of enterprise technology project.
What Makes ERP Data Migration Uniquely Difficult
**Interdependency.** ERP data entities are not independent. A sales order references a customer, a product, a pricing rule, a warehouse, and an accounting posting configuration. If any of these referenced entities do not exist in the target system in the correct form when the sales order migrates, the migration will fail, produce an error record, or silently create a malformed posting. Migrating ERP data requires migrating entities in the correct sequence and validating referential integrity at each stage.
**Business rule complexity.** ERP systems encode decades of business process decisions: account mappings for different transaction types, tax configurations, organisational hierarchies, intercompany relationship rules. Much of this configuration is not explicitly documented; it is embedded in the system and inferred from current outputs. Reproducing it correctly in the target ERP requires comprehensive configuration documentation before migration begins.
**Historical data requirements.** Open transactions (unpaid invoices, open purchase orders, work in progress) must migrate with all the data needed to process them: payment terms, pricing, approval status, delivery history. Historical closed transactions must migrate with sufficient detail to support period comparisons, audit trails, and regulatory compliance. The scope of historical data to migrate — and the level of detail required — is a significant decisions that affects both migration complexity and post-migration system performance.
**Cutover timing.** ERP cutovers must happen at a point where the data is in a clean state: ideally at a period-end (month-end, quarter-end, year-end) when all open transactions for the closing period have been processed. Migrating mid-period creates partial-period data that requires reconciliation and creates accounting complexity.
The Migration Scope Decision
Before technical work begins, the migration scope must be defined along several dimensions:
**Which entities migrate.** Full master data (chart of accounts, customers, vendors, products, employees, fixed assets) is almost always migrated. Transactional data scope is a decision: all open transactions (required), recent closed transactions (typically last 1–3 years for operational reference), and full historical archive (often retained in a legacy system or data warehouse rather than migrated into the live ERP).
**What data quality standard is required for migration.** Some fields are required for the target system to function; others are reference data that is desirable but not required. Defining the minimum quality standard for each field (required vs. desirable vs. optional) enables a realistic assessment of migration readiness and a prioritised data cleansing approach.
**How legacy data is cleaned before migration.** Data quality issues discovered in profiling require remediation before migration. Some remediation happens in the legacy system (deduplication, data correction); some happens in the migration transformation (mapping, defaulting, enrichment). The approach for each issue type determines the transformation logic in the migration tool.
Migration Phases for ERP
**Phase 1: Master data migration.** Chart of accounts, customers, vendors, products, and other reference entities migrate first. These are the entities that all transactional data references; they must exist in the target system before transactional migration can proceed. Master data quality has a multiplicative impact on transaction migration success: a customer master record with a missing required field will cause every sales transaction for that customer to fail.
**Phase 2: Open transaction migration.** Open purchase orders, open sales orders, open invoices, work in progress, and other transactions that are active at cutover migrate second. These require careful handling: they are mid-process, with dependencies on master data, pricing rules, and approval configurations that must be correctly reproduced.
**Phase 3: Historical data migration.** Closed transactions from recent periods migrate after cutover validation confirms that open transactions are correct. Historical migration can proceed in parallel with live operations in the new system, reducing cutover window pressure.
**Phase 4: Archive and legacy decommission.** Historical data beyond the migration scope (typically 3+ years) is archived in a data warehouse or read-only legacy system and decommissioned from the operational ERP environment.
Validation for ERP Migrations
ERP migration validation is more complex than typical data migration validation because the target outputs are financial reports, not data tables.
**Control totals reconciliation** — the sum of migrated balance sheet accounts must equal the closing balance from the legacy system. The sum of open invoice balances must match. The count and value of open purchase orders must match. These reconciliations are the primary validation that financial data migrated correctly.
**Transaction processing tests** — after migration, process a representative set of transactions in the new system: post an invoice payment, receive a purchase order, invoice a customer. The accounting postings produced by these test transactions should match the expected journal entries. If they do not, configuration errors in the target system are producing incorrect postings.
**Report comparison** — run the same financial reports (P&L, balance sheet, ageing reports) in both the legacy and target systems for the most recent closed period. Discrepancies indicate either a migration error or a configuration difference; each discrepancy must be investigated and resolved.
**User acceptance testing** — the finance and operations teams who use the system daily test the most common workflows before cutover. UAT catches configuration errors and usability issues that technical testing does not expose.
Our data architecture practice designs ERP data migration strategies for organisations undertaking major ERP transitions — contact us to discuss your ERP migration programme.
A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.
Book a Call →