Clean Core is not a project that finishes — it is a standard you hold. SAP’s extensibility model offers three graded tiers, and the discipline is simply always using the least invasive one that does the job. VISCAP’s role is to establish that standard and then keep you inside it — assessment, remediation, extension architecture and the release governance that stops the debt rebuilding.
Eight capability areas, stated before any tool name. Each one is something an IT organisation can point at after the work is done — not a policy document, a licence or a maturity score.
6 tiers · 54 capabilities · 12 named products — ordered least invasive first
SAP S/4HANA in-app extensibilityKey-user tools
The first tier to try. Nothing leaves the sanctioned extension points, so the result survives every upgrade untouched.
ABAP CloudSAP S/4HANA developer extensibility
Where key-user tooling runs out. The same language as before, a much narrower contract.
SAP BTP ABAP environmentSAP Build CodeSAP Business Application StudioSAP Cloud Application Programming Model
The tier for anything substantial — logic outside the core entirely, on its own release cycle.
SAP Build AppsSAP Build Process AutomationSAP Build Work Zone
The governance matters more than the tooling — ungoverned low-code rebuilds the same debt in a new place.
SAP Integration SuiteAPI ManagementSAP Event Mesh
A clean core with point-to-point integrations reaching into its tables is not a clean core.
SAP custom code analysisTransport and lifecycle management
Usage analysis routinely shows a large share of custom objects have not executed in years — retiring those is the cheapest clean core work available.
Clean Core fails as an edict and succeeds as an operating discipline. VISCAP works the whole arc — from the custom-object inventory nobody has run in years through to the release governance that keeps the debt from rebuilding; this is where each stage belongs and what we own inside it.
Clean Core touches almost every part of an SAP estate — the code, the interfaces, the release calendar and the way people are allowed to build. These eight VISCAP service lines cover the work around it.
All VISCAP servicesRun the clean core assessment, review customization and technical debt, and set the extensibility and upgrade-readiness direction.
Hold the clean core standard inside new implementations and rollouts, where fit-to-standard decisions are still cheap to make.
Custom-code inventory, usage analysis, retirement, remediation and the rebuild of surviving logic as side-by-side extensions.
Define clean core integration principles, rationalize interfaces, and move point-to-point connections onto governed APIs and events.
Move custom reporting off modified core objects onto released views and a governed analytics layer.
Operate the extension inventory, transport and lifecycle controls, and the guardrails that keep new build inside the standard.
Release-impact assessment, deprecated-functionality tracking, regression scope and the upgrade backlog, release after release.
Enable key users and developers on the extensibility tiers, so the right tier gets chosen without an architect in every conversation.
Usage-based analysis across a chemicals group’s ECC estate showed most custom code had not executed in three years. Retiring it first took a year off the conversion.
Clean Core is the principle that the SAP digital core stays close to standard, with anything custom built through sanctioned extension points rather than by modifying the core itself. The practical payoff is that upgrades become routine, because SAP can change the core without breaking logic that was never supposed to depend on its internals.
No — it means customization in the right place. Every business has processes that genuinely differentiate it, and those still get built. The discipline is about where: through key-user tooling, through ABAP Cloud against released objects, or side by side on SAP BTP, rather than by modifying standard code.
Three, ordered from least to most invasive. In-app extensibility lets key users adapt the standard from inside the application. Developer extensibility uses ABAP Cloud against released objects. Side-by-side extensibility puts the logic on SAP BTP entirely outside the core. Clean Core is largely the habit of stopping at the earliest tier that does the job.
ABAP Cloud is the restricted development model for building inside modern SAP systems. The language is familiar, but the contract is much narrower: development is limited to released APIs and objects, so it cannot reach into internals that SAP is free to change. That restriction is exactly what makes the resulting code upgrade-safe, and it means existing ABAP skills carry across.
A released API or event is one SAP has published as a stable contract and committed to maintaining across releases. Building against released objects rather than reading tables directly is the single most reliable predictor of whether an extension survives an upgrade untouched.
SAP BTP is where side-by-side extensions live. The SAP BTP ABAP environment, SAP Build Code and SAP Build Apps let you build substantial custom applications that read SAP data and process context through governed interfaces, while running on their own lifecycle — so the extension and the core can be released independently of one another.
A core with dozens of point-to-point interfaces reaching into its tables is not clean, whatever the code looks like. Integration Suite moves those onto managed APIs and events with central governance, so the interface layer becomes a published contract rather than an undocumented dependency.
Not entirely, but doing the inventory and retirement work first is almost always cheaper. Usage analysis routinely shows a large share of custom objects have not run in years; carrying those into a conversion means paying to remediate and test code nobody uses. The retirement decision is far easier before the move than after.
We start with a custom development inventory and usage-based analysis — what exists, what actually executes, and what depends on objects SAP has not released. That produces a quantified technical-debt picture, an upgrade-readiness baseline and a gap list, which is what the extensibility strategy and remediation plan are then built from.
Yes, and that is the more common engagement. Plenty of S/4HANA estates have drifted since go-live. The work is the same shape — inventory, remediation, rebuilding surviving logic side by side, rationalizing interfaces, and putting governance around new build so the position holds rather than degrading again.
Speak with VISCAP’s SAP architects about your custom-code position, your upgrade cycle, and how much of the core you are still modifying.