Your ERP has been running for three years. The core modules work. And yet your technical teams keep raising a fundamental question: should you stick with this monolith or start extracting it into microservices? Competitors in your sector are showcasing “composable architectures.” A consultant just mentioned MACH. And a peer CIO at a conference explained how their team decoupled the product catalogue into an independent service, cutting feature delivery from months down to days.
The result: you’re getting mixed signals. Architecture articles rave about microservices. Real-world post-mortems describe projects that burned eighteen months on migration for a modest return. The truth lies somewhere in between — and it depends entirely on your context.
This article is not an architecture textbook. It is a decision-making tool: when decomposition makes sense, when the monolith remains the rational choice, and how to navigate between the two with the strangler fig strategy.
Monolith, Microservices, Composable: What These Terms Actually Mean in an ERP Context
The Modern Monolith in 2026: Not Your Legacy ERP from the 2000s
The word “monolithic” still conjures images of a rigid system, hard to change, deployed twice a year. That picture is outdated for today’s major ERP platforms.
SAP S/4HANA Cloud, Microsoft Dynamics 365, and Oracle Fusion Cloud are all built on internal microservices architectures. On the vendor side, SAP teams deploy independent services (finance, inventory, order management) that communicate via APIs and can evolve separately. What you perceive as a monolith through your user interface is actually an aggregation of vendor-managed services.
As a CIO, your actual choice is not whether your ERP is internally a monolith or not. It is whether you build your extensions, customisations, and peripheral integrations as independent microservices — or as a unified application layer on top of the ERP.
Microservices Applied to ERP: Decoupling Functional Domains
In an ERP context, microservices architecture means extracting one or more functional domains — product catalogue, pricing, B2B e-commerce order management, customer notifications — from the ERP into autonomous application services. These services are independently deployable and communicate with the ERP via APIs or asynchronous events.
Each service owns its own database and deployment lifecycle, and can be updated without touching the others. A pricing service change does not require retesting and redeploying the finance module.
The advantage is genuine on high-change domains. The drawback is equally real: coordinating multiple distributed services introduces operational complexity that is systematically underestimated at design time.
Composable ERP (MACH): Promises vs. Ground Reality in 2026
The MACH acronym — promoted by the MACH Alliance (founded in 2020, now with several hundred members including Commercetools, Contentful, Algolia, and Akeneo) — describes an architecture approach built on four principles: Microservices, API-first, Cloud-native, Headless.
In an ERP context, a “composable ERP” means an architecture where functional layers are assembled from specialised commercial building blocks rather than a single general-purpose ERP: a PIM like Akeneo for the product master, a pricing engine like Pricefx, a dedicated OMS for e-commerce order management — all connected to a back-office ERP handling finance and logistics.
The promise is compelling: swap out any brick independently, accelerate iteration on differentiating domains. Ground reality in 2026 is more nuanced. A well-executed composable project genuinely delivers remarkable functional agility on e-commerce and pricing fronts. A poorly scoped composable project multiplies interfaces to maintain, creates cross-system data consistency issues, and generates integration costs nobody budgeted correctly.
When Decomposing Your ERP into Microservices is the Right Call
Transaction Volume and Asymmetric Scalability
The most compelling case for extracting a domain into a microservice is asymmetric scalability: one part of your system needs to scale disproportionately compared to the rest.
The classic example is B2B e-commerce during demand spikes (seasonal tenders, sales events, marketing campaigns): the catalogue browsing and order placement service needs to absorb ten times normal traffic without affecting finance module performance, production scheduling, or inventory management. Isolating this service in an auto-scaling deployment (Kubernetes, managed cloud services) lets you handle those peaks without over-provisioning your entire system for worst-case load.
This justification only holds when your volumes genuinely require it. For a mid-market company with 5,000 orders per day at peak, the question of ERP auto-scaling rarely arises — modern cloud ERPs absorb these loads without custom architecture.
Time-to-Market on Differentiating Functions
Second solid case: you’ve identified a functional domain that represents a direct competitive advantage, where you need to iterate rapidly and independently from your ERP release cycles.
A personalised recommendation engine for your B2B catalogue, a dynamic pricing engine incorporating real-time market data, a sector-specific promotional rules logic — these functions benefit from being developed and deployed outside the constraints of the ERP release cycle.
The condition: the domain must be functionally stable before decomposition. The classic mistake is decomposing into microservices a domain whose business rules are still being defined. Every rules change then requires evolving the interface between services, generating a refactoring cost that grows with the number of involved services.
The Non-Negotiable Organisational Prerequisites
Before any decomposition project, honestly assess three organisational prerequisites:
1. Autonomous product teams per domain. The two-pizza rule (popularised by Amazon) states that a microservice should be owned by a team of 6 to 10 people maximum. In practice, a mid-market company of 800 employees rarely has 3 or 4 distinct DevOps teams each capable of owning a service end-to-end. Before creating five services, make sure you have the teams to maintain them long-term.
2. Real DevOps maturity. Microservices require automated CI/CD infrastructure, independent test pipelines per service, distributed observability (tracing, aggregated logging), and per-service secrets and certificate management. An environment where deployments are still manual or semi-manual is not ready for microservices architecture, regardless of the functional case for decomposition.
3. API contract governance. In a distributed architecture, the interface between services becomes a critical contract. Any non-backwards-compatible change to an internal API can break consuming services. Managing these contracts — versioning, documentation, contract testing — requires an engineering discipline that many organisations have yet to internalise.
When Keeping a Monolithic ERP is the Rational Decision
Mid-Market Under 1,500 Employees: Coordination Costs Outweigh the Benefits
For a company of 200 to 1,500 employees, the cost-benefit analysis of microservices architecture often tips toward costs. IT teams are lean (5 to 15 people covering the full application scope), functional domains don’t have the volumes that justify independent scaling, and business change cycles are not fast enough for the differential time-to-market of an independent service to materially move the needle.
In this context, the operational complexity of microservices — service mesh management, circuit breakers, distributed transactions via the saga pattern — represents a technical debt that far outweighs the value created.
A well-structured monolithic ERP, properly configured, with clean integrations to peripheral solutions via connectors or a lightweight iPaaS, covers the needs of the vast majority of mid-market companies in this size range.
Legacy Integration Constraints: The Unacceptable Async Overhead
The second case where the monolith remains the rational choice is legacy-heavy environments: mainframes, proprietary business applications, tightly coupled relational databases.
Microservices architecture depends on asynchronous event-driven communication (message broker) or synchronous API calls with distributed error handling. In a system that exchanges data with legacy applications via daily batch flows or direct database connections, migrating to an event-driven architecture represents a significant infrastructure project that often has no direct relationship to the business value being sought.
The Modular Monolith: What Vendors Don’t Call Microservices but Comes Close
Modern ERPs like SAP S/4HANA, Dynamics 365, and Odoo (to a lesser extent) offer significant internal modularity: documented REST APIs, the ability to disable unused modules, extension mechanisms (ABAP for SAP, Power Platform for D365, Python modules for Odoo) that allow customisations without touching the core system.
This approach — sometimes called a “modular monolith” by architects — lets you capture the transactional consistency of an integrated system while preserving meaningful agility on extensions. For most mid-market companies, it represents the right balance between a frozen legacy monolith and the full operational complexity of a microservices architecture.
The Middle Path: The Strangler Fig Strategy on Your Existing ERP
Extracting 1 to 2 High-Stakes Domains
The strangler fig strategy, popularised by Martin Fowler, involves progressively extracting capabilities from an existing system without replacing it all at once. Applied to an ERP, it means identifying 1 or 2 domains with high business stakes — B2B e-commerce, product catalogue, dynamic pricing, real-time logistics — and extracting them as independent services while keeping the ERP as the transactional core for finance, payroll, and procurement.
A reference example from the manufacturing sector: an 1,800-employee company that extracted its product catalogue and variant configuration engine from Dynamics 365 into a dedicated service. The result: time-to-market for new product configurations dropped from several weeks to a few days. D365 remains the system of record for confirmed orders, inventory valuation, and accounting. The two systems communicate via an Azure Service Bus message broker.
This approach offers a decisive advantage: you don’t need to migrate your entire system to gain microservices agility on the perimeter that genuinely needs it.
Integration Patterns: API Facade and Asynchronous Events
Two integration patterns structure the communication between the ERP and extracted services:
The API facade on the legacy ERP: instead of exposing the ERP’s native APIs directly (often complex and vendor-specific), you build an abstraction layer that translates business calls into ERP calls. This facade lets you change the underlying ERP implementation without impacting consuming services, and maintains a stable API contract even during major ERP upgrades.
Asynchronous events via message broker: rather than synchronous API calls between the ERP and services (which create temporal coupling and availability issues), you publish business events (order created, stock updated, customer modified) to a message bus, which subscribed services consume at their own pace. This model is more resilient and scalable, at the cost of added complexity in error handling and eventual data consistency.
Common Tooling in 2026: Costs and Human Prerequisites
The most widely used technologies for these integration patterns in an ERP context in 2026:
- Apache Kafka: the reference for high-volume event-driven architectures. Significant operational cost (dedicated infrastructure or managed service like Confluent Cloud from several hundred euros/month for moderate usage). Prerequisite: a team capable of running Kafka in production, which is non-trivial.
- Azure Service Bus / Azure Event Hub: managed option for Microsoft environments (D365, Azure). Native integration with Logic Apps and Power Platform. Usage-based pricing, accessible for mid-market.
- SAP Integration Suite (formerly SAP Cloud Platform Integration): the reference solution for SAP environments, with pre-built connectors for major SaaS platforms and data transformation management.
- MuleSoft Anypoint Platform: enterprise iPaaS for complex multi-vendor architectures. Significant pricing (from several thousand euros/month), justified for broad integration scopes. For a full comparative analysis of iPaaS options, see our ERP integration architecture comparison: MuleSoft, Boomi, Make, and native connectors.
Comparison Table: Monolith vs Microservices vs Composable Across 6 Criteria
| Criterion | Monolithic | Microservices | Composable (MACH) |
|---|---|---|---|
| 5-year TCO | Low to moderate (ERP licence + routine maintenance) | High (distributed infrastructure, observability, dedicated teams) | High (multiple vendor licences + integration costs) |
| Time-to-value for new features | Slow on differentiating functions (ERP release cycle) | Fast on extracted services, slow initial setup | Fast once architecture is stable, long to reach that point |
| Operational complexity | Low (one system to operate) | High (distributed monitoring, partial failure management, sagas) | Very high (multi-vendor governance, data consistency) |
| Vendor dependency | High (ERP roadmap drives evolution) | Low (independent, replaceable services) | Low by design, but high in practice per service |
| Selective scalability | None (entire system scales uniformly) | High (each service scales independently) | High per service |
| Team size required | Small (2 to 5 IT people sufficient) | Large (1 to 2 teams per service in production) | Large (integration team + teams per building block) |
The Decision Framework: 8 Questions to Choose Your ERP Architecture
Answer these 8 questions. Count your A (monolith), B (microservices), or C (composable MACH) responses according to the guidance below.
1. How large is your internal IT team dedicated to ERP and business applications?
- Fewer than 5 full-time people → A
- 5 to 15 people → may move toward B on 1 domain
- More than 15 people with dedicated product teams → B or C feasible
2. Does your organisation already have automated CI/CD pipelines and an established DevOps practice?
- No, deployments are still partially manual → A
- Yes, for most applications → B possible
- Yes, with distributed observability already in place → B or C
3. Is there a specific functional domain where current time-to-market is directly hurting revenue?
- No → A (no ROI justification for decomposition)
- Yes, on 1 to 2 identified domains → targeted B (strangler fig)
- Yes, across the entire commercial system → C worth evaluating
4. Do your transaction volumes create asymmetric load spikes between modules?
- No, loads are uniform → A
- Yes, on a limited perimeter (e-commerce, pricing) → targeted B
- Yes, across multiple independent domains → B or C
5. Is the functional domain you’re considering decomposing already stable?
- No, business rules are still evolving → Wait (regardless of architecture model)
- Yes, rules have been stable for at least 12 months → B or C possible
6. What is your acceptable ROI horizon for an architecture project?
- Less than 12 months → A (microservices projects rarely break even before 18–24 months)
- 18 to 36 months → targeted B feasible
- More than 36 months acceptable → B or C depending on previous answers
7. Does your system include legacy applications with batch interfaces or direct database connections?
- Yes, many → A or legacy migration before any decomposition
- No, primarily documented REST APIs → B or C possible
8. Does your functional domain require working with multiple specialised vendors (PIM, OMS, pricing) rather than extending your current ERP?
- No, the current ERP covers the need with extensions → A
- Yes, on a limited scope (e-commerce only) → targeted B
- Yes, across multiple differentiating domains → C worth serious evaluation
Interpretation:
- Mostly A: maintain and optimise your monolithic architecture. Invest in clean integrations and internal ERP modularity.
- Mostly B, 1–2 targeted domains: adopt the strangler fig strategy. Start with a single service on the most justified domain.
- Mostly C or B across many domains: evaluate a composable approach, but with rigorous scoping of integration costs and a dedicated architecture team.
To go further on related topics, see our composable ERP guide: architecture, costs, and success conditions for 2026 and our analysis on ERP vs best-of-breed: 8 processes where native modules fall short.
