SAP Clean Core in S/4HANA: Warum Custom Code nicht einfach verschwinden darf

Clean Core is one of the central principles of modern SAP transformations. It describes the idea of keeping the ERP core as close to standard, upgrade-stable, and maintainable as possible. SAP defines Clean Core as a set of guiding principles that support continuous business transformation through agile, innovative, and efficient ERP systems.

But in many organizations, the term creates uncertainty. Does Clean Core mean that custom code is automatically bad? Do all custom developments have to be removed? And how can an SAP system remain specific enough to reflect real business requirements?

The short answer: Clean Core does not mean companies need to give up differentiation. It means extensions should be handled more consciously, more cleanly, and in a way that remains maintainable over time.

Clean Core Is Not a Ban on Individuality

Many SAP systems have grown over years. Reports, interfaces, extensions, and modifications were developed to reflect specific business requirements. In many cases, this custom code was necessary to run processes efficiently or create competitive advantages.

The problem is not custom code itself. The problem is uncontrolled custom code.

When custom developments are poorly documented, tightly coupled with the standard, or technically outdated, they make upgrades harder, increase maintenance effort, and add complexity to transformation projects. This is where Clean Core becomes relevant.

The goal is not to standardize everything. The goal is to make conscious decisions:

• What stays in the standard?
• What needs to be adapted?
• What can be removed?
• What should be modernized?
• What should be extended outside the ERP core?

Why Clean Core Matters for SAP S/4HANA

SAP S/4HANA is designed more strongly around continuous innovation, cloud readiness, and regular updates than traditional ECC landscapes. The more a system is burdened by unchecked modifications, the harder it becomes to adopt new functions, releases, and innovations quickly.

SAP’s Clean Core approach is clear: the core should remain close to standard and upgrade-stable, while differentiation remains possible. This is why SAP points to side-by-side extensions on SAP BTP as well as on-stack extensions with ABAP Cloud.

For companies, this changes the core question. It is no longer only about whether a requirement can be implemented. It is about where and how it should be implemented.

What Happens to Existing Custom Code

Existing custom code does not automatically disappear because of Clean Core. It needs to be analyzed, assessed, and prioritized.

Typically, custom code falls into four categories:

1. Custom Code That Is No Longer Used

Many systems contain custom developments that were created for historical reasons but are rarely or no longer used today. These developments should be identified and removed before they are unnecessarily carried into a new system.

2. Business-Critical Custom Code

Some custom code remains highly relevant because it supports central business processes. This code needs to be reviewed and, where necessary, adapted for SAP S/4HANA.

3. Technically Outdated Custom Code

Some developments still serve a purpose but are no longer technically future-ready. Here, companies need to decide whether they should be modernized, rebuilt, or replaced by standard functionality.

4. Strategic Extensions

Some extensions create real differentiation. These should not simply be removed. They should be architected properly, for example through SAP BTP, APIs, or ABAP Cloud.

The Role of SAP BTP and ABAP Cloud

SAP BTP plays a central role in Clean Core strategies. Side-by-side extensions make it possible to build individual applications or integrations outside the ERP core. This helps keep the central S/4HANA system more stable and easier to update.

ABAP Cloud, on the other hand, enables extensions within the SAP environment, but with a stronger focus on stable APIs, clear development models, and long-term maintainability.

The key point is this: companies do not have to choose between standardization and individuality. They need to choose the right architecture for each requirement.

Custom Code Adaptation as the Foundation for Clean Core

Before companies can decide how to handle their custom code, they need transparency. This is where Custom Code Adaptation becomes essential.

For custom code analysis in the context of SAP S/4HANA, SAP recommends using the ABAP Test Cockpit with S/4HANA checks. These checks identify findings related to S/4HANA simplifications and point to relevant SAP Notes.

This analysis is an important starting point. But it does not answer every question. Companies also need to assess:

• Which findings are business-critical?
• Which adaptations have priority?
• Which developments can be removed?
• Which adaptations are recurring?
• Which tasks can be automated?
• Which extensions should be implemented differently in the future?

Clean Core therefore does not begin in the target system. It begins with an honest assessment of the existing landscape.

Why Clean Core Should Not Be Treated as a Purely Technical Topic

Clean Core is a technical architecture principle, but its impact is strategic. A clean core affects not only IT effort, but also innovation capability, release readiness, and operating costs.

If companies treat Clean Core as a developer-only task, they miss the bigger picture. Business departments need to be involved as well. Many custom developments exist for a reason. They reflect real requirements, special processes, or historical decisions.

The central question should therefore not be: “How do we remove as much custom code as possible?”
A better question is: “Which individuality is truly valuable, and how do we implement it in a future-ready way?”

Common Mistakes in Clean Core Initiatives

Many companies start with the right intention, but run into similar problems.

Mistake 1: Treating Clean Core as Pure Standardization

When Clean Core is understood only as “back to standard,” resistance from business departments is likely. A better approach distinguishes between unnecessary complexity and valuable differentiation.

Mistake 2: Analyzing Custom Code Too Late

If custom code is assessed only shortly before or during the migration, unnecessary pressure is created. The analysis should start early, ideally during the planning phase.

Mistake 3: Prioritizing Technical Findings Without Business Context

Not every technical finding has the same relevance. Prioritization needs to combine technical urgency with business impact.

Mistake 4: Treating BTP as the Answer to Everything

SAP BTP is an important building block, but not every requirement automatically belongs on BTP. The decisive factor is a clear architectural decision.

Mistake 5: Forgetting Governance

Clean Core only remains effective if future developments follow clear rules. Without governance, the next layer of complexity starts growing immediately.

How Lupus Consulting Can Support

Lupus Consulting helps companies not only analyze custom code, but place it into a pragmatic and future-ready SAP architecture.

This includes:

• analyzing existing custom developments,
• assessing S/4HANA relevance,
• prioritizing adaptation effort,
• Custom Code Adaptation,
• SAP Development,
• architecture decisions around SAP BTP,
• support with Clean Core roadmaps.

With the Lupus Consulting CCA Toolset, recurring tasks in Custom Code Adaptation can be handled more efficiently. This helps reduce manual effort and makes implementation more predictable.

Conclusion: Clean Core Means Control, Not Restriction

Clean Core is not an attack on individual business processes. It is a way to make SAP landscapes more stable, maintainable, and innovation-ready over the long term.

The key lies in assessing custom code correctly. What no longer creates value should be removed. What is business-critical needs to be adapted properly. What creates strategic differentiation should be developed in a way that does not burden the ERP core.

For companies on the road to SAP S/4HANA, Clean Core is not a side topic. It is a central requirement for an SAP landscape that is not only migrated, but truly future-ready.