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.
The ideal time is after internal requirements have been clarified and before the first vendor contact. Starting too early wastes vendor appointments; starting too late reduces your negotiating leeway. Clear signals to start are documented knock-out criteria and an internal project team with a decision-making mandate. A lead time of 4-8 weeks before vendor selection is common.
Who should be involved in ERP data migration?
A mixed team of IT, business departments (accounting, sales, logistics depending on the module focus) and executive management. IT contributes the technical perspective, the business departments the process expertise, and management decides on budget and strategy. Ideally there is a dedicated project lead with 30-50% of their time available. Larger mid-market companies frequently also bring in external selection support — see selection advisory.
How long does ERP data migration typically take?
The duration varies greatly with complexity: simple setups take 4-8 weeks, mid-market ERP projects 6-12 months, corporate group transitions 18-36 months. The functional preparation phase is frequently underestimated — it accounts for 30-40% of the total project time. Realistic timelines factor in holiday and quarter-end peaks as well as typical delays in data migration. A buffer of 20-30% on the initial plan is standard industry practice.
What typical mistakes occur in ERP data migration?
Common pitfalls: no written requirements document, too few reference checks with vendors, underestimated data migration and a lack of change management for end users. Another mistake is committing to a vendor without a demo on your own data. Risk is minimised through a structured approach, written documentation and at least three vendors for comparison. External support significantly reduces the risk of wrong decisions.
Which tools or templates help with ERP data migration?
Proven aids are a structured requirements document, a weighted vendor evaluation matrix, a demo script with your own data and a RACI model for role clarity. Templates are available at requirements document template. In addition, a project tracking tool (Jira, Asana, MS Project) with milestone tracking is worthwhile. Weekly status calls with an escalation path are mandatory in every project phase.
