Clean core is the phrase SAP has been using consistently in its conversations with customers, partners, and analysts for the past several years. If you have been in any SAP-related technology conversation recently, you will have encountered it. And if you are like most enterprise technology leaders, you have heard it enough times to know it is important without being entirely certain what it means in practice or what it actually requires from your organisation.
That ambiguity is not accidental. Clean core is simultaneously a genuine architectural philosophy, a commercial strategy, and a product positioning narrative. Understanding which dimension is being emphasised in any given conversation is important for making sense of what is being asked of you and why.
This blog cuts through the terminology to explain what clean core actually means in operational terms, why SAP is pushing it so consistently, what the genuine benefits are for organisations that achieve it, and what the honest challenges are for the many that are starting from a long way behind where clean core requires them to be.
What Clean Core Actually Means
Clean core, in the SAP context, refers to a philosophy of keeping the SAP system as close to standard as possible. In the days of SAP ECC, enterprise customisation was the norm. Organisations routinely modified SAP’s source code directly, built bespoke functionality on top of standard processes, and created integrations that reached deep into SAP’s proprietary architecture. This approach delivered tailored systems that fitted the organisation’s specific processes, but it came at a cost. Upgrades were expensive because every customisation had to be reviewed, retested, and often rebuilt. Implementations took longer. Maintenance burden grew with every additional line of custom code.
Clean core inverts this philosophy. The principle is that the core SAP system should be kept standard, with customisations and extensions built outside the core using SAP’s Business Technology Platform rather than directly modifying the S/4HANA system itself. Extensions are deployed through defined extension points, integrations use documented APIs, and the core system remains upgradeable and maintainable without the technical debt of embedded customisations.
In practice, clean core is not a binary state. It is a spectrum. An organisation with a completely unmodified S/4HANA system is theoretically at one end. An organisation that has migrated from ECC carrying years of custom development into S/4HANA without rationalising any of it is at the other. Most real-world implementations sit somewhere in between, and the journey toward clean core is one of incremental rationalisation rather than a single transformation event.
SAP’s own blog publishes regular guidance on the clean core philosophy, including practical frameworks for assessing extension and customisation scope and the SAP Business Technology Platform capabilities that support clean core-compatible development. Their SAP blog clean core strategy and guidance provide the vendor perspective on what clean core means in practice, including technical guidance on the extension patterns that are and are not compatible with a clean core approach.
Why SAP Is Pushing Clean Core So Hard
Understanding SAP’s motivation for promoting clean core helps organisations interpret the commercial context of the conversation. Clean core serves SAP’s interests in several ways that are worth being transparent about.
First, clean core makes SAP’s quarterly release cycle commercially viable. S/4HANA Cloud Public Edition operates on a rapid release cadence, delivering new functionality every quarter. This is only sustainable if customers can absorb those updates without expensive retesting of heavily customised environments. If every customer had a bespoke system that required months of testing before each update, the SaaS delivery model would collapse. Clean core is the architectural prerequisite for the cloud operating model SAP is trying to establish.
Second, clean core moves development activity onto SAP’s Business Technology Platform, for which SAP charges separately. When organisations extend S/4HANA using BTP rather than custom ABAP development, they are purchasing BTP services in addition to their S/4HANA licences. Clean core is therefore not just an architectural philosophy. It is a commercial expansion strategy.
Third, clean core reduces SAP’s support complexity. Supporting customers with heavily customised systems requires vendor resources and creates support complexity that impacts SAP’s service margins. Standardised systems are cheaper to support.
None of these motivations mean that clean core is bad advice for customers. The genuine benefits of a more standardised system, including faster upgrades, lower maintenance burden, and easier access to SAP’s innovation roadmap, are real. But understanding that SAP’s enthusiasm for clean core aligns with its commercial interests allows organisations to engage with the strategy on their own terms rather than simply following a vendor recommendation.
Deloitte’s SAP practice publishes research on clean core adoption patterns and the organisational challenges that determine whether a clean core strategy delivers its expected benefits. Their Deloitte SAP clean core and ERP transformation research address the practical implementation requirements of a clean core approach, covering the extension rationalisation work, BTP adoption considerations, and change management challenges that organisations face as they pursue a more standardised SAP environment.
The Custom Code Challenge
For most organisations that have been running SAP for a long time, the honest starting point for any clean core conversation is a reckoning with the volume and complexity of existing custom code. ABAP customisations accumulated over ten or fifteen years represent a technical debt burden that does not disappear simply because the organisation has migrated to S/4HANA. Many S/4HANA migrations carried this custom code forward with minimal rationalisation, either because the migration timeline did not accommodate the clean-up work or because the business was not ready to change the processes that the custom code supported.
A clean core programme for these organisations has to start with a custom code audit that identifies what exists, what is actively used, what duplicates standard SAP functionality that has since been added to the core product, and what is genuinely necessary because the business process it supports cannot be delivered through standard configuration. This audit is invariably a sobering exercise. In most mature SAP environments, a significant proportion of existing custom code can be retired without any business impact because the standard product has evolved to cover the same ground.
The custom code that genuinely needs to be retained then needs to be evaluated for migration to BTP extension patterns rather than continued maintenance as embedded ABAP. This migration is not technically trivial, and it requires investment in BTP skills that many SAP development teams do not currently have. The skills transition from ABAP development to BTP-based extension development is one of the most significant organisational challenges in any serious clean core programme.
The New Stack covers enterprise cloud-native development practices and the technology transitions that organisations are navigating as they move from legacy platform-specific development toward API-driven extension architectures. Their The New Stack cloud-native development and platform transition coverageprovide context on the development practice changes that clean core requires, including the shift toward API-first integration patterns and the organisational capability development needed to sustain clean core-compatible extension development.
BTP: The Other Side of the Clean Core Equation
SAP Business Technology Platform is the technical foundation on which clean core-compatible extensions are built. It provides integration capabilities, development tools, data management services, and AI features that are designed to extend S/4HANA without embedding code in the core. For organisations pursuing a clean core strategy, BTP is not optional. It is the platform on which the extensions that used to live inside the SAP core now need to live instead.
This creates a commercial consideration that many organisations have not fully factored into their clean core planning. BTP is a separate licensed product with its own consumption-based pricing. As extensions move from ABAP inside S/4HANA to BTP-based services, the BTP cost increases. The internal development cost may decrease as custom ABAP maintenance falls, but the BTP service cost rises to partially offset that saving. Modelling the total commercial impact of clean core, including the change in BTP licensing cost, is essential for understanding what the strategy actually costs over a three to five year horizon.
BTP also requires a different technical skill set from the ABAP development capabilities that most mature SAP organisations have built. BTP uses modern development languages and frameworks, cloud-native architecture patterns, and integration approaches that are new to many SAP development teams. The skills investment needed to build and maintain BTP-based extensions is a real cost that needs to be planned for explicitly.
DATAVERSITY publishes research on enterprise data platform strategy and the technical governance requirements of cloud-native extension architectures. Their DATAVERSITY enterprise platform and extension architecture research address the data management and integration governance considerations that organisations need to establish as they build BTP-based extensions and move away from tightly coupled ABAP customisations in the SAP core.
Is Your Organisation Ready for Clean Core?
The honest answer for most large SAP customers is: not yet, but the direction is right. Clean core is a multi-year journey for organisations with complex existing SAP landscapes. It requires a custom code audit and rationalisation programme, investment in BTP skills and capabilities, a process governance framework that prevents new customisations from accumulating outside the clean core pattern, and a business change management programme that addresses the process standardisation that clean core often requires.
Organisations that try to pursue clean core as a technology programme without the process and governance dimensions typically find that the custom code problem reasserts itself within a few years. The technical architecture of clean core is the enabler. The organisational discipline to maintain it is the harder and more important part.
The starting point that most organisations can take immediately, regardless of where they are in their S/4HANA journey, is a custom code audit that establishes a clear picture of what they currently have. This audit does not commit the organisation to a particular clean core roadmap. It provides the evidence base from which an informed, commercially grounded clean core strategy can be developed.
Conclusion
SAP clean core is a genuine and valuable architectural direction for organisations that are committed to it for the right reasons and prepared to invest in the organisational and technical work it requires. It is not a short-term project or a simple configuration choice. It is a multi-year programme that touches custom code, business processes, development skills, BTP licensing, and the governance frameworks that prevent the problem from recurring. The organisations that approach it with that level of seriousness will build SAP environments that are more maintainable, more upgradeable, and more capable of leveraging SAP’s ongoing innovation. The ones that treat clean core as a messaging commitment rather than an operational transformation will find that the technical debt they started with simply accumulates in a different location.
