An SAP S/4HANA clean-core strategy is a governed method for keeping the ERP core as close as practical to supported standards while placing necessary differentiation in upgrade-stable extension patterns. It is not a promise to remove every extension, and it is not achieved by choosing greenfield alone.
Direct answer
A workable clean-core migration has four controls:
- an evidence-based inventory of custom code, modifications, interfaces and extensions;
- a disposition decision for every relevant object;
- approved extension and integration patterns for new requirements; and
- recurring governance that prevents the backlog from returning after go-live.
SAP explains that a system conversion begins close to the existing ERP design and therefore aims to get the core clean, while a new implementation starts clean and must keep the core clean. SAP also states that greenfield, brownfield and selective transition can all be compatible with clean-core objectives. See SAP’s clean-core transition guidance.
Start with usage and business ownership
A code object should not be retained merely because it exists. Collect evidence about execution, users, dependent processes, controls, data touched and operational criticality. Then assign a business and technical owner.
An initial disposition model can use these categories:
| Disposition | When it fits | Required evidence |
|---|---|---|
| Retire | No current business use or duplicate capability | Usage evidence and owner approval |
| Replace with standard | Target standard meets the requirement | Fit-to-standard result and process acceptance |
| Rebuild as an approved extension | Differentiation remains necessary | Architecture decision, API availability and test scope |
| Remediate in core | No viable external pattern and risk is accepted | Documented exception, upgrade impact and accountable owner |
| Defer | Evidence is incomplete | Time-bound investigation and stop condition |
SAP tooling can assist with compatibility analysis. For example, SAP documents how readiness and ABAP Test Cockpit checks can flag objects for review in conversion and upgrade scenarios. See the SAP S/4HANA conversion and upgrade scenario.
Separate extension choices from product slogans
The architecture team should choose among in-app extensibility, released APIs, ABAP Cloud patterns, side-by-side services, events and integration-platform capabilities based on the requirement and target deployment. The decision needs to address:
- transaction consistency and latency;
- data ownership and authorization;
- supported interfaces and lifecycle compatibility;
- error handling, retries and monitoring;
- testing and rollback;
- operational ownership and cost.
Moving a fragile customization outside the core does not automatically make it clean. An unsupported interface, duplicated business rule or unowned side-by-side service can still create upgrade and operating risk.
Build a clean-core migration backlog
Each backlog item should include the object or interface, business process, owner, usage evidence, target disposition, dependency, security impact, effort range, test requirement and deadline. Group items by process and release risk rather than by technical object type alone.
The backlog should feed three delivery streams:
- removal and simplification for unused or duplicate assets;
- remediation and replacement for required capabilities; and
- governance enablement for standards, review gates, monitoring and exceptions.
Controls that keep the core clean
After the migration, require architecture review for extensions, automated checks where practical, a register of approved APIs and events, time-bound exceptions, regression evidence and a quarterly review of custom developments. Track trends such as new exceptions, objects without owners, unreleased-interface usage, upgrade findings and extension incidents.
Clean-core success is not “zero custom code.” A more useful outcome is that every deviation is visible, owned, justified, testable and supportable through the next upgrade cycle.
Practical lab: classify a custom landscape
The S/4HANA Readiness Lab includes a synthetic custom-code and integration inventory. Learners classify each item, choose a target pattern and explain what evidence is still missing. The full course extends this into a remediation backlog and operational governance plan.
Frequently asked questions
Does greenfield remove the need for clean-core governance?
No. It avoids inheriting legacy modifications by default, but new extensions can recreate the same upgrade problem unless architecture and lifecycle controls remain active.
Must every custom development move to SAP BTP?
No. The appropriate pattern depends on the requirement, deployment model, supported extensibility options, transaction needs, data access and operational constraints. Validate licensing and product capabilities against current SAP terms before implementation.
How is clean core measured?
Use operational measures: exception count and age, unsupported-interface findings, upgrade remediation effort, regression failures, unowned extensions and incidents caused by custom behavior.
Explore the SAP S/4HANA Migration Training program or discuss a private team lab.