Reaching Clean Core during an S/4HANA migration is hard. *Staying* there is harder, and it is the part most teams underestimate. Clean Core is not a one-time clean-up; it is an operating discipline that governs how every future change, enhancement, and integration is built so the digital core stays standard, upgrade-safe, and cloud-ready. This guide is about the maintenance side: the custom-code strategy and governance that keep your core clean after the migration is done, rather than watching technical debt quietly creep back in. If you want the foundational definition first, start with our explainer on Clean Core architecture.
Why Clean Core Erodes
Clean Core erodes for the same reason any standard erodes: pressure and convenience. A business request lands, the deadline is tight, and the fastest path is a quick modification to a standard object or a bit of custom logic bolted into the core. Each one is small and reasonable in isolation. Collectively, over a couple of years, they rebuild exactly the brittle, upgrade-blocking mess the migration was supposed to eliminate.
The cost shows up later, as a tax on every upgrade and every innovation. Modified standard objects break or need rework when SAP ships updates. Continuous-innovation releases become risky events instead of routine ones. The "clean" core you paid to achieve slowly stops being clean, and you are back to deferring upgrades because they hurt.
Maintaining Clean Core means refusing the convenient path by default and having a governed, equally fast alternative ready when a real requirement arrives.
Classify Your Custom Code Honestly
Whether you are finishing a brownfield conversion or governing a live system, the starting point is the same: an honest classification of custom code. The tooling (the ABAP test cockpit, custom code analysis, and the cloud-readiness checks) gives you the inventory; the strategy is what you do with it.
A workable classification:
- Retire. Code that is unused or obsolete. The biggest and most overlooked win — measure actual usage, do not assume. Dead code is the cheapest debt to clear.
- Replace with standard. Custom logic that now duplicates standard S/4HANA functionality. Adopt the standard and delete the custom.
- Remediate in place. Code that is still needed and belongs in the core but violates HANA or Clean Core rules. Fix it to be compliant.
- Relocate to the side. Enhancements that should never have lived in the core. Move them to a side-by-side extension model.
The discipline is to push as much as possible into the first two buckets. Every object you retire or replace is one you never have to maintain, test, or carry through the next upgrade. This is the heart of a sound custom-code strategy, and it is exactly the work our legacy SAP modernization service focuses on.
The Extensibility Model: Where New Logic Goes
Maintaining Clean Core depends on having a clear, governed answer to "where does new logic go?" SAP's extensibility model gives you three tiers, and the rule of thumb is to use the lightest one that meets the need.
| Tier | What it is | Use when |
|---|---|---|
| Key-user (in-app) | Low-code extensions inside the application by business experts | Simple fields, logic, and UI adaptations |
| Developer (on-stack) | ABAP Cloud / released APIs and extension points within the system | Deeper logic that must run close to the data, using only released objects |
| Side-by-side (BTP) | Apps and services built on SAP BTP, integrating via released APIs and events | Substantial custom apps, cross-system logic, or anything that should be decoupled from the core |
The unifying principle is build only on released, stable interfaces (released APIs, extension points, events) rather than reaching into internal SAP objects. Code that consumes released interfaces survives upgrades; code that depends on internals does not. Side-by-side extension on SAP BTP is where the heavier custom apps belong, keeping the digital core standard while you still get the bespoke capability the business needs.
Governance That Actually Holds
A strategy without governance decays. The teams that keep their core clean put a few lightweight controls in place and enforce them consistently:
- A "no modifications to standard" default. Modifying standard objects requires explicit, senior sign-off and a documented reason. Make the exception rare and visible.
- An extension decision rule. Every new requirement runs through the tier model above: can it be key-user? If not, on-stack with released APIs? Only then side-by-side. The default is never "modify the core."
- Released-interface-only development. Developers build against released APIs and extension points; using internal objects is treated as a defect.
- Clean Core in the definition of done. Code reviews and quality gates check Clean Core compliance, not just functionality. The ABAP test cockpit and cloud-readiness checks run in the pipeline.
- A periodic custom-code review. Quarterly or per-release, re-run the inventory, retire what has gone unused, and catch creep before it compounds.
None of this is heavy. It is a handful of defaults and gates that make the clean path the path of least resistance, which is the only way a standard survives contact with real deadlines.
Brownfield Reality: You Will Carry Some Debt
If you came through a brownfield conversion, be realistic: you almost certainly did not remediate everything before go-live, and you should not have tried to. The pragmatic approach is to get the core compliant enough to be upgrade-safe at conversion, then run a deliberate, post-go-live remediation backlog, retiring, replacing, and relocating custom code in priority order while the governance above prevents new debt from forming.
That two-speed approach, stabilize at conversion, then remediate on a managed backlog, is usually cheaper and lower-risk than trying to achieve a perfect Clean Core in one big-bang event. The trap to avoid is finishing the conversion, declaring victory, and quietly letting the backlog and the discipline both lapse. We cover how this fits the broader migration decision in our brownfield vs greenfield guide.
The Payoff
A maintained Clean Core turns upgrades from dreaded events into routine, low-risk releases, and it is the precondition for adopting new SAP capabilities, including AI and agentic automation, without a remediation project first. The investment is not the one-time clean-up; it is the ongoing discipline of classifying code honestly, extending on released interfaces, and governing the few defaults that keep the core standard.
If you want help building and running that custom-code strategy, our legacy SAP modernization work covers code remediation and Clean Core governance, and we sequence it against your broader S/4HANA migration so the core you worked to clean actually stays that way.