Miguel Santos

By Miguel Santos · SAP & Management

Clean Core has become one of the most frequently used expressions in SAP transformation programmes. Yet it is often reduced to a technical objective: remove custom code, avoid modifications and move extensions to SAP BTP.

That interpretation is incomplete.

Clean Core is a transformation principle that affects business processes, architecture, data, integration, delivery governance and operations. It requires decisions from business and technology leaders throughout the programme lifecycle.

For SAP transformation leaders, the central question is not simply:

“How do we reduce custom code?”

The more relevant questions are:

• Which processes should follow the SAP standard?
• Which capabilities truly differentiate the business?
• Where should extensions be implemented?
• How should integrations and APIs be governed?
• Who owns data quality?
• How will the organisation remain clean after go-live?

Clean Core does not mean zero customisation

Every large organisation has regulatory requirements, industry-specific processes and capabilities that provide competitive differentiation. Attempting to eliminate every deviation from the standard is neither realistic nor necessarily desirable.

A Clean Core strategy distinguishes between:

• requirements that can be covered by SAP standard functionality;
• processes that should be redesigned to adopt best practices;
• genuine differentiating requirements that justify an extension;
• legacy customisations that no longer provide sufficient business value;
• temporary exceptions that require an agreed remediation roadmap.

The objective is to keep the ERP foundation stable, transparent and upgradeable while allowing the organisation to innovate through controlled, cloud-compliant extensions and integrations.

SAP structures Clean Core around five dimensions: business processes, extensibility, data, integration and operations. SAP Learning – Introducing the Clean Core Approach

1. Business processes: challenge before customising

Fit-to-standard should not become a workshop in which every difference between the legacy system and SAP is automatically registered as a gap.

Transformation leaders should require every proposed deviation to answer four questions:

1. Is this a legal, regulatory or industry requirement?
2. Does it provide measurable competitive differentiation?
3. Can the objective be achieved by changing the business process?
4. Does the value justify the implementation and lifecycle cost?

The business process owner must participate in this decision. Clean Core cannot be delegated exclusively to architects or developers because many customisations originate from business decisions.

A strong governance model therefore makes process owners accountable for justifying deviations and accepting the long-term consequences.

2. Extensibility: choose the right extension model

An extension may be necessary, but its location and design determine whether it creates sustainable differentiation or future technical debt.

Depending on the requirement, the solution may use:

• standard configuration;
• key-user extensibility;
• developer extensibility using released SAP objects and ABAP Cloud;
• side-by-side extensibility on SAP BTP;
• an external application integrated through governed APIs or events.

Side-by-side development is not automatically the correct answer for every requirement. A simple field or validation may be better handled through supported in-app extensibility. More complex and decoupled capabilities may justify SAP BTP.

SAP’s guidance distinguishes between on-stack and side-by-side extensibility and recommends using supported APIs and events to preserve upgradeability. SAP Help – Getting Started with Extensibility

Transformation leaders should establish an Architecture Review Board with clear decision criteria. Every extension should have:

• a business owner;
• a documented business case;
• an architecture decision record;
• a lifecycle owner;
• a support model;
• a retirement or reassessment date.

3. Integration: govern the landscape, not only the interface

A transformation programme may deliver a clean S/4HANA system while recreating complexity through hundreds of unmanaged point-to-point interfaces.

A Clean Core integration strategy should define:

• approved integration patterns;
• when to use APIs, events, IDocs, files or middleware;
• SAP Integration Suite and API Management standards;
• ownership of data contracts;
• authentication and security requirements;
• monitoring, retry and error-handling mechanisms;
• interface versioning and decommissioning rules.

Each integration should be evaluated as part of an end-to-end business process. Technical connectivity alone is not sufficient. The programme must understand what happens when a message is delayed, duplicated, rejected or processed in the wrong sequence.

Clean Core therefore requires both design governance and operational observability.

4. Data: migration is not the end of data governance

Poor-quality data moved into a new S/4HANA environment remains poor-quality data.

The transformation programme must define:

• authoritative data sources;
• data ownership;
• quality thresholds;
• cleansing responsibilities;
• retention and archiving policies;
• reconciliation controls;
• governance for master and reference data after go-live.

Historical data also requires a deliberate decision. Not everything needs to be migrated into the operational system. Some information may remain in an archive or legacy access platform, provided that business continuity, reporting and regulatory requirements are protected.

Data governance must continue after deployment. Otherwise, the new environment gradually reproduces the inconsistencies of the legacy landscape.

5. Operations: staying clean after go-live

A system does not remain clean simply because it was clean on the go-live date.

After deployment, business requests, urgent fixes, acquisitions, regulatory changes and local requirements will create pressure for exceptions.

The operating model must therefore include:

• release and change governance;
• architecture reviews;
• monitoring and alerting;
• upgrade planning;
• test automation;
• technical debt measurement;
• periodic review of extensions and integrations;
• decommissioning of obsolete objects;
• clear ownership across SAP, the customer, hyperscalers and service providers.

SAP Cloud ALM supports implementation governance, requirements, testing, deployment, operations and traceability. Within the RISE with SAP Methodology, Clean Core tasks and quality gates can be managed across the implementation lifecycle. SAP Learning – Clean Core Success Plan with SAP Cloud ALM

What transformation leaders should put in place

A practical Clean Core governance model should include:

1. A clear decision framework

Define what can be approved by functional teams, what requires architecture review and what must be escalated to programme governance.

2. Named business accountability

Every deviation from standard must have a business owner, justification and measurable value.

3. Architecture principles

Document the approved rules for processes, extensions, integrations, data and operations.

4. Clean Core quality gates

Review Clean Core adherence at the end of each transformation phase, not only before go-live.

5. A transparent exception register

Record deviations, risks, owners, remediation actions and target dates.

6. Measurable indicators

Track indicators such as:

• number of deviations from standard;
• custom objects by compliance level;
• extensions without active ownership;
• point-to-point integrations;
• interfaces without monitoring;
• obsolete developments;
• failed regression tests;
• upgrade impact and remediation effort.

7. Governance that continues into operations

Transfer Clean Core responsibilities to the permanent operating model, architecture function or SAP Centre of Excellence.

Clean Core is a leadership commitment

The greatest Clean Core challenge is rarely the technology.

It is the ability to challenge historical requirements, make cross-functional decisions, assign ownership and resist short-term solutions that create long-term complexity.

A successful Clean Core strategy does not prevent innovation. It creates the foundation for innovation by making the SAP landscape more understandable, governable and ready for continuous change.

For transformation leaders, Clean Core should therefore be treated as:

• a business transformation principle;
• an architecture strategy;
• a delivery governance model;
• an operational discipline;
• and a long-term commitment beyond go-live.

The real measure of success is not how clean the system appears on deployment day.

It is whether the organisation can continue to evolve, integrate, upgrade and innovate without rebuilding the complexity it worked so hard to remove.