SAP Clean Core,
explained without the jargon

The core is the standard SAP software your company runs. It is clean when nobody has altered it — only extended it from the outside.

SAP ships a large, standard business system. Every customer gets the same one. Almost no company can use it entirely as delivered, because every company does something slightly differently — a discount rule, an approval step, a report the auditors want in a particular shape.

For thirty years the obvious answer was to change the system itself. You could open SAP's own programs and edit them, or hook your own code directly into them. It worked, it was fast, and it is the reason a great many SAP systems today contain tens of thousands of pieces of custom code.

The bill arrives at upgrade time. When SAP ships a new version, it replaces its own programs — and every place where somebody edited them has to be found, understood, and reconciled by hand. A system with heavy modifications can turn a routine update into a project lasting months.

"Clean Core" is the discipline of getting the benefit of customisation without paying that bill: leave the standard software untouched, and put your own logic beside it, connected through interfaces SAP has promised to keep stable.

Custom code is the software your company wrote itself inside SAP, usually in a language called ABAP. Most of it exists for good reasons.

ABAP is SAP's own programming language. Programs written in it live inside the SAP system rather than on a separate server, which historically made them fast, convenient, and dangerously easy to entangle with SAP's own code.

Custom objects are conventionally named with a leading Z or Y — so a report called ZFI_INVOICE_CHECK is yours, and one called RFBILA00 is SAP's. That naming convention is the single most useful thing to know when you first look at an SAP system.

It is worth being fair to the people who wrote all this. Custom code is usually not carelessness; it is the accumulated record of decisions the business needed and the standard did not offer at the time. The problem is not that it exists. The problem is where it sits and what it touches.

ABAP

Advanced Business Application Programming — SAP's programming language, running inside the SAP system itself.

Z-object / Y-object

A custom object. The leading Z or Y is a naming convention reserved for customers, so SAP's own updates never collide with it.

S/4HANA

SAP's current generation of business software. The move to it is what forces most organisations to confront their custom code.

Three things: upgrades become expensive, cloud migration becomes impossible, and nobody can say which risk is real.

The first is upgrade cost, described above. The second is sharper: SAP's cloud offerings simply do not permit the old techniques. Code that reads a standard table directly, writes files to the application server, or calls an unpublished function will not run there. It is not discouraged — it does not compile.

The third problem is the quiet one. A system with 40,000 custom objects contains some that are business-critical, some that nobody has executed since 2014, and no reliable way to tell them apart without looking. Programmes stall here, not on the technology.

Learn these and most SAP architecture conversations become followable.

Released API

An interface SAP has formally promised to keep stable, with a documented contract and a deprecation process. Building on one is what makes an extension upgrade-safe. Building on anything else is a private arrangement SAP never agreed to.

Extensibility

The supported ways of adding your own behaviour without modifying the standard. SAP distinguishes several, described in Part 3.

In-app extensibility

Your code runs inside the SAP system, but only through released interfaces. Close to the data, tightly governed.

Side-by-side extensibility

Your code runs outside the SAP system, on a separate platform, and talks to SAP over published interfaces. More freedom, more moving parts.

SAP BTP

SAP's cloud platform where side-by-side extensions live, part of the SAP Business AI Platform. Think of it as the sanctioned place to put things that no longer belong inside the ERP.

ABAP Cloud

The restricted ABAP dialect for the cloud era. It permits only released interfaces, which is precisely why code written for it survives upgrades.

RAP

ABAP RESTful Application Programming Model — the modern way to build an application in ABAP Cloud. Used for in-app extensions.

CAP

Cloud Application Programming Model — SAP's framework for building services on SAP BTP, typically in Node.js or Java. Used for side-by-side extensions.

Modification

A change to SAP's own code. The thing Clean Core exists to eliminate. Distinct from an extension, which leaves the standard intact.

Technical debt

The future cost of a decision that was convenient at the time. In this context: every shortcut that has to be unwound before a cloud move.

abapGit

An open-source tool for moving ABAP code in and out of Git. Relevant because it is how generated code gets into a real system for review.

ADT

ABAP Development Tools — the Eclipse-based environment where modern ABAP is actually written and tested.

Software stack, extensions, data, integrations and processes — each can be clean or dirty independently.

It is tempting to treat Clean Core as a code-cleanup exercise, because code is visible and countable. In practice a programme is only as clean as its weakest dimension: pristine extensions built on a tangle of point-to-point integrations still block an upgrade.

Data gravity and transactional coupling pull in-app; independent lifecycle and non-SAP concerns push side-by-side.

The choice is not a matter of taste, and it is not "cloud is modern so everything goes to SAP BTP". It follows from what the object does.

Logic that reads and writes SAP business data in the same transaction — a validation on a sales order, a derivation during posting — belongs in-app, as RAP. Moving it outside means network round trips inside a transaction boundary, which is both slow and fragile.

Logic that serves a different audience, changes on a different schedule, or needs libraries the ABAP stack does not have — a partner portal, a machine-learning scoring service, a mobile back end — belongs side-by-side, as CAP on SAP BTP.

Between those poles sits a large grey zone, and this is where honest architecture happens. The tie-breaker worth applying: if the extension must be deployed in lockstep with the ERP to remain correct, it is in-app. If it can be released on its own cadence, it is side-by-side.

Some techniques have no cloud equivalent at all. Recognising them early saves the most time.

A handful of patterns are not merely discouraged in the cloud — they have no replacement, and code relying on them needs a rethink rather than a translation.

Every custom object lands in one of four grades, and the grade tells you what to do with it.

The grades describe what an object depends on, not how well it is written. A beautifully engineered report that writes directly to a standard table is still grade D, because the dependency is what breaks in the cloud — not the code quality.

This matters for estimating. Grades A and B need review; grade C needs an interface; grade D needs a decision about whether the object should exist at all. Treating them as one bucket is how modernisation budgets go wrong.

Before remediation comes measurement. Without numbers per object, a Clean Core programme has no way to show progress or defend a decision.

The extensibility dimension is the one you can actually measure, which is why it is the sensible place to start. The useful figures are not "how many objects do we have" but questions with consequences: how many are grade D, how many objects are touched by the next upgrade, how many were executed at all in the last year.

That last one deserves emphasis. A meaningful share of any large custom-code estate is dead — written for a process that no longer exists, kept because deleting felt riskier than ignoring. Usage data turns that from a suspicion into a number, and retiring an object is always cheaper than modernising it.

Once the figures exist per object, progress becomes reportable: grade D count going down over quarters is a sentence a steering committee can act on, in a way that "the team is working on Clean Core" is not.