ERP
ERP Data Migration: How to Avoid the Mistakes That Sink Projects
May 202511 min read
Photo by Unsplash
Photo by Unsplash
Ask any ERP project manager what keeps them up at night, and data migration will be near the top of the list. It is the workstream that is most frequently underestimated at the start of a project, most likely to surface hidden complexity mid-project, and most directly connected to go-live success or failure. Poor data quality in a new ERP system does not just cause inconvenience — it can trigger incorrect financial reporting, disrupt order fulfillment, and in regulated industries, create compliance exposure. Having led data migration workstreams on multiple SAP S/4HANA and Oracle Fusion implementations, I'll walk through the methodology, tools, and hard-won lessons that distinguish clean migrations from chaotic ones.
The root cause of most data migration failures is treating migration as a technical task rather than a business process. Data migration is fundamentally about business data quality — and business data quality can only be validated by business users, not by ETL developers. Organizations that assign migration entirely to the IT team, without meaningful business ownership and sign-off at each stage, consistently discover data quality issues too late to fix them before cutover.
Every organization believes its data is better than it is. The first data profiling exercise — running automated quality checks against the legacy data — almost always produces results that shock the business stakeholders who signed off on 'our data is fine.' Common findings include: customer records with missing payment terms or contact information, material master records with inconsistent units of measure across plants, vendor records with duplicate entries differing only by punctuation, and open purchase orders from three years ago that were never goods-receipted or cancelled. These issues are not just technical problems — each one represents a business decision that must be made before the data can be migrated.
Mapping legacy data fields to the new ERP schema sounds straightforward until you encounter the reality: the legacy system's 'customer number' is a free-text field that was used inconsistently across business units; the new ERP requires a strict 10-character alphanumeric format. The legacy system has 47 payment term codes accumulated over 15 years; the new ERP design has rationalized these to 12 standard terms. These rationalization decisions require business input, consensus, and documentation. Every mapping decision that gets deferred becomes a crisis during cutover.
Build your data migration mapping document in a format that business users can review directly — a simple spreadsheet with legacy field, target field, transformation rule, and example values is more effective than a technical ETL specification that only developers can read. Business ownership of the mapping is essential for quality sign-off.
A structured data migration follows a defined lifecycle with clear gates between phases. Skipping phases — particularly the mock cutover rehearsals — is the single most common cause of migration failures at go-live.
| Phase | Key Activities | Key Risk |
|---|---|---|
| Data Discovery | Legacy data profiling, record counts, quality assessment, issue cataloging | Underestimating issue volume; deferring business decisions on quality |
| Data Design | Field mapping, transformation rules, data rationalization decisions, migration object scoping | Incomplete mapping; unresolved business rules for edge cases |
| Data Cleansing | Source system cleanup, deduplication, mandatory field completion, business sign-off | Business not allocating time; cleansing deferred to post-go-live |
| Migration Build & Mock Runs | ETL build, three mock cutover runs, validation scripts, reconciliation reports | Insufficient mock runs; validation gaps discovered at real cutover |
| Final Cutover | Legacy freeze, final ETL run, balance validation, go/no-go decision, hypercare | Cutover window overrun; rollback criteria not pre-defined |
The choice of migration tooling depends on the target ERP platform and the complexity of the migration objects. For SAP S/4HANA, the primary tool is the SAP Data Migration Cockpit (DMCC), which replaced LSMW for most scenarios in the S/4HANA era.
The Data Migration Cockpit is S/4HANA's built-in migration tool, available via transaction LTMC (on-premise) or through the SAP Fiori launchpad (cloud). It supports over 450 standard migration objects — customer masters, vendor masters, material masters, open purchase orders, open sales orders, asset master data, and more. The workflow is standardized: download the migration template (an Excel or CSV file), populate it with your cleansed source data, upload it, run validation, and then execute the migration. The validation step is where most data quality issues surface. Every validation error maps to a business rule — a required field missing, a code value not matching the configuration, a foreign key reference that doesn't exist in the target system.
For complex migrations — particularly where multiple legacy systems are being consolidated, or where heavy data transformation is required — a dedicated ETL platform is often warranted. SAP Data Services (BODS), Talend, Informatica PowerCenter, and Microsoft SSIS are all used in enterprise ERP migrations. These tools excel at complex transformations, deduplication logic, and auditability — providing a full lineage trail from source to target that is valuable both for quality assurance and for post-go-live audit. For Oracle Fusion migrations, Oracle's own data migration tools (FBDI — File-Based Data Import) provide a similar structured template-based approach.
The single most frequent project management mistake in data migration is reducing mock cutover runs due to time pressure. Teams that have not run at least three full mock cutovers before the real cutover consistently discover issues during the real window — when there is no time to resolve them gracefully. Mock cutovers are not just technical rehearsals; they are the primary mechanism for validating data quality with business stakeholders, and for time-boxing the cutover window accurately. If your cutover plan says 'migrate customer masters in 2 hours' but mock run 1 took 4 hours, you cannot go live on that plan.
The cutover plan is the operational script that bridges from legacy to new ERP. It is a time-boxed, task-level document that assigns every step — system access, migration execution, validation, business sign-off — to a named owner with a planned start time and duration. It must be detailed enough that anyone on the team can execute any step, and it must include explicit go/no-go criteria and a defined rollback procedure.
Every cutover plan must define the conditions under which the project will roll back to the legacy system rather than go live. Common rollback triggers include: migration completion below a defined threshold at a defined time checkpoint (e.g., less than 90% of customer masters validated at Hour 6 of a 16-hour window), critical validation errors on financial opening balances, and failure of key business process smoke tests (a test order-to-invoice cycle) before the legacy system shutdown is confirmed. The rollback decision must be pre-authorized — defined in advance, not subject to real-time political negotiation when the team is exhausted and under pressure at 3am.
Run your final mock cutover on a system that has been refreshed with production-equivalent data — not a sandbox with stale test data. The confidence level difference between a mock on stale test data and a mock on a recent production refresh is enormous. The final mock should be indistinguishable from the real thing in terms of data volume, complexity, and business sign-off process.
Data migration does not end at go-live. The first two weeks after cutover are when users interact with migrated data for the first time in a live context and discover issues that no amount of pre-migration validation will have caught — a vendor with the wrong payment terms, a material with an incorrect valuation class, an open purchase order with a missing account assignment. Set up a structured data issue log with business owners, prioritize issues by financial or operational impact, and resolve them rapidly. Data quality issues that are not addressed in the first hypercare window tend to become permanent workarounds embedded in user behavior.
Key terms used in this article include ETL, DMCC (Data Migration Cockpit), LSMW, cutover plan, and data quality.