Parallel operation
Parallel operation is the phase of an ERP implementation in which the old and new systems run live at the same time for a limited period. Transactions are recorded in both systems so that results can be reconciled and the new ERP validated before the legacy system is switched off.
In an ERP implementation, parallel operation refers to the phase in which the old and new systems both run live for a deliberately limited period. During this window, the same transactions – orders, postings, stock movements – are recorded or mirrored in both systems so that the results can be compared directly. Parallel operation is therefore a safety net: it allows the new ERP to be validated under real-world conditions without switching off the legacy system immediately, and to fall back on the proven state if something goes wrong.
Unlike a big-bang switchover, where the legacy system is replaced instantly on a cut-off date, parallel operation overlaps old and new for days to a few months. The phase ends with a deliberate decision to decommission the legacy system once the new ERP demonstrably delivers correct and complete results. The price of this added safety is a temporary duplication of data entry and reconciliation effort – which is why parallel operation is planned carefully and kept tightly time-boxed.
At a glance
- Old and new systems run live simultaneously for a limited time
- Transactions are recorded twice and the results are reconciled
- Purpose: validation, error detection and a fallback option before shutdown
- Temporarily costs double data-entry and reconciliation effort
- The counter-model to a big-bang switchover; often part of a phased rollout
How parallel operation works
In parallel operation, the current data set – master data, open orders, stock, open items – is migrated into the new ERP on a defined cut-off date. From that point on, both systems stay live: every new transaction is either posted manually in both systems or mirrored from the leading system into the second via an interface. At the end of defined periods – usually daily or weekly – the results are compared: if stock levels, revenue, open items and posting balances match in the old and new systems, the new system is considered confirmed for that segment.
The key question is which system leads during the phase. If the legacy system leads, the new system acts as a shadow runner and is merely validated; if the new system leads, the switchover is essentially already complete and the legacy system runs only as a control. Both variants are valid – the choice depends on how much confidence there already is in the new ERP and how critical an error would be.
Full and selective parallel operation
Full parallel operation mirrors all processes in both systems – demanding, but seamless. In practice, selective parallel operation prevails: only especially critical or error-prone areas, such as invoicing, inventory management or the month-end close, run in duplicate, while non-critical processes are handled straight away in the new system alone. This keeps the safety net taut where errors would be most expensive, without burdening the entire workforce with duplicate data entry.
Why parallel operation matters
The value of parallel operation lies in risk reduction. No test and acceptance procedure covers every edge case that live operation produces – unusual discount tiers, rare return constellations, borderline VAT cases. Parallel operation confronts the new ERP with exactly this real-world mix of transactions and makes discrepancies visible while the legacy system is still available as a reference and fallback. If an error surfaces, the correct values from the legacy system are available and operations do not grind to a halt.
At the same time, parallel operation builds trust among users and management: those who see for weeks that the new and old systems arrive at identical figures accept the switchover more readily. This benefit comes with clear costs – duplicate entry ties up staff, ongoing reconciliation requires discipline, and a parallel operation stretched too long wears the organization out. The rule is therefore: as long as necessary, as short as possible, with shutdown criteria defined in advance.
Parallel operation in the ERP switchover
Within an ERP implementation, parallel operation is one possible switchover strategy alongside the big bang and the phased rollout. It is frequently combined with the phased approach: one site or one functional area goes live, runs in parallel with the legacy system for a while and is only finally cut over after a successful reconciliation, before the next area follows. The go-live marks the beginning of parallel operation, not its end – the legacy system is decommissioned later in a controlled manner.
Technically, parallel operation requires either reliable interfaces that keep transactions synchronized between the two systems, or the willingness to do duplicate manual entry. For stock, clean inventory synchronization is central so that one system does not sell what is already sold out in the other. At the end comes a final data reconciliation that ensures all transactions created during the parallel period are present in the new system completely and correctly.
Distinction from big bang and rollout
A big-bang switchover shuts the legacy system off completely on the cut-off date – fast and cheap, but with no fallback net. Parallel operation is the lower-risk counter-model: it buys safety with double effort. A rollout, in turn, describes the entire spread of the system across users and sites; parallel operation and big bang are two possible patterns by which a single switchover within that rollout is carried out. Parallel operation is also not a permanent state: running two systems permanently would be a hybrid or best-of-breed architecture, not a switchover method.
Parallel operation and DACH compliance
In the DACH region, parallel operation touches on the principles of proper bookkeeping. In Germany, the GoBD require that accounting-relevant transactions be recorded completely, correctly, on time and in a tamper-proof way – if transactions temporarily run in both systems, it must be unambiguously documented which system is the leading one for the tax and commercial balance sheet, in order to avoid double postings and contradictory documents. The switchover itself, as well as the data handover, belong in the procedural documentation.
The legacy system being switched off must not simply be deleted: tax-relevant data is subject to retention requirements and must remain audit-proof and readable for the statutory period – either in the still-analyzable legacy system, in an archive system, or via an auditable export. Austria and Switzerland have analogous requirements. Anyone planning parallel operation should define the handover to DATEV or BMD and the cut-off date for the leading accounting early, so that the first close in the new ERP is clean and traceable.
Example
Example: a trading company secures invoicing through parallel operation
A mid-sized B2B trading company replaces its organically grown merchandise management with a modern ERP. Because an error in invoicing would immediately cost revenue and customer trust, the project team decides against a big bang and in favor of a four-week, selective parallel operation. On the cut-off date, master data, open orders and stock are migrated into the new system; from then on, every outgoing invoice is generated in both the old and the new ERP.
Every evening the team reconciles the invoice totals, tax amounts and open items of both systems. In the first week, two discrepancies come to light: an incorrectly mapped tax code and a discount tier that the new system rounds differently. Both are corrected without any customer receiving a faulty invoice, because the validated values from the legacy system are the ones sent out. From week three, the figures match consistently. After the month-end close, which likewise runs in duplicate without errors, the legacy system is switched to read-only mode and parallel operation ends.
Frequently asked questions
Matching ERP systems
Related services
Sources
Questions about Parallel operation in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.