ERP Migration

ERP migration is the project of moving an organisation from one ERP system to another, or from an old release to a major new one. It is broader than a pure data migration: it covers process redesign, configuration, integrations, testing, training and the production cut-over. The trigger is often the end of support for a legacy product, a move to the cloud, or business growth that the existing system can no longer carry. For DACH SMEs the best-known example is the shift from older Dynamics or SAP releases to current platforms such as S/4HANA, but the discipline applies to any vendor change.

What a migration includes

An ERP migration is a programme made up of several work streams that run in parallel. Typical components are:

• Scoping and process design — deciding which processes are kept, simplified or changed, often captured in a functional specification.
• Data migration — extracting, cleansing, mapping and loading master and transactional data into the new system.
• Configuration and customising — setting up the standard system and any required customising.
• Integration — reconnecting interfaces to banking, e-invoicing, shop and logistics systems.
• Testing, training and cut-over — validation, user enablement and the switch to live operation.

Greenfield, brownfield and hybrid

Migrations are commonly classified by how much of the old setup is carried over. A greenfield approach rebuilds the system on standard processes and migrates only selected data. A brownfield approach converts the existing system in place, keeping configuration and history. Hybrid or selective approaches sit between the two, taking some entities greenfield and converting others. The choice is documented in the greenfield-vs-brownfield decision and has a large effect on cost, risk and how much historic data survives.

Risks and controls

The recurring risk areas are data quality, scope creep and an underestimated cut-over. Poor master-data quality in the legacy system surfaces during loading and can stall a go-live; cleansing therefore starts early, not at the end. In DACH projects, fiscal and compliance requirements add constraints: ledgers and documents must remain auditable under GoBD, and tax-relevant history often has to stay accessible for the statutory retention period, whether migrated or archived. A documented mapping, a test load against production-like data and a rehearsed cut-over plan are the standard controls.

Cut-over and go-live

Cut-over is the transition window when the old system is frozen, final data is loaded and the new system goes live. Organisations choose between a big-bang cut-over, where everything switches at once, and a phased rollout by site, module or company code. Big-bang is faster but concentrates risk; phased reduces risk but requires the two systems to interoperate during the overlap. A fallback plan and a defined acceptance check decide whether the new system stays live or the project rolls back. Total effort and cost are often assessed alongside TCO over the system's expected life.

Related Topics

• Greenfield
• Brownfield
• Data migration