ERP Data Migration
Data migration — moving data from a legacy ERP (or pre-ERP spreadsheet patchwork) into a new ERP — is the most consistently underestimated workstream in ERP projects. Migration typically consumes 10-25% of total implementation effort and is the single most common cause of go-live delays. Failed migrations bring down go-live weekends, force fall-back to the legacy system, and create trust damage that lingers for years.
What gets migrated
ERP data migration covers three categories. (1) Master data: customers, suppliers, materials, employees, chart of accounts, cost centres, BOMs, routings. Generally the largest in row count, often 100,000-5,000,000 rows in mid-market. (2) Open transactions: open sales orders, open purchase orders, open invoices receivable, open invoices payable, open production orders, inventory balances. Critical for day-one operations — if these are wrong, the new ERP cannot operate. (3) History: closed transactions for the past X years. Optional but often required for audit, customer queries and reporting continuity. Typically migrated in summary form (monthly balances) or via parallel-archive access to the legacy system.
ETL methodology and tools
Migration follows the ETL pattern (Extract, Transform, Load) with iterative trial migrations before the real one. Extract: pull data from legacy ERP, spreadsheets or operational systems into a staging area. Tools: legacy ERP's built-in export, SAP Data Services, IBM InfoSphere DataStage, Microsoft SSIS, Talend, Pentaho, or simple SQL exports. Transform: data cleansing, deduplication, format conversion, mapping legacy codes to new ERP codes. Often the biggest effort. Load: use the target ERP's import tools: SAP Migration Cockpit, Microsoft Configuration Package, Oracle FBDI, NetSuite CSV Import. Validation: structural checks (row counts, totals balance) plus business validation (sample transactions complete end-to-end). Cutover: a sequence of go-live activities compressed into 24-72 hours where legacy data is frozen, final migration runs and the new ERP opens for users.
Common pitfalls
- Underestimating data quality — the legacy data is rarely as clean as the team thinks. Plan for 2-5 cycles of cleansing and reload
- Late mapping decisions — deciding the target chart of accounts or material classification a month before go-live forces compressed migration work
- No trial migrations — running migration for the first time on go-live weekend is a guaranteed failure
- Ignoring open transactions — focusing on master data while leaving open AP, open AR and open inventory for the last week
- Missing audit-trail data — not capturing transaction sources for GoBD compliance after go-live
- Manual reconciliation as plan B — relying on humans to fix migration errors post-go-live
Realistic effort estimates
For a 50-user mid-market ERP project, plan 100-300 person-days for data migration: 30-50 person-days of mapping and analysis, 40-150 person-days of cleansing and transformation, 30-100 person-days of trial migrations, validation and cutover preparation. Cost in DACH consulting rates: 200,000-700,000 EUR for the migration stream alone. Larger projects with multiple legacy systems or multi-country master data scale to 1,500-4,000 person-days. The discipline that separates clean go-lives from chaotic ones is data ownership: every data set has a named business owner accountable for its quality at go-live.
Related Topics
Frequently Asked Questions
How many trial migrations should we plan?
Minimum three: first to test the technical pipeline, second to validate cleansing rules, third as a full dress-rehearsal under realistic timing constraints. Many projects do five or more for the master-data sets. Open-transaction migrations typically need fewer cycles because they happen on smaller data sets in a stable production-mirror environment.
Can we migrate years of history?
Technically yes, practically often not worth the effort. Migrating 5+ years of detailed transactions adds 30-100% to migration effort and rarely earns its cost. The pragmatic pattern: migrate balances and key reference data into the new ERP, retain the legacy system in read-only mode for 1-3 years for audit and customer queries, then archive.
Should we use the legacy system as a staging area?
No. Stage in a neutral environment (SQL Server, PostgreSQL, cloud data lake, or the new ERP's staging tables). Using the legacy system risks accidental updates and locks the cleansing work to a system that is about to be decommissioned. A clean staging environment gives the cleansing team room to work iteratively without affecting daily operations.