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 US 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 the legacy system for audit access. Keep in mind that the IRS generally expects you to retain supporting tax records for at least three to seven years, so the legacy system must remain readable for that window even when the data is not migrated. 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 the legacy ERP, spreadsheets, and 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 the 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). Where financial data is in scope, build the validation around US GAAP and ASC 606 revenue recognition so opening balances and open receivables reconcile cleanly, and document the controls if the company is subject to SOX.
Specialized 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 the 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 a 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 an acceptable level. Trial 4 (performance validation): full timing under production-like conditions. Discover timing issues affecting the 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 a 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 the new ERP go-live. (2) Final extracts from the legacy system. (3) Transformation execution. (4) Load into the target ERP. (5) Validation with structural checks plus business validation. (6) Go/no-go decision: defined decision criteria; a clear rollback plan if the 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 the mid-market; up to 5 days for enterprise. Dedicated war-room operations with all stakeholders available throughout.
Realistic effort estimates
For US mid-market projects. Small (20-50 users): 30-100 person-days, $65,000-$275,000 data-migration cost. Mid-market (50-200 users): 100-300 person-days, $275,000-$875,000 data-migration cost. Upper mid-market (200-500 users): 300-800 person-days, $875,000-$2,750,000 data-migration cost. Enterprise: 1,000+ person-days, multi-million-dollar 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.