Clean Core SAP: How Clean Core Assessment, Maturity Level, Modifications, Z-Code, and Integrations Are Evaluated

Clean Core SAP is more than a technical architecture principle; it is the foundation for keeping SAP systems upgradeable, innovation-ready, and manageable over the long term. In this article, you will learn how companies can assess their Clean Core maturity level, what risks arise from modifications, Z-code, and organically grown integrations, and why a structured Clean Core Assessment is crucial before any S/4HANA transformation.

---

Table of Contents

---

What does Clean Core SAP mean?

Clean Core SAP describes an architecture and operating strategy in which the SAP standard core remains as unchanged as possible. Adaptations, extensions, and integrations should not be deeply embedded in the core system, but implemented via approved extension points, stable APIs, clean data models, and decoupled architectures.

The goal is not to prevent every form of customization. Rather, it is about implementing individual requirements where they create genuine business value – without unnecessarily blocking future releases, upgrades, or innovations.

A clean SAP core is therefore the prerequisite for:

• stable release and upgrade capability
• faster innovation cycles
• better maintainability
• clearer governance
• greater flexibility for S/4HANA, RISE with SAP, SAP BTP, and cloud ERP scenarios

SAP describes Clean Core as an approach designed to keep business-critical systems flexible, cost-efficient, and ready for innovation. To do this, SAP considers five central dimensions: processes, extensions, data, integrations, and operations.

This refers to business processes that stay close to the standard, cleanly implemented extensions, consistent data models, stable interfaces, and controlled operating structures. This makes it clear: Clean Core is not purely a development topic. Instead, the approach affects the entire SAP landscape.

Many SAP landscapes have grown over years or decades. They contain customer-specific tables, user exits, BAdIs, modifications to SAP objects, reports, workarounds, direct database access, and interfaces whose business purpose is no longer clearly documented today.

This is exactly where a Clean Core Assessment comes in.

Why a Clean Core Assessment is necessary

A Clean Core Assessment is a structured inventory of the current SAP core. It does not simply answer the question of whether a system is “clean” or “unclean.”

What matters is a differentiated assessment. A Clean Core Assessment shows

• whether adaptations jeopardize upgradeability,
• how cleanly extensions have been implemented,
• where integrations create technical dependencies,
• which Z-developments are business-critical,
• which legacy burdens cause maintenance effort without real benefit,
• and which topics should be prioritized before an S/4HANA transformation.

This transparency is crucial, especially before an S/4HANA conversion, a brownfield project, a Selective Data Transition, or a move to a cloud ERP model.

After all, anyone who only discovers during the actual transformation project that central processes are deeply embedded in custom code loses time, budget, and freedom of decision.

An early Clean Core Assessment brings these insights forward. It makes visible which technical debts should be cleaned up, modernized, or consciously accepted.

Clean Core maturity level: How clean is your SAP core?

The Clean Core maturity level of an SAP landscape cannot be measured by the number of Z-objects alone.

A company with many well-documented, API-based extensions may be more mature than a company with only a few, but highly critical, modifications to the SAP standard.

What matters is the combination of:

• technical implementation
• business relevance
• documentation
• integration architecture
• governance
• operating model

A practical maturity model can distinguish between four levels:

---

Level 1: Critical

The SAP core is heavily modified and has limited upgradeability.

Typical characteristics:

• many modifications to the SAP standard
• direct table access
• unclear technical dependencies
• limited documentation
• high dependency on individual knowledge
• manual tests without clear coverage

Assessment: High need for action. Risks should be made transparent and prioritized before larger transformation initiatives.

---

Level 2: Controlled

The main risks are known, but have not yet been systematically reduced.

Typical characteristics:

• custom code has been partially analyzed
• critical modifications are known
• initial priorities exist
• governance exists, but is not consistently established
• technical debt is addressed selectively

Assessment: Good starting point, but not yet a sustainable Clean Core state.

---

Level 3: Modernized

Extensions largely follow approved mechanisms.

Typical characteristics:

• use of BAdIs, APIs, RAP, ABAP Cloud, or SAP BTP
• reduced modifications
• documented interfaces
• clear technical guidelines
• defined architecture principles
• clean separation between standard and extension

Assessment: The landscape is significantly more future-proof and better prepared for S/4HANA innovations.

---

Level 4: Continuously clean

Clean Core is firmly embedded in architecture, development, and operations.

Typical characteristics:

• regular architecture reviews
• clear transport and development governance
• documented integration strategy
• test automation
• continuous lifecycle management

Assessment: Clean Core is no longer a project, but part of the operating model.

---

Important: Clean Core is not a one-time target state. An SAP system may be clean today and build up technical debt again in two years if new extensions are implemented without architecture reviews, an API strategy or governance.

That is why a Clean Core Assessment should not only take place before transformation projects, but regularly as part of the SAP roadmap.

Assessing modifications: Where has the SAP standard been changed?

Modifications are particularly critical in the Clean Core context because they intervene directly in the SAP standard.

While customizing and approved extension points are generally intended adaptation mechanisms, modifications change standard objects themselves. This can lead to conflicts during upgrades, support packages, or release changes.

A Clean Core Assessment should therefore identify all modifications and classify them by risk.

This is not just about the technical number of modifications. The business significance is what matters.

A modification in a rarely used report must be assessed differently from a change in a central posting, procurement, or production process.

At least the following questions should be answered for each modification:

• What business purpose is behind the modification?
• Is there now an SAP standard that covers the requirement?
• Can the logic be represented through an approved extension point?
• How often is the affected function used?
• What would be the impact of an error after an upgrade?
• Is the modification documented and testable?
• Who is the business owner of the adaptation?

The key mindset here: modifications are not a technical assignment of blame. Many were created because the SAP standard at the time could not cover certain requirements.

For the future, however, they are a risk that should be consciously assessed and, where useful, reduced.

Clean Core therefore does not mean dismantling at any cost, but risk transparency and conscious architecture decisions.

Analyzing Z-code: What is business-critical, and what is ballast?

In many SAP landscapes, Z-code is the most visible expression of individual requirements.

Customer-specific reports, programs, tables, function modules, classes, transactions, and interface logic have helped tailor processes precisely over the years.

At the same time, Z-code is often the area where technical debt grows particularly strongly.

In the assessment, Z-code should therefore not be assessed as bad across the board. The better question is:

Is this code still necessary, cleanly implemented, and future-proof?

A business-critical Z-report with clear ownership, test cases, and approved interfaces can be more useful than a poorly documented workaround for the standard that no one understands anymore.

A sound Z-code assessment combines technical analysis with business validation.

Technical checks include, among other things:

• usage frequency
• dependencies
• syntax risks
• unreleased objects
• direct table access
• performance risks
• S/4HANA compatibility
• testability
• documentation status

From a business perspective, the following must be clarified:

• Does the original requirement still exist?
• Is the code actively used?
• Is there now an SAP standard for it?
• Would a side-by-side extension via SAP BTP be more suitable?
• Can the logic be modernized or decommissioned?

For companies, this means: Z-code should not simply be migrated just because it exists.

Every object needs a clear decision:

• Keep
• Modernize
• Replace
• Decouple
• Decommission

This is exactly where one of the biggest levers of a Clean Core Assessment emerges.

The new SAP Clean Core level concept: assessing custom extensions from A to D

A central component of a modern Clean Core Assessment is the assessment of customer extensions. SAP increasingly classifies custom extensions not only according to the earlier 3-tier model, but based on four levels: Level A, B, C, and D.

This classification makes visible how upgrade-stable, cloud-ready and architecturally clean an extension is. This creates a clear basis for decision-making: Which extensions can remain, which should be modernized and which pose a risk to Clean Core SAP?

Level A describes the target state. Extensions are fully upgrade-stable, cloud-compatible, and use only approved interfaces. Technologically, implementation takes place either on-stack with ABAP Cloud or side-by-side via the SAP Business Technology Platform, for example with SAP Build or CAP. For new developments, Level A should generally be the first choice.

Level B covers extensions that are compatible but still use classic SAP technologies. These include, for example, approved BAPIs, standard IDocs, classic BAdIs, or RFC function modules. In existing landscapes, such solutions are often still viable. Nevertheless, new requirements should be implemented directly according to Level A wherever possible.

With Level C, there is an increased upgrade risk. These extensions access internal or not officially released SAP objects, such as internal tables, unreleased CDS views, or unreleased function modules. They often work in the current system, but can cause problems during S/4HANA upgrades or release changes.

Level D marks the red zone. Here, extensions directly change the SAP standard, for example through modifications, problematic implicit enhancements, overwrite exits, or direct write access to SAP database tables. Such interventions contradict the Clean Core principle and should be assessed with the highest priority in the assessment.

This makes the level concept a practical steering instrument: Level A is the target vision, Level B is usually acceptable, Level C carries risk and Level D should be actively remediated.

Why the level concept is so important for the Clean Core Assessment

The A-to-D model makes technical risks easier to understand. Business departments, IT leadership, and management receive a shared language.

The model creates clear risk logic:

• Level D marks interventions in the SAP standard that are not recommended.
• On the contrary Level A covers clean and future-proof extensions.
• Level B includes acceptable classic extensions.
• With Level C, there is a clear upgrade risk.

This makes the Clean Core Assessment more action-oriented. Companies can cluster their extensions, prioritize them, and derive concrete measures. The key question is therefore no longer just: “How much Z-code do we have?” Much more important is: “At which Clean Core level are our extensions?”

Checking integrations: API-first instead of point-to-point dependency

Integrations are often the underestimated dimension of SAP Clean Core.

An SAP system may have a comparatively clean core and still remain difficult to modernize because of rigid point-to-point interfaces, direct database access, or historically grown middleware logic.

Especially in S/4HANA transformations, integrations quickly become the critical path because they connect processes across system boundaries.

A Clean Core-compliant integration architecture follows the API-first principle.

This means:

• systems are connected via stable and documented interfaces
• data flows are traceable
• technical dependencies are reduced
• direct access to internal table structures is avoided
• interfaces have clear business and technical owners
• integrations are suitable for S/4HANA, SAP BTP, and cloud scenarios

In the assessment, integrations should be evaluated according to the following criteria:

Criterion	Guiding question
Degree of coupling	How strongly does the interface depend on internal SAP structures?
Technology	Is an approved API, an event, IDoc, OData service, or proprietary logic used?
Stability	How error-prone is the integration in operation?
Documentation	Are data flows, responsibilities, and error scenarios documented?
Business criticality	Which processes come to a standstill if the integration fails?
Future readiness	Is the interface suitable for S/4HANA, Cloud ERP, or SAP BTP?

Integrations that access internal table structures or use implicit knowledge about old data models are particularly critical.

What worked for years in ECC can become a risk in S/4HANA due to changed data models, new APIs, or different operating models.

That is why integrations should not only be examined during technical migration testing, but early on in the Clean Core Assessment.

Assessment matrix for a Clean Core Assessment

A good Clean Core Assessment brings together technical facts and business priorities.

The following matrix is suitable as a pragmatic starting point:

Assessment area	Guiding question	Typical measures
Modifications	Has the SAP standard been changed?	Dismantling, replacement with BAdI/API, review of standard process
Z-code	Is customer-specific code still used, documented, and upgradeable?	Usage analysis, refactoring, decommissioning, modernization with ABAP Cloud/RAP
Integrations	Are interfaces stable, documented, and decoupled?	API-first strategy, middleware cleanup, review of event-based integration
Data	Can master data, transaction data, and historical data be transformed?	Data cleansing, archiving, governance model, data quality rules
Processes	How close are processes to the SAP standard?	Fit-to-standard workshops, process harmonization, reduction of variants
Operations	Are governance, tests, and automated controls in place?	ATC checks, architecture boards, transport governance, test automation

Important: The assessment should not only create a traffic-light logic.

Red does not automatically mean “delete immediately.”
Red means: high risk, high attention, clear decision required.

Green does not mean “never check again.”
Green means: currently clean, but still keep under governance.

The value comes from a prioritized basis for decision-making.

From analysis to a Clean Core roadmap

The biggest mistake after a Clean Core Assessment would be to file the results away as mere documentation.

The real value only emerges through a concrete Clean Core roadmap.

This roadmap should prioritize measures according to the following criteria:

• technical risk
• business impact
• transformation relevance
• effort
• dependencies
• quick-win potential
• effects on S/4HANA, RISE, SAP BTP, or Cloud ERP

In practice, a three-part structure is useful:

---

1. Quick Wins

These include topics that can be cleaned up with manageable effort:

• unused Z-code
• obsolete interfaces
• duplicate reports
• outdated custom developments without usage
• legacy objects with little documentation and no business relevance

These measures quickly create transparency and reduce unnecessary complexity.

---

2. Transformation-critical topics

This is where the greatest risks for S/4HANA programs lie.

Typical examples:

• modifications in core processes
• developments that are not S/4HANA-compatible
• direct table access
• integrations with a high degree of coupling
• custom developments without test coverage
• central processes with high custom-code dependency

These topics should be prioritized early because they can influence project duration, budget, and migration strategy.

---

3. Strategic modernization

This is about the long-term target state.

Typical measures:

• development of an SAP BTP extension strategy
• use of ABAP Cloud and RAP
• transition to approved APIs
• introduction of architecture governance
• setup of automated checks
• clear rules for new extensions
• integration of Clean Core into the operating model

Companies should not try to clean up the entire SAP core all at once.

A focused approach is more successful:

1. Create transparency
2. Prioritize risks
3. Make decisions
4. Implement measures in waves
5. Establish governance permanently

Clean Core is not a cosmetic IT project. It is a strategic architecture program.

It determines how quickly a company will be able to adopt innovations from SAP S/4HANA, SAP BTP, automation, and AI in the future.

Conclusion: Clean Core SAP creates decision-making capability

Clean Core SAP is not a dogma and does not mean giving up individuality.

On the contrary: a clean SAP core creates the prerequisite for companies to remain individual where it is truly relevant to their competitiveness.

The difference lies in the way it is implemented.

Instead of modifications, uncontrolled Z-code, and rigid integrations, what is needed is:

• approved extension points
• stable APIs
• decoupled architectures
• clean data models
• clear governance
• automated checks
• regular architecture decisions

A Clean Core Assessment makes visible where an SAP system stands today. It assesses maturity level, modifications, Z-code, integrations, data, processes, and operations not in isolation, but in context.

This results in a robust roadmap for S/4HANA, RISE with SAP, SAP BTP, Cloud ERP, and future innovation cycles.

The most important insight is:

Clean Core does not begin in the migration project. Clean Core begins with the decision to make technical debt transparent and to actively steer architecture again.

Those who do this work early reduce risks, lower complexity in the long term, and gain room for innovation.

Start a Clean Core Assessment with Fink IT-Solutions

Would you like to know how clean your SAP core really is?

Fink IT-Solutions supports you in structurally analyzing modifications, Z-code, integrations, and technical debt – with a clear view of your specific system landscape, your transformation goals, and your SAP roadmap.

Our Clean Core Assessment helps you to:

• make risks visible early before an S/4HANA transformation
• assess custom code and modifications from both a business and technical perspective
• check integrations for future readiness
• prioritize quick wins and critical measures
• build a robust Clean Core roadmap
• establish governance for future extensions

Talk to the SAP experts at Fink IT-Solutions and create the foundation for an upgradeable, innovation-ready, and manageable SAP landscape.

Please feel free to use our contact form to get in touch with Fink IT-Solutions:
Contact form | Fink IT-Solutions – IT consulting & solutions in Würzburg – Fink IT-Solutions

FAQs about Clean Core SAP