The “Clean Core” Prerequisite: The SAP AI Strategy Everyone Skips

Most SAP AI conversations skip the boring part. Everyone wants to talk about Joule agents and generative UI. Almost nobody wants to talk about the ABAP modifications from 2011 that will quietly break every one of those agents.

Clean core is that boring part. It’s also the reason some enterprises are activating Joule features in weeks while others are stuck in year-long remediation projects.

What clean core actually means

A clean core S/4HANA system is one where the application core hasn’t been directly modified. Custom logic sits in one of two places: in-app extensions built through SAP’s approved extensibility framework, or side-by-side on SAP Business Technology Platform. SAP has formalized this into a maturity model – Levels A through D – that grades every extension on architectural integrity and upgrade safety.

Level A means fully clean-core-compliant. Level D means you’re going to have a bad time at your next upgrade.

This wasn’t always the doctrine. For years, SAP customers built whatever they wanted directly in the core. That worked when you upgraded once every seven years. It doesn’t work when SAP is shipping quarterly business AI releases and expecting your system to absorb them.

Why AI makes this urgent

Joule agents work by traversing SAP’s Knowledge Graph – the semantic backbone that connects purchase orders to contracts to goods receipts to invoices to payments. When you modify a standard table or hardwire logic inside a standard function module, you break relationships the agent depends on.

Concretely: if your finance team modified the invoice document flow ten years ago to add a custom approval step, the Dispute Resolution Agent doesn’t know that step exists. It looks at the standard document flow, sees a status the standard process shouldn’t produce, and either escalates every case as an exception (defeating the ROI) or gets it wrong.

Multiply that across every custom modification in a mid-sized SAP landscape and the calculus is clear. Clean core isn’t a philosophical preference. It’s the condition under which any of this AI works.

The migration decision

If you’re running ECC and looking at the top SAP implementation partners in USA to help with an S/4HANA move, this is the question worth grilling them on: how do they handle custom code remediation? There are essentially three approaches.

The first is lift-and-shift with modifications intact. Fast, cheap, and it recreates every technical debt problem you already had. Six months post-go-live, when SAP ships a Joule agent your team wants to activate, you’ll discover the modifications are blocking it.

The second is greenfield – throw everything out, adopt standard, rebuild custom logic on BTP. Cleanest outcome, longest timeline, biggest change management burden.

The third is what most sensible programs actually do: brownfield migration with a parallel remediation stream. Move to S/4HANA, but classify every custom object against SAP’s Level A–D model. Retire what you don’t need. Rebuild the important stuff as BTP side-by-side apps. Accept in-app extensions where they make sense. The end state is a Level A or B core within 18–24 months of go-live.

What “BTP-first” costs and what it saves

BTP extension development takes longer than dropping a Z-table into the core. That’s the honest tradeoff. What you get back is upgrade independence. SAVIC data referenced in SAP partner briefings suggests enterprises with mature BTP extension practices are spending 30–40% less on annual maintenance and moving through upgrade cycles roughly twice as fast as their modified-core peers.

For any organization evaluating the Top SAP BTP Partners in US, the useful diligence question isn’t “do you have BTP experience?” – everybody says yes. It’s “show me a BTP CAP application you built two years ago that has survived four SAP quarterly releases without code changes.” That answer tells you whether they built to the doctrine or built to the deadline.

Where MSITEK fits

We’ve been running clean-core-first S/4HANA implementations since the doctrine solidified. Our approach is not to preach it – it’s to price it. Every implementation proposal we send breaks out the custom code inventory into remediation buckets, so you know exactly what belongs in-app, what belongs on BTP, and what should be retired. If you’re mid-scoping an S/4HANA program, we’re happy to run that inventory as a fixed-price assessment before you commit to a partner.