SAP clean core levels A–D explained: which custom objects survive the S/4HANA upgrade?

As organizations continue their journey toward SAP S/4HANA, one concept has become increasingly important: SAP Clean Core. Businesses that have spent years building custom developments often worry about what will happen to those custom objects during upgrades. Will they continue working? Will they require remediation? Or will they break entirely?

The Clean Core strategy was introduced by SAP to help customers reduce technical debt, simplify upgrades, and accelerate innovation. Instead of heavily modifying the ERP core, organizations are encouraged to use approved extension methods that remain compatible with future releases. Understanding the different Clean Core levels, A, B, C, and D is essential for evaluating upgrade readiness and determining which custom objects are likely to survive an SAP S/4HANA upgrade.

Understanding the SAP Clean Core Strategy

The primary goal of the Clean Core approach is to keep the standard SAP system as untouched as possible. Historically, many SAP landscapes accumulated thousands of custom programs, enhancements, modifications, and Z-objects. While these customizations solved business requirements, they often created challenges during upgrades, requiring extensive testing and remediation.

SAP's Clean Core framework categorizes custom developments according to their level of compliance with SAP-recommended extensibility practices. The closer an organization stays to SAP standard functionality, the easier upgrades become. A cleaner core also allows businesses to adopt innovations, security updates, and new features much faster than heavily customized environments.

What Are Clean Core Levels A–D?

SAP classifies customizations into four broad levels that indicate how upgrade-friendly they are.

Level A – SAP Standard

Level A represents the ideal Clean Core state. At this level, organizations rely entirely on standard SAP functionality without introducing custom code or modifications. Since no custom objects interact directly with the ERP core, upgrades are typically straightforward and involve minimal risk.

Custom objects in Level A environments naturally survive upgrades because they do not exist within the ERP core. Organizations operating at this level benefit from lower maintenance costs, reduced testing effort, and quicker adoption of new SAP innovations.

Level B – Key User Extensibility

Level B includes customizations created through SAP-approved key user extensibility tools. Examples include custom fields, custom business logic, forms, reports, and workflow extensions developed using in-app extensibility features.

These extensions are designed specifically to remain compatible with future SAP releases. Because SAP manages the underlying framework, most Level B objects survive upgrades with little or no modification. This level is considered highly compliant with Clean Core principles and is recommended for many business-specific requirements.

Level C – Developer Extensibility

Level C consists of extensions built using released APIs, extension points, business events, and side-by-side development techniques. Developers create custom functionality while respecting SAP's published extensibility model.

These objects generally survive upgrades well because they depend on stable, released interfaces rather than internal SAP code. While testing is still necessary after upgrades, the risk of disruption is significantly lower compared to traditional modifications. Many organizations use SAP Business Technology Platform (BTP) to implement Level C extensions, keeping custom logic outside the ERP core while maintaining integration with SAP processes.

Level D – Classic Modifications

Level D represents the highest-risk category. It includes direct modifications to SAP standard objects, unreleased APIs, implicit enhancements, custom code embedded in the ERP core, and other traditional customization approaches.

These custom objects are the least likely to survive upgrades without intervention. Whenever SAP updates standard code, modifications may be overwritten, become incompatible, or require extensive retrofit activities. Organizations with a large number of Level D developments often face longer upgrade projects, increased testing efforts, and higher maintenance costs.

How Clean Core Levels Affect S/4HANA Upgrades

Upgrade success depends heavily on where custom developments fall within the Clean Core framework. The more compliant a customization is with SAP's extensibility model, the greater its chances of surviving future releases.

Level A and B environments typically experience the smoothest upgrade cycles because they rely on SAP-supported mechanisms. Level C objects also perform well, provided they use released APIs and documented extension points. Level D customizations, however, often become the primary source of upgrade delays, project overruns, and technical remediation efforts.

Organizations planning S/4HANA transformations frequently perform custom code assessments to identify which objects belong to each level. This assessment helps prioritize modernization efforts and reduce upgrade risk over time.

Which Custom Objects Survive an S/4HANA Upgrade?

The survivability of custom objects depends on how they interact with the SAP core.

Objects Most Likely to Survive

• Standard SAP configurations
• Custom fields created through key user extensibility
• In-app business logic extensions
• SAP-released APIs
• Business events and extension points
• Side-by-side applications on SAP BTP
• CDS views built using supported frameworks

These objects are designed around SAP-supported extensibility mechanisms and typically require minimal remediation during upgrades.

Objects That May Require Validation

• Custom reports using released interfaces
• Integration scenarios using approved APIs
• Advanced developer extensions
• Custom workflows connected to standard processes

These developments generally survive upgrades but should undergo functional and regression testing after each release.

Objects Most at Risk

• Modified SAP standard programs
• Direct database table updates
• Unreleased API dependencies
• Implicit enhancements
• Core code modifications
• Legacy custom developments with tight coupling to SAP internals

Such objects frequently require redevelopment, adaptation, or replacement during major upgrades.

Comparison of Clean Core Levels A–D

This comparison clearly shows why SAP encourages organizations to move custom developments toward Levels A, B, and C whenever possible.

Best Practices for Maintaining a Clean Core

Organizations aiming for long-term S/4HANA success should establish governance processes that prevent unnecessary modifications. New business requirements should first be evaluated against standard SAP capabilities before custom development is considered.

Using SAP BTP for side-by-side extensions is one of the most effective strategies for maintaining a Clean Core. By moving custom applications outside the ERP core, businesses can innovate rapidly without jeopardizing upgrade stability. Developers should also prioritize released APIs, business events, and SAP-supported extension frameworks whenever customization is necessary.

Regular custom code assessments, architecture reviews, and extensibility governance policies help ensure that environments remain aligned with Clean Core principles.

Benefits of Moving Toward Level A and B

Organizations that reduce dependence on Level D customizations gain several advantages. Upgrade projects become faster, testing efforts decrease, and technical debt is minimized. IT teams spend less time fixing compatibility issues and more time delivering business value.

A cleaner core also improves security, system performance, and operational agility. Businesses can adopt new SAP innovations sooner because fewer custom developments need remediation during each release cycle. This enables organizations to remain competitive while maintaining a stable ERP landscape.

Common Mistakes Organizations Make

One common mistake is assuming that every business requirement needs custom development. Many modern SAP capabilities already provide flexible configuration and extensibility options. Another frequent issue is relying on unreleased APIs or direct modifications because they appear faster in the short term.

Organizations also struggle when governance controls are weak. Without clear development standards, custom code can quickly accumulate, increasing future upgrade complexity. Successful Clean Core programs require collaboration between business stakeholders, architects, developers, and governance teams.

Future of Clean Core in SAP S/4HANA

Clean Core is becoming a foundational principle across SAP's cloud-first strategy. As SAP continues investing in cloud ERP, released APIs, event-driven architectures, and SAP BTP services will play an even greater role in customization strategies.

Organizations that embrace Clean Core today position themselves for smoother future upgrades, easier innovation adoption, and lower total cost of ownership. Rather than treating upgrades as disruptive projects, businesses can transform them into routine maintenance activities supported by modern extensibility practices.

Conclusion

SAP Clean Core Levels A–D provide a practical framework for evaluating upgrade readiness and customization risk within SAP S/4HANA environments. Level A and B developments offer the highest upgrade compatibility, while Level C extensions remain relatively safe when built using SAP-approved interfaces. Level D customizations, including direct modifications and unreleased dependencies, present the greatest risk during upgrades.

For organizations pursuing long-term ERP sustainability, the objective should be clear: minimize core modifications, maximize use of approved extensibility options, and gradually move custom developments toward cleaner, upgrade-friendly models. By doing so, businesses can reduce technical debt, simplify future upgrades, and unlock the full value of SAP S/4HANA innovation.