How can teams extend SAP S/4HANA without undermining clean core?

Clean core is often reduced to a slogan about avoiding custom code. That is too narrow. SAP’s clean-core extensibility material frames the goal as enabling customers to extend where needed while supporting smooth upgrades and the handling of system extensions.

The useful question is not simply “Can we customize this?” It is “Which supported extension approach best fits this requirement, and how will we keep it understandable, governed, and upgrade-ready?”

Use a decision sequence before implementation. It helps teams distinguish a genuine business differentiator from a familiar process that may already be supported by standard SAP capability.

Maintainability depends on more than where code runs. Teams need to know why an extension exists, what business process it supports, which supported interfaces it uses, and who is responsible for reviewing it when SAP or a connected system changes.

A concise extension register can record the business owner, technical owner, interface or extension point, release dependencies, automated checks, and retirement criteria. This is a practical governance recommendation—not a substitute for checking SAP documentation for the specific product, release, and deployment model.

Ask the team to explain the extension in one sentence, identify the supported extension mechanism, and show how the change will be tested before and after an upgrade. If those answers are unclear, pause and improve the design or documentation before the extension becomes operational dependency.

The result is not customization-free software. It is a more deliberate balance between business-specific capability and a system that can continue to change.