ERP Data Migration Guide
Data migration is the workstream most consistently underestimated in ERP projects. While the glossary entry on data migration covers the conceptual foundation, this guide focuses on practical execution: scope decisions, methodology choices, tooling, common pitfalls and the discipline that separates successful migrations from chaotic ones. For DACH mid-market projects, the patterns described here reflect experience across dozens of mid-market implementations.
Scope decisions
Three fundamental scope decisions shape the migration. (1) What master data to migrate: customer, supplier, material, BOM, fixed-asset, employee. Typically all are migrated; the question is the cleansing depth. Master-data cleansing during migration is the highest-leverage data-quality investment in the entire ERP lifecycle. (2) What transaction history to migrate: open transactions (always migrated); closed transactions (sometimes, partial, controversial). The pragmatic pattern: open transactions plus 12-24 months of closed history; older history retained in legacy system for audit access. Migrating 5+ years of detailed history almost always costs more than the value delivered. (3) What configuration to migrate: pricing rules, approval workflows, report definitions, output formats. Usually rebuilt rather than migrated; greenfield design intent dominates. Brownfield migrations preserve more configuration automatically.
ETL methodology in practice
The Extract-Transform-Load (ETL) pattern structures migration work. Extract phase: pull data from legacy ERP, spreadsheets, operational systems into a staging area. Tools: SAP Data Services, Microsoft SQL Server Integration Services (SSIS), Talend, Pentaho, simple Python or SQL exports. Modern projects use cloud-native data-warehouses (Snowflake, BigQuery, Azure Synapse) as staging environment. Transform phase: cleansing, deduplication, format conversion, mapping legacy codes to new ERP codes. The largest single effort. Modern approaches use dbt (data build tool) for SQL-based transformation with version control. Load phase: use the target ERP's import tools: SAP Migration Cockpit, Microsoft Configuration Package, Oracle FBDI, NetSuite CSV Import. Validation: structural checks (row counts, totals) plus business validation (sample transactions complete end-to-end).
Specialised migration tools
For complex migrations, specialist tools accelerate the work. SAP migration: SNP CrystalBridge (now SNP Glue), Cbs Enterprise Transformer, SAP Data Services, Datavail. Microsoft Dynamics 365 migration: To-Increase Data Migration, Microsoft Configuration Package, custom Power Query scripts. Oracle Cloud ERP migration: Oracle Cloud Migration Tools, partner-built data-migration accelerators. Cross-platform: Informatica Intelligent Cloud Services (IICS), Talend Cloud, Apache Airflow (open-source orchestration). Selective data transition: SNP CrystalBridge and Cbs Enterprise Transformer support the bluefield pattern, migrating selected data subsets rather than full historical migration. Tool choice depends on source-and-target platforms and project scale; specialist tools pay back at upper-mid-market and enterprise scale.
Trial migrations as success factor
Multiple trial migrations are non-negotiable for serious projects. Trial 1 (technical pipeline): verify the technical extract-transform-load works end-to-end on subset of data. Discover technical issues. Trial 2 (full data, cleansing validation): full data set with first-pass cleansing. Discover data-quality issues needing cleansing rules. Trial 3 (cleansing completion): refined cleansing rules applied; data quality at acceptable level. Trial 4 (performance validation): full timing under production-like conditions. Discover timing issues affecting cutover weekend. Trial 5 (dress rehearsal): complete cutover simulation with hour-by-hour timing. Final pre-production verification. Each trial reveals issues that would otherwise surface during the actual cutover. Companies attempting production cutover with 0-1 trial migrations consistently experience extended downtime or rollback scenarios.
The cutover weekend
The cutover weekend (or longer cutover window for complex migrations) compresses high-risk activities. Standard runbook activities: (1) Legacy data freeze on Friday end-of-business. No further data entry until new ERP go-live. (2) Final extracts from legacy system. (3) Transformation execution. (4) Load into target ERP. (5) Validation with structural checks plus business validation. (6) Go/no-go decision: defined decision criteria; clear rollback plan if go-decision is 'no'. (7) Production opening with selected key users for first-day operations. (8) Full opening Monday morning with hyper-care support. Typical duration: 24-72 hours for mid-market; up to 5 days for enterprise. Dedicated war-room operations with all stakeholders available throughout.
Realistic effort estimates
For DACH mid-market projects. Small (20-50 users): 30-100 person-days, 60,000-250,000 EUR data-migration cost. Mid-market (50-200 users): 100-300 person-days, 250,000-800,000 EUR data-migration cost. Upper mid-market (200-500 users): 300-800 person-days, 800,000-2,500,000 EUR data-migration cost. Enterprise: 1,000+ person-days, multi-million EUR cost. Data migration typically represents 10-25% of total implementation cost; complex multi-source migrations can reach 30-40%. Companies that under-budget data migration consistently overrun the total ERP project budget.
Related Topics
Frequently Asked Questions
How do we estimate cleansing effort?
Cleansing effort scales with master-data quality. As a rough heuristic: each duplicate-customer pair takes 5-15 minutes of human review; each material-master with missing classification takes 10-30 minutes. For 50,000 customer records with estimated 5% duplicate rate, plan 200-600 hours of cleansing review. The estimate is rough; actual experience varies based on data complexity and team experience.
Should we migrate or archive historical data?
Archive in most cases. Detailed transaction history typically delivers little operational value in the new ERP. Audit and customer-query needs are met by legacy-system retention in read-only mode. Migration cost-benefit rarely justifies migrating more than 12-24 months of detailed history.
What is the typical cutover-weekend timeline?
Mid-market: 36-60 hours from Friday evening to Sunday evening. Upper mid-market: 48-72 hours. Enterprise: up to 5 days. The timeline depends heavily on data volume, validation activities and dress-rehearsal results. Compressed cutovers (under 24 hours for mid-market) require very mature processes and discipline.