01 What exactly is an ERP data migration?
An ERP data migration consists of transferring data from one management system to another: from a legacy ERP to S/4HANA, from a homegrown system to IFS, or from several merged instances into a single one. But the honest definition is more demanding. It means rebuilding a data estate inside a model that does not expect it.
Two workstreams need explicit ownership. The system migration covers installation, configuration and training. The data migration covers extraction, transformation, qualification and loading. They constrain each other and need a shared plan with the integrator and business teams.
The target model and its interfaces must be understood alongside the history of the sources. Unexamined source data creates risks that a technically successful deployment does not resolve.
Migrating a technical repository (Windchill, 3DEXPERIENCE, Teamcenter) rather than a management system? Product structures follow different rules: see the PLM data migration guide.
02 The link that decides whether the project succeeds
ERP disruption can affect manufacturing, shipping and customer service. Our article on the cost of a failed migration examines Revlon, Hershey and Navy reports, distinguishing sales effects from additional charges and programme expenditure.
These reports do not isolate data migration as the sole cause. For your programme, a wrong value loaded into an ERP that drives production, inventory and invoicing is a concrete risk to test before cutover.
03 Which data to migrate, and which to leave behind
Migrating everything is as costly a mistake as migrating too little. Scope is decided by category:
- Master data (parts, bills of materials, customers, suppliers, chart of accounts): the heart of the job. It must be qualified, deduplicated and shaped to the target model. This is where the quality of the future system is decided;
- Open transactional data (in-flight orders, inventory, work in progress, unsettled postings): essential for business continuity, and the most sensitive to cutover timing;
- History: decide what must remain operational in the target and what can stay in a searchable archive, taking account of access and retention requirements. Compare the costs on your actual scope.
04 Everything starts with an audit of the real data
Before deciding anything, you need to know what actually exists: effective volumes, duplicates, orphaned objects, diverging reference data, accumulated exceptions. The data audit is the phase everyone overlooks, yet it is the one that conditions all the others.
A serious audit extracts and profiles the entire source dataset, not a convenient sample. Its deliverable is a quantified map of the risk: what goes through as-is, what needs a rule, what requires a business decision. Without it, the project plan rests on assumptions. And assumptions are exactly what makes migrations fail.
On an undocumented legacy system, the audit carries more weight still: the profile of the values is the only specification that survived, and reading it back is most of the work.
05 Big bang, phased, or trickle: choosing your approach
The cutover strategy determines when responsibility moves from the source system to the target. Choose it after measuring volumes, dependencies, acceptable downtime and coexistence requirements.
Big bang moves the agreed scope within one cutover window. It concentrates the operational risk, so timings, acceptance criteria and rollback must be rehearsed.
Phased cutover moves by site, domain or data family. Each wave needs a coherent boundary, temporary interfaces and clear ownership of shared data.
Trickle migration moves data incrementally during coexistence. Define the authoritative system for each data family and how changes propagate; bidirectional synchronisation is needed only where both systems must write.
This choice is distinct from the earlier decision on how source data conforms to the target model.
Comparing cutover strategies | Strategy | Organisation | Main constraint | Evidence before cutover |
|---|
| Big bang | One window for the agreed scope | Downtime and recovery after new transactions begin | Full-volume rehearsal, timed reconciliation and a tested rollback plan |
| Phased | Successive waves by coherent scope | Shared data and temporary interfaces between waves | Dependency map, ownership rules and reconciliation across systems |
| Trickle | Incremental transfer during coexistence | Capturing changes and resolving conflicting writes | Measured replication lag, conflict rules and final reconciliation |
06 What the migration tooling must support
Tooling must make transformations, load status and corrections repeatable. This can be built with scripts or a dedicated platform; the requirement is reproducibility and visibility over failures.
An asynchronous chain with per-record status and replay is one approach. Plan full-scope rehearsals and track what each one establishes: remaining discrepancies, business checks and cutover duration.
07 The five phases of a controlled migration
Our full methodology details each phase; in short:
- 01 · Audit: measure the real scope, the volumes, the anomalies. Reality before assumptions;
- 02 · Build: build a configurable, traceable, repeatable chain with status tracking, reconciliation and replay;
- 03 · Run / Fix: execute on real scopes, correct every discrepancy, loop until stable;
- 04 · Dry Run: the dress rehearsal, at real volume, across the complete chain;
- 05 · Go-Live: cutover after reviewing acceptance criteria, outstanding issues and rollback arrangements.
08 The pitfalls that cost the most
Five risks to include in the migration plan:
- Validating only on clean samples. Use difficult cases during development and full-scope reconciliation before acceptance.
- Confusing valid data with qualified data. A record that is correct in the old system can violate the target model. S/4HANA is the textbook case: MATDOC, ACDOCA and the universal journal do not forgive unshaped reloads, and the standard toolchain validates structure rather than meaning;
- Trusting native tools. Standard bridges move records, not structures. The Windchill to 3DEXPERIENCE case shows it: links, BOMs and lifecycles must be rebuilt, not copied;
- Discovering volumes at load time. Initial estimates may miss sources or history; measure and reconcile the scope early.
- Freezing the code too early, the data too late. Data keeps living until cutover day: the chain must absorb the deltas, not suffer them.
09 What determines the budget
The estimate accounts for source systems, data families, interfaces, history and dependencies. Record volume matters, as does the number of rules and business decisions needed to make the data usable in the target.
Before an audit, list these inputs and identify the business owners available to arbitrate. A count of systems or a percentage of ERP licence cost is not sufficient to price the work.
The readiness audit is scoped and quoted separately. Its findings support the estimate for transformations, iterations, reconciliation and cutover.
10 A real anonymised case: 400,000 parts, two truths
An industrial group, four production sites, migrating a homegrown ERP and two site-level systems to a single S/4HANA instance. The integrator was in place, the functional design was signed off, and the data workstream was scheduled as a two-month task near the end of the plan.
What the audit found. The declared scope was 250,000 active parts. The extraction returned 412,000, because two sites had kept creating records in a legacy system everyone believed had been switched off in 2019. Of those, 61,000 were duplicates across sites: the same physical component with different codifications, different units of measure, and in 9,000 cases different suppliers listed as sole source. No single system held the truth, and no rule could pick a winner: only the site engineers could.
What was corrected. The deduplication was not automated, because it could not be. It was turned into an arbitration workflow: the chain grouped candidate duplicates, presented them with their usage and their stock, and routed each group to the site that owned the part. The engineering effort went into the routing and the audit trail, not into a matching algorithm that would have guessed wrong 9,000 times. In parallel, the unit-of-measure conversions were rebuilt as explicit rules rather than inferred from the target model.
Result. The arbitration took eleven weeks of part-time work from four site teams, which is the number nobody wanted to hear and the reason the go-live moved by one quarter. The migration itself ran twenty-eight full passes before cutover. Go-live weekend loaded 351,000 parts with 240 rejects, all of them qualified and replayed within the window. No production stoppage.
The honest reading of this case is not that the migration went well. It is that the two months allocated to data were wrong by a factor of five, and the audit is the only reason anyone found out while the date could still move.
11 Data migration checklist
The short version, in the order that matters. If you can answer all of these with a measurement rather than an estimate, your plan rests on something.
- Inventory and extract every source in scope, including systems believed to be inactive; verify that status;
- Measure records and anomalies: counts by family, duplicates, orphaned objects and target-model violations;
- Separate automated rules from business decisions and reserve arbitration time in the plan;
- Name a business owner per data family, with authority to decide;
- Agree the history scope, access needs and retention requirements;
- Make the chain repeatable, with per-record status and replay;
- Test values and business processes, then reconcile the full scope; see what each test establishes;
- Plan changes after extraction: capture, transform and reconcile deltas;
- Run a full-volume dry run, including target interfaces and timed reconciliation;
- Agree rollback authority, thresholds and deadline before the cutover window.