Why Joule Needs a Clean Core First: The 2027 Sequencing Problem

In brief: Most enterprises are running their S/4HANA migration and their SAP AI strategy as two programmes with two budgets and two steering committees. They are one programme. The extensions that break your upgrade are the same extensions that make your business logic invisible to Joule. Sequence clean core first and AI enablement becomes a configuration exercise. Sequence it second and you will pay for the same remediation twice.

Two clocks are running in every SAP estate right now, and most boards are treating them as unrelated.

The first is well understood. Mainstream maintenance for SAP ERP 6.0 enhancement packages 6, 7 and 8 ends on 31 December 2027. Extended maintenance is available at additional cost through 31 December 2030, and SAP has committed to supporting at least one S/4HANA release until 2040. That is the compliance clock, and it has been on the risk register for years.

Two footnotes on that date, because both change who is actually affected. Older enhancement packages — EhP 0 through 5 — left mainstream maintenance on 31 December 2025. If you are on one of those, you are already outside mainstream support today. And beyond 2030 there is an SAP ERP private edition transition option, purchasable from 2028 and running 2031–2033. It is a continuity mechanism, not a strategy: scope is restricted, with no new legal changes, restricted security notes and no technology-update guarantee.

The second clock is newer and less visible. Across 2026, SAP has been shipping AI capability into the suite at a pace that outstrips most customers' ability to consume it. In Q2 2026 alone, SAP recorded twenty-one named capabilities reaching general availability, spanning finance, spend, CX and supply chain. The 2027 roadmap adds Joule Assistants across essentially every line of business.

Here is the part that changes the budget conversation: these are not two programmes competing for the same money. They are one programme, and the order you run it in determines what you get.

Clean core has always been justified on upgrade economics. Keep custom code off SAP internals, and upgrades get cheaper and less risky. That argument is true, and for a decade it was also easy to defer — you could always absorb one more expensive upgrade.

AI removes the option to defer, for a reason that has nothing to do with upgrades.

An AI agent acting inside your ERP has to do two things: read the state of the business accurately, and act on it safely. Both depend on going through released interfaces and the standard data model. SAP's own tooling makes this dependency explicit. SAP Domain Models — the specialised models running underneath Joule and Joule Studio — are described by SAP as helping developers "understand and generate clean core-compliant code from natural language," and SAP states these capabilities "will help create clean core extensions while preserving SAP standards and governance."

Read that carefully. SAP's AI development tooling assumes clean core as the target state. It generates clean-core-compliant code. It does not read your Level D modifications and reason about them.

The consequence is uncomfortable but simple. Where your pricing logic lives in an implicit enhancement, where your credit check writes directly to an SAP table, where your order validation sits in a modification — an agent cannot see that logic. It will reason about the standard process, which is not the process your business actually runs. That is not a model quality problem that a better LLM fixes next year. It is an architectural visibility problem.

Clean core stopped being an upgrade conversation. It is now the precondition for every AI capability on SAP's roadmap.

You cannot sequence work you have not measured. In August 2025 SAP evolved its original three-tier extensibility model into a four-level clean core maturity model, announced by SAP's Cloud ERP and BTP product leadership. SAP governs it at code level through the ABAP Test Cockpit. This is now the vocabulary your remediation plan should be written in.

One further caveat: SAP defines this model for S/4HANA Cloud extensibility. Applying it as a classification scheme across an ECC estate before conversion is a sensible adaptation, and it is the one we use — but it is an adaptation, not an SAP instruction.

Two things follow from this table that materially change how a programme is costed.

First, Level C and D are where your AI value is trapped. Not evenly distributed across the estate — concentrated in exactly the high-value, differentiated processes you would most want an agent working on. The reason those processes were customised is that they matter.

Second, the remediation you do for 2027 and the remediation you do for AI are the same remediation. A Level D modification retired for upgrade safety is simultaneously retired for agent visibility. You do this work once, or you do it twice.

The instinctive objection to clean core remediation is scale. A mature ECC estate carries thousands of custom objects and no appetite for a multi-year rewrite.

The data argues otherwise. SAP's own Custom Code Migration Guide for SAP S/4HANA reports that, based on more than fifteen years of SAP statistics, between 30% and 60% of custom code in a productive SAP ERP system is never executed — with a further portion replaceable by standard functionality on conversion.

Treat that range as what it is. It is an estimate across a heterogeneous customer base, not a measurement of your system, and the gap between 30% and 60% is the difference between a modest cleanup and a transformed budget. You will see higher figures quoted around this topic — 60–75% is common in partner material. We are not going to repeat those, because we cannot trace them to a primary source. SAP's published range is defensible; the folklore above it is not.

What the range does establish is that the problem is triage, not rewrite. The first move is not remediation — it is measurement. Collect production usage data, and a large share of the inventory — on SAP's own figures, potentially anywhere from a third to well over half — resolves to "delete," costing nothing but the governance to approve it. The remediation budget then applies to a much smaller set of objects that are both used and non-compliant.

Note the sequencing hazard, and it is a serious one: SAP recommends collecting usage data for at least twelve months before conversion. Seasonal processes — year-end close, annual reporting, statutory runs — execute once a year, and a three-month sample will misclassify every one of them as dead code. Organisations that decide in mid-2027 to start measuring will not have a defensible dataset before the deadline. This is the single most common reason clean core programmes end up over-scoped: the triage evidence was never gathered in time, so everything got treated as in-scope.

One capability worth knowing about now: SAP's S/4HANA custom code migration agent reached general availability in Q2 2026. It runs ABAP Test Cockpit readiness checks across custom code packages, categorises findings, and applies a mix of deterministic quick fixes and AI-based changes with confidence scores — recording all updates in transport requests for traceability. High-confidence fixes apply automatically; lower-confidence proposals become developer comments.

Check the prerequisites before you get attached to it, because they are not trivial: it runs in ABAP Development Tools for Eclipse against an S/4HANA 2021 or later target system, and requires a GitHub Copilot Pro or Amazon Q Developer Pro licence alongside your SAP entitlement. That target-system requirement means it is a tool for the conversion itself and the work after it, not something you point at a bare ECC estate on day one.

There is a detail in SAP's own Q2 2026 release record that deserves more attention in board papers than it currently gets.

Across that release post, the line-of-business AI capabilities that name a deployment target name SAP S/4HANA Cloud Public Edition. Private Edition appears once — for Joule multi-system connectivity, not for any agent capability. RISE and on-premise are not mentioned at all in that document.

Be careful about how much weight this carries. Absence of a statement is not the same as a stated restriction, and SAP publishes deployment entitlements elsewhere. But if your target architecture is Private Edition or on-premise, verify capability-by-capability entitlement with SAP before you build a business case on a specific assistant or agent. Do not assume parity across deployment models because a Sapphire keynote implied it.

This matters for sequencing too. Deployment model is decided during migration planning, not after. Getting it wrong is expensive to reverse.

The failure mode is running Phase 4 in parallel with Phase 1 — piloting Joule against a dirty core, getting poor results, and concluding the technology is not ready. The technology is not the variable being tested in that experiment.

The difference between these is not effort. It is ordering.