Switching ERP Without Chaos: Migration & Data Transfer

An ERP switch goes off without chaos when you pick the right migration strategy, clean up your data before the transfer, and define a clear fallback for the go-live day. The system change itself is not a single button press but a planned transition from the old to the new system—with a deliberate choice between big-bang, parallel run and phased cut-over, a clean data migration, and a cut-over that is planned down to the last detail. This guide shows you how to set up the ERP migration so that day-to-day business keeps running and you are never left without a working system when things go wrong.

Choosing a Migration Strategy: Big-Bang, Parallel Run or Phased

The most important decision in an ERP switch is the migration strategy: it determines how and when the new system takes over operations. Three basic patterns have become established. Which one fits depends on company size, risk tolerance, process complexity and the resources available—there is no single "best" option that works for everyone.

Big-Bang: Everything at Once

With the big-bang approach, the old system is switched off on a fixed cut-off date and the entire company starts on the new system the next working day. The upside: no double maintenance effort, no data sets to keep in sync in parallel, one clean cut. The price is concentrated risk—if something goes fundamentally wrong on the cut-off date, it hits every area at once. Big-bang is best suited to small and mid-sized operations with manageable, close-to-standard processes and a thoroughly tested system.

Parallel Run: Old and New at the Same Time

In a parallel run, the old and new systems run side by side for a defined period, often with documents entered in both systems and the results reconciled. This lowers risk, because you can fall back on the still-active old system at any time and check the new system's data quality directly. The downside is the double workload: staff maintain transactions twice, which is tiring and error-prone. A parallel run should therefore stay tightly time-boxed.

Phased Migration: Module by Module, Site by Site

With a phased (or staged) migration, you go live area by area—for example warehouse management first, then financial accounting, or site by site. This spreads the risk and the learning curve across several smaller cut-overs. The catch: during the transition period, the old and new systems have to stay connected via interfaces so that data flows between the still-separate worlds. That raises the technical complexity.

If you are still at the start and comparing systems, you will find a market overview in the ERP directory. You are best off making the strategy decision together with your implementation partner and the business departments.

Data Transfer and Data Cleansing in an ERP Switch

The most common reason a system change ends in chaos is bad data. A new system full of duplicates, outdated items and inconsistent balances frustrates users from day one. Rule of thumb: data migration is largely cleanup work and only to a smaller extent technology.

Clean First, Then Migrate

An ERP switch is the best moment to get rid of legacy baggage. Before anything is transferred, you need to raise the data quality in the old system:

• Remove duplicates: merge duplicate customers, suppliers and items.
• Weed out dead records: data sets with no activity for years do not need to come along.
• Complete mandatory fields: add missing tax codes, units or accounts.
• Standardize formats: consolidate numbering logic, units of measure and address formats.

What gets migrated is primarily master data such as items, customers, suppliers and accounts, plus selected transaction data such as open items and current stock levels. Historical documents often stay in the old system, which is kept available for read access during the statutory retention period. That saves migration effort and at the same time meets the GoBD requirements on traceability and immutability of tax-relevant data. When in doubt, clarify how to handle old documents with your tax advisor.

Mapping and Test Migration

For every source field you define a target field—this field mapping is the translation table between the old and new system. Then comes the single most important safeguard against nasty surprises: the test migration. You run the transfer through in full at least once on a test system, spot-check the results against the source and log every error. Only once the test migration runs cleanly and the business departments confirm the transferred data do you go at the real data. This dress rehearsal is not optional—it is the difference between a plannable and a risky go-live day.

The Cut-Over: Planning the Switch-Over Moment Cleanly

The cut-over is the actual moment of change: the final data transfer, the last sign-off and the switch to live operation. It is usually scheduled for a low-turnover time—a weekend, a public holiday or the start of the month, when periods are closed anyway.

A cut-over plan answers three questions for every step: who does what, by when, and how do we know it worked? A proven sequence:

1. Set the cut-off date and lock the old system for new postings.
2. Migrate the delta: transfer the current stock levels and open items created since the last test migration.
3. Final check: reconcile balances, stock levels and document ranges against the old system.
4. Sign-off: business departments and project management formally release the go-live.
5. Switch over: set the new system live, activate accounts and interfaces.

Right after the cut-over, the hypercare phase begins with intensified support, during which the project team stays available and errors are worked through by priority. If you lack the internal capacity for cleanup, mapping and cut-over, external ERP migration as a service supports the entire transition.

Risks in an ERP Switch and How to Reduce Them

The typical risks of a system change are rarely purely technical. These are the points you should actively manage:

• Dirty legacy data: defused by early cleanup and test migration.
• Underestimated data volume: capture transaction data and special cases (batches, serial numbers, drop shipments) in good time.
• Process gaps: when a workflow works differently in the new system—run it through end-to-end in the test beforehand.
• Change resistance: involve users early and train them role-based on real processes.
• Time pressure on the cut-off day: plan generous time windows and clear abort criteria.
• Legal obligations: factor in GoBD, retention periods and e-invoicing from the outset (see below).

A word on e-invoicing, because it affects many ERP switches: in Germany, the B2B obligation to receive electronic invoices has been in force since 1 January 2025. The obligation to issue them is staggered—as a rule from 1 January 2027 for companies with more than 800,000 euros in prior-year revenue, and from 1 January 2028 for everyone. The format follows the EN 16931 standard (such as XRechnung or ZUGFeRD). When switching, check whether your new system can generate and receive these formats—a system change is the ideal moment to set this up correctly right away.

Fallback: The Plan B for the Worst Case

No go-live day without a fallback. It describes what happens if something goes so fundamentally wrong during the cut-over that live operation is not ready to start. A viable Plan B covers at least:

• Defined abort criteria: at what error picture is the go-live stopped, rather than "somehow pushing it through"?
• A working old system: in a big-bang it stays reactivatable for at least a defined period; in a parallel run it is still live anyway.
• Secured data states: a complete, verified backup from the cut-off date, so you can return to a known state.
• Clear communication: who decides on the fallback, and how are users and customers informed?

The big-bang in particular lives or dies by a resilient fallback, because everything switches over at the same time. The parallel run has the fallback more or less built in, but pays for it with double the effort. Define the criteria in writing and before the cut-over—when things go wrong there is no time for debates about first principles.

Conclusion

An ERP switch becomes plannable when you decide three things early: the migration strategy (big-bang, parallel run or phased), the approach to data transfer and cleansing, and the fallback for the cut-over. Most problems arise not in the technology but in dirty legacy data, underestimated data volume and a go-live day without a Plan B. If you clean the data before the transfer, rehearse the migration in a test migration, plan the cut-over step by step and keep a real fallback ready, you will bring your new system into live operation without chaos—and use the switch at the same time to clear out legacy baggage and open topics like e-invoicing for good.