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 evolved from a technical architecture concept into a broader transformation principle for organisations modernising their SAP landscapes. It is particularly relevant for companies moving to SAP S/4HANA, adopting cloud ERP, modernising custom code, or preparing their SAP environment for AI and continuous innovation.

The concept emerged from a practical challenge: SAP systems tend to accumulate custom code, modifications, and tightly coupled integrations over years of operation. While these developments may solve genuine business requirements, they can also increase technical debt, make upgrades more complex, and create dependencies that limit the organisation's ability to adopt new SAP capabilities.

As SAP moved towards S/4HANA, cloud-based ERP, and more frequent innovation cycles, the traditional approach of embedding business-specific logic directly into the ERP core became increasingly difficult to sustain. This led to a shift towards standardising the core and moving necessary custom functionality into controlled extension and integration layers.

The central idea is simple: keep the SAP core as standard, stable, and upgrade-safe as practical, while implementing necessary differentiation through governed extensions, integrations, and applications.

But Clean Core does not mean eliminating custom development. The real challenge is deciding what should remain in the core, what should be modernised or retired, and what should move to an extension layer such as SAP BTP.

Key Takeaways

• SAP Clean Core is not about eliminating customisation. It is about keeping the SAP core standard and upgrade-stable while placing necessary extensions in the appropriate architectural layer.
• Standard SAP should be the starting point. Custom development should be justified by a genuine business requirement or competitive differentiation.
• SAP BTP and ABAP Cloud are key extension options. They allow organisations to build custom capabilities while reducing unnecessary dependency on the S/4HANA core.
• Legacy custom code should be assessed before an S/4HANA transformation. Organisations should decide what to retain, remediate, replace, move, or retire rather than automatically migrating everything.
• Integration is part of Clean Core. A clean ERP core can still be undermined by tightly coupled, difficult-to-maintain integrations.
• Clean Core supports AI readiness. A more standardised and governed SAP landscape can provide a stronger foundation for trusted data, automation, and AI-enabled processes.
• Clean Core requires ongoing governance. Without clear rules for new extensions, integrations, and custom development, technical debt can gradually return.

Want to Explore Your Clean Core Strategy? Talk to our SAP experts to learn more about SAP Clean Core or discuss how the approach could apply to your specific SAP landscape, custom code, extensions, and transformation plans.
Talk to our SAP experts

What Is SAP Clean Core?

SAP Clean Core is an approach to managing an SAP landscape in which the ERP core stays as close as practical to standard SAP functionality and uses supported, upgrade-stable mechanisms for extensions and integrations.

This is particularly important in long-running SAP environments, where custom ABAP code, modifications, bespoke workflows, custom tables and reports, point-to-point integrations, and legacy applications can accumulate over time. Such complexity can make the system harder to maintain, upgrade, and adapt.

Clean Core addresses this by keeping business-specific logic out of the ERP core wherever practical and using modern extension approaches instead.

SAP BTP is an important part of this approach, supporting side-by-side extensions, applications, integrations, automation, and AI capabilities without unnecessarily modifying the S/4HANA core.

SAP also supports on-stack extensibility with ABAP Cloud, providing another option for requirements that need to run within the SAP environment.

Why Does SAP Clean Core Matter?

The business case for Clean Core goes beyond cleaner code. It can affect the teams responsible for SAP operations, development, business processes, upgrades, integrations, and innovation.

More Predictable Upgrades for IT

Custom modifications and tightly coupled developments can make SAP upgrades more complicated because changes need to be assessed for compatibility and regression risk.

Using supported extension mechanisms can make upgrades more predictable and reduce the effort required to adapt custom developments.

Lower Technical Debt for IT and Development Teams

Custom functionality has an ongoing cost. It requires maintenance, testing, documentation, security controls, and specialist knowledge.

Reducing unnecessary custom code can lower the technical debt that development and support teams need to manage over time.

Greater Flexibility for Business Teams

A heavily customised SAP environment can make it harder to change business processes or adopt new capabilities.

A more standardised core gives business and product teams greater flexibility to introduce:

• AI;
• automation;
• analytics;
• cloud services;
• digital applications;
• new business processes.

Easier Innovation for Architecture and Integration Teams

Clean Core supports an architecture in which SAP handles core business processes while differentiated applications, integrations, and services can evolve more independently.

This can make it easier for enterprise architects and integration teams to introduce new technologies without creating additional dependencies in the ERP core.

Better Foundation for AI and Data Teams

AI and analytics depend on reliable data, consistent processes, and well-defined interfaces.

A more standardised SAP environment can reduce the complexity of accessing and using business data across SAP and surrounding applications, creating a stronger foundation for AI-enabled processes and analytics.

Who Benefits from Clean Core?

The impact is therefore broader than the SAP development team:

Clean Core therefore becomes a business and technology governance principle, not simply a development standard.

Clean Core Does Not Mean No Customisation

Clean Core Does Not Mean No Customisation

One of the most common misconceptions is that Clean Core means organisations should stop customising SAP.

That is not the objective.

Businesses often have legitimate reasons to differentiate. A retailer may need a unique customer experience. A utility may need a specialised field-service application. A manufacturer may have proprietary production processes.

The question is not:

Should we customise SAP?

It is:

What is the appropriate way to implement this requirement without unnecessarily coupling it to the ERP core?

SAP's extensibility model provides several options, from key-user extensibility to developer extensibility and side-by-side extensions.

A strong Clean Core strategy therefore recognises that custom development can be legitimate when it is deliberate, maintainable, and implemented in the right architectural layer.

What Should Stay in the SAP Core?

What Should Stay in the SAP Core?

The starting point should normally be standard SAP functionality.

Before creating a custom solution, ask:

• Does SAP already support the process?
• Can the business adopt the standard process?
• Is the requirement genuinely differentiating?
• Would changing the business process be preferable to changing SAP?

This is closely aligned with Fit-to-Standard thinking used in modern SAP transformations.

For example, organisations should question whether a heavily customised finance workflow is genuinely differentiating before deciding to rebuild it in a new S/4HANA environment.

What Should Be Extended Outside the Core?

What Should Be Extended Outside the Core?

Some requirements should remain custom when standard SAP does not reasonably cover them or when they support genuine business differentiation.

Typical examples include:

Customer-facing applications

Custom portals, mobile applications, and digital experiences can consume SAP data and services without becoming part of the transactional core.

Industry-specific applications

A utility company may require an application designed specifically for field engineers, asset inspections, or network operations.

AI applications

An organisation may want to build AI-powered applications or agents around SAP business processes without embedding all AI logic directly inside S/4HANA.

Complex integrations

Third-party systems, legacy platforms, external services, IoT environments, and specialised operational applications may need to connect with SAP through governed integration patterns.

Differentiated workflows

Where a business has a genuinely unique process, an extension can provide the required functionality without turning the ERP core into a bespoke application platform.

SAP BTP and Clean Core

SAP BTP and Clean Core

SAP Business Technology Platform is SAP's cloud platform for building, integrating, extending, and operating applications and services across an organisation's SAP and non-SAP landscape.

For Clean Core, BTP provides a place to build side-by-side extensions - custom applications, workflows, integrations, automation, data services, and AI capabilities that need to work with SAP but do not need to become part of the S/4HANA core.

With side-by-side extensibility, applications and services can run independently from the SAP core while interacting with S/4HANA through supported interfaces. This helps separate the lifecycle of custom applications from the lifecycle of the ERP and can reduce direct dependencies on the core.

SAP describes BTP as a foundation for side-by-side extensions and identifies a BTP-first approach as an important option for clean extensibility.

SAP also supports on-stack extensibility with ABAP Cloud, which is useful when an extension requires close integration with the S/4HANA application itself.

The choice should therefore be based on the requirement rather than a blanket rule that everything must run on BTP.

On-Stack vs. Side-by-Side Extensibility

On-Stack vs. Side-by-Side Extensibility

Once an organisation decides that a requirement should be implemented as an extension rather than as a modification of the SAP core, the next question is where that extension should run.

SAP provides two main approaches: on-stack extensibility, where the extension runs within the S/4HANA environment, and side-by-side extensibility, where it runs separately from the ERP core, typically on SAP BTP.

On-Stack

Appropriate when the extension is tightly connected to S/4HANA and benefits from close integration with the application.

SAP's ABAP Cloud development model supports clean-core-compliant on-stack developer extensibility in SAP S/4HANA Cloud environments.

Side-by-Side

More appropriate when the application needs:

• an independent lifecycle;
• loose coupling;
• significant custom business logic;
• integration across multiple systems;
• independent scaling;
• external services;
• a broader application context.

SAP BTP supports this model through side-by-side development.

The important question is therefore not simply "BTP or S/4HANA?", but "Which extension location creates the lowest long-term dependency on the core?"

SAP Clean Core and ABAP

SAP Clean Core and ABAP

Clean Core does not mean abandoning ABAP. For organisations with established SAP development teams, the goal is to modernise how ABAP is developed and where it is used, rather than discard existing skills.

SAP's ABAP Cloud development model is designed for clean-core-compliant applications, extensions, and services. It uses released APIs and supported development approaches to reduce dependencies on SAP's internal implementation.

ABAP Cloud can be used for both on-stack extensions in SAP S/4HANA Cloud and side-by-side development on SAP BTP.

The shift is therefore not from ABAP to no custom code, but from:

Uncontrolled Embedded Custom Code

to

Governed, Upgrade-Stable Extension Development

SAP Clean Core and Legacy Custom Code

SAP Clean Core and Legacy Custom Code

For existing SAP customers, this is often the hardest part of the journey.

A mature SAP landscape may contain years of accumulated developments, including code nobody fully understands anymore.

Before an S/4HANA transformation, organisations should determine:

• what still creates business value;
• what can be replaced by standard SAP;
• what is obsolete;
• what requires remediation;
• what should be redesigned;
• what should move to another extension layer.

SAP provides tooling for assessing custom code and its impact during S/4HANA transformation and Clean Core initiatives.

A useful rule: Do not migrate technical debt simply because it already exists. A new S/4HANA environment is an opportunity to question the historical assumption that every legacy customisation must survive.

The 10 Customisations You Should Question First

The 10 Customisations You Should Question First

Not every custom development deserves the same attention.

These are particularly worth reviewing during a Clean Core assessment:

1. Custom reports that duplicate standard SAP analytics
2. Custom approval workflows
3. Legacy interfaces with limited business ownership
4. Modifications to standard SAP objects
5. Custom logic built around old business processes
6. Redundant master-data processes
7. Bespoke forms that could use modern capabilities
8. Old batch jobs and background programs
9. Applications duplicating functionality available in SAP
10. Custom developments with no clearly defined business owner

For each one, ask:

Would we build this again today?

If the answer is no, the next question should be whether it can be retired rather than simply modernised.

How Clean Is Your SAP Core?

How Clean Is Your SAP Core?

A useful Clean Core assessment can start with a simple set of questions.

Custom Code

• How much custom ABAP is in the landscape?

• How much of it is still actively used?

• How much relies on older or unsupported approaches?

Extensions

• Which extensions use released APIs and official extension points?

• Which are tightly coupled to internal SAP objects?

Integrations

• How many point-to-point interfaces exist?

• Which integrations rely on non-released interfaces?

• Who owns and maintains them?

Business Processes

• Which processes have been heavily customised?

• Which of those customisations are genuinely differentiating?

Governance

• Can development teams introduce new custom logic without architectural review?
• Are there clear standards for how new extensions should be designed?

If new customisations can be introduced without clear architectural controls, a clean core can gradually become a complex core again.

SAP Clean Core Levels A, B, C and D

SAP Clean Core Levels A, B, C and D

SAP's newer extensibility guidance uses four Clean Core levels to classify extensions based on their architectural characteristics and upgrade risk.

Level A

Extensions aligned with released APIs and official extension points and intended to be upgrade-safe.

Level B

Extensions that also use classic but documented APIs and technologies supported by SAP.

Level C

Extensions that access internal SAP objects. These may continue to work but have higher dependency and upgrade risk.

Level D

Extensions using approaches SAP does not recommend, including certain modifications, implicit enhancements, or direct write access to SAP tables.

SAP uses the levels as a way for organisations to understand the maturity of their extensions and identify where cleanup or modernisation should be prioritised.

This creates a useful principle for transformation planning:

Do not treat every piece of custom code as equally risky.

Prioritise the developments with the highest combination of business criticality, technical risk, and upgrade impact.

Clean Core Is Also an Integration Strategy

Clean Core Is Also an Integration Strategy

A clean ERP core can still sit inside a complex integration landscape. That is why Clean Core should address integration architecture as well as custom code and extensions.

SAP's 2026 guidance explicitly treats integration as part of the Clean Core strategy, focusing on reducing integration-related technical debt, improving upgrade stability, and using appropriate API-based, event-driven, and central middleware patterns.

This is particularly important for organisations with:

• legacy applications;
• third-party SaaS platforms;
• warehouse automation;
• IoT;
• customer platforms;
• e-commerce;
• operational technology.

The objective is not simply to remove customisations from SAP, but to avoid replacing one tightly coupled architecture with another.

Clean Core and AI: The Connection Many Organisations Miss

Clean Core and AI: The Connection Many Organisations Miss

AI is one of the strategic reasons organisations are paying more attention to Clean Core.

AI depends on reliable business data, consistent processes, well-defined interfaces, and sufficient business context. A heavily customised SAP landscape can make these foundations harder to establish when business rules and data are spread across:

• SAP configuration;
• custom ABAP;
• external applications;
• spreadsheets;
• integrations;
• manual processes.

SAP increasingly positions Clean Core as a foundation for continuous innovation and AI-enabled business processes.

The important point is:

Clean Core is not an AI strategy by itself. It is one of the architectural foundations that can make enterprise AI easier to scale.

Clean Core Business Case

Clean Core Business Case

The business case for Clean Core is not simply about reducing development or maintenance costs. Its value comes from reducing the cost and risk of change across the SAP landscape.

A more standardised core can affect several areas of the total cost of ownership:

Lower Cost of Change

Custom code and tightly coupled integrations make even relatively small SAP changes more expensive because they require additional analysis, development, testing, and regression work.

Reducing unnecessary dependencies can lower the effort required to introduce changes over time.

More Predictable Upgrades

The more an organisation depends on custom modifications and non-standard interfaces, the more work may be required to assess and remediate them during an upgrade.

A cleaner core can reduce this remediation effort and make upgrade planning more predictable.

Lower Technical Debt

Every custom development creates a future maintenance obligation. Over time, obsolete code, undocumented logic, and dependencies on individual specialists can become a significant cost.

Rationalising the customisation footprint prevents organisations from continuing to invest in functionality that no longer delivers sufficient business value.

Faster Adoption of Innovation

The value of Clean Core is also measured in what the organisation can do more easily.

A less constrained SAP landscape can make it easier to adopt new S/4HANA capabilities, cloud services, automation, analytics, and AI without repeatedly redesigning or working around legacy customisations.

Reduced Operational Risk

Fragile integrations, unsupported extensions, and poorly understood custom code can create operational and upgrade risks that are difficult to quantify until they cause a problem.

Clean Core governance helps make these dependencies visible and gives organisations a structured way to reduce them.

How to Build the Business Case

Rather than relying on generic savings claims, organisations should establish their own baseline. Useful measures include:

• annual effort spent maintaining custom code;
• regression-testing effort for SAP changes;
• upgrade remediation effort;
• number and complexity of point-to-point integrations;
• dependency on specialist developers;
• cost of obsolete or unused developments;
• time required to introduce new SAP capabilities.

The business case is therefore not "how much custom code can we remove?"

It is:

"How much easier, faster, and less risky can we make change across the SAP landscape?"

How Much Does SAP Clean Core Cost?

The cost of a Clean Core programme depends mainly on the size and complexity of the SAP landscape. Typical consulting budgets can range from £30,000–£80,000 for an initial assessment to £150,000–£500,000+ for a broader Clean Core transformation.

Typical cost areas include:

These figures are indicative market ranges for planning purposes and are not LeverX pricing or quotations.

For an ECC-to-S/4HANA transformation, Clean Core activities are usually part of the wider migration budget rather than a separate project.

The final cost depends on the number of custom developments and integrations, the amount of functionality that can be retired or replaced with standard SAP, and the extent of remediation and extension work required.

The best way to establish an accurate budget is to start with a Clean Core assessment and build the roadmap from the findings.

Request a Clean Core assessment

How Long Does a SAP Clean Core Programme Take?

The timeline depends on the scope and complexity of the SAP landscape.

These are indicative planning ranges, not LeverX project timelines or commitments. Actual timelines depend on the number of custom developments, integrations, business processes, and remediation activities involved.

Why Start Your Clean Core Journey Now?

The longer technical debt remains in an SAP landscape, the more expensive it can become to address. Starting early gives organisations time to assess their customisations, make rationalisation decisions, and modernise selectively rather than under the pressure of a major transformation.

There are several reasons to start now:

• S/4HANA transformation is already changing SAP landscapes. Organisations moving from ECC have an opportunity to address legacy custom code and integrations instead of carrying them forward.
• SAP innovation cycles are accelerating. A heavily customised core can make it harder to adopt new capabilities as they become available.
• AI initiatives depend on a strong digital foundation. Organisations planning AI use cases need reliable data, processes, and integrations around the ERP core.
• Technical debt compounds over time. The longer obsolete developments and fragile integrations remain, the more difficult it can be to understand, replace, or retire them.

Starting with an assessment does not mean transforming the entire landscape at once. It means understanding where the biggest risks and opportunities are and creating a prioritised roadmap.

Existing SAP Customer vs. New S/4HANA Implementation

The Clean Core strategy looks different depending on where the organisation starts.

Existing SAP Customer: From ECC to S/4HANA

For organisations running SAP ECC, Clean Core is often part of a broader S/4HANA transformation rather than a standalone technical initiative.

Years of development may have resulted in:

• custom ABAP programmes and modifications;
• bespoke reports and workflows;
• custom tables and enhancements;
• point-to-point integrations;
• interfaces built around legacy processes;
• business processes that have evolved beyond the original SAP design.

The key question is not whether all of this can be technically migrated to S/4HANA, but whether it should be.

A useful approach is:

Assess → Rationalise → Remediate → Retire → Re-architect

Each existing customisation should be assessed for business value, technical compatibility, upgrade impact, and future relevance. Some functionality can be replaced by standard S/4HANA processes, some may need remediation or redesign, and some may be better implemented as an extension outside the core.

This makes the move from ECC an opportunity to reduce accumulated technical debt rather than simply carry it into the new environment.

New S/4HANA Programme

For organisations implementing S/4HANA without the same legacy footprint, the priority is prevention.

The biggest risk is taking the old operating model and rebuilding it as a new customised implementation. A new programme should establish extension, integration, and governance rules from the beginning.

The principle is simple:

Do not recreate tomorrow's technical debt while trying to eliminate yesterday's.

SAP Clean Core Red Flags

These signs should trigger a closer review of the SAP landscape:

Every Upgrade Becomes a Major Project

If upgrades require extensive custom-code analysis, remediation, and regression testing, the landscape may be too tightly coupled.

Nobody Knows Why a Customisation Exists

A custom object without a clear business owner or purpose is a strong candidate for review.

Business Logic Exists in Several Systems

Duplicated logic increases complexity and can lead to inconsistent business outcomes.

New Applications Require Direct Core Modifications

This may indicate that the current extension architecture is creating unnecessary dependencies on S/4HANA.

AI Projects Cannot Access Consistent Business Data

The problem may not be the AI technology itself, but the underlying data, process, and integration landscape.

The Business Depends on a Small Number of SAP Developers

Heavy reliance on a few specialists creates operational risk and makes knowledge transfer more difficult.

Integrations Frequently Break

Frequent interface failures may indicate deeper architectural dependencies rather than isolated operational issues.

New Developments Are Approved Without Architectural Governance

Even a successful Clean Core transformation can deteriorate if new customisations and integrations are introduced without clear standards and review.

A Practical Clean Core Decision Framework

Before approving a custom requirement, use the following questions to assess its business value, architectural fit, and long-term impact:

1. Is there standard SAP functionality?

2. Can the business process be adapted instead?

3. Is the requirement genuinely differentiating?

4. Which approved extension mechanisms could support it?

5. Does it require tight coupling to S/4HANA?

6. Could it be implemented side-by-side?

7. Which released APIs or extension points are available?

8. Who will own and maintain the solution?

9. How will it affect future upgrades?

10. Would we still make this architectural decision three years from now?

That final question is often the most useful: a solution that looks appropriate today should not create unnecessary constraints for tomorrow.

How to Implement a SAP Clean Core Strategy

A Clean Core strategy should be treated as an ongoing transformation programme rather than a one-time technical cleanup. The practical goal is to understand what is in the SAP landscape, decide what still deserves to exist, and establish clear rules for everything that is built next.

1. Build a Current-State Inventory

Start by creating a reliable inventory of the SAP landscape. This should cover:

• custom code;
• modifications;
• extensions;
• interfaces and integrations;
• custom tables;
• workflows;
• reports;
• surrounding applications.

The inventory should show not only what exists, but also where it runs, what it connects to, who owns it, and whether it is still being used.

For example, a custom ABAP programme that has not been used for several years should not automatically be carried into an S/4HANA transformation simply because it is technically compatible.

Do not rely entirely on tribal knowledge. Combine SAP analysis tools, system data, usage information, technical analysis, and input from business owners to establish an evidence-based view of the landscape.

Output: a current-state catalogue showing the organisation's customisation, extension, and integration footprint.

2. Assess Business Value

Next, determine why each significant customisation exists and whether that reason is still valid.

Ask:

• What business process does it support?
• Who uses it?
• What happens if it is removed?
• Does it provide measurable business value?
• Could standard SAP now provide the same capability?

This step is particularly important for ECC-to-S/4HANA transformations. A custom process may have been justified years ago because standard SAP did not support the requirement. That does not mean the same justification still applies today.

For example, a bespoke approval workflow may have been created to address a historical process that the business could now handle using standard S/4HANA functionality.

Output: a business-value assessment for each significant customisation.

3. Assess Technical Risk

Business value alone is not enough. A business-critical customisation may still need to be retained, but its technical implementation may need to change.

Review:

• dependencies on SAP objects;
• use of released or non-released APIs;
• modifications;
• architecture and integration patterns;
• upgrade impact;
• security;
• maintainability;
• documentation;
• ownership.

The aim is to identify developments that are particularly difficult to maintain or likely to create problems during future SAP changes.

A useful approach is to combine business criticality with technical risk. A technically risky development that supports a critical process may deserve higher priority than a technically complex object that is rarely used.

Output: a prioritised view of technical risk and remediation needs.

4. Rationalise

Use the business and technical assessments to decide what should happen to each development:

Retain → Replace → Remediate → Rebuild → Move → Retire

For example:

• Retain when the functionality remains valuable and the existing implementation is appropriate.
• Replace when standard SAP can provide the required capability.
• Remediate when the functionality is still needed but the technical implementation creates unnecessary risk.
• Rebuild when the business capability is important but requires a fundamentally different implementation.
• Move when the functionality belongs outside the S/4HANA core, such as a side-by-side application.
• Retire when the functionality no longer provides sufficient value.

This prevents a common S/4HANA transformation mistake: migrating every existing customisation simply because it already exists.

Output: a rationalisation decision and target action for each significant customisation.

5. Define the Target Extension Architecture

Once the organisation knows what it needs to keep, replace, or rebuild, define where new functionality should live.

Establish when the organisation should use:

• standard SAP;
• key-user extensibility;
• developer extensibility;
• ABAP Cloud;
• SAP BTP side-by-side extensions;
• external applications.

The decision should reflect the nature of the requirement.

For example, a small business adjustment closely connected to an S/4HANA process may be suitable for on-stack extensibility. A customer-facing application with its own lifecycle and integrations across several systems may be better suited to a side-by-side architecture on SAP BTP.

The objective is not to put every custom requirement on BTP. It is to choose the extension location that provides the required capability without creating unnecessary dependency on the core.

Output: a target extension architecture and clear decision rules for future development.

6. Modernise Integrations

Review integrations alongside custom code rather than treating them as a separate technical issue.

Identify interfaces that:

• depend on non-released SAP objects;
• create tight point-to-point dependencies;
• duplicate business logic;
• are difficult to test or monitor;
• have unclear ownership;
• frequently break when SAP changes.

Where appropriate, move towards supported APIs, event-driven patterns, and suitable integration platforms or middleware.

For example, if several external applications directly depend on internal SAP objects, replacing those dependencies with supported interfaces can reduce the impact of future S/4HANA changes.

Output: an integration roadmap that identifies which interfaces should be retained, redesigned, consolidated, or retired.

7. Establish Clean Core Governance

Clean Core can deteriorate quickly if new customisations are introduced without controls.

Define clear rules for:

• custom development;
• APIs and extension points;
• integration;
• architecture reviews;
• documentation;
• ownership;
• exceptions to Clean Core standards.

For example, a new custom development should have a documented business justification, an identified owner, a defined extension approach, and an assessment of its future upgrade impact.

Governance should apply to both the existing landscape and new developments. Otherwise, an organisation can complete a major Clean Core transformation and gradually rebuild the same complexity.

Output: a governance model that makes Clean Core part of normal SAP decision-making.

8. Measure Progress

Finally, establish a baseline and track improvement over time.

Useful indicators include:

• custom-code footprint;
• extension maturity;
• obsolete objects retired;
• number of risky interfaces;
• upgrade remediation effort;
• percentage of processes using standard functionality;
• number of new developments approved through Clean Core governance.

The objective is not to achieve a particular number of custom objects. A smaller custom-code footprint is useful only if the remaining functionality continues to support the business effectively.

The more meaningful question is whether the SAP landscape is becoming easier to understand, maintain, upgrade, integrate, and change.

Output: a Clean Core scorecard that shows progress and highlights areas requiring further action.

SAP Clean Core: Industry Use Cases

The Clean Core principle applies across industries, but the specific challenges vary depending on the complexity of the SAP landscape and the systems surrounding the ERP core.

Energy & Utilities: Connecting ERP with Operational Systems

Energy and utility organisations often have particularly complex SAP landscapes because ERP processes need to coexist with asset-intensive operations and specialised operational systems.

Typical environments may include:

• asset management;
• field service;
• customer systems;
• billing;
• smart meters;
• GIS;
• SCADA;
• workforce management;
• procurement;
• finance.

In this environment, Clean Core should be considered as part of a broader enterprise architecture strategy.

For example, a utility may need a custom field-service application for engineers. The requirement may be highly specific to the organisation, but that does not mean the application should be embedded deeply in S/4HANA.

A side-by-side application can provide the required functionality while keeping the ERP focused on core business processes and reducing dependencies on the SAP core.

The Clean Core decision is therefore not about removing industry-specific functionality. It is about placing that functionality in the right architectural layer.

Retail: Separating Core Processes from Digital Experiences

Retailers face a different but equally complex landscape involving:

• stores;
• e-commerce;
• pricing;
• promotions;
• inventory;
• loyalty;
• product data;
• supply chain;
• warehouse systems;
• customer applications;
• AI.

Here, the challenge is often to keep core ERP processes stable while allowing customer-facing and digital capabilities to evolve quickly.

Standard SAP can support core finance, procurement, and supply-chain processes, while custom applications and extensions can address differentiated retail experiences and integrations.

For example, an AI-powered personalisation or pricing application may need to consume SAP data but have its own development and release cycle. Keeping that capability outside the S/4HANA core can allow the retailer to innovate without repeatedly changing the ERP foundation.

The same principle can apply to forecasting, connected stores, customer applications, and agentic commerce: use the SAP core where standard ERP capabilities are appropriate, and extend around it where the business needs to differentiate.

Need Help Applying Clean Core to Your Landscape?

LeverX can help assess your SAP landscape and define a practical Clean Core strategy.

Talk to our SAP experts

Common SAP Clean Core Mistakes

Common SAP Clean Core Mistakes

Treating Clean Core as "Zero Custom Code"

Clean Core does not mean eliminating all custom development. Some requirements may genuinely need a custom solution.

The mistake is treating customisation itself as the problem rather than assessing its business value and architectural impact.

Rebuilding Every Legacy Customisation

An existing development should not automatically be carried into S/4HANA.

If it supports an outdated process or duplicates functionality now available in standard SAP, rebuilding it simply preserves unnecessary complexity.

Putting Everything on BTP

BTP is not automatically the right answer for every custom requirement.

The appropriate approach depends on the functionality, integration needs, lifecycle, and level of coupling required.

Ignoring Integration Debt

A landscape can remain highly complex even after unnecessary SAP customisations have been removed.

Legacy interfaces and tightly coupled dependencies therefore need to be considered as part of the overall transformation.

Focusing Only on IT

Clean Core decisions also require business input.

A technically complex solution may still be justified if it supports a critical business capability, while a technically simple customisation may no longer have sufficient business value.

Treating Clean Core as a One-Time Project

Clean Core needs to be maintained as new requirements emerge.

Without clear decision-making standards, unnecessary complexity can gradually accumulate again.

SAP Clean Core Checklist

SAP Clean Core Checklist

Before beginning an S/4HANA transformation or Clean Core programme, ask your SAP team:

• How much custom code do we have?
• Which developments are business-critical?
• Which are still actively used?
• Which use non-released APIs or internal objects?
• Which modifications create upgrade risk?
• How many point-to-point integrations exist?
• Which customisations can be replaced by standard SAP?
• Which developments should be retired?
• Which extensions should move to BTP?
• Which should use ABAP Cloud?
• Who owns every critical custom solution?
• How much effort does an SAP upgrade currently require?
• How will new custom development be governed?

The answers create the starting point for a realistic Clean Core roadmap.

Conclusion

Conclusion

SAP Clean Core is not a project to remove custom code for the sake of technical purity.

It is a way to build an SAP environment that is easier to upgrade, easier to maintain, easier to extend, and better prepared for continuous innovation.

For existing SAP customers, that means making deliberate decisions about legacy custom code, integrations, extensions, and business processes.

For organisations implementing S/4HANA, it means establishing the right architecture before technical debt becomes embedded again.

And for organisations investing in AI, Clean Core can provide part of the foundation required to connect trusted data, business processes, extensions, and intelligent applications.

The goal is not to eliminate differentiation.

The goal is to differentiate outside the places where differentiation creates unnecessary complexity.

Ready to Assess Your SAP Clean Core Strategy?

LeverX helps organisations modernise SAP landscapes across SAP S/4HANA, SAP BTP, custom development, integration, data, AI, and broader SAP transformation programmes.

Talk to our SAP experts

Disclaimer: This article is provided for general informational purposes and reflects general SAP Clean Core principles and practices. Recommendations, costs, timelines, and implementation approaches may vary depending on an organisation's SAP landscape, business requirements, technical environment, and transformation scope. Any cost and timeline figures are indicative planning ranges only and do not represent LeverX pricing, quotations, or project commitments. Specific recommendations should be based on an assessment of the individual SAP environment.