The Migration Danger Zone#
Data migration is where ERP implementations often go wrong. It happens late in the project, under time pressure, with limited opportunity for correction. Understanding migration failure patterns is essential for avoiding them.
Case Study 1: The Invisible Corruption#
Situation: A manufacturing company migrated from a legacy ERP to a modern cloud ERP. The migration appeared successful. Data volumes matched. Spot checks looked correct.
Discovery: Six months after go-live, inventory valuation was significantly wrong. Investigation revealed that unit of measure conversions had not been correctly migrated. Historical transactions used different units than the new system expected.
Impact: Financial restatement. Auditor concerns. Manual reconciliation required for months.
Root cause: Migration testing focused on data completeness, not data integrity in context.
Lesson: Test migration with end-to-end business scenarios, not just data reconciliation.
Case Study 2: The Duplicate Explosion#
Situation: A retail organisation migrated customer data from multiple legacy systems into a single ERP.
Discovery: Customer master contained massive duplication. A single customer might appear 5-10 times with slight variations in name, address, or contact details.
Impact: Credit limits ineffective—customers could exceed limits by using different "identities." Marketing communications sent multiple times to the same person.
Root cause: Master data deduplication was underestimated and underresourced.
Lesson: Invest in master data cleansing before migration. It never gets easier after go-live.
Case Study 3: The Missing History#
Situation: A professional services firm migrated to a new ERP with a decision to migrate only two years of historical data.
Discovery: After go-live, the firm realised that project profitability analysis required historical data that was no longer accessible. The legacy system had been decommissioned.
Impact: Inability to analyse multi-year projects. Loss of historical performance data.
Root cause: Historical data requirements were not fully understood before migration decisions were made.
Lesson: Document all historical data requirements before deciding on migration scope.
Case Study 4: The Encoding Disaster#
Situation: A multinational organisation migrated data including European and Asian characters.
Discovery: After migration, special characters were corrupted. Customer names, addresses, and product descriptions displayed incorrectly.
Impact: Customer communications showed corrupted names. Invoices had incorrect addresses.
Root cause: Character encoding was not consistently handled across the migration pipeline.
Lesson: Test migration with the full character set that will be encountered in production.
Case Study 5: The Orphan Transactions#
Situation: An organisation migrated transaction data but not all master data.
Discovery: Transactions existed without corresponding master records. Invoices without customers. Orders without products.
Impact: Reports failed. Transactions could not be processed. Manual cleanup required.
Root cause: Migration was performed in batches without referential integrity validation.
Lesson: Validate referential integrity as part of migration, not after.
Migration Success Patterns#
Successful migrations share common patterns:
Early assessment: Data quality is assessed early, revealing issues while there is time to address them.
Cleansing before migration: Data is cleansed in the source system before migration, not in the target after.
Comprehensive testing: Migration is tested with production-like data volumes and complexity.
Rollback planning: A clear plan exists to roll back if migration fails.
Parallel running: Old and new systems run in parallel long enough to validate data integrity.
Conclusion: Respect Migration Complexity#
Data migration is not a technical afterthought. It is a critical project phase that requires careful planning, adequate resources, and rigorous testing. The organisations that treat migration casually are the ones that appear in case studies like these.