Why Clean Core Projects Fail in Brownfield S/4HANA Transformations

Every few months, an enterprise going through SAP modernisation declares that Clean Core is a myth. It’s just SAP marketing dressed up as architecture, fine for a greenfield demo but useless once you’ve got twenty years of real custom code to wrangle.

We understand that S/4HANA transformations are inherently messy. Every enterprise system carries years of accumulated decisions, shortcuts and technical debt, and some landscapes have been customised so heavily that the original standard processes are barely recognisable.

So when organisations attempt a Clean Core transformation and end up disappointed, it’s tempting to conclude that Clean Core itself is the problem.

But after working on large-scale brownfield transformations, we’ve come to a different conclusion.

Most Clean Core projects don’t fail because Clean Core doesn’t work. They fail because nobody was willing to challenge the legacy landscape.

And a project that fails technically doesn’t stay a technical problem for long. It becomes a budget, agility, and risk problem at the board level, which is exactly why it’s worth getting independent eyes on the architecture while it’s still a design decision rather than a remediation job.

How A Clean Core Project Actually Fails In A Brownfield Transformation

Brownfield transformations are attractive because they appear less disruptive. The promise is simple: keep your processes, keep your customisations, and move to S/4HANA faster.

Unfortunately, that’s also where many projects start drifting away from Clean Core principles.

In a brownfield conversion, fifteen years of Z-code, modifications and old habits all come along for the ride, for the simple reason that lifting them across is quicker than stopping to rethink them.

The pressure to meet deadlines often outweighs the urge to modernise. Business users want familiar processes, project teams want predictable timelines, and system integrators want to reduce delivery risk.

So the easiest path typically wins: to move everything across. Every enhancement, every report, every workaround, every historical business rule. Nobody wants to ask the awkward question, “do we still need this?”

When that conversation never happens, technical debt survives the migration. And the organisation ends up rebuilding the very environment it was trying to escape.

What gets sold as a “Clean Core transformation” turns out to be a plain technical migration of legacy problems into a newer, pricier S/4HANA environment.

And a year on, they discover that upgrades are becoming difficult, testing effort is increasing, and innovation projects are stuck behind custom-code dependencies. The system may be technically running on S/4HANA, but operationally, it’s still behaving like the same polluted ECC landscape. The only thing that really changed is the licence bill.

That’s what failure looks like here: a transformation on paper, a lift-and-shift in practice.

The Importance of Governance in Clean Core Projects

The biggest reason Clean Core initiatives fail has nothing to do with technology. It is governance. Most organisations treat Clean Core as a project activity. In reality, it is an operating model. A project ends; governance continues.

Without governance, every future enhancement becomes a potential threat to the core.

We’ve seen organisations spend millions creating a relatively clean S/4HANA environment, only to start introducing exceptions within weeks of go-live.

Just one enhancement. Just one direct modification. Just one quick workaround. Those decisions collectively rebuild the technical debt that the transformation was supposed to eliminate.

Successful organisations establish clear architectural guardrails before development begins.

They define:

• What is allowed inside the core.
• What must be built as an extension.
• Which APIs are approved.
• Which development patterns are prohibited.
• How architectural decisions are reviewed.

Without those controls, Clean Core eventually becomes a slide deck rather than a reality.

The “we’ve always done it this way” problem

Most S/4HANA programmes set out wanting to cut custom code, push logic back to standard, and use side-by-side extensions where it makes sense. Then the business gets involved. Users want the legacy behaviour replicated to the letter, especially where a report, a bit of compliance logic, or some operational shortcut has been bedded in for years. That’s the exact moment Clean Core starts to bend, and if nobody’s willing to push back, it snaps.

Get past the “we’ve always done it this way” crowd, and you’ve won most of the battle. Don’t, and no amount of clever architecture will save you.

The Mistake of Chasing Perfection

One of the most dangerous mistakes we see is organisations trying to achieve a theoretically perfect Clean Core. This often creates total paralysis where every custom object turns into a debate and every requirement into a battle

That is not how successful transformations work. The goal is not perfection. The goal is progress.

Brownfield is not greenfield, and it shouldn’t pretend to be. What matters is having a roadmap.

For example, not every legacy object needs replacing on day one; some existing developments may temporarily remain dependent on internal APIs or transitional approaches while the organisation plans a future migration path.

That is often a perfectly reasonable business decision.

The danger is letting the temporary quietly become permanent. Treat unsupported approaches as technical debt with an expiry date, not as a long-term strategy.

How to Approach Clean Core Right In Brownfield Transformations

The single biggest misunderstanding is that Clean Core means ripping out all your custom code in its name. It doesn’t, and that myth is exactly what makes people hate it.

SAP worked this out too, which is worth knowing if you still reckon the whole thing is a marketing stunt. In August 2025, they scrapped the old all-or-nothing model, the one that branded every brownfield system “not clean” and flattened everyone’s morale before they’d even started, and brought in the Clean Core Level Concept: four levels, A to D, that let you get clean at your own pace. That shift on its own tells you Clean Core was never meant to be greenfield-only.

Here’s how we grade every object:

• Level A is the gold standard. ABAP Cloud, released APIs only, fully decoupled from SAP internals and upgrade-safe. This is where new builds should aim.
• Level B is clean enough. Classic released APIs, still stable, still safe to sit on.
• Level C is the pragmatic middle: wrapped or internal objects kept under guardrails, where you park something while you wait for a proper released successor.
• Level D is the danger zone. Direct hits on the core, unreleased internals, the stuff that welds your code to SAP’s and turns every upgrade into a fight. This is what you’re getting away from.

For new developments, aim for A. If A isn’t on the table yet, drop to B. Use C only with a plan to climb out of it, and steer clear of D altogether.

For existing developments, it’s a judgement call, and that judgement is where experience earns its keep. Is now the moment to rework the whole flow? If it is, lift it up to A or B properly. If it isn’t, leave it alone, but tag it and set a transition window so it moves up the moment a released API or classic successor lands. SAP is providing changelogs for the B and C levels, which keeps your upgrade testing sane instead of re-testing the world every release.

How Successful Teams Approach Clean Core Differently

After working on multiple Clean Core transformations, we see the same handful of habits on the projects that work.

They run strong cross-functional governance. Technical architects, business process owners, security specialists, integration teams, and data experts all participate in design decisions.

They model end-to-end business processes before building solutions. Many organisations focus on individual transactions rather than understanding the complete process landscape. That approach inevitably creates fragmented solutions.

They treat data as seriously as custom code. They take data as seriously as custom code, since poor data quality can sink a transformation just as fast as poor development.

They treat architecture reviews as risk management, not bureaucracy.

And they lock in their key resources for the long term because one of the most overlooked risks in a big SAP programme is dependency on a handful of individuals. And once the critical architectural knowledge walks out the door, keeping everything consistent gets a great deal harder.

Get a Clean Core Adoption Roadmap for Brownfield Projects

At AvoTechs, we’ve worked through Clean Core in some of the most complex brownfield S/4HANA transformations going, and we’ve also shared our implementation approach at SAP TechEd Berlin 2025.

Our Clean Core Adoption Strategy consulting defines how Clean Core gets implemented and governed across your S/4HANA landscape, both during the programme and in long-term operations. It turns SAP’s Clean Core principles into an executable model: which custom code stays, which gets refactored or re-platformed, and how future development is controlled. You come away with a roadmap that protects upgradeability while letting the business carry on delivering change.

If your brownfield project is starting to feel more like a migration of old problems than a transformation, it’s probably time for an independent review.

Schedule a free 30-minute consultation with our team, and let’s talk about getting your transformation back on track.