Abstract shield with a checkmark in gold on navy, representing clean core governance

Clean Core Is a Governance Question, Not Just a Technical One

Clean core is generally introduced to SAP Cloud ERP customers as a technical principle, keeping the standard system unmodified and building any necessary extensions through supported, upgrade safe methods on SAP Business Technology Platform. That description is accurate as far as it goes, but it understates what actually protects clean core in practice, which is governance rather than technology. A well designed extensibility framework changes nothing if there is no one with the authority, and the willingness, to challenge a requirement before it becomes a customisation.

SAP's own Design Authority guidance is built around exactly this idea, combining structured challenge, decision review, risk management and quality assurance rather than a purely technical checklist. In practice, this means every significant deviation from standard should be tested against a small set of questions before it is approved.

  • Is there a standard SAP process that would meet the underlying business need?
  • Is the requirement genuinely differentiating for the business, or legally required, rather than simply familiar from a previous system?
  • Could the business process change instead of the software?
  • Where an extension is genuinely justified, is the extension pattern chosen compatible with clean core principles, and who will own and test it through every future release?

Asking these questions consistently requires a governance body with real authority, not a technical guideline that individual project teams are trusted to apply unevenly under delivery pressure. Without that authority, clean core tends to erode gradually, one reasonable sounding exception at a time, until the system a customer eventually runs looks very little like the standardised, upgrade ready platform SAP Cloud ERP was meant to deliver, and every subsequent release becomes correspondingly harder to adopt.

We treat clean core as one of the central responsibilities of implementation governance, alongside decision rights, quality gates and change control, rather than as a separate technical workstream to be delegated to the architecture team alone. Approached this way, clean core stops being an aspiration stated at the start of a programme and becomes something the programme is actually held to, release after release, long after go live.