The True Cost of ERP Customisation: Why Clean Core Is Worth the Pain

Every ERP implementation starts with a business case that promises transformation. Many end with a post-mortem that asks: where did the money go? The answer, in the majority of cases, is customisation. Bespoke development, modified standard processes, and “we’ve-always-done-it-this-way” configurations compound over years into a technical debt burden so heavy that the ERP stops enabling the business and starts constraining it. In 2026, with SAP’s ECC mainstream support deadline looming in December 2027 and AI-powered ERP capabilities requiring clean, standard environments to function, the true cost of ERP customisation has never been more visible or more painful.

The Hidden Arithmetic of ERP Customisation

When a project team agrees to a customisation, they typically calculate its cost as the development hours to build it. This is the build cost — and it is only a fraction of the true cost. The full cost over a typical ERP lifetime (10–15 years) includes:

• Build cost: development, configuration, and testing (the only cost usually budgeted)
• Documentation cost: capturing what was built and why, so future teams can maintain it
• Testing cost: every customisation must be regression-tested with every support package and upgrade forever
• Upgrade cost: custom code must be retested and often rewritten when the vendor releases a new version; this is the cost that kills ERP transformation programmes
• Support cost: customisations break when standard code changes; they require specialist knowledge to maintain; they create single points of failure
• Opportunity cost: while IT resources are maintaining custom code, they are not building new capabilities; the business falls behind competitors who are running standard

Industry benchmarks suggest that the total cost of an ERP implementation runs 1.5–2x the first-year software cost for standard deployments and can exceed 3x for highly customised ones. For enterprise SAP or Oracle programmes routinely budgeted at $1M–$3M+, the delta is significant.

The Dead Code Problem: Paying for Customisations Nobody Uses

One of the most striking findings in ERP rationalisation projects is the proportion of custom code that is no longer in use. Statistically, 40% to 50% of custom code in regional SAP systems is dead code — written for a requirement that no longer exists, a user who left, or a process that changed — but still present, still requiring maintenance, and still increasing upgrade complexity.

This happens because removing customisations is psychologically and politically harder than adding them. Nobody wants to be the person who decommissioned the report that turns out to be critical during year-end close. The result is accumulated technical debt that grows silently until an upgrade or migration forces a reckoning.

What Is “Clean Core” and Why Does It Matter Now?

The clean core principle, championed most prominently by SAP for its S/4HANA platform, holds that the ERP core should be kept as close to standard as possible, with extensions built in a separate layer using APIs and platform services rather than modifications to the core code. In SAP’s architecture, this means using the Business Technology Platform (BTP) for custom extensions instead of traditional ABAP modifications.

The clean core principle matters in 2026 for several interconnected reasons:

• SAP ECC end of support: mainstream support ends December 2027. Organisations running highly customised ECC systems face either an expensive “lift and shift” migration that perpetuates their technical debt, or a painful clean-up before migrating to S/4HANA
• AI readiness: SAP Joule and similar AI copilots only function effectively on standard S/4HANA processes. Customisations break AI features, effectively locking highly customised organisations out of next-generation productivity tools
• Continuous updates: cloud ERP vendors are moving to continuous delivery models. A highly customised system cannot absorb quarterly updates; a clean-core system can
• BTP adoption: 50% of SAP customers now actively use BTP services (up 10 percentage points from 2025), demonstrating that the extension-via-platform model is operationally viable

---

A clean core enables faster upgrades, lower total cost of ownership, and readiness for AI tools like SAP Joule. Parle achieved approximately 30% reduction in total cost of ownership while enabling clean core architecture.

SAP Clean Core Strategy Research, 2026

The Pain of Getting to Clean Core: Why It’s Worth It Anyway

Make no mistake: transitioning from a heavily customised ERP landscape to a clean core is painful. It requires:

• Custom code analysis: inventorying every modification, understanding its business purpose, and classifying it as “keep,” “rebuild on BTP,” or “decommission”
• Business process redesign: many customisations exist because the business refused to adapt its processes to standard — clean core requires revisiting those decisions
• Stakeholder management: every customisation has a business owner who believes their process is unique. Convincing them to accept standard is a change management challenge, not a technical one
• Transition risk: the period of rebuilding extensions on BTP while the core is being cleaned is a period of elevated risk that requires careful programme management

But the evidence supports enduring this pain. Parle, the world’s largest biscuit brand, achieved a 30% reduction in total cost of ownership after transitioning to clean core architecture. Across documented clean core transformations, the consistent outcomes are: faster upgrade cycles, lower annual support costs, higher user adoption of standard tools, and — critically — the ability to activate AI features that require clean, standard data and process flows.

The Framework for Customisation Decisions

Not all customisation is bad. Some business processes genuinely are differentiating — and those may justify extension development on the platform layer. The key is a disciplined decision framework applied to every customisation request:

Before approving any ERP customisation, ask:

1. Is this a competitive differentiator? If the answer is no — if competitors run the same process in standard — the business case for customisation is weak
2. Has the standard process been fully evaluated? Many customisations are requested without thoroughly understanding what the standard process can do; often the gap is smaller than the requester believes
3. What is the lifetime TCO? Calculate build cost × upgrade factor (typically 2–5x over 10 years) + annual support cost × years + opportunity cost
4. Can this be built on the platform layer? If yes, build it there — not as a core modification
5. Who owns it? Every approved customisation needs a named business owner responsible for keeping it current, justified, and eventually decommissioned

What Organisations Running Standard Are Doing Instead

The organisations that resist customisation pressure are not accepting worse business outcomes — they are achieving better ones through different means:

• Process redesign: re-engineering business processes to fit the standard system rather than bending the system to fit a broken process
• Configuration over customisation: using the ERP’s built-in configuration options (of which there are thousands) before writing a line of custom code
• Third-party apps: using certified, vendor-supported add-ons for genuinely specialised functions (tax compliance, industry-specific regulatory reporting) rather than building from scratch
• RPA for edge cases: using robotic process automation for narrow, high-volume edge cases that would otherwise require ERP modification
• API integrations: connecting best-of-breed point solutions via APIs rather than building everything inside the ERP core

Key Takeaways

• The true cost of ERP customisation includes build, documentation, testing, upgrade, support, and opportunity costs — not just the initial development invoice. Total lifetime cost is typically 3–5x the build cost
• 40–50% of custom code in mature SAP systems is dead code: no longer used but still costing money to maintain and upgrade
• Clean core — keeping the ERP standard and extending via platform APIs — is not just a best practice; it is now a prerequisite for AI readiness and continuous cloud update adoption
• SAP’s ECC support deadline (December 2027) makes 2026 the critical year for organisations to assess their customisation burden and plan a migration strategy
• Clean core transformations consistently deliver 25–35% reductions in total cost of ownership and unlock AI features that standard-hostile landscapes cannot access
• Every customisation request should be evaluated against a lifetime TCO model, not just a build-cost estimate

---

The clean core principle asks organisations to do something genuinely difficult: challenge long-held assumptions about what makes their business unique, accept short-term process change pain in exchange for long-term agility, and resist the political pressure to customise everything. Those that succeed will find themselves with ERP systems that upgrade quickly, support AI natively, and cost significantly less to run. Those that don’t will find themselves, in 2027 and beyond, facing migrations of a customised landscape so complex that the only affordable option is to start from scratch at a cost that dwarfs what the clean core path would have required. The pain of clean core is real. The pain of its alternative is greater.