“Clean core” is useful when it guides investment and engineering decisions. It is unhelpful when it becomes a blanket instruction to remove customisation without understanding why it exists, what business capability depends on it, or where the replacement logic will live.
An organisation does not have one clean-core decision. It has a portfolio of custom code, configurations, interfaces, reports, forms, data movements and extensions. Each item carries business value, technical cost and change risk. The task is to classify that portfolio and choose a responsible treatment.
Define the outcome of clean core
The goal is not an aesthetically pure system. The goal is to preserve the ability to adopt vendor change, patch safely, understand dependencies and deliver distinctive business capability at a sustainable cost. That means reducing avoidable modification while improving the governance of what remains outside the core.
Agree the outcomes that matter: upgrade effort, regression burden, incident risk, delivery speed, support skill scarcity, platform cost or control. These measures help resolve trade-offs when a technically elegant option is commercially or operationally weak.
Build an evidence-based extension inventory
Start by combining technical discovery with business context. Usage statistics alone are insufficient: a low-volume transaction may support a critical annual process. Business interviews alone are also insufficient: teams may not see hidden dependencies or duplicated logic. Bring code, interface, job, role and process evidence together.
For each item, record owner, purpose, users, frequency, criticality, data touched, integration dependencies, failure impact, test coverage, support effort and fit with current standard capability. Unknown ownership is itself a risk signal.
Use a small set of treatment patterns
A practical portfolio normally uses several treatments. Retire items with no continuing value. Revert to standard where the business can adopt an acceptable supported process. Reconfigure where standard capability exists but was not used well. Rebuild distinctive logic as a governed side-by-side extension. Retain a core exception only where the evidence justifies it.
The treatment should include timing. An item may be retained through an S/4HANA transition and removed after process redesign. Another may need early remediation because it blocks upgrade testing. Clean core becomes executable when treatment, sequence and ownership are visible.
Retire: no defensible business use remains.
Standardise: supported capability meets the need with acceptable change.
Reconfigure: preserve the outcome using maintainable configuration.
Extend: place distinctive logic behind governed APIs, events or platform services.
Retain by exception: document the reason, owner, tests and review date.
Keep side-by-side extensions clean too
Moving code to SAP BTP or another cloud platform does not automatically improve architecture. Unowned services, duplicated data, point-to-point interfaces and uncontrolled consumption can create a second legacy estate. Extensions need product ownership, lifecycle management, observability, security and cost controls.
Use published interfaces where possible, isolate domain logic, minimise replicated data and define what happens when the core changes. Capture architectural decisions so teams understand why an extension exists and what condition would cause it to be retired or redesigned.
Treat integration as part of the portfolio
Interfaces are often the longest-lived custom assets. Catalogue batch files, middleware mappings, APIs, events and manual reconciliations alongside code. Assess semantic coupling: an interface may use a supported endpoint but still depend on internal status logic or fragile sequencing.
A clean integration posture uses stable contracts, clear ownership, idempotent processing, error visibility and controlled versioning. It also avoids copying more data than the consuming workflow requires.
Create governance that helps delivery teams decide
Teams need a fast decision path, not a committee that meets after the sprint. Publish design principles, approved patterns, evidence requirements and decision rights. Provide architecture support early and record exceptions with owners and expiry or review dates.
Track the portfolio over time: custom-code retirement, standard adoption, extension health, interface risk, regression effort and platform consumption. This turns clean core from a migration slogan into an ongoing management capability.
A useful first move
Select a bounded business domain and create the inventory, treatment model and decision process there. Use the findings to estimate remediation value and expose policy gaps before scaling across the estate. The output should be a prioritised backlog with owners and architectural choices—not a percentage score without context.
Review the backlog as business requirements and supported platform capabilities change. Keep the reason, owner and review date for each retained exception.