In most mid-market and large organisations, the ERP landscape is not a tidy garden. It is an archipelago: an SAP S/4HANA inherited from the parent company, an Odoo adopted by the e-commerce subsidiary acquired two years ago, a Sage X3 that has been running headquarters finance for fifteen years. Each island works on its own, but the whole does not communicate — or communicates badly.
The question is not new, but it has gained fresh urgency. External growth is accelerating, regulatory requirements are multiplying across jurisdictions, and integration platforms (iPaaS) finally make viable what was a pharaonic undertaking five years ago. So: should you migrate everything to a single ERP, or accept coexistence and invest in orchestration?
This article provides a decision framework for CIOs and transformation directors who manage — or are managed by — a multi-ERP landscape. It complements our guide to multi-site and multi-entity consolidation with a single ERP and our iPaaS architecture comparison for ERP integration.
Why Groups End Up with Multiple ERPs
External Growth and Serial Acquisitions
This is the most common scenario. An industrial group acquires a competitor, a complementary startup, or a player in a neighbouring market. Each acquisition brings its own ERP, well-established business processes, and teams that know the tool. Forcing an immediate migration to the acquirer’s ERP is a major operational risk at precisely the moment post-acquisition integration demands stability.
Private equity firms know this dilemma well: with a three-to-five-year exit horizon, investing 18 months and several million in ERP convergence makes no economic sense. Multi-ERP is not an accident in this context — it is the rational strategy.
Subsidiaries in Sectors or Countries with Incompatible IT Requirements
A group operating in both food manufacturing and professional services does not have the same ERP needs. Manufacturing requires batch traceability, expiry-date management, and food safety compliance. Services require staffing, timesheets, and project billing. No generic ERP covers both universes with the same depth.
Similarly, local regulatory requirements — e-invoicing mandates in Italy, the SII and TicketBAI regime in Spain, e-Factura in Romania, and Making Tax Digital in the UK — can justify a locally compliant ERP rather than a complex configuration layer bolted onto the central system.
Deliberate Choice: Best-of-Breed per Business Unit vs. Group Uniformity
Some groups consciously choose best-of-breed. Rather than a monolithic ERP that does everything adequately, they prefer a specialised manufacturing ERP for production, a PSA for consulting activities, and a financial ERP for group consolidation. This is the “composable” approach that Gartner has promoted since theorising the post-modern ERP in 2013.
A Rimini Street study of 455 IT decision-makers found that 78% of SAP customers are considering a multi-vendor approach to innovation in their ERP landscape (E3 Magazine / Rimini Street). The monolith is no longer dogma.
Single-Instance, Multi-Instance, Multi-ERP: Clarifying the Architectures
Before deciding, the terminology needs to be precise. Three architectures coexist, and they carry very different implications.
Single-Instance: One ERP, One Tenant, All Entities
This is the canonical model promoted by SAP with S/4HANA Cloud: all legal entities in the group operate within a single tenant, sharing a common chart of accounts, unified master data, and native consolidation. The advantage is obvious: one system to maintain, one version to upgrade, real-time visibility across the entire group.
The trade-off: a long deployment (12 to 24 months minimum for a multi-country group), high cost, and a rigidity that can stifle subsidiaries with atypical needs. Every local specificity translates into additional configuration or bespoke development that complicates future upgrades.
Multi-Instance: The Same ERP, Separate Tenants by BU or Country
The group uses the same vendor (for example Microsoft Dynamics 365 Finance), but each subsidiary or region operates its own tenant. Master data is distinct, configurations are adapted to local requirements, and consolidation happens via interfaces between instances.
This model offers a good compromise between local autonomy and vendor consistency. Skills are poolable, upgrades are coordinated, and the implementation partner works on a homogeneous technical foundation. The downside: inter-instance interfaces must be built and maintained, which is not free.
Multi-ERP: Different Vendors Coexisting
This is the most complex scenario — and the most common in groups shaped by acquisitive growth. SAP for the industrial division, Odoo for retail, Sage Business Cloud for corporate finance, Workday for HR. Each system has its own logic, APIs, release cycles, and partner ecosystem.
The advantage: each business unit has the tool best suited to its activities. The disadvantage: integration between systems becomes a project in itself — permanent and costly.
Comparison Matrix
| Criterion | Single-Instance | Multi-Instance | Multi-ERP |
|---|---|---|---|
| Data consistency | Very high | High (if interfaces work) | Low without MDM |
| Subsidiary autonomy | Low | Medium | High |
| Integration cost | Low (native) | Medium | High (iPaaS + MDM) |
| Deployment timeline | Long (12–24 months) | Medium (6–12 months/instance) | Short per BU, long for consolidation |
| Business flexibility | Limited to standard | Moderate | Maximum |
| Skills required | One vendor | One vendor, N tenants | N vendors, N logics |
| Upgrade complexity | Moderate | Multiplied by N | Independent per BU |
When Multi-ERP Is the Right Strategy
PE Holdings with Short Exit Horizons
For a fund planning to divest an entity in three to five years, unifying the ERP is money spent without return. The next acquirer will impose their own system. The rational strategy: stabilise each existing ERP, deploy a lightweight iPaaS layer for financial consolidation, and invest the saved budget in operational growth.
Subsidiaries with Strong Local Regulatory Requirements
When a UK subsidiary must comply with Making Tax Digital, an Italian entity is subject to FatturaPA e-invoicing, and a Spanish division must implement TicketBAI, forcing a central ERP to handle all three regimes natively is often more expensive than running a locally compliant ERP in each country. Regulatory complexity sometimes justifies application landscape fragmentation.
Fundamentally Different Entities: Manufacturing + Services + Retail
A group operating simultaneously in industrial manufacturing, engineering consulting, and online distribution has three fundamentally distinct businesses. A manufacturing ERP (Infor CloudSuite Industrial, IFS Cloud) does not handle staffing and time-and-materials billing well. A PSA (Deltek, Kantata) does not manage production with manufacturing orders. And an OMS for e-commerce has different requirements than both. Multi-ERP here is an architectural choice, not a historical accident.
When Multi-ERP Is a Trap
Financial Consolidation Impossible Without Heavy Middleware
The most critical flow in a multi-ERP landscape is financial consolidation. Aggregating accounts from subsidiaries using different charts of accounts, different currencies, and different intercompany elimination rules requires a dedicated consolidation tool (SAP BPC, OneStream, Tagetik) or significant custom development. If the group is subject to IFRS, the complexity multiplies: every adjustment between local GAAP and IFRS must be traceable and auditable.
Exploding Maintenance and Skills Costs
Each ERP requires its own skills: functional consultants, technical developers, system administrators. Maintaining three different ERPs means maintaining three teams — or paying three separate managed service contracts with three different partners. The total cost of ownership (TCO) of a multi-ERP landscape is structurally higher than that of a unified ERP at equivalent functional scope.
Loss of Real-Time Visibility into Group KPIs
Without a robust integration layer, group reporting becomes a manual consolidation exercise. Dashboards are fed by Excel exports, data arrives 48 hours late, and no one trusts the numbers. For an executive committee managing week-by-week, this is a major operational handicap.
Orchestrating a Multi-ERP Landscape: The Integration Layer
If multi-ERP is the chosen strategy — or the inherited reality — the challenge shifts to orchestration. The goal is not to merge the ERPs, but to create an intermediate layer that ensures critical data flows reliably.
iPaaS as the Backbone
Cloud integration platforms (iPaaS) — MuleSoft, Boomi, Workato — have become the standard for connecting heterogeneous ERPs. They offer pre-built connectors to major ERP systems, a data transformation engine, and centralised monitoring of all flows.
The global iPaaS market is estimated to exceed $70 billion by 2030, growing at over 30% annually (Latenode, 2025). This growth directly reflects the need to integrate heterogeneous application landscapes. The annual cost of an enterprise iPaaS platform typically ranges from €50,000 to €250,000 depending on flow volume and connector count.
Priority flows to connect: intercompany orders, inter-site stock movements, accounting entries for consolidation, shared customer and supplier master data.
MDM for Master Data Consistency
Master Data Management (MDM) is the most frequently underestimated prerequisite in multi-ERP environments. Without a shared reference for customers, suppliers, items, and chart-of-accounts mappings, iPaaS cannot correctly map data between systems.
The MDM market is growing steadily, from approximately $19 billion in 2025 to a projected $70 billion by 2032 (Verdantis, 2026). Yet one in four companies still delays its MDM deployment due to the complexity of integration with legacy systems.
Leading vendors (Informatica, Reltio, Stibo Systems) offer cloud solutions that synchronise master data between ERPs in real time. MDM project costs range from €100,000 (a single domain for a mid-market company) to several million for multi-country, multi-domain groups.
Data Warehouse / Data Lakehouse for Analytical Consolidation
Both operational consolidation (stock, orders, production) and financial consolidation often flow through a common data store. A data lakehouse (Snowflake, Databricks, BigQuery) aggregates data from each ERP, normalises it, and exposes it via unified dashboards (Power BI, Looker, Tableau).
This is the answer to the loss of visibility: rather than demanding native reporting from each ERP, you create a shared analytical layer that absorbs source heterogeneity.
API Gateway and Governance of Inter-ERP Flows
In a multi-ERP landscape, the number of point-to-point integrations grows combinatorially. With three ERPs, you have potentially six bidirectional flows. With five, twenty. An API gateway centralises calls, enforces security and throttling policies, and provides a single observation point for exchange health.
Flow governance is not a technical luxury: it is what prevents an incident on one ERP from propagating to others through a domino effect. Each flow must have an identified business owner, a documented SLA, and an escalation path in the event of failure.
Roadmap: Decide, Map, Orchestrate
Phase 1: Map the Existing Application Landscape (4–6 Weeks)
Before deciding, you need visibility. The mapping covers:
- ERP inventory: vendor, version, hosting model (on-premises / cloud / hybrid), user count, active modules.
- Inter-system data flows: which flows exist today (even manual ones via spreadsheet), frequency, volume, criticality.
- Current costs: licences, managed services, hosting, internal resources per ERP.
- Regulatory requirements: local obligations (e-invoicing, country-specific accounting localisation, sector compliance) that impose specific configurations.
The deliverable is a matrix crossing group entities with ERPs used, critical flows, and associated costs. This is the factual basis for any decision.
Phase 2: Define the 3-Year Target (2–4 Weeks)
Three scenarios typically emerge:
- Full convergence: migrating all entities to a single ERP. Appropriate for mature, stable groups with a long horizon and a substantial budget.
- Partial convergence: clustering the closest entities onto the same ERP while retaining specialised systems for atypical cases. This is usually the most pragmatic scenario.
- Managed coexistence: keeping existing ERPs and investing in the orchestration layer (iPaaS + MDM + data warehouse). Appropriate for PE holdings, highly diversified groups, or recent post-acquisition contexts.
The choice depends on three factors: the ownership horizon, the diversity of business activities, and available budget. There is no universal answer, but there are wrong reasons to choose (nostalgia for a single-instance dream, commercial pressure from a vendor, or inertia in the face of complexity).
Phase 3: Prioritise Integrations by Business Value (Ongoing)
Once the target is defined, execution depends on rigorous prioritisation of integration flows. The criterion is not technical complexity but business value:
- Financial consolidation: the non-negotiable flow. Without it, the group cannot close its accounts.
- Customer and supplier master data: without consistency on this data, every entity lives in its own commercial universe.
- Intercompany stock and orders: critical for groups with physical flows between entities.
- HR and payroll reporting: important but usually less urgent than the three above.
Each integrated flow is a project in its own right, with its own budget, timeline, and business owner. The temptation to integrate everything in parallel is a classic trap — one well-integrated flow is worth more than ten unstable ones.
Key Takeaways
Multi-ERP is neither inevitable nor a mistake. It is the reality for the majority of sizeable groups, and sometimes the smartest strategy. The error is not having multiple ERPs — it is failing to orchestrate them.
Companies that combine open, composable architectures with a multi-vendor approach outperform in 83% of cases, compared to just 27% for traditional monolithic approaches (E3 Magazine / Rimini Street). The paradigm has shifted: the question is no longer “which single ERP should we choose?” but “how do we make the tools best suited to each business coexist intelligently?”
To go further, read our guide to multi-site and multi-entity management with a single ERP, our iPaaS architecture comparison for ERP integration, and our analysis of the first 100 days post-merger IT integration.
