ERP Migration — Strategies, Phases, Risks

An ERP migration — whether from a legacy system to a new platform, from on-premises into the cloud, or from one vendor to another — is one of the riskiest IT projects a mid-market company runs. Studies have shown for years that 50–70 % of ERP migrations miss budget or timeline targets, sometimes dramatically. Anyone starting a migration should approach it with professional methodology and realistic expectations.

This guide covers the most important migration strategies, the typical project phases and the failure modes that surveys keep finding, with practical recommendations for mid-market companies in the DACH region.

Migration strategies — big bang vs. phased

Three classic migration strategies are available:

Big Bang

All modules go live at the same time, the legacy system is switched off. Advantage: no interim interfaces between old and new are needed. Disadvantage: highest risk — everything has to work the first time. Big bang remains the standard for compact deployments (a single business unit, under 200 users) and for greenfield setups without a real legacy.

Phased / step-by-step

Modules are migrated one after the other (typically: financial accounting first, then sales, then production). Advantage: more controllable, learning effects between phases, lower per-go-live risk. Disadvantage: temporary interfaces between legacy and new system are required, with the operational overhead and reconciliation effort that brings.

Parallel operation

Legacy and new system run in parallel for a transition period. Advantage: comparability, very defensive variant. Disadvantage: double posting workload, high cost, frequent data-consistency problems and user confusion about which system is the source of truth. Parallel operation is rare today outside regulated industries that mandate it.

In the DACH mid-market the phased approach has become dominant, with big-bang elements for tightly coupled modules (e.g., accounting + sales going live together because the integration is too dense to bridge sensibly).

Phases of an ERP migration

Initiation (1–3 months): business case, investment decision, steering committee
Vendor selection (4–8 months): requirements document, longlist, demos, negotiation — see also our ERP RFP process playbook
Design (3–6 months): fit-gap analysis, customisation specification, interface design
Realisation (6–12 months): customisation, interface build, data-migration preparation
Test (2–4 months): module test, integration test, user acceptance test, load test
Cutover (1–4 weeks): final data migration, go-live weekend, stabilisation
Hypercare (2–6 months): intensive support, bugfixing, gradual handover to line organisation

A detailed task list per phase is in our ERP implementation guide.

Data migration as the critical success factor

Data migration is by far the most common cause of failed or delayed ERP projects. A methodical approach covers:

Data-source inventory: which data is in which system, in what quality, with which volumes?
Mapping: which fields in the legacy match which fields in the new system, with which transformations?
Cleansing: duplicates, missing values, format inconsistencies must be fixed before migration, not afterwards
Test migrations: at least three full dress rehearsals on real volumes, not synthetic samples
Reconciliation: automated count and total checks comparing legacy and new for every entity
Cut-over plan: minute-by-minute schedule for the migration weekend, with go / no-go decision gates

A common underestimation: master-data cleansing usually takes 3–6 months of dedicated effort and must start in parallel with the vendor selection, not afterwards.

Typical risks and countermeasures

Underestimated scope: the most common reason for budget overruns. Counter: rigorous fit-gap with a realistic customisation budget, not the vendor's optimistic baseline.

Insufficient user training: productivity collapse in week one is almost always a training problem, not a software problem. Counter: train-the-trainer with hands-on sandbox time, not slide-based classroom sessions.

Change resistance: if business users perceive the migration as imposed by IT, adoption fails. Counter: involve key users from day one, communicate the why, accept that some processes will need to change to fit the standard.

Insufficient testing: shortcuts in UAT and integration testing always cost more in hypercare than they saved in test. Counter: explicit test-coverage targets, no go-live decision without test-exit sign-off from the business.

Häufig gestellte Fragen

How long does an ERP migration take in the mid-market?

From initiation to stable live operation, a realistic estimate for mid-sized companies is around 18 to 36 months, depending on company size, module scope and customising depth. A large share of the project duration goes to conceptual design, customising and data migration, a smaller share to testing, training and the productive rollout. Promises of significantly shorter timelines are often unrealistic, since data migration and testing in particular tend to take more time than planned. The actual cutover weekend then usually lasts only a few days, but the subsequent stabilisation (hypercare) takes another two to six months.

Big bang or phased – which migration strategy is safer?

The phased approach is generally considered lower-risk because modules are migrated one after another and learning effects can be applied between phases, but it is more expensive due to temporary interfaces between the legacy and the new system. Big bang activates all modules simultaneously and avoids these interfaces, but concentrates the risk on a single go-live event. In practice, a hybrid form often prevails in the DACH mid-market, in which tightly coupled modules such as financial accounting and sales are switched over together as a mini big bang. Which variant fits depends on system complexity, the number of sites and the company's risk tolerance.

How much budget reserve should you plan for an ERP migration?

A reserve of around 20 to 30 percent on top of the vendor's quote is considered standard market practice — more for particularly ambitious or customising-heavy projects. Industry analyses show that a substantial share of ERP projects miss budget or time targets, frequently due to underestimated data migration, escalating customising and unplanned change requests. Licence fees usually make up only a smaller share of total costs; the bulk goes to implementation, customising, training and data migration. Strict change request discipline and a clear business case for every modification are the most effective levers against cost overruns.

How many test migrations are needed before go-live?

The data migration should never go live without several complete test runs; in practice, four to six test migrations with progressively improved data quality are common. At least the last two runs should complete without errors and within the planned time window, as they also demonstrate the realistic duration of the productive migration run. After each migration, reconciliation reports show whether, for example, posting totals and record counts match between the legacy and the new system. Any discrepancies must be fully resolved before the cutover is approved, since data errors are difficult to correct in live operation.

What happens to historical data and retention obligations during a migration?

Not all legacy data has to be transferred to the new system, but documents relevant under tax and commercial law are subject to statutory retention periods in Germany, which since the Fourth Bureaucracy Relief Act (Viertes Bürokratieentlastungsgesetz, early 2025) run to six, eight or ten years depending on the document type – accounting records such as invoices now have to be retained for eight instead of ten years, while books, annual financial statements and inventories still require ten years. If data is converted into a new format during migration, the GoBD require traceable process documentation of the lossless conversion as well as machine analysability and immutability of the archived records. Instead of carrying over the complete history wholesale, it is often sensible to migrate only the operationally needed data and keep the rest in a GoBD-compliant archive or audit-proof data export. Tax and legal advice should be sought on the specific setup, as deadlines and requirements can change.

How long should the legacy system remain available after go-live?

In practice, the legacy system is usually not switched off immediately but kept accessible at least in read-only mode for a transition period of often around three to six months. This allows historical orders, old documents or payments to be looked up and discrepancies to be reconciled with the new system while live operation stabilises. Permanent parallel operation with a double posting workload, by contrast, is expensive and error-prone and is usually avoided. Before the final shutdown, the continuing retention obligations must be taken into account so that records subject to retention are preserved in an audit-proof form.