Why Testing Matters More in the SAP Clean Core Era

One question comes up in nearly every Clean Core conversation:

"Once we move custom code out of the core, it's all SAP standard. SAP already tests the standard. Why do we still need test automation?"

Fair question. One of Clean Core's core promises is that upgrades get easier and testing effort decreases. With custom code removed from the core, there are fewer conflicts during upgrades and less to verify. That part is true.

But reading that promise as "testing is optional" leads to a production incident on your first scheduled upgrade after the transition.

This post breaks down what Clean Core actually changes about testing — and why test automation becomes more necessary, not less.

1. What Clean Core actually changes

The structural shift

In legacy SAP environments, custom code lived inside the core. Z-programs, enhancements, and direct table modifications were tangled with standard code. Every upgrade triggered conflicts between custom and standard changes, extending project timelines and expanding test scope.

Clean Core fundamentally restructures this. The core stays standard; custom logic moves outside. Extensions are built as side-by-side applications on SAP BTP or as on-stack extensions using the ABAP Cloud model. One principle: don't touch the core.

SAP introduced a four-level classification system (A through D) to govern extensions:

• Level A: Uses only released APIs — fully upgrade-safe, the target for all new development

• Level B: Uses classic APIs (BAPIs, etc.) — permitted with governance approval

• Level C: Accesses SAP internal objects — carries upgrade risk, requires a remediation roadmap

• Level D: Direct modifications, enhancements, direct table access — retirement candidates

The API strategy shifts as well. Instead of direct BAPI/RFC calls, the standard is to use released OData/SOAP APIs through SAP Integration Suite.

Governance also shifts from reactive to proactive. The ABAP Test Cockpit (ATC) automatically checks code-level Clean Core compliance, and developers must verify whether a released API exists before writing new code.

Why SAP is pushing this so hard

In the cloud model, all customers share the same code base. For SAP to deliver regular innovation, customer cores must be clean. An upgrade can't be pushed into a core packed with custom code. Clean Core is a prerequisite for RISE with SAP and the foundation of SAP's entire cloud strategy.

That's why SAP built dedicated Clean Core tools into Cloud ALM:

• RISE with SAP Methodology Dashboard: Tracks Clean Core compliance, version currency, and extension readiness for the next upgrade

• Custom Code Analytics: Provides detailed insights into custom code usage, performance impact, and standards compliance

• Extensibility Governance: Tracks extensions and identifies custom code that may impact the core

• Release Assessment (RASD): Assesses the impact of new SAP releases on the customer landscape

These are Clean Core's promises, and they're largely delivered.

The problem starts when one conclusion is drawn incorrectly: "Less custom code means less testing."

2. "SAP already tests the standard, right?"

The most common misconception — and the most dangerous one.

What SAP tests

SAP validates that the standard core functions correctly with each release. Standard transactions work, cross-release compatibility holds, processes run in default configurations.

This is true, and Clean Core customers benefit more directly from this validation since there's no custom code in the way.

What SAP doesn't test

Three areas remain the customer's responsibility — even after Clean Core.

Your specific business process combinations. Even with only standard functionality, every company has unique configurations: industry-specific settings, org structures, pricing conditions, tax rules. SAP tests whether VA01 works. SAP does not test whether your special discount + multi-currency + tax-exempt combination flows unbroken from VA01 through delivery, billing, and into FI. Only your environment can verify that.

BTP extensions after upgrades. Custom logic moved to BTP is your asset, not SAP's testing scope. Cloud ALM itself includes manual and automated testing as a required component of Clean Core extensibility, explicitly stating that extensions must be thoroughly tested to ensure they don't introduce issues into the core.

Cross-system integrations. An HR record created in SuccessFactors flowing through to cost centers and travel management. Cloud ALM provides visibility into these cross-system processes, but visibility is monitoring — not verification. Whether those integrations still work after an upgrade can only be confirmed by running them.

The bottom line: SAP tests whether the standard core works. SAP does not test whether your business processes survive an upgrade. Even on pure standard, your configurations, integrations, and data combinations are unique — and that uniqueness is where failures occur.

3. Testing doesn't shrink — it shifts

What decreases

Credit where it's due. Some testing genuinely decreases.

Z-program and enhancement testing drops — the code has been removed or moved to BTP. Custom code conflict testing during upgrades drops — no custom code in the core means no conflicts.

This is where Clean Core's promise is real, and it does reduce effort.

What increases or appears new

The problem is that focusing only on what decreases misses the full picture.

BTP extension verification is new. Decoupled doesn't mean disconnected. BTP extensions still communicate with the core through released APIs. When the core upgrades, subtle API behavior changes or version bumps can break extensions. What used to be tested as one system now requires separate but coordinated verification of core upgrades and extension compatibility.

Regression testing frequency increases. Clean Core assumes rapid adoption of new releases. S/4HANA Cloud Public Edition has semi-annual major upgrades with feature updates in between. Private Edition delivers Feature Pack Stacks on a similar cadence. Where teams could previously defer upgrades, Clean Core expects them to stay current.

Each individual test cycle may be smaller. But the number of cycles grows. A team that ran one major regression annually now needs to run regression semi-annually — or more often.

Integration testing complexity grows. Clean Core architecture distributes logic across the core, BTP, Integration Suite, and third-party systems. More connection points than the legacy monolith means more places where end-to-end process verification is needed.

Think of it this way: renovating a house and reducing the number of rooms doesn't eliminate cleaning. The rooms are fewer, but there's now a yard (BTP) and connecting walkways to neighbors (integrations). What you clean has changed. Cleaning itself hasn't gone away.

4. What test automation needs to deliver in the Clean Core era

Speed that fits the upgrade calendar

Clean Core assumes recurring upgrades. Hundreds of regression test cases need to finish within a realistic window every time a new release or Feature Pack Stack arrives.

The speed bottleneck in regression testing applies directly here. UI replay automation runs 20–40 minutes per case. At 500 cases, that's days. In an environment where upgrades arrive semi-annually, that speed makes full regression impossible.

Backend direct transmission bypasses the UI entirely, sending test data directly to the SAP backend. The same 500 cases finish in hours. In a Clean Core environment with recurring upgrades, this speed difference determines whether regression testing is feasible or skipped.

E2E process verification

Automation must validate the entire business process flow — including BTP extensions — as a single scenario. Module-level testing can't catch failures at the boundaries between core, BTP, and Integration Suite.

Order creation (core) → custom approval logic (BTP) → delivery (core) → third-party logistics (Integration Suite) → billing (core). This entire chain needs to run as one test scenario. Individual steps passing doesn't guarantee the flow holds end to end.

Production data-driven testing

Even standard processes produce different data combinations at every company. Testing with sample data simply re-verifies the happy paths SAP has already tested.

Real verification comes from exception combinations in production data: special discounts plus multi-currency plus tax exemptions, bulk returns plus partial cancellations plus follow-up billing. Extracting real transaction data from production and applying it directly to test scenarios is what turns testing from theoretical to meaningful.

Conclusion: Clean Core isn't complete without a repeatable verification system

Clean Core is the right direction. A clean core means easier upgrades, faster access to SAP innovation, and freedom from custom code conflicts. SAP has good reasons for building dedicated dashboards and code analysis tools into Cloud ALM to drive adoption.

ut Clean Core's promise is not "testing disappears." It's "testing changes character."

Custom code conflict testing shrinks. BTP extension verification, recurring regression testing, and integration testing become the new center of gravity. And because these tests repeat with every upgrade cycle, they can't be sustained manually.

Same Clean Core, different outcomes

Consider two companies that have both completed their Clean Core transition.

Company A feels reassured. "We removed all the custom code — upgrades should be smooth now." They apply the semi-annual upgrade without separate regression testing. The first upgrade passes uneventfully. On the second, a subtle API response format change breaks a BTP-based approval workflow. The operations team discovers it a week later — after pending approvals have piled up and business users start asking questions.

Company B builds regression test automation alongside their Clean Core transition. Before every semi-annual upgrade, they run hundreds of E2E scenarios via backend direct transmission in a matter of hours, covering edge cases with production data. On the second upgrade, pre-go-live testing catches the BTP API compatibility issue. It's fixed before the upgrade goes live.

The difference isn't whether they adopted Clean Core. It's whether they built a repeatable verification system on top of the clean core.

Clean Core isn't complete the moment the core is clean. It's complete when you can quickly verify BTP extensions and the full scope of your business processes with every scheduled upgrade.