Clean core has moved from an aspirational SAP design principle to something close to a business requirement for any organisation planning an S/4HANA migration or already running RISE with SAP. Understanding what following this mandate actually costs, in licensing terms as much as engineering effort, is a conversation most transformation programmes have not had in enough depth before committing to a migration timeline.
What Clean Core Actually Requires
SAP’s own guidance defines the practice clearly. Clean core means keeping the S/4HANA core as close to SAP’s standard as possible, avoiding direct modifications to standard objects, and instead building extensions through either side-by-side development on SAP BTP or on-stack extensibility using ABAP Cloud. Independent analysis of the model explains that SAP has evolved its original three-tier extensibility model into a four-level maturity concept (A through D), categorising every extension by how upgrade-safe and API-compliant it is, giving organisations a common framework for classifying existing customisations rather than treating clean core as a single pass or fail state.
Level A extensions, built entirely on released APIs, are fully upgrade-safe and represent the target state. Level D, involving direct core modifications or unreleased internal object access, is explicitly what clean core exists to eliminate. Most real-world SAP estates today sit somewhere between these extremes, carrying a mix of extension levels accumulated over years of customisation that predates the clean core mandate entirely.
The Custom Code Cost Nobody Budgets For Accurately
The financial case for clean core rests substantially on the cost of maintaining custom code under the old model, and the numbers are larger than most transformation budgets assume. A widely cited study conducted jointly by ASUG and Pillir found that organisations spend an average of eight hundred thousand dollars annually maintaining their most valuable SAP custom code, representing up to fifty percent of annual IT spend for over a third of organisations surveyed, while ninety one percent of SAP users report relying heavily on custom code to run mission-critical business processes.
That combination, heavy reliance on custom code paired with a significant ongoing maintenance cost, is precisely the trap clean core is designed to break. Every SAP upgrade cycle historically required re-testing, re-coding, and re-validating whatever custom modifications existed in the core, and that cost compounds with every release rather than being paid once. Migrating that custom logic to BTP does not eliminate the underlying business requirement the code was built to serve, but it does change the maintenance cost profile substantially by decoupling that logic from the core upgrade cycle.
Why BTP Is Not Automatically the Cheap Option
The most common misconception entering a clean core initiative is that moving custom logic to BTP is inherently a low-cost or free alternative to keeping it in the core. In practice, extensions built on BTP consume genuine platform capacity, whether metered through the Cloud Platform Enterprise Agreement model included with RISE, through Kyma runtime charges, or through Integration Suite consumption, and that consumption is a real cost that needs to be modelled rather than assumed away.
RISE with SAP contracts typically include a defined allocation of BTP credits, and extension scenarios that exceed that allocation trigger overage charges. Organisations planning an ambitious side-by-side extensibility programme without first modelling expected BTP consumption against the included allocation risk discovering the overage cost only once the extensions are already live and generating charges against the tenant.
The Governance Layer Clean Core Actually Requires
Achieving clean core is not simply a one-time migration project completed alongside an S/4HANA transformation. It requires ongoing governance to remain clean, since the same pressures that produced the original custom code, a business requirement standard functionality does not quite meet, do not disappear once the migration is complete. SAP’s own community guidance stresses that clean core is not the elimination of customisation but the placement of that customisation in the correct architectural layer, requiring active governance, monitoring, and operational discipline to remain clean over the system’s full lifecycle rather than only at the point of go-live.
That governance requirement has a genuine cost of its own, typically a defined review process for any new extension request, a standing centre of excellence or equivalent function evaluating whether a given business requirement can be met through standard configuration before defaulting to a custom BTP extension, and periodic audits of the existing extension landscape to catch drift back toward core modifications under project time pressure.
AI Adoption Is Raising the Stakes on This Decision
The connection between clean core and SAP’s AI roadmap is becoming difficult to separate from the underlying cost conversation. Embedded AI capabilities including Joule and the broader SAP Business AI platform are built around assumptions of standard data structures and released APIs, and custom fields buried directly in the core or integrations built on unreleased function modules leave an organisation’s most valuable emerging AI capabilities effectively stranded, unable to reliably access data trapped in non-standard structures.
This reframes the clean core cost conversation for any organisation planning meaningful AI adoption over the coming several years. The custom code maintenance savings clean core delivers are real, but the AI readiness clean core enables is increasingly the more strategically significant argument, since a heavily modified core with years of Level C and Level D extensions is not simply expensive to maintain. It is functionally unable to take advantage of the AI capabilities SAP is investing in most heavily right now.
The Build Versus Buy Question Inside Every Extension
Before any custom extension gets built on BTP, whether through side-by-side or on-stack extensibility, it is worth asking whether the underlying business requirement can be met through standard SAP configuration or a pre-built SAP Store solution instead. This question sounds obvious stated plainly, but in practice it is frequently skipped under project time pressure, since building a bespoke extension often feels faster in the moment than researching whether a standard capability already covers the requirement adequately.
That shortcut is precisely how organisations end up with a growing library of custom BTP extensions duplicating functionality SAP already ships as standard, each one consuming BTP capacity and requiring its own ongoing governance, when a small configuration change or minor process adjustment would have met the same business need without adding to the extension inventory at all.
Building a Realistic Remediation Budget
Given the scale of typical custom code maintenance spend, a realistic clean core business case should include a genuine remediation budget for the existing extension landscape, not just the cost of building new extensions correctly going forward. That remediation work, auditing existing custom code against the four-level extensibility framework, prioritising which Level C and D extensions carry the highest business risk, and rebuilding those specifically on BTP or ABAP Cloud, is where the bulk of a clean core initiative’s cost and timeline typically sits, considerably more than the cost of building new functionality cleanly from a blank slate.
The Talent and Skills Dimension of a Clean Core Programme
A clean core initiative also changes what skill set a transformation programme needs to staff, and this is frequently underestimated in initial project planning. Traditional ABAP development skills remain necessary for on-stack extensibility, but side-by-side development on BTP increasingly requires cloud-native development skills, including familiarity with SAP Build, the CAP framework, and integration patterns that look considerably more like modern cloud application development than classic SAP customisation work.
Organisations staffing a clean core programme purely with traditional SAP ABAP developers, without building or acquiring the complementary cloud-native development capability BTP extensions require, tend to find the migration takes longer and costs more than planned, simply because the skill set needed to build extensions correctly the first time is genuinely different from the skill set that built the custom code sitting in the core today.
Measuring Progress Without Overstating It
A clean core programme needs an honest way to measure progress that goes beyond a binary clean or not clean assessment. Tracking the proportion of the estate’s total extensions sitting at each of the four maturity levels, and watching that distribution shift toward Level A and B over successive quarters, gives a genuine, gradual measure of progress that a simple pass or fail framing does not capture. Presenting clean core progress this way to leadership, as a trend line rather than a single completion milestone, also sets more realistic expectations for how long a genuine remediation programme takes, since moving a large, years-old custom code estate from predominantly Level C and D toward predominantly Level A and B is measured in years, not months, for most sizeable SAP landscapes.
Why Executive Sponsorship Matters More Than the Technical Plan
Clean core initiatives that succeed tend to have visible, sustained executive sponsorship, not because the technical work itself requires executive attention, but because the discipline clean core demands runs directly against the natural pressure every project team faces to ship a working solution quickly regardless of which architectural layer it lands in. Without visible leadership backing for the clean core standard, individual project teams under deadline pressure will quietly drift back toward core modifications whenever that route is faster than the properly governed BTP alternative, and that drift compounds silently until an organisation discovers, at the next major upgrade cycle, that its core is considerably less clean than the original programme intended.
Conclusion
Clean core is not free, and treating it as a simple architectural best practice rather than a genuine commercial decision with real BTP consumption costs, governance overhead, and remediation budget requirements is how transformation programmes end up surprised by their own clean core initiative’s true cost.
The organisations getting this right are modelling BTP consumption against included RISE allocations before committing to an extensibility roadmap, building a genuine governance function to keep the core clean after go-live rather than only at the point of migration, and treating the existing custom code remediation effort as the largest single cost driver in the entire clean core business case, since it consistently is.
