Clean core and composable are two words an SI will use to justify an architecture decision that sets your upgrade cost for the next decade. Clean core means keeping custom code out of the ERP itself and putting extensions on a side platform. Composable means buying best-fit pieces around a lean core instead of one monolith. The payoff is money. Holding customization under 10 to 15% of requirements saves 20 to 40% of implementation cost (ERP Research), and it keeps the vendor's frequent cloud releases cheap to absorb. The discipline is the hard part, and it is where most programs lose the saving.
Clean core means custom code lives beside the ERP, not inside it
Clean core is a rule about where your custom logic sits. In the old model, developers wrote changes directly into the ERP's own code. Every release from the vendor then had to be reconciled against those changes by hand, which is slow and expensive. Clean core moves that logic out. The ERP stays close to what the vendor ships, and the custom work sits on a separate platform that talks to the ERP through published interfaces.
Every tier 1 vendor now sells the side platform for this. SAP calls it SAP Business Technology Platform, or BTP. Oracle has Oracle Integration Cloud and APEX, Microsoft has the Power Platform and Azure, and Workday has Workday Extend. The names differ. The idea is the same: the core stays standard, and the custom work is kept at arm's length where a vendor update cannot break it.
The reason this matters now is cadence. Cloud ERP updates are frequent and non-negotiable. Oracle ships quarterly, and Workday and Dynamics 365 update twice a year (ERP Today). When the core carries little custom code, each update is a small regression test. When the core is heavily modified, each update is a mini-project, several times a year, forever.
Composable means a lean core with best-fit pieces bolted around it
Composable is the next question out. Once the core is kept clean, you decide how much the core should do at all. A monolithic suite tries to run every process in one system. A composable architecture runs a lean core for the common processes, usually finance and the central records, and buys specialist systems for the edges the core does not do well.
The edges are specific functions. A specialist billing system, a warehouse management system, a field service application, or a tax engine. Each is bought because it fits one job better than the core does. The core becomes the system of record, and the specialist systems feed it through integrations.
Composable and clean core are related but not the same. Clean core is about how you extend one system. Composable is about how many systems you run. You can keep a clean core inside a monolithic suite, and you can build a composable estate badly by writing custom code everywhere. The discipline that makes clean core pay is the same discipline that makes composable pay, which is holding the line on where logic lives.
What you are buying is a cheaper upgrade and faster access to vendor features
Two things are for sale here, and both are real. The first is a lower upgrade cost over the life of the system. The clearest proof is what heavy customization did to the last generation. An ECC to S/4HANA migration commonly runs 1.5x to 3x the cost of the original ECC implementation (ERP Research), and the custom code accumulated over years is a large part of why. A clean core is a bet that you never build that debt again.
The arithmetic is worth seeing. Consider a $5M single-region tier 1 program where SI fees are 40 to 60% of the bill, so $2M to $3M. Holding customization under 10 to 15% of requirements is the lever behind the 20 to 40% implementation saving, which is $1M to $2M on that program. The saving is not a rounding error. It is the difference between two serious quotes.
The second thing you buy is speed to the vendor's new features. When the core stays standard, a release installs cleanly and you get what the vendor shipped. Increasingly that includes AI features built into the core, which is why the pace of vendor releases now matters more than it did, a point the AI-assisted ERP implementation pillar develops in full. A modified core sits a release or two behind because the upgrade is too painful to take on schedule.
What it demands is custom-code discipline, integration spend, and governance
The saving has a price, and it comes in three parts. The first is custom-code discipline. The 10 to 15% threshold is a budget, not a wish. Every requirement that the business insists must be custom spends against it, and once the budget is gone the saving goes with it. Someone has to say no, repeatedly, to people more senior than they are.
The second is integration cost. A composable estate has interfaces, and interfaces are not free. Each one has to be built, tested against every core release, and monitored in production. Annual maintenance and support after go-live already run 15 to 25% of implementation cost (Ecosire), and a composable estate pushes toward the top of that range because there is more to keep running. The money you save on the core is partly spent on the seams.
The third is governance. Clean core is a standing decision, not a one-time design. The body that approves exceptions has to outlast the program, because the pressure to modify the core is heaviest after go-live, when the business meets the standard process and wants its old one back. Without a named owner and a written rule, the core drifts back to custom within two or three release cycles, and nobody notices until the next upgrade quote arrives.
Clean core fails the moment industry depth is pushed into a side system
Here is the honest trade, and it is the part an SI will not volunteer. Clean core only works if the industry depth your business runs on stays as functionality you can buy or configure, either in the core or in a genuine specialist product. The failure mode is subtle. The core does not do what your industry needs, so the team rebuilds that depth as custom logic on the side platform and calls it clean core because it is technically outside the ERP.
It is not clean core. It is the same custom code in a new location, plus an integration to maintain. The upgrade saving was supposed to come from running a standard core, and a standard core that depends on a pile of bespoke extensions to function is not standard. The rule we recommend is blunt. If a side-platform extension encodes a process rule that is specific to your industry and changes when regulation or the market changes, you have not removed the custom code. You have moved it, and you now pay to integrate it as well.
This is why the architecture decision cannot be delegated to the SI. The SI is paid to deliver what you asked for, and if you ask for industry depth the core lacks, it will build it wherever you point. Gartner expects more than 70% of recently implemented ERP initiatives to fall short of their original business case by 2027 (Gartner), and an architecture that promised a cheap upgrade and quietly delivered an expensive one is one way to land in that number.
Composable versus monolithic is a real choice with conditions on each side
Composable is not the right answer for everyone, and the vendors reflect that. Workday runs every customer on one version and enforces a clean core by not letting you modify it, which suits a finance-heavy or people-heavy service organization that never wants to manage an upgrade. Oracle Fusion ships a broad suite on a quarterly cadence, which suits a buyer who wants most functions in the core and few bolt-ons. SAP's clean core doctrine and BTP suit a large, multi-entity SAP estate that will extend heavily and wants those extensions isolated. Microsoft Dynamics 365 with the Power Platform suits an organization with Microsoft-skilled IT that wants low-code extensions close at hand. In the mid-market, a monolithic suite such as NetSuite or Business Central is often the right call precisely because it keeps the estate small.
The table below is the decision, not a vendor scorecard. Read down the conditions and count which column you land in more often.
| Condition | Favors a lean core with composable pieces | Favors one monolithic suite |
|---|---|---|
| Industry fit of the core | A specialist function the core cannot match | The core already fits roughly 90% of requirements |
| IT's integration capability | A team that can own interfaces and data contracts | Thin IT that needs one vendor accountable |
| Pace of change at the edges | Edge processes change faster than the core can follow | Processes are stable and standard |
| Appetite for integration cost | Willing to pay to build, test, and run interfaces each release | Wants the fewest moving parts |
| Accountability for failures | Comfortable managing several vendors | Wants one party to answer for the whole system |
A buyer who lands mostly in the right column should resist a composable pitch, however current the word sounds. Every additional system is another integration to test against every core release, and the saving from best-fit features has to beat that running cost to be worth it.