You have made the decision to migrate to a cloud ERP. The contract with the integrator is signed, the kick-off meeting has taken place, the project is underway. And then a reality sets in that few project documents had truly anticipated: for the next eighteen to thirty-six months, you will be running two ERP systems in parallel.
This is not a failure. It is the norm. Large-scale ERP migration projects never switch over in a big bang overnight. Most are spread over several years, with a coexistence phase where the old system remains in production on certain perimeters while the new one ramps up on others. According to Panorama Consulting data (2024 ERP Report), 68% of ERP projects exceed their initial timeline. A significant share of this overrun happens precisely during this coexistence period, which is often poorly planned.
Most articles cover the decision to migrate, the vendor selection, or the go-live. This article covers what comes after the partial go-live: the four phases of coexistence, the concrete risks, and the governance decisions that determine whether the transition goes smoothly or drags on for five years instead of two.
The Bimodal Reality: A Structural Fact, Not an Anomaly
The term “bimodal” was coined by Gartner in 2014 to describe an IT organization managing two modes simultaneously: a Mode 1 focused on the reliability of core systems, and a Mode 2 dedicated to innovation and new capabilities. In the context of an ERP migration, bimodality takes a very concrete form: your on-premise ERP remains the system of record for accounting and logistics, while the new cloud ERP takes over commercial management or human resources.
The problem is not running two systems. The problem is running them without anyone being certain, at any given moment, which system is the source of truth for a given piece of data.
Managing coexistence effectively means answering that question continuously — for every process, every module, every data flow. What this article proposes is a four-phase framework to answer it methodically.
Phase 1 (Months 0–3): Map the Coexistence Before It Overwhelms You
The first mistake is starting the migration project without producing a document dedicated to coexistence. The migration plan describes the target state. The coexistence plan describes the transition state — which will last far longer than expected.
The Coexistence Matrix: Your 24-Month Compass
The main deliverable of this phase is a coexistence matrix. It cross-references three dimensions: processes (procurement, sales, accounting, logistics, HR, etc.), the system hosting them (legacy, cloud, or both in parallel), and the target cutover date. This matrix must be validated by the steering committee and updated at each phase review.
It allows you to immediately answer questions such as: “Where do we create a new supplier in September?” or “Which system shows available stock in real time in March?” Without this matrix, business teams improvise. And improvisation in a bimodal context produces duplicates, data inconsistencies, and unnecessary escalations.
iPaaS or Native Connector: The Integration Architecture Decision
Once the matrix is established, the second Phase 1 decision is the integration architecture between the two systems. Two main options:
- Native connector: most cloud vendors offer pre-configured connectors to the most widely used ERPs (SAP ECC, Oracle E-Business Suite, Microsoft Dynamics AX). These connectors cover standard flows but show their limitations on heavily customized processes.
- iPaaS (Integration Platform as a Service): platforms such as Boomi, MuleSoft, or Workato enable you to build custom integration flows. They offer more flexibility but require integration expertise and an additional budget (licences and implementation from €60,000 to €200,000 depending on complexity).
The decision rule is straightforward: if more than 30% of your processes have been customized in the legacy system, a native connector will be insufficient. You will need an iPaaS.
Identify Duplicate Data From Day One
The third task of Phase 1: catalogue the entities that will exist in both systems during the coexistence period. Typically: the third-party master data (customers, suppliers), products and pricing, open orders at the partial cutover date, and management accounts.
For each duplicated entity, you must decide immediately: which system is master (source of truth)? Which system is slave (it receives a read-only copy)? This decision must be documented and non-negotiable throughout the entire coexistence phase.
Phase 2 (Months 3–12): Two Systems in Production, Zero Chaos
This is the longest and most risky phase. Both systems are in production on different perimeters. Teams are learning the new system while maintaining the old one. Incidents occur precisely in flows that cross both environments.
Synchronization Architecture: Real Time or Batch?
Not all data requires real-time synchronization. Knowing where to set the threshold is a decision that directly impacts infrastructure costs and interface complexity.
As a general rule, high-impact operational processes require real-time or near-real-time synchronization (every 5–15 minutes): stock availability for order entry, shipment status, active prices and commercial terms. A 24-hour lag on these flows produces errors visible to customers.
By contrast, management and reporting data tolerates a daily or weekly batch: management KPIs, budget vs. actuals, project portfolio. Most finance functions accept a management close with a J-1 lag.
Recommended architecture for Phase 2: designate the new cloud system as the “golden record” for all entities it owns. The legacy receives read-only copies. Never the reverse. This asymmetry, once rigorously enforced, eliminates 80% of reconciliation problems.
Access Rights Governance: The Detail That Makes or Breaks It
The question “who can create a customer in which system?” seems trivial. It is in fact the source of the majority of third-party duplicates seen during coexistence phases.
The rule to apply from the very first day of Phase 2: each process for creating or modifying a master entity can only take place in one system, with a single validation workflow. If a sales rep creates a customer in Salesforce, and that customer is automatically synced to the legacy ERP as a read-only record, the legacy must no longer allow the manual creation of a new third party with the same name or company registration number.
This governance requires careful configuration of access rights in the legacy system. This is often where projects cut corners they should not: disabling write access in the legacy is politically difficult because legacy teams are used to working autonomously. It is nonetheless non-negotiable to avoid duplicates.
Bimodal Financial Close: Three Accounting Traps to Avoid
The monthly close with two ERPs running in parallel is the acid test of Phase 2. Three recurring accounting traps:
Trap 1: prepaid expenses and accruals. If a supplier invoice is recorded in the legacy but relates to a service delivered within the new system’s perimeter, the analytical allocation and matching can diverge between the two databases. Solution: define a single allocation rule in Phase 1 and have it validated by your auditor before the first bimodal close.
Trap 2: cross-system provisions. Provisions for disputes or inventory can be entered in either system depending on the accounting manager’s scope. Without an explicit rule, they risk being entered twice — or forgotten in both. The rule to establish: provisions are always entered in the system that hosts the underlying operational cost.
Trap 3: data consolidation. With two separate databases, consolidating financial dashboards requires a reporting tool capable of querying both systems. If your current BI tool supports only one connector, anticipate this requirement at the start of Phase 2 — not two weeks before the year-end close.
Phase 3 (Months 12–24): Reducing the Legacy Footprint, Module by Module
Phase 3 is where the migration actually progresses. Each module switched over to the new system reduces the coexistence surface and simplifies the interfaces.
Which Module to Migrate First?
There is no universal answer, but two logics compete:
“Finance first” logic: migrating general and management accounting first provides a single financial reference. The monthly close becomes straightforward again. In return, interfaces with the legacy operations (procurement, logistics) are complex during the transition period.
“Operations first” logic: migrating logistics and procurement first reduces operational risks visible to customers and suppliers. Accounting temporarily remains in the legacy, with an interface to the cloud for stock movements and invoices.
In practice, service businesses often migrate finance first because their logistics is simple. Manufacturers and distributors migrate operations first to avoid disrupting the value chain.
Five Signals That a Legacy Module Is Ready to Be Switched Off
Before switching off a module in the legacy system, verify these five conditions:
- Zero open transactions: all open orders, unmatched invoices, and active provisions have been transferred or cleared in the new system.
- Historical data accessible: data from the last five years is available in read-only mode from the new system or from structured archiving (see Phase 4).
- Interfaces disabled: no automated flow is still writing to the legacy module. Verify in integration logs, not just in documentation.
- Users trained and self-sufficient: the adoption rate in the new system exceeds 80% for the relevant functions. Below that, the legacy module will be reactivated under user pressure.
- CIO + CFO co-sign-off: mandatory before shutdown. The CIO validates technical feasibility; the CFO validates the absence of accounting or tax risk.
Phase 4 (Months 24–36): Final Cutover and the Safety Net Period
From around month 24, the majority of operational processes run in the cloud ERP. The legacy is in residual mode: a few accounting modules, historical data, and a handful of users who “check the old system” out of habit or genuine need.
Legacy in Read-Only Mode: How Long Should You Keep It?
The answer is not technical — it is regulatory. Requirements vary by jurisdiction, but accounting data typically must remain accessible for 7–10 years (10 years in France, 7 years in Germany, 6 years in the UK under the Companies Act 2006, and generally 7 years in the US for tax purposes). Supporting documents — supplier invoices, expense claims — must remain accessible for the duration of the applicable statutory limitation period, which varies from 3 to 7 years depending on the jurisdiction and type of audit exposure.
In practice, keeping the legacy in read-only mode for 12–18 months after the final cutover is a reasonable duration to handle ad hoc queries from business teams and potential audits. Beyond that, structured archiving (exporting data in a durable, indexed format) is more cost-effective than maintaining a full infrastructure.
Decommissioning Checklist (Phase 4)
Before permanently switching off the legacy:
- Data archived in accordance with the applicable legal retention framework (accounting, contracts, payroll — verify requirements per jurisdiction)
- Open archival format, documented and indexed (structured CSV, XML with XSD, or a certified SAE platform meeting ISO 14721 / OAIS standards)
- Vendor and maintenance contracts terminated with the required notice periods
- Servers decommissioned in accordance with data protection obligations (secure erasure of personal data)
- End-of-project audit documented: actual scope vs. initial scope, actual costs vs. budget, coexistence incidents catalogued
The 3 Most Common Incidents in the First 30–90 Days After Final Cutover
Even after a successful cutover, three incidents recur regularly in the first few weeks:
Incident 1: missing data. A user looks for a 2023 document and cannot find it in the new system because the historical migration was limited to three years. Preventive solution: clearly document the scope of the historical migration and train users to use the archiving interface for older data.
Incident 2: undocumented interfaces. An interface with a third-party system (EDI, customer portal, payroll software) continues sending data to the legacy. The integration was omitted from the migration scope because no one knew it existed. Preventive solution: map all interfaces in Phase 1 from network logs, not just from IT documentation.
Incident 3: regression on regulatory reports. A VAT export or reconciliation report produced by the new system does not match exactly the format expected by the tax authority or the auditor. Preventive solution: test regulatory reports in parallel with the legacy at least three months before the final cutover.
Budget and Resources: The True Cost of Coexistence
Bimodal coexistence has a direct cost that must be budgeted explicitly — not absorbed into the migration budget.
The Cost of Running Dual Infrastructure
As long as the legacy is in active production or supervised read-only mode, it generates costs: vendor licences, server infrastructure or hosting, monitoring and support. For an on-premise ERP at a mid-market organisation, these costs typically fall between €80,000 and €200,000 per year (infrastructure and support, excluding the cost of the internal team maintaining it). Multiplied by two to three years of coexistence, this is a material line item that the new ERP business case must include to be honest.
ERP Today (source) recommends explicitly allocating 15–20% of the total migration project budget to legacy decommissioning, including coexistence and archiving costs. Organisations that fail to anticipate this line item often extend the coexistence period due to budget constraints — which paradoxically increases total costs.
Human Resources Dedicated to Coexistence Management
At the peak of Phase 2 (months 3–12), a well-managed organisation typically allocates:
- 0.5 to 1 FTE dedicated to monitoring interfaces between the two systems (log checks, rejection management, reconciliation of divergent data)
- 0.25 FTE in finance for managing bimodal closes and producing consolidated reports
- A one-hour weekly touchpoint between the migration project manager, the legacy owner, and the cloud system owner to triage coexistence incidents
These resources are often absorbed by existing teams without being tracked. The absence of traceability for this cost systematically understates the project’s ROI: the cost of the transition period gets omitted from the return-on-investment calculation.
Conclusion: Coexistence Is a Project Within the Project
The bimodal transition is not a temporary anomaly you grit your teeth and endure. It is a full project phase in its own right, with its own deliverables (coexistence matrix, integration architecture, access rights governance), its own risks (third-party duplicates, bimodal financial closes, undocumented interfaces), and its own dedicated budget.
The organisations that succeed in their ERP migrations are not those that executed the fastest. They are those that treated coexistence as a structured sub-project, with an identified owner, tracking KPIs, and an explicit budget. Appointing a “coexistence manager” distinct from the migration project manager is not a luxury. It is a documented success factor.
To deepen your strategies for your current system before migrating, read our guide Modernize Your Legacy ERP Without Replacing It: 5 Strategies for IT Leaders. To prepare the step that follows, our plan Legacy ERP Decommissioning: The 8-Step Plan for a Risk-Free Retirement covers archiving, licence termination, and compliance. And if your priority is user adoption in the new system, our ERP Change Management: The 8-Step Plan to Maximize User Adoption will give you the operational structure to maximise the post-cutover adoption rate.
