SAP S/4HANA Clean Core: A Practical Framework for Custom Code Assessment and Remediation

Years of SAP customization add up. Z-reports, user exits, BAdIs, custom interfaces, Smart Forms, and bespoke Fiori apps all accumulate over time. Most of this coding in the past has helped to solve business problems.

Still, in the process of switching to SAP S/4 HANA, it has become one of the main factors resulting in project risks, excessive project costs, instability after going live, and complications in upgrade processes.

This article provides a clear technical framework for the assessment of custom coding in the framework of the Clean Core strategy.

What Clean Core Actually Means?

A clean core is not zero customization. It is an architecture where SAP standard functionality stays untouched, while business-specific needs are met through approved channels.

Under this model, custom logic should be:

• Decoupled from SAP standard objects
• Built on released APIs and CDS views
• Integrated through event-based patterns where possible

Tight coupling to SAP's internal implementation (direct table changes, unreleased API calls, core enhancement points) is what breaks during upgrades. Loosely coupled extensions built on stable, released interfaces generally survive release changes.

Why Custom Code Assessment Matters?

Most SAP ECC environments carry more custom code than expected. A typical inventory includes:

Assessment Area	Examples
Reports	Z Reports, Y Reports
Enhancement	User Exits, BAdIs
Interfaces	IDocs, APIs, Middleware Integrations
Forms	Smart Forms, Adobe Forms
Applications	Custom Fiori Apps
Database Objects	Tables, Views, CDS Extensions

A large share of this code is often inactive. It remains in production but is no longer tied to a live business process.

Skipping assessment and migrating everything as-is causes problems:

• Inflated conversion effort
• Larger regression testing scope
• Technical debt carried into the new environment

A structured assessment avoids this by identifying which objects are worth migrating and which are not.

Step 1: Build a Complete Custom Code Inventory

The first step is a full inventory of custom objects. SAP's Custom Code Migration app and the Analyze Custom Code functionality in SAP Readiness Check make this largely tool-driven.

For each object, capture:

• Usage frequency
• Business owner
• Technical complexity
• Dependencies (upstream and downstream)
• Performance footprint
• Simplification-item impact

Without this data, remediation decisions become guesswork.

Step 2: Score Business Value Against Technical Risk

Once the inventory is built, evaluate each object on two dimensions:

• How much business value it still delivers
• How much technical risk it carries going forward

Usage analytics often show that a meaningful percentage of custom objects have not executed in over a year. Objects with no clear owner, no recent execution, and no link to a regulated or differentiating process are strong candidates for retirement.

Step 3: The Five-Way Remediation Model

Every custom object should fall into one of five categories.

1. Retain

Keep objects that:

• Support genuinely differentiating processes
• Already use released APIs
• Carry low upgrade risk

Examples include industry-specific analytics or specialized calculation logic.

2. Retire

Remove:

• Unused reports
• Duplicate functionality
• Redundant enhancements

SAP explicitly recommends eliminating dead code as part of Clean Core adoption. Every retired object is one less thing to test, secure, and carry forward.

3. Replace with Standard Functionality

Many customizations exist only because standard SAP lacked a capability at the time they were built. Recent S/4HANA releases have closed many of those gaps in:

• Finance
• Procurement
• Supply chain
• Embedded analytics
• Workflow

Re-checking old customizations against current standard capability is often the highest-leverage step in the entire program.

4. Refactor with Modern Extensibility

Some objects are still necessary but rely on unsupported enhancement points. These should be rebuilt using:

• The ABAP Cloud development model
• Released APIs
• CDS views instead of direct table access

This trades short-term refactoring effort for long-term upgrade stability.

5. Move to Side-by-Side Extensions on SAP BTP

Some functionality does not belong inside the ERP core at all. Candidates include:

• Customer portals
• Supplier collaboration tools
• AI-driven applications
• Multi-system orchestration

Moving these to SAP BTP lets them scale and release independently of the core upgrade cycle.

Governance Is What Makes It Last

Remediation is not a one-time cleanup project. Without governance, the custom code backlog grows right back after go-live.

Sustainable governance includes:

• Approved extension patterns
• Mandatory API usage standards
• Architecture review boards
• Code review gates for new development

Governance should be treated as a permanent operating control, not a project task that ends at cutover.

The need for strong governance extends beyond SAP environments. Government digital modernization frameworks increasingly emphasize proactive management of technical debt and legacy technology to maintain system agility, security, and long-term sustainability.

For example, the UK Government's Central Digital & Data Office (CDDO) recommends establishing a legacy-proofing plan for digital services to prevent the accumulation of technical debt and reduce future modernization risks. Organizations can explore this guidance here: Prevent Technical Debt and Legacy.

The Final Thoughts

Organizations that reap the greatest benefits from S/4HANA updating adhere to a single guiding principle for the management of all custom objects, such as, keep what is unique to the business, get rid of what is no longer useful, substitute what is achievable in SAP now, improve what is important yet requires updating, and migrate innovative functionalities to SAP BTP.

The outcome is a core closely aligned with the SAP standard, which can be subject to upgrades with little hassle, while at the same time preserving space for necessary customization.

Frequently Asked Questions (FAQs)

Does Clean Core mean we can't customize S/4HANA at all?

No. It means SAP standard stays untouched, and custom needs are met through approved channels like released APIs and CDS views, not direct changes to core objects.

How do we know which custom objects are safe to retire?

Check usage data. Objects with no execution in over a year, no clear owner, and no link to a regulated process are usually safe to retire.

What's the difference between "Retain" and "Refactor"?

Retain is for objects already using released APIs with low upgrade risk. Refactor is for objects still needed but built on unsupported enhancement points, so they get rebuilt for stability.

Why move some functionality to SAP BTP instead of the core?

Things like customer portals or AI apps don't need to sit inside the ERP core. On BTP, they can scale and release on their own schedule.

Is custom code assessment a one-time project?

No. Without ongoing governance, like API standards and code review gates, the custom code backlog tends to build back up after go-live.

How much of our SAP customization is usually unnecessary?

It varies, but assessments often find a large share of custom objects are inactive in production, which is why an assessment before migration matters.