Learn what SAP Clean Core means, why it matters, and how to modernise custom code, extensions and integrations for SAP S/4HANA.
SAP Clean Core has become an important principle for organisations modernising their SAP landscapes. It is particularly relevant for businesses moving to SAP S/4HANA, adopting cloud ERP, addressing legacy custom code, or preparing their systems for continuous innovation.
Over time, SAP environments tend to accumulate custom developments, modifications, reports, workflows, and integrations. While these additions may address genuine business requirements, they can also increase technical debt, complicate upgrades, and make the system harder to maintain.
Clean Core addresses this challenge by keeping the SAP core as close as practical to standard functionality while using supported extensions and integration patterns for additional business requirements.
The goal is not to eliminate custom development. It is to make deliberate decisions about what should remain in the core, what should be modernised, and what belongs in a separate extension or integration layer.
Key Takeaways
- Clean Core is an architectural and governance principle, not a ban on custom code. It helps organisations manage customisations while maintaining a more upgrade-stable SAP environment.
- Standard SAP should be the starting point. Before building custom functionality, assess whether standard processes or supported extensions can meet the requirement.
- SAP BTP and ABAP Cloud support different extension scenarios. The right option depends on the functionality, integration requirements, and target architecture.
- Legacy custom code and integrations need to be assessed together. Moving to S/4HANA without reviewing technical debt can carry unnecessary complexity into the new environment.
- Clean Core requires ongoing governance. A one-time cleanup will not prevent technical debt from accumulating again unless new developments follow clear architectural standards.
What Is SAP Clean Core?
SAP Clean Core is an approach to designing and managing an SAP environment so that its core remains as standard, maintainable, and upgrade-stable as practical.
In a traditional SAP landscape, business requirements are often addressed through custom ABAP programmes, modifications to standard objects, bespoke reports, workflows, and tightly coupled integrations. Over time, these developments can create dependencies that are difficult to understand or test when the system changes.
Clean Core encourages organisations to assess those dependencies and use standard SAP functionality wherever it meets business needs. When additional functionality is necessary, the organisation should choose an appropriate extension approach and use supported interfaces wherever possible.
For example, a manufacturer may need a specialised application for production reporting. Rather than embedding every part of that application into the S/4HANA core, the business could use a side-by-side extension connected through supported interfaces.
The principle is straightforward: preserve the integrity of the ERP core while allowing the business to innovate around it.
Clean Core is therefore relevant to development, integration, architecture, business-process design, and IT governance. It is not simply a code-cleanup exercise.
Why Does Clean Core Matter?
The business value of Clean Core comes from reducing unnecessary dependencies across the SAP landscape.
When custom code or integrations are tightly coupled to the core, even a relatively small change can require additional analysis, remediation, and regression testing. This creates ongoing work for development and operations teams and can make future upgrades less predictable.
A more standardised core can reduce some of that complexity and provide a clearer foundation for introducing new functionality. It can also help organisations identify obsolete developments, simplify ownership, and direct investment towards capabilities that still create business value.
The impact extends across several teams. IT leadership gains greater visibility into technical debt and the long-term cost of change. Enterprise architects can establish clearer design standards, while SAP developers can work with more consistent extension patterns. Business process owners can also evaluate whether legacy customisations remain necessary or whether standard SAP functionality is now sufficient.
Clean Core can support AI and analytics initiatives, too, by encouraging consistent business processes and better-defined interfaces. It does not automatically make data AI-ready, but it can help establish a more manageable architecture for data access and AI-enabled applications.
What Should Stay in the SAP Core - and What Should Change?
A Clean Core programme starts by distinguishing between functionality the business genuinely needs and technical complexity that has accumulated over time.
Standard SAP functionality should usually be the first option. Before approving custom development, assess whether the requirement can be met through standard processes, configuration, or supported extensibility. If it can, adapting the business process may be preferable to maintaining a bespoke alternative.
Some custom functionality will still be necessary. It may support an industry-specific process, a distinctive customer experience, or a genuine competitive advantage. The important question is where and how that functionality should be implemented.
A practical assessment considers four dimensions:
|
Assessment area |
Key question |
|
Business value |
Does the functionality still support a necessary or differentiating process? |
|
Technical risk |
Does it rely on modifications, internal objects, or fragile dependencies? |
|
Standard alternatives |
Can standard SAP functionality or a supported extension replace it? |
|
Long-term ownership |
Is there a clear owner responsible for maintenance, testing, and future changes? |
Based on the findings, each development can be retained, remediated, replaced, redesigned as an extension, or retired.
For example, an old custom report may duplicate standard SAP analytics and no longer need to be maintained. A business-critical calculation may still be required but need technical remediation. A customer-facing application may be better suited to a separate architecture rather than further customisation of the ERP core.
The decision should be based on business value and architectural fit—not on whether a development is custom simply by definition.
SAP BTP, ABAP Cloud, and Extension Architecture
Once an organisation determines that additional functionality is necessary, it needs to select the appropriate extension approach.
SAP supports multiple extensibility options, including key-user extensibility, developer extensibility using ABAP Cloud, and side-by-side extensions. These options serve different requirements; they should not be treated as interchangeable technologies.
On-Stack Extensibility with ABAP Cloud
On-stack extensions run within the SAP environment. They can be suitable when functionality needs close integration with S/4HANA processes and data.
ABAP Cloud provides a development model designed around released APIs and supported development approaches. It enables organisations to continue using ABAP skills while reducing unnecessary dependencies on SAP's internal implementation.
Side-by-Side Extensibility with SAP BTP
Side-by-side extensions run separately from the ERP core, typically on SAP Business Technology Platform (BTP). They can be suitable for applications that need an independent lifecycle, connect multiple systems, or contain business logic that does not need to run directly inside S/4HANA.
SAP BTP supports application development, integration, automation, and extensions around the SAP core. However, moving functionality outside S/4HANA does not automatically make an architecture clean. Poorly designed interfaces, duplicated business logic, and unclear ownership can create technical debt in the extension layer as well.
The objective is to select the simplest supported architecture that meets the business requirement without introducing unnecessary dependencies.
Our SAP BTP implementation guide for UK businesses explains how BTP architecture, integration, extensions, and governance fit together.
Understanding SAP Clean Core Levels A, B, C, and D
SAP's Clean Core extensibility model classifies extensions into four levels according to their use of APIs and extension technologies, architectural characteristics, and alignment with upgrade-stability principles. The classification helps organisations assess their existing developments and prioritise remediation.
|
Level |
General characteristics |
Implication |
|
A |
Uses released, stable APIs and supported extension points |
Preferred approach for upgrade-stable extensibility |
|
B |
Uses classic APIs and technologies considered suitable under SAP's guidance |
May be appropriate where the relevant APIs and technologies are supported for the scenario |
|
C |
Relies on internal SAP objects |
Requires additional risk assessment and monitoring of relevant changes |
|
D |
Uses explicitly non-recommended techniques, such as modifications or certain implicit enhancements |
Highest concern for Clean Core alignment and should be prioritised for review |
The levels do not mean every object in a particular category must be removed immediately. They provide a structured way to assess the technical characteristics and risks of extensions.
For example, a Level C development may still support a critical legacy process. The organisation should assess its business value, dependencies, available alternatives, and upgrade exposure before deciding whether to remediate or replace it.
A Level D development may warrant higher priority because it relies on approaches SAP does not recommend.
For current definitions and the applicable technical guidance, refer to SAP's Clean Core extensibility guidance.
Clean Core Is Also an Integration Strategy
A standardised S/4HANA core can still be surrounded by a complex and difficult-to-maintain integration landscape. Clean Core should therefore cover interfaces and dependencies between SAP and other applications, not just custom ABAP.
Legacy point-to-point integrations can create risks when they rely on internal SAP objects, duplicate business logic, or have no clear owner. The same problem can occur when an extension runs outside S/4HANA but depends on undocumented interfaces or reproduces functionality already maintained elsewhere.
A more sustainable integration architecture uses supported APIs and appropriate integration patterns, with clear ownership, monitoring, and lifecycle management.
For an organisation planning an S/4HANA transformation, integration design should be considered alongside custom-code remediation and data migration. Leaving interface dependencies until the later stages can create significant testing and cutover issues.
Our SAP S/4HANA transformation guide covers the relationship between migration strategy, custom code, data, integration, and target architecture.
How to Implement an SAP Clean Core Strategy
Clean Core should be implemented as a structured programme, with decisions based on evidence rather than a blanket requirement to remove custom code.
1. Assess the Existing Landscape
Create an inventory of custom code, modifications, extensions, reports, workflows, interfaces, and surrounding applications. Establish which developments are actively used, which systems they depend on, and who owns them.
This baseline should combine technical analysis with input from business users. A development that appears obsolete from a technical perspective may still support a critical process, while a long-standing customisation may have no remaining business value.
2. Evaluate Business Value and Technical Risk
For each significant development, determine whether it supports a valid business requirement and whether its implementation introduces avoidable risk.
Review its dependencies, use of released APIs, maintainability, security, upgrade impact, and available standard alternatives. Prioritise items that combine high technical risk with significant business impact or frequent maintenance effort.
3. Rationalise Custom Code
Choose a target action for each development: retain, remediate, replace, redesign, or retire.
Legacy developments should not automatically be migrated into S/4HANA merely because they already exist. The transformation is an opportunity to remove functionality that no longer creates value and modernise the functionality that remains necessary.
4. Define the Target Architecture
Establish when to use standard SAP, configuration, key-user extensibility, ABAP Cloud, side-by-side extensions, or external applications. The decision should reflect how closely the functionality needs to interact with S/4HANA, which interfaces are available, and how the solution will be maintained.
5. Modernise Integrations and Establish Governance
Review interfaces alongside custom code, identify unsupported dependencies, and prioritise integration improvements.
Define approval rules for new custom developments, API usage, architecture reviews, documentation, and ownership. Every new extension should have a clear business justification and a maintenance plan.
6. Measure Progress
Track indicators that demonstrate whether the SAP landscape is becoming easier to manage. Useful measures include the number of obsolete developments retired, the proportion of extensions aligned with approved standards, the volume of high-risk interfaces, upgrade remediation effort, and maintenance work attributable to legacy custom code.
The goal is not to achieve the lowest possible number of custom developments. It is to make the SAP environment easier to understand, maintain, integrate, and change.
Applying Clean Core to Industry-Specific Requirements
Clean Core principles apply across industries, but the appropriate extension approach depends on how each business operates.
Energy and Utilities
Energy and utility organisations often connect SAP with asset-management, field-service, GIS, metering, and operational systems. Some requirements are highly specific to their operating model, so the priority is to preserve essential functionality while avoiding unnecessary coupling to S/4HANA.
For example, a specialised application for field engineers may need to exchange data with SAP without embedding every aspect of the application into the ERP core. A supported integration and extension architecture can help keep these responsibilities separate.
Retail
Retailers may need to connect core ERP processes with e-commerce, stores, warehouse systems, customer applications, pricing, and analytics.
A Clean Core approach allows organisations to maintain standard ERP processes while developing differentiated customer or digital experiences in suitable extension layers. This can help business applications evolve without requiring every change to be implemented inside the ERP core.
Across both industries, the principle is the same: preserve standard processes where they work well, and design custom capabilities around genuine business requirements.
Building the Business Case for Clean Core
The business case should focus on the cost and risk of maintaining the existing SAP landscape and the potential benefits of making it easier to change.
Organisations can start by measuring how much effort is spent maintaining custom developments, preparing upgrades, remediating interfaces, and testing changes. They can also identify unused functionality, dependency on specialist developers, and developments that duplicate standard SAP capabilities.
These measures provide a baseline against which improvement can be assessed. Benefits may include reduced maintenance effort, more predictable upgrades, lower technical debt, and a clearer path to adopting new SAP capabilities.
There is no universal cost or timeline for a Clean Core programme. The effort depends on the number and complexity of custom developments, integration dependencies, target architecture, and the extent of remediation required. A focused assessment can establish a realistic scope and roadmap before the organisation commits to a wider transformation.
For organisations moving from SAP ECC to S/4HANA, Clean Core activities are often part of the broader migration programme rather than a separate initiative. Our SAP S/4HANA migration guide for UK businesses explains how custom code, data, and integration considerations affect the migration approach.
Common Clean Core Mistakes to Avoid
The most common mistake is treating Clean Core as a requirement to eliminate all custom development. That can lead organisations to remove business-critical functionality or redesign solutions unnecessarily.
The opposite mistake is to move every legacy customisation into S/4HANA without assessing whether it remains necessary. Doing so can preserve the technical debt that the transformation was meant to address.
Organisations should also avoid assuming that every extension belongs on BTP. The architecture should be selected according to the requirement, available interfaces, lifecycle, and maintenance needs. Similarly, a clean ERP core will not solve integration problems if the surrounding applications remain tightly coupled.
Finally, Clean Core should not be treated as a one-time project. Without governance for future development and integration, the same complexity can accumulate again.
What to Review Before Starting
Before launching a Clean Core programme, establish a shared understanding of the current landscape and the decisions that must be made.
At a minimum, confirm which custom developments remain business-critical, which rely on risky dependencies, where standard SAP capabilities can replace custom functionality, how integrations should evolve, and who will own each retained or redesigned solution.
These decisions should lead to a prioritised roadmap that balances business value, technical risk, available resources, and the wider SAP transformation strategy.
How LeverX Supports SAP Clean Core Initiatives
At LeverX, we help organisations assess and modernise SAP landscapes through SAP consulting, S/4HANA transformation, custom-code assessment, integration, SAP BTP, data management, and application support.
Our approach connects architectural decisions with business requirements. We help determine which developments should be retained, remediated, replaced, moved, or retired, and how the target extension and integration model should support the organisation's future operating needs.
For UK organisations, this work can be part of a broader S/4HANA transformation or a focused initiative to reduce technical debt and improve the maintainability of an existing SAP environment.
Learn more about our SAP S/4HANA transformation expertise or SAP BTP implementation capabilities.
Frequently Asked Questions
Does SAP Clean Core mean eliminating all custom code?
No. Clean Core aims to keep the SAP core as close to standard as practical while implementing necessary custom functionality through appropriate, maintainable extension approaches. Business-critical custom development may still be justified.
What is the difference between on-stack and side-by-side extensibility?
On-stack extensibility runs within the SAP environment and can be suitable for functionality closely connected to S/4HANA. Side-by-side extensions run separately, typically on SAP BTP, and can be appropriate for applications that need an independent lifecycle or broader integration.
What are SAP Clean Core levels A, B, C, and D?
They classify extensions according to their use of APIs and technologies, architectural characteristics, and alignment with SAP's Clean Core guidance. Level A represents the preferred use of released, stable interfaces, while Level D covers explicitly non-recommended approaches. The model helps teams assess and prioritise risk rather than treating every custom object identically.
How does SAP BTP support Clean Core?
SAP BTP provides capabilities for side-by-side applications, integration, automation, and extensions. It can help separate custom functionality from the S/4HANA core, provided the solution uses appropriate interfaces and has clear ownership and governance.
When should an organisation start a Clean Core assessment?
An assessment is particularly useful before an S/4HANA transformation, when upgrading a heavily customised SAP environment, or when technical debt and integration complexity are making changes difficult. Starting with an inventory and risk assessment helps establish priorities before committing to remediation.
How much does an SAP Clean Core programme cost?
There is no universal price. Costs depend on the size of the SAP landscape, the number and complexity of custom developments, integration dependencies, and the level of remediation required. An initial assessment is the best way to define scope and create a realistic budget.
Disclaimer: This article is provided for general informational purposes and reflects general SAP Clean Core principles. Specific recommendations depend on the organisation's SAP products, release, architecture, business requirements, and transformation scope. SAP capabilities and technical guidance may evolve, so relevant documentation should be verified during solution design.
