The Clean Core Paradox: How to customize SAP S/4HANA without breaking it

SAP S/4HANA is the future, and for most CIOs the pressure is on. Mainstream maintenance for SAP Business Suite systems winds down in 2027, with only limited and increasingly costly options beyond that, making inaction less of a strategy and more postponement with rising risk.

But how do you even begin a SAP S/4HANA migration when you know you are about to let go of years of ABAP customizations, Z‑code, and embedded workflows that keep day-to-day operations running?

SAP is explicit about this. Much of that custom logic cannot move across unchanged. It must be identified, adapted, or removed entirely, leaving CIOs exposed to a parallel challenge alongside the migration itself.

Critical business logic that once lived safely inside the core must be rebuilt elsewhere and rebuilt fast enough to avoid disrupting operations. But where does this logic go, and how do you reintroduce it without recreating the very technical debt S/4HANA is designed to eliminate?

The clean core strategy: Why SAP prioritizes scalability and long-term agility

Large enterprise ERP systems tend to accumulate complexity in ways that eventually work against the organization. Over years of customization, business logic becomes deeply embedded in the core through custom code, enhancements, and tightly coupled integrations, making systems harder to upgrade, slower to scale across regions, and more expensive to maintain.

The clean core approach is SAP’s response to this pattern. By keeping the ERP core standard and upgrade stable, organizations gain the ability to adopt new SAP releases more predictably, roll out changes consistently across global operations, and prevent technical debt from compounding over time.

SAP has two extensibility models for this purpose. In‑app extensions that live inside S/4HANA but are not modifying the standard core (best for lightweight changes that stay close to standard processes like BAdIs, Fiori app extensions, or ABAP RAP), and side‑by‑side extensions that live outside S/4HANA, typically on SAP BTP. These are separate applications, workflows, and integrations that communicate with S/4HANA through APIs and events (best for complex business applications, AI/ML services and integrations, multi-system data orchestration, customer portals and mobile apps).

According to SAP, innovation does not disappear in this model. It simply moves to places where it can evolve without putting the stability of the core at risk. But how true is that in practice?

SAP extensibility vs. Low code: Choosing the right execution model for business-critical applications

SAP’s direction on extensibility is architecturally sound. By introducing clear extension models SAP enables organizations to keep the S/4HANA core stable while still allowing innovation around it. From a scalability, upgradeability, and long-term agility perspective, this approach makes sense.

However, clearly defining where custom logic should live does not always translate into the speed, sustainability, and predictability required to deliver business‑critical capabilities.

Why business-critical extensions increase technical debt in legacy SAP environments

Even when built side by side, native SAP extensions typically rely on traditional development approaches using ABAP, UI5, or CAP. These remain high-code efforts with longer design, build, and test cycles than business timelines allow, that over time can:

• slow down delivery
• make costs harder to predict
• increase dependency on scarce specialist skills
• add governance and coordination overhead
• shift CIO focus from innovation to capacity management and long-term maintenance risk

How low code helps CIOs reduce technical debt and regain speed, predictability, and control

Low code platforms such as Mendix are designed to operate fully side‑by‑side with SAP S/4HANA, integrating through standard APIs and events while keeping the digital core clean. Instead of treating clean‑core extensibility as a purely technical exercise, low code helps CIOs:

1. Restore critical business logic faster 

Visual development models, reusable components, and rapid iteration cycles allow teams to rebuild workflows much faster than traditional high‑code approaches. This helps organizations reintroduce essential business functionality without delaying operations during or after S/4HANA migration.

2. Reduce dependency on scarce SAP skills 

Low code changes how delivery teams are structured. Rather than relying exclusively on scarce ABAP, UI5, or CAP expertise, CIOs can form cross‑functional teams that combine business knowledge with IT governance. This expands delivery capacity and reduces risk tied to specialized staffing constraints.

3. Enable modular, reusable extensions 

Low code applications are built as composable components that can be reused across processes and business units. This reduces the proliferation of one‑off extensions and supports scalable growth as new requirements emerge, without recreating technical debt outside the core.

4. Simplify upgrades through clear separation 

By operating independently of the S/4HANA lifecycle and integrating through released interfaces, low code extensions simplify upgrades and regression testing. At the same time, CIOs retain control by defining clear standards for how extensions are built, owned, and maintained.

In this operating model, SAP Business Technology Platform remains the secure and scalable foundation, while low code becomes the execution layer that turns clean ore from a theoretical principle into a practical and repeatable capability. By modularizing business logic outside the S/4HANA core, low code platforms can help CIOs actively manage and prevent technical debt instead of continuously accumulating it through tightly coupled customizations.

CLEVR’s Role: From clean core approach to working architecture

Understanding the clean core principle is one thing. Turning it into something that actually works across systems teams and business units is another.

With more than 30 years of experience delivering enterprise‑grade low‑code solutions using Mendix, CLEVR has helped multiple organizations translate clean‑core principles into working, business‑critical applications.

Instead of treating extensions as individual solutions built in isolation, at CLEVR we help define how extensions should be designed, connected to SAP, governed, and maintained over time.

This includes:

• defining clear architectural patterns aligned with SAP’s clean‑core principles
• advising on integration strategies using standard APIs and events
• establishing ownership and governance models across IT and business teams
• setting development standards that balance speed with control
• designing lifecycle processes so extensions remain manageable, upgrade‑safe, and predictable as they grow in scope and importance

Clean core is only valuable if you can execute it safely

A clean core is not a theoretical goal. For CIOs, it is a promise that business‑critical systems will remain stable, upgradeable, and secure while the organization continues to operate and evolve. But that promise only holds if the logic that keeps the business running can be rebuilt and extended with confidence.

 This is where experience matters. Building side‑by‑side applications for SAP landscapes requires more than tooling. It requires architectural judgment, governance discipline, and a delivery model that works under real business pressure. And with decades of experience delivering enterprise‑grade, business‑critical applications, CLEVR can deliver exactly that.

If you are planning or already navigating an S/4HANA migration and want to extend SAP safely without risking core business operations, our team is ready to help.

Contact CLEVR for a consultation to discuss how to build secure, business‑critical extensions that keep your core clean while your organization continues to move forward with confidence.

‍