Skip to main content

Data Migration in ERP Projects

Data migration is the transfer of business data from a legacy system into a new ERP — in practice an ETL exercise (extract, transform, load) applied to the ERP switch. It covers deciding what moves at all, cleansing what does, mapping legacy fields onto the new data model, rehearsing the load, and executing the final cutover. Migration quality determines go-live quality: an ERP that starts with wrong customer terms, stale part numbers, or unbalanced open items loses user trust in the first week. In US mid-market projects, migration is one of the most frequently underestimated workstreams — technically unglamorous, but on the critical path from day one.

The five phases

  1. Scoping: inventory every data object in the legacy landscape and decide per object: migrate, archive, or leave behind. The most expensive mistake is the default answer migrate everything — history that is only ever read belongs in an archive or a data warehouse, not in the new transactional system.
  2. Cleansing: deduplicate customers and vendors, retire obsolete items, complete mandatory fields, standardize addresses and units of measure. Cleansing is business work, not IT work — only the sales team knows which of three similar customer records is the real one.
  3. Mapping and transformation: define, field by field, how legacy structures translate into the new data model — chart-of-accounts conversion, new item numbering, payment-term codes, tax codes per state. Every rule is documented in a mapping specification that later doubles as audit evidence.
  4. Mock loads: full rehearsal loads into a test environment, validated with record counts, checksum comparisons, and — most importantly — business sign-off on samples: does this customer look right, does this open-order value match? Two to three mock loads before cutover are standard practice; the first one always fails in instructive ways.
  5. Cutover: the final, scheduled load during the go-live window, typically over a weekend or period-end. A cutover runbook defines the sequence, owners, verification steps, and the no-go criteria that would trigger a rollback.

Master data vs. transactional data

The two data families behave differently in migration. Master data — customers, vendors, items, bills of materials, the chart of accounts — must migrate, because nothing works without it; its challenge is quality and governance (see master data management). Transactional data — historical orders, invoices, postings — is where scope discipline pays off. Common US mid-market practice: migrate open items (open sales orders, open purchase orders, open AR/AP, current inventory balances) plus opening general-ledger balances, and keep deep transaction history in the legacy system in read-only mode or in a reporting database. Migrating years of closed transactions multiplies mapping effort and testing volume for data that is rarely touched again.

Budget share and timeline

In mid-market planning practice, data migration is commonly budgeted in the range of 10 to 15 percent of the total project budget, and it climbs beyond that when legacy data quality is poor or when long transaction history must be converted. The timeline error is more dangerous than the cost error: cleansing needs business users who also have day jobs, so it must start months before go-live, not in the final sprint. Teams that compress migration into the last project phase are the ones that postpone go-live. A phase-by-phase walkthrough with checklists is in the ERP data migration guide.

Common pitfalls

  • Cleansing in the target system: loading dirty data with the plan to fix it later — later never comes, and the new ERP inherits the old problems.
  • No single owner per object: without a named business owner signing off customers, items, and balances, validation becomes nobody's job.
  • Unrepeatable loads: manual, undocumented load steps that cannot be rerun identically make mock results worthless as a cutover rehearsal.
  • Ignoring reconciliation: opening balances must tie to the legacy trial balance to the cent; auditors will ask, and the mapping documentation plus load logs form the audit trail.

Selection criteria for US buyers

  • Import tooling: does the ERP offer robust, template-based import interfaces with validation and error reporting, or does every load require consultant scripting?
  • Staging and sandbox environments: mock loads need a target environment that can be reset cheaply and repeatedly — clarify what test environments cost and how fast they refresh.
  • Partner migration experience from your legacy stack: a partner who has extracted from your specific legacy system (QuickBooks, Sage, a legacy AS/400 application, a homegrown database) brings proven extraction routines and known mapping traps.
  • Validation reporting: ask to see the standard reconciliation reports — record counts, value comparisons, rejected-record logs — a migration produces out of the box.
  • Historical-data strategy: check options for read-only legacy access or low-cost archive storage so history does not force its way into migration scope.

Comparable terms

ETL is the generic extract-transform-load pattern; migration is its one-time, project-shaped application. Master data management is the ongoing discipline that keeps migrated data clean after go-live. Data conversion is often used synonymously with migration in US project language, sometimes narrowed to the mapping step. A migration done well is also the moment a company establishes its single source of truth.

Related Topics