Microservices arrived in enterprise architecture conversations around 2014 and 2015 with unusual speed, and ERP teams were among the first to be asked why they were not doing it. The pattern had a name, a canonical write-up, container tooling that had just reached its first stable release, and a set of consumer-internet reference architectures that made monolithic systems look like a failure of nerve. Decomposing the ERP monolith became a standing agenda item in enterprise architecture reviews. Most of those conversations were wrong in the same way. They treated an ERP as a large application that happened to be poorly factored, when it is more accurate to describe it as a shared transactional data model with applications attached. That distinction determines what can be extracted, what cannot, and why the programmes that succeeded looked nothing like the reference architectures.
Why ERP resisted decomposition
In a microservices architecture, each service owns its data. That is the constraint that produces the benefits — independent deployment, independent scaling, team autonomy — and it is precisely the constraint an ERP violates by design. A sales order in a typical suite touches the customer master, credit limits, inventory availability, pricing conditions, tax determination, the general ledger and controlling objects. These are not services calling each other. They are tables in one database, updated inside one transaction, with referential integrity enforced by the database and financial correctness guaranteed by the fact that everything either commits or does not. Split that into six services and you have replaced a database transaction with a distributed one. The industry's answer — eventual consistency, compensating transactions, sagas — is well understood and works. It is also a significantly harder engineering problem than the one being solved, and it introduces states that finance functions find difficult to accept. "The order was created but the inventory reservation failed and the compensating transaction is pending" is not a sentence that survives an audit conversation comfortably. There is also an ownership problem. Microservices assume teams that own services end to end. Most ERP estates are maintained by a shared team or an external integrator, organised around modules that mirror the vendor's structure rather than around business capabilities. Conway's law applies in reverse: an organisation that is not structured into autonomous product teams will produce services that require coordinated releases, which is a distributed monolith with extra latency.
What could actually be extracted
The programmes that worked drew a line between the transactional core and everything that had accumulated around it — and only decomposed the latter. The extractable layer is generally where change is frequent and consistency requirements are weaker: customer and supplier portals, quote configuration and complex pricing, approval workflows, document generation, notifications, product catalogue and search, reporting and analytics, integration adapters to partners and marketplaces, and customer-facing order status. These are the parts of the estate that business users request changes to constantly, and they are the parts that were historically implemented as customisations inside the core because there was nowhere else to put them. Moving them out has a specific, measurable benefit that has nothing to do with scalability. It lets the volatile parts of the system change on a weekly cadence while the core stays on a quarterly one. That is the actual value proposition for enterprise systems — decoupling release cadence, not handling traffic spikes. The non-extractable layer is the financial and inventory transaction core. Attempts to break the general ledger into services have a poor record, and there is no obvious reason to try: it is the part of the system that changes least and where correctness matters most.
Define the boundary
Separate frequently changing experience logic from ledger and inventory transactions.
Use a supported interface
Keep the core as the record; read through an approved interface and write through supported operations.
Move consumers gradually
Introduce the new capability in stages with an owner and a documented fallback.
Retire only after verification
Confirm consumers and statutory processes no longer depend on the old implementation.
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
The strangler pattern, applied to business systems
The technique that generalised best was incremental interception rather than replacement. Put an interface in front of a capability, route new consumers to it, implement the new version behind it, migrate consumers one at a time, and remove the old implementation when nothing calls it. Applied to ERP, that usually means the new service reads from the core — through an API where one exists, through change data capture or a replicated read model where it does not — and writes back through the supported transaction interface. The core remains the system of record. The extracted service owns the experience and the volatile logic, not the financial truth. This is less architecturally pure than the diagrams and considerably more likely to be running in production five years later. The projects that failed were nearly always the ones that attempted to move the system of record.
Practical Guidance for Modernization Roadmap Session
- Separate the system of record from the systems of engagement before drawing any architecture. Everything downstream follows from that line, and getting it wrong is the difference between incremental modernisation and a failed re-platform.
- Rank candidates by change frequency, not by technical appeal. Extract what the business asks you to modify every month. Leave what has not changed in five years exactly where it is.
- Do not distribute a transaction that finance depends on. If the answer to "what happens if step three fails" requires explaining compensating logic to an auditor, keep it in one transaction.
- Fix the integration layer first. Reliable events or change data capture out of the core is the prerequisite for everything else. Without it, each new service invents its own extract and the estate gets worse.
- Check whether you have the operational maturity. Twelve services require deployment automation, distributed tracing, centralised logging, on-call ownership and dependency management. Without those, you have multiplied failure modes and lost the debugger.
- Align services to business capabilities and to teams that can own them. A service with no permanent owner becomes a legacy system faster than the monolith it replaced.
- Keep a documented fallback path to the core for every extracted capability. Statutory and month-end processes cannot wait for a service to be fixed.
- Set a stopping point. Decomposition is not an end state. Decide in advance which parts of the estate will remain monolithic permanently, and defend that decision.
The Regional Dimension
For groups operating across the GCC, the argument for selective extraction is stronger than the generic case, for structural reasons rather than technical ones. Regional groups typically run several legal entities — a mainland company, free-zone entities, a Saudi subsidiary, branches elsewhere in the Gulf — frequently on different system instances acquired at different times. There is rarely one monolith to decompose; there are three or four, plus a spreadsheet layer holding them together. In that situation, building shared capability services above the instances — a single vendor portal, one approval workflow, one consolidated reporting layer — delivers value that a single-instance organisation would get simply by upgrading. Compliance integration is the second driver. E-invoicing under the Saudi regime, VAT and corporate tax obligations in the UAE, wage protection file submission and gratuity calculation, GOSI contributions and nationalisation reporting: these are externally mandated integrations with their own change cycles, driven by regulators rather than by the organisation. Implementing each of them as a customisation inside the core means every regulatory change becomes a core release. Implementing them as separate services with clean interfaces to the core is the difference between a two-week change and a two-month one. Two local constraints deserve planning attention. Much of the regional estate is maintained by systems integrators, and the right to extract capability, access APIs and deploy independently is defined by a statement of work that was written for a different purpose — renegotiate it before designing around it. And bilingual data means any extracted service handling customer, supplier or employee records must deal with Arabic and English representations of the same entity from the outset, because retrofitting identity resolution across services is far worse than doing it in one database.
The objection worth taking seriously
The strongest counterargument is that most organisations attempting this ended up with a distributed monolith: services that cannot be deployed independently, share a database anyway, fail together, and are harder to debug than the system they replaced. That outcome was common enough to be the base case rather than the exception. The underlying error was adopting an architectural pattern designed for a specific problem — large engineering organisations needing autonomous teams to ship independently — in organisations that had neither the team structure nor the deployment frequency that made the trade-off worthwhile. If your ERP changes four times a year and one team maintains it, service decomposition costs you a great deal and buys you almost nothing. The honest position is that a well-structured monolith with clean internal boundaries beats a badly structured set of services in nearly every dimension that matters to a business system, and that the correct scope for most enterprises was never decomposition of the core. It was getting the volatile, customer-facing, frequently changing capabilities out of a system that was never designed to host them — which is a much smaller and much more defensible programme.
Common Questions
Can the ERP core itself be turned into microservices?
In practice, no — and the vendors have largely answered this for the market by keeping the transactional core integrated while offering extension platforms alongside it. The financial core depends on transactional consistency that distribution undermines, and the benefit of independent deployment is minimal for a component that changes rarely. Target the periphery.
How do extracted services stay consistent with the core?
Through events or change data capture for reads, and through the vendor's supported transaction interfaces for writes, with the core remaining the system of record. Accept eventual consistency for display and analytics; do not accept it for postings. Where a read model can be briefly stale, say so in the interface rather than pretending otherwise.
What is the first thing to extract?
Usually a read-heavy, customer-facing capability with weak consistency requirements — order status, a supplier portal, document generation. It delivers visible value, exercises the integration layer, and fails safely if it goes wrong. Starting with anything that writes to the ledger is a way to end the programme early.
Does AI change the decomposition argument?
It shifts value toward clean interfaces rather than toward smaller services. Agents and AI features need well-defined, documented, permissioned operations they can call and reliable event streams they can observe — exactly the integration groundwork that selective extraction requires. Organisations that built that layer are finding AI features straightforward to add; those whose logic is buried in core customisations are discovering there is nothing for an agent to call.
Modernization Roadmap Session — the goal is not fewer lines of code in the core, it is being able to change the parts of the business that move quickly without touching the parts that must not move at all.