Article

Clean core never was an IT decision

The real reason clean core programmes fail
Published

18 June 2026

Every organisation running SAP has an opinion on clean core. However, almost none of them have made it a business priority. This gap is why most clean core programmes quietly fail.


Ask most IT teams what clean core means, and they will usually say: standardise the system, remove modifications, and decouple extensions. They are not wrong, but that is only part of the answer. Clean core should not be seen as a purely technical objective but rather as a response to a much bigger business question:  how do we create an organisation that can adapt faster, scale more easily, and strengthen its competitive edge?


This distinction matters. If clean core is treated only as an IT programme, its impact will be limited to the system itself. The ERP landscape may become cleaner, but the organisation will not necessarily become more agile. And without changes to processes, governance, and decision-making, old patterns will soon reappear – just in newer code.

What is clean core?

Clean core in SAP is an architectural approach focused on keeping the central ERP system (the ‘core’) as close as possible to standard SAP functionality. Rather than changing the core source code to meet specific business requirements, organisations place customisations in cloud-based extensions and side-by-side applications.


In 2027, SAP will end mainstream maintenance for SAP ECC/Business Suite 7 and encourage its customers to move to SAP S/4HANA. In this process, a clean core programme is about making that move easier and keeping the future S/4HANA landscape simpler and easier to maintain and upgrade.

With SAP ECC mainstream support ending in 2027 – and some versions already out of mainstream support – the pressure to act is increasing. But urgency without a clear direction often leads to shortcuts. The organisations that take shortcuts now may find themselves facing the same problems again in just a few years.


What the complexity actually costs


Before talking about solutions, it is worth being honest about the scale of the problem. In a typical legacy SAP landscape:

  • 60–70% of custom code is unused – still carried, tested, and maintained through every upgrade cycle.
  • Years of accumulated modifications – each justified at the time – have made the system too expensive to change.

That first number is the most important. Most of that code was never a source of competitive differentiation. It was built to solve a problem that no longer exists, for a process that has since changed, by a team that long since moved on. It persists because retiring it requires a decision – and decisions require ownership. So, the code is not the real problem. The real problem is the absence of ownership.


Where business decisions become technical debt


Every modification in a legacy SAP system started as a business request. Someone needed something the standard process could not deliver. A decision was made quickly, locally, and without much consideration of what it would cost to maintain. Then another decision was made. And then another. And another.


The code is simply the record of those decisions, which explains why cleaning it up without changing how decisions get made is merely a cosmetic exercise. The system may look different, but the organisation behaves identically.


Complexity is not a technical problem with a technical solution. It is the accumulated residue of decisions made without long-term accountability. This is why the three most common failure modes in clean core programmes have almost nothing to do with technology:

The most common failure modes in clean core programmes:

One exception at a time, complexity rebuilds itself.

What it looks like when it works


The organisations that get clean core right make one decision before anything else: they agree on what actually makes them different. Not in the abstract, but specifically. Which processes create genuine competitive advantage – and which ones simply exist because they were built that way. When that question is answered honestly, the list is almost always shorter than expected. Most of the complexity was never protecting anything valuable. It was just never challenged.


From there, they establish governance that reflects that clarity, with a defined process for evaluating every extension request, real authority to say no, and a standard that applies consistently, not just during the migration but after it too. Because the real measure of a clean core programme is not whether the system is clean at go-live, but whether it is still clean two years later.


The question that determines everything


If your organisation ran the clean core programme again in five years, would it produce a different result? If the answer is uncertain, the programme is treating symptoms. The 2027 SAP deadline is real, and the technical implications matter. But the organisations that will genuinely benefit are the ones that use this moment to change how they make decisions – not just what their system looks like. Done well, clean core is not so much a migration but a commitment to operating differently. That is – and always has been – a business decision.

Related0 4