What Is a Realistic Clean Core Approach? A Step-by-Step Guide

Clean core is like traveling light: less to carry, less friction, and a more pleasant journey overall. 

“ERP without the baggage”. A cleaner core makes every step forward easier. 

For years, SAP systems grew the same way many successful businesses do: by adapting.

Custom code filled gaps. Enhancements supported edge cases. Integrations solved problems that the standard didn’t cover at the time.

That adaptability, however, came with a cost: technical debt.

In most cases, that debt was not the result of bad decisions. Quite the opposite. It emerged naturally from day-to-day operations. From quick fixes, integrations, and custom logic added to support critical functionality when the standard fell short.

This is not a SAP problem either. Every company has its own particularities. The things that differentiate it from competitors. Expecting a single standard to cover every edge case is unrealistic, like trying to boil the ocean.

Of course, a certain level of technical debt is inevitable in any long-lived ERP landscape.

The challenge appears when that debt keeps compounding over decades. What started as isolated enhancements slowly turns into a dense web of custom code, integrations, and dependencies that becomes increasingly hard to untangle.

Now, with a clear modernization deadline on the calendar, this becomes a tough moment for IT leaders. Here’s why.

Why Does Clean Core Need a Realistic Interpretation?

SAP ECC is approaching the end of mainstream support. Staying on ECC means moving into extended maintenance, with higher fees, no major updates, and increased operational risk that few CIOs are willing to take on.

That said, for most organizations, there aren’t many viable alternatives beyond S/4HANA at this point.

At the same time, CIOs and IT leaders face another reality.

They are expected to modernize their systems, while also dealing with growing pressure to adopt AI and move faster on innovation. Boardrooms expect the business to have the speed and agility to incorporate new capabilities and, often, every new “shiny” initiative that promises a reasonable ROI.

All of this is expected to happen while the S/4HANA migration is still underway. And that migration can take months or even years, depending on how each organization approaches the project.

Clean core connects directly to this challenge.

What Clean Core Is (And What It Is Not)

SAP has been clear about what Clean Core is not:

“A Clean Core does not mean the absence of custom code.”

The goal is not to remove what makes each business different. It’s to rethink where customization is placed.

In SAP’s own words, customization should be decoupled from the core, so innovation does not come at the cost of stability, upgrades, or future flexibility. SAP even summarizes this idea as “ERP without the baggage.”

The problem is how clean core is often interpreted:

Taken literally, it sounds like an ideal scenario where everything runs standard, and the Z code disappears. That view does not reflect how businesses operate, nor how SAP landscapes evolved over the decades.

A more realistic and useful approach is different. Clean core works when it is applied pragmatically. Customization is still there, because in most cases it supports business-specific functionality that the standard does not fully cover. The difference is how that customization is structured, isolated, and maintained.

This article walks through a step-by-step approach to implementing Clean Core realistically.

What does Clean Core actually mean in SAP?

Before going into principles, it helps to clear up a common misconception. Clean Core is not a tool, a product, or a method you “apply” to a system. It is closer to an aspirational goal that guides architectural and design decisions over time.

With that in mind, a Clean Core approach aims to:

  • Keep the SAP core close to standard

  • Avoid modifying standard objects

  • Use released extensibility mechanisms

  • Decouple business-specific logic from the core

  • Reduce upgrade and operational friction over time

  • The emphasis is not on purity, but on sustainability.

Should the system adapt to the business or the business to the system?

That question has been sitting at the center of SAP implementations for decades.
And it’s the real tension behind the Clean Core discussion.

Most companies operating in the same industry share a similar backbone. Finance, procurement, logistics, compliance. Those foundations rarely differ that much from one organization to another.

Where companies truly compete is not in the core. It’s at the edges.

That’s where you find pricing models that don’t fit the standard, contract structures shaped by years of negotiation, regulatory nuances that only apply in specific markets, performance-sensitive workflows, and industry-specific logic that makes the business work the way it does.

A realistic Clean Core approach starts by acknowledging both realities.

You need a stable, maintainable core. And you also need room for differentiation.

The challenge is not choosing one over the other. It’s preventing differentiation from turning the core into something unmanageable.

What are the real benefits of clean core?

When applied pragmatically, Clean Core can deliver:

  • Faster and safer upgrades

  • Less regression testing effort

  • More predictable operating costs

  • Lower dependency on legacy expertise

  • Easier adoption of new SAP capabilities

There is also an implicit trade-off. The more custom code lives inside the core, the more expensive, slow, and risky S/4HANA becomes to operate.

What are the risks and trade-offs of clean core?

Clean Core is not all roses.

Many organizations invested heavily in custom development to cover gaps in the SAP standard. That code often exists for valid reasons and supports business-critical processes.

Removing or externalizing it without analysis can:

  • Break key workflows

  • Create performance bottlenecks

  • Add integration overhead

  • Shift complexity instead of reducing it

This is why Clean Core is best treated as a direction, not a fixed end state.

How do RISE with SAP and GROW with SAP relate to clean core?

Both models promote Clean Core, but they serve different organizational needs:

Dimension RISE with SAP GROW with SAP
Target organizations Large and complex enterprises Mid-sized organizations
Deployment model Private cloud or single-tenant Public cloud, multi-tenant
Level of control High. Greater control over system behavior and upgrades Limited. More standardized by design
Customization flexibility Higher. Allows more flexibility when using supported approaches More constrained. Customization options are intentionally limited
Clean Core enforcement Strongly encouraged, but not absolute Largely enforced by the platform
Typical use case Organizations with complex processes, legacy customizations, and higher transformation needs Organizations prioritizing speed, standardization, and faster adoption
Fit for heavily customized landscapes Better suited Limited fit

What Role Does SAP BTP Play in a Realistic Clean Core Approach?

SAP Business Technology Platform acts as the innovation and extension layer in a Clean Core architecture.

It enables:

  • Side-by-side applications

  • API-based extensions

  • Integration across systems

  • Experimentation with AI and automation

Many organizations use BTP even while still on ECC, often starting by replatforming PI/PO to Integration Suite or building custom apps.

When the backend later moves to S/4HANA, much of this work can be reused by changing API endpoints rather than rebuilding logic. In that sense, BTP is not a detour. It is a bridge.

What is Z code and why does it matter for Clean Core?

In SAP terminology, Z code refers to customer-built objects that sit outside the SAP standard.

Objects prefixed with Z* or Y*:

  • Are not maintained by SAP

  • Were built by customers or partners

  • Can become upgrade and maintenance risks if unmanaged

Z code is not inherently bad. The problem arises when it:

  • Modifies standard objects

  • Creates deep dependencies

  • Replicates ECC-era patterns without rethinking

  • Lives permanently inside the core

Is ABAP incompatible with Clean Core?

No.

ABAP is SAP’s native language and is used extensively in the standard product itself.

ABAP aligns with Clean Core when used through:

  • Released BAdIs

  • In-app extensibility

  • CDS views

  • Key user extensions

  • ABAP Cloud

  • Whitelisted APIs and objects

ABAP conflicts with Clean Core only when it modifies standard objects, relies on non-released exits, or creates tight core dependencies.

What Does a Realistic Step-by-Step Clean Core Approach Look Like?

Step 1: Inventory and classify custom code

Identify what is obsolete, redundant, business-critical, and performance-sensitive.

Step 2: Remove what no longer adds value

Unused logic increases risk without benefit. This is where the fastest gains usually come from.

Step 3: Protect true differentiators

Not all customization should disappear. Preserve what genuinely supports competitive advantage.

Step 4: Decide where customization belongs

In-core via released extensibility, side-by-side on BTP, or external systems via integrations. This should be an architectural decision, not an ideological one.

Step 5: Establish governance

Clean Core fails without discipline. Clear rules for new customization, ownership, and lifecycle management are essential.

Final Takeaway for IT Leaders

When it comes to clean core in SAP modernization, thinking in absolutes often leads to the wrong conclusions.

On one end of the spectrum, clean core is interpreted as zero customization, as if what works for one business should work the same way for everyone else. In reality, every organization has its own differentiators. Many customizations were built to address real gaps in the standard and often represent years of thoughtful investment.

On the other end, excessive customization inside the core increases coupling, slows down upgrades, and raises operational risk. This is what makes it harder to adopt new capabilities and turns modernization into a heavy, frustrating experience for IT teams.

There is a more balanced approach, and this is how I interpret what SAP is actually aiming for.

SAP states it clearly: “A clean core does not mean the absence of custom code.”

In practice, there will always be functionality that sits in gray areas and exists because a specific business genuinely needs it. That reality should be acknowledged. The goal is not to discard past investments, but to restructure them.

A realistic clean core approach is about keeping the core stable while placing customization where it belongs, decoupled, controlled, and able to evolve independently. That is what creates long-term agility and makes future innovation, upgrades, and new technologies far easier to adopt.

As SAP partners, we work with organizations navigating this balance every day. If you want to explore a pragmatic modernization path and align your ECC to S/4HANA transition with the upcoming deadlines, we’re happy to share how we approach clean core in real-world transformations. Book a call with us.


FAQs:

Is Inclusion Cloud an SAP partner?

Yes. Inclusion Cloud is an SAP partner with hands-on experience supporting ECC, S/4HANA, SAP BTP, and Clean Core–oriented modernization programs.

Does Inclusion Cloud follow SAP’s Clean Core principles?

Yes. Inclusion Cloud aligns with SAP’s Clean Core guidelines, focusing on minimizing core modifications, using released extensibility, and decoupling business logic where appropriate.

Does Clean Core mean eliminating all custom code?

No. SAP explicitly states that a Clean Core does not mean the absence of custom code. The focus is on where and how customization is implemented, not removing it entirely.

How does Inclusion Cloud approach customization under Clean Core?

Customization is evaluated case by case. Business-critical logic is preserved, but structured using supported extensibility, side-by-side patterns, or integrations instead of core modifications.

Can Inclusion Cloud help modernize ECC systems before S/4HANA migration?

Yes. Inclusion Cloud helps organizations modernize incrementally, often using SAP BTP and integration patterns, even while ECC is still in place.

Does Inclusion Cloud support both RISE with SAP and GROW with SAP?

Yes. Inclusion Cloud works with both models and helps organizations understand how Clean Core applies differently depending on deployment, scale, and control requirements.

Inclusion Cloud: We have over 15 years of experience in helping clients build and accelerate their digital transformation. Our mission is to support companies by providing them with agile, top-notch solutions so they can reliably streamline their processes.