You're probably living this already. The business wants faster releases, the cloud program wants a cleaner environment, and your SAP team is staring at years of ECC-era custom code that nobody fully trusts anymore. Every upgrade feels like a judgment day for old enhancements, brittle interfaces, and reports that only one person still understands.
That's where SAP Clean Core stops being a buzzword and becomes an operating discipline. Done well, it gives CIOs a way to keep the ERP core stable, classify what's acceptable to extend, and push real complexity into governed layers instead of letting it rot inside S/4HANA.
Table of Contents
- Why Clean Core Has Become an Upgrade Survival Skill
- What Clean Core Actually Means in S/4HANA
- The Four Levels of Extensibility Explained
- Choosing Between On-Stack and Side-by-Side Extensions
- Governance Patterns That Keep the Core Clean
- What Clean Core Means for Integration and Data Architecture
- The Hard Decision to Retire, Refactor, or Keep
- A Practical Roadmap for Cleaning Up Your Core
Why Clean Core Has Become an Upgrade Survival Skill
A CIO usually meets the problem at the worst possible time, during a migration wave, when the business still depends on old enhancements, scattered Z-programs, and integrations nobody wants to touch. The technical team says the upgrade is ready, then testing explodes because every custom path has to be checked again. The project loses time not because SAP is unstable, but because the enterprise has made the core harder to reason about than the business can afford.
SAP Clean Core addresses that reality with operating discipline. SAP's guidance treats it as a governed model, and the RISE with SAP Methodology dashboard in SAP Cloud ALM includes clean-core compliance views plus data-volume-efficiency KPIs such as unused data, redundant data, outdated data, custom table footprint, HANA memory, and HANA disk, with trend tracking over time, so cleanup becomes measurable rather than a matter of opinion (SAP clean-core governance overview). That matters because the upgrade problem is no longer just code, it also involves data, operations, and evidence.
Practical rule: if a customization makes the next upgrade harder to test, harder to explain, or harder to govern, it already costs more than it should.
Why the old habits stop working
Freezing custom code sounds safe until the business asks for a new process, a regulatory change, or a new digital channel. Delaying upgrades creates a different problem, because cloud release cycles do not wait for a long cleanup program to finish. Heavy regression testing can keep the lights on for one cycle, but it does not solve the root problem, it only preserves it.
SAP's own materials show that the answer is to manage the environment continuously, not in bursts. In SAP-published customer material, one case reduced SAP ERP add-ons from more than 9,000 to 520 and reported faster SAP S/4HANA Cloud upgrade cycles, shorter project times, and lower costs. Another SAP practice deck showed a move from more than 5,000 objects in ABAP Standard to fewer than 100 objects in ABAP Cloud after only a few months (SAP customer value network material). Those examples do not mean every program will look the same, but they do show the direction. Less core modification means less upgrade friction.
| Dimension | Legacy ECC Approach | Clean Core Approach |
|---|---|---|
| Change style | Modify the core when business asks | Extend through released, governed interfaces |
| Upgrade posture | Treat upgrades as exceptions | Treat upgrade readiness as a standing requirement |
| Testing burden | Large regression cycles after each change | Smaller, more targeted validation around controlled extensions |
| Technical debt | Hidden inside custom objects | Visible in dashboards and remediation backlogs |
| Operating model | Project-based cleanup | Ongoing governance discipline |
What Clean Core Actually Means in S/4HANA
A Clean Core is easier to understand if you picture an engine bay where every part has a label, a purpose, and a way to be replaced without dismantling the whole vehicle. In SAP terms, that means the standard processes, standard APIs, standard data model, and standard integration patterns stay intact, while business-specific needs are handled through approved extension points.
That's the key point many teams miss. Clean Core does not mean zero customization. It means you extend in a way that keeps the ERP upgrade-stable and observable. A customer-specific report built on released APIs is very different from a direct table write, even if both solve a business problem on day one.
SAP's own Clean Core materials frame this around five control domains, extensibility, integrations, data, business processes, and operations, so the conversation is broader than ABAP alone (SAP ABAP extensibility guide). That is the right mental model for a CIO, because the architectural decision is never only technical. It shapes how the business changes, how data moves, and how the operating team proves compliance.
Three examples that make the boundary visible
A clean extension could be a Fiori app that reads released business objects and writes back through approved APIs. Another clean example is a side-by-side service on SAP BTP that orchestrates a workflow without touching SAP internals. A third is a custom report that uses the supported data access patterns available in the environment.
By contrast, a direct modification of standard code, an implicit enhancement that hooks into internal behavior, or a direct write to an SAP table belongs on the other side of the line. SAP's guidance makes that distinction explicit because upgrade safety depends on it. The boundary matters more than the label.
Use this sentence in executive conversations: Clean Core is not about forbidding innovation, it's about deciding where innovation lives so the ERP core stays predictable.
The Four Levels of Extensibility Explained
The biggest gain from SAP's newer model is that it replaces vague judgment with a risk-ranked classification. Instead of asking whether a customization is “allowed,” SAP now groups extensions into four levels, which is far more useful for portfolio management.
Level A and Level B are the safe zone
Level A is fully clean. SAP defines it as extensions that use only released APIs, either built on-stack with ABAP Cloud or side-by-side on SAP BTP. A pricing validation built on released business objects would belong here. So would a new app or service that lives outside the core but interacts through documented interfaces.
Level B can still be acceptable, but it uses classic, documented SAP APIs. That makes it more constrained than Level A, yet still manageable if governance is strong. A legacy report rewritten to use supported classic APIs instead of internal objects is the kind of case that often lands here.
Level C and Level D are where upgrade exposure starts
Level C relies on internal SAP objects. SAP says these should be placed on a remediation roadmap, not treated as the endpoint. A custom enhancement that reaches into non-released classes or function modules is the classic example. It may keep business moving today, but it raises maintenance risk every time the platform changes.
Level D is the red flag category. It covers direct modifications, implicit enhancements, and direct table writes. These are the changes that create severe upgrade exposure, because they sit closest to the areas SAP expects to remain standard. If your setup still contains these, you don't have a design preference, you have a remediation backlog.
SAP's classification turns clean core into a backlog with priorities. New development should go to Level A by default. Older objects should be mapped, then reduced in waves, with Level D first, then Level C, while the business keeps only the exceptions that earn their place.
A clean-core program fails when it tries to solve everything at once. It succeeds when teams rank every extension by risk, business value, and how hard it would be to replace.
Video reference for teams that prefer a walkthrough format.
Choosing Between On-Stack and Side-by-Side Extensions
Once an extension has been classified as clean enough, the next question is where it belongs. That decision usually comes down to lifecycle ownership, data proximity, performance needs, and integration complexity. In practice, the choice is less about ideology and more about what kind of change the business is asking for.
On-stack ABAP Cloud works well when the logic is tightly coupled to SAP transactions and needs to stay close to the core data model. A pricing check, a validation step, or a business rule that depends on transactional context often belongs there. The advantage is simple, the extension stays close to the process it serves.
Side-by-side on SAP BTP makes more sense when the requirement is orchestration-heavy, integration-heavy, or user-experience heavy. Process coordination, workflow layers, external API mediation, and new digital front ends often fit better there. A useful overview of that model is Kagool's guide to SAP extend and innovate, which places extensions in the BTP layer to preserve core stability.
A simple decision rule
If the logic must act inside the transaction, keep it on-stack. If it must coordinate across systems, expose a new experience, or buffer change over time, move it side-by-side. That rule is simple enough for architecture boards and specific enough to reduce debate.
| Decision factor | On-stack ABAP Cloud | Side-by-side on SAP BTP |
|---|---|---|
| Best fit | Transactional logic with data locality | Orchestration, UI, and cross-system workflows |
| Upgrade safety | High when only released APIs are used | High, because logic stays outside the core |
| Skill profile | ABAP Cloud and SAP business object modeling | SAP BTP services, integration, and app development |
| Performance | Best for low-latency core-adjacent tasks | Better for decoupled, distributed scenarios |
| Integration pattern | Directly tied to SAP process context | Strong fit for API-led and event-driven design |
The mistake is treating BTP as a universal answer. It isn't. If the extension adds another hop without reducing risk, you've moved the problem, not solved it. If it creates a governed layer that absorbs change and keeps the ERP stable, it earns its place.
Governance Patterns That Keep the Core Clean
A CIO usually hears “clean core” first as an architecture promise, then as a control problem. The promise is simpler upgrades. The control problem is harder, because a core stays clean only when the organization can see what is being added, who approved it, and what it will cost later. SAP now makes that visible through tooling such as the Cloud ALM clean-core compliance dashboard, plus metrics that track stack version, custom code volume, business modifications, and, in newer guidance, data-efficiency indicators. That changes governance from a policy statement into part of the release cadence.
The governance artifacts that matter
A Clean Core policy should define what the enterprise permits at each extensibility level. It should also make the approval path visible, so a Level D change does not slip through under the label of “small customization.” A remediation backlog should rank Level D first, then Level C, with named owners and target dates. Release readiness should include a check on whether new work is drifting into unreleased internals.
A quarterly review is usually where the picture appears. Teams compare what they believed was clean with what the dashboard shows is still drifting, still modified, or still carrying technical debt. The dashboard matters because it turns the discussion into evidence, not opinion.
Data governance belongs in the same room
Clean core often gets misunderstood because the code can be tightly controlled while the data layer becomes messy. SAP's newer dashboard KPIs include unused data, redundant data, outdated data, custom table footprint, HANA memory, and HANA disk, so the governance lens reaches into data discipline as well. That is why architecture reviews should include both technical owners and data stewards, not only ABAP leads or basis teams. The question is not just whether the extension is allowed, but whether the data it creates can be governed after it is live, which is where SAP data governance for enterprise intelligence becomes a useful reference point.
If your organization is also working through master data ownership, the connection to master data governance MDM is direct. Extension design and master data rules tend to fail together. When the extension model ignores ownership, validation, and lifecycle control, the core stays technically clean while the business sees inconsistent records, duplicate entries, and reporting gaps.
Clean Core governance works when the business knows who owns each extension, who approves deviations, and which KPI shows the portfolio is actually getting cleaner.
What Clean Core Means for Integration and Data Architecture
A clean core changes where complexity lives. Once teams stop pushing logic straight into the ERP core, the pressure moves into middleware, interface contracts, data pipelines, and analytics platforms. That shift only works when those surrounding layers are governed with the same discipline the core now follows, or the organisation relocates technical debt instead of reducing it.
Integration gets cleaner, but not simpler
SAP's guidance pushes teams toward standard APIs and SAP Integration Suite patterns, while reducing reliance on older approaches like RFC and direct table access. It also places SAP Event Mesh in the mix for event-driven scenarios, which fits situations where asynchronous business events work better than point-to-point calls. A useful practical discussion of the broader integration challenge is Bridge Global's piece on maximizing software integration, because clean core programmes often fail if the integration layer is left unmanaged.
The architectural picture is clearer, but the operational load does not disappear. Integration teams take on more of the work around mapping, monitoring, retries, and exception handling, so the question becomes whether those controls are visible, owned, and tested. Clean core redistributes that burden into a different part of the stack.
Data discipline becomes part of the architecture
SAP's latest governance direction makes the data side more visible, with dashboard measures for unused, redundant, and outdated data, plus custom table footprint and HANA resource consumption. That matters because data sprawl becomes harder to justify once the ERP core is standardised. If the business keeps creating duplicate tables and unmanaged extracts, the technical debt moves outward.
The same logic applies to platform boundaries. Kagool's guidance on what SAP BTP means for business leaders helps clarify which parts of the new complexity belong in BTP, which belong in the data platform, and which should stay in SAP. Clean core becomes a portfolio-management discipline at that point, with choices about where to place each extension, interface, and dataset rather than a simple yes-or-no rule.
Governance has to cover the full chain. If the integration layer, data layer, and analytics layer are not measured together, the core may look cleaner while the surrounding architecture grows harder to support.
The Hard Decision to Retire, Refactor, or Keep
The hardest clean-core decision is not technical. It's whether a customization still deserves its place in the portfolio. A lot of teams assume every old object should be modernized, but that can waste budget on things the business barely uses. The question is whether the object still earns its lifecycle cost.
Use three questions, not one rule
First, does the extension still deliver clear business value? If the answer is weak, retirement should be on the table. Second, can the need now be met by standard functionality or a released API? If yes, refactor or replace it. Third, what is the ongoing cost of keeping it in place, including upgrade testing, support, and knowledge risk?
Those three questions are better than a binary “keep or kill” rule because they let the business justify a small set of exceptions. A clean-core program does not have to eliminate every Level C object to be successful. It has to keep the exceptions deliberate, visible, and owned.
When to tolerate a small exception set
If an extension is differentiating, hard to replace, and stable enough to govern, it may be rational to keep it for now. That's especially true when the business value is clear and the remediation effort would distract from higher-risk items. The discipline is in being honest about why it stays.
A useful test is this. If a business sponsor can't explain why the customization exists, and the technical team can't explain why it can't be replaced, it probably belongs in the retirement queue. If both can explain it, you've got a candidate for controlled retention, not blind preservation.
A Practical Roadmap for Cleaning Up Your Core
A workable clean-core program usually unfolds in four phases, and each phase should have a different success measure. The aim isn't perfection on day one. It's to make the system cleaner with every release while the business keeps moving.
The sequence that works
| Phase | Focus | Typical Duration | Success Metric |
|---|---|---|---|
| Discovery | Inventory custom code and classify A to D | Early program wave | Complete baseline of extensions and data hotspots |
| Quick wins | Retire obvious Level D dead code and redundant reports | First cleanup cycle | Visible reduction in highest-risk objects |
| Steady state | Build dashboards, governance rituals, and release gates | Ongoing after baseline | Regular compliance reviews and fewer exceptions |
| Continuous | Treat clean core as portfolio management | Multiple release cycles | New work defaults to Level A and old risk keeps shrinking |
What to do first
Start by inventorying what you have. Classify custom objects into A, B, C, and D, then separate business-critical items from dead weight. That gives you a real backlog instead of a vague cleanup wish list.
Then remove the obvious waste. Retire unused reports, duplicate tables, and Level D items that create obvious risk but little business value. After that, lock in the operating rhythm, including named owners, dashboard reviews, and release checks that stop new debt from creeping back in.
Best operating habit: every new extension should be asked two questions before it's built, where does it sit in the A to D model, and what happens to it at the next upgrade?
A clean-core journey is rarely one project, because the environment keeps changing. The right objective is a portfolio that stays governable, upgrade-ready, and honest about where the hard complexity now lives.
If you want help turning this into a practical SAP roadmap, Kagool works on SAP delivery, integration, data governance, and platform design for enterprises that need cleaner extensibility and better control across hybrid environments. Visit Kagool to explore how its SAP and data teams approach governed modernization, from core cleanup to integration and analytics architecture.
