Clean Core with SAP CAP: Extend SAP CX Without the Upgrade Pain

You customise SAP. A year later, an upgrade breaks your changes and your team spends weeks fixing them. It is one of the most common stories we hear from companies that come to us with an existing SAP landscape.

That is the cost of custom code inside the SAP core. It adds up quietly: after a few rounds, every release turns into a small project of its own, and the team starts to dread release notes instead of reading them.

Clean Core stops this cycle. Keep the SAP core standard and build your custom logic next to it, not inside it, using the extension framework SAP provides.

TL;DR: Clean Core means no modifications inside the SAP core. We build extensions side by side with the SAP Cloud Application Programming Model (CAP) on SAP BTP. They talk to SAP Sales Cloud V2, Service Cloud V2 or S/4HANA Public Cloud through released APIs and events. When SAP ships a release, you retest the API contract of your extensions instead of repairing modified core code.

What does Clean Core actually mean?

The principle: no custom code inside SAP. Your business logic lives in separate extensions that talk to SAP through stable, released APIs. SAP has made this its explicit guidance for cloud ERP; its own article on how to extend SAP S/4HANA Cloud the right way explains the model. In SAP S/4HANA Public Cloud it is not even optional: the platform only allows released extension points.

SAP Sales Cloud V2 and SAP Service Cloud V2 follow the same design. They expose REST APIs, documented on the SAP Business Accelerator Hub, and an event system meant for side-by-side extensions. SAP updates the core on its schedule, and your extensions keep working as long as the API contract holds.

This is not a workaround. The V2 products were built to keep the core and customer logic apart.

How do we build extensions with SAP CAP?

We use the SAP Cloud Application Programming Model (CAP), SAP’s framework for building services on SAP BTP, and run the services in the Cloud Foundry environment of SAP BTP. It is our default for side-by-side extensions on Sales Cloud V2, Service Cloud V2 and S/4HANA Public Cloud, for three reasons:

• Little infrastructure work. Cloud Foundry handles scaling, routing and deployment. The team writes business logic, not operations scripts.
• SAP connectivity built in. CAP integrates with XSUAA for authentication, the Destination service and SAP event messaging, and consumes the Sales and Service Cloud V2 APIs without custom glue code.
• A standard stack. Node.js or Java, OData and REST, CDS for data modelling. Developers already know the tools, and there is no exotic lock-in.

The result: extensions you can deploy, test and update independently of SAP’s release calendar. We describe the full setup, from subaccount to deployment, in how to extend SAP Sales Cloud V2 with custom Cloud Foundry apps and, for the ERP side, in extending S/4HANA Public Cloud on BTP Cloud Foundry. Where logic belongs next to the ERP data, S/4HANA also offers on-stack ABAP Cloud, covered in our post on embedded Steampunk.

What does this look like in practice?

Sales Cloud V2 example: a customer needs custom validation on the opportunity plus a few extra fields for their process. We deploy a CAP service on Cloud Foundry that holds the validation logic and the additional data. It reacts to opportunity events instead of polling or running scheduled jobs. A custom UI is embedded in Sales Cloud V2 as a mashup, so sales reps work in one interface.

The Sales Cloud V2 core stays untouched. When SAP ships the next release, we retest the API calls and events the extension relies on; there is no modified core code to repair.

Service Cloud V2 example: custom escalation rules, enriched case data, connections to external ticketing tools. All CAP extensions on Cloud Foundry, all outside the core.

S/4HANA Public Cloud example: the same pattern applies when a CX process needs ERP data, such as a credit check before a quote is released. The extension calls released S/4HANA APIs and never touches the ERP core. That is how one team can keep the ERP core and the CX stack standard at the same time.

Why does Clean Core matter for your budget?

Custom code that breaks during upgrades is one of the most common reasons SAP projects run over time and budget. Many IT leaders have lived through an upgrade that went sideways because a modification made years earlier was never documented.

Without Clean Core, every SAP release costs you: the team tests custom code, adapts it and fixes what broke, every time. With Clean Core, a release mostly means retesting your extensions against an API contract that SAP versions and keeps stable. How much faster upgrades become depends on how much logic you move out of the core, but the effort shifts from repair work to regression testing.

Over three to five years, that difference compounds. Less time on maintenance means more time for features that grow the business.

If you are planning an S/4HANA move and want to know how much of your custom code has to be rebuilt, our S/4HANA readiness assessment answers that before the project starts. For choosing a partner who builds extensions this way, see our overview of the best SAP BTP development partners in Switzerland.

FAQ

What if my extension needs data from the SAP core?

A CAP extension reads and writes data through the released APIs of SAP Sales Cloud V2, Service Cloud V2 or S/4HANA Public Cloud. For changes such as a new opportunity, event notifications (for example through SAP Event Mesh) inform the extension. It never accesses the core database directly.

Can existing customisations be migrated to Clean Core?

Yes, but it is a refactoring effort, not a lift-and-shift. Custom ABAP or in-core modifications are rebuilt as side-by-side services or as released on-stack extensions. The business logic stays the same; the architecture changes.

Does Clean Core work for SAP Commerce Cloud too?

The principle is the same, the mechanism differs. Commerce Cloud uses extensions in its type system and defined extension points instead of core modifications. On the frontend, SAP Composable Storefront (formerly Spartacus) separates customisations through Angular dependency injection.

Is CAP the only option for Clean Core extensions?

No. Any technology that calls SAP’s released APIs works, including Java, Node.js, Python or low-code with SAP Build. We use CAP because it brings authentication, data modelling and SAP connectivity out of the box, which is the shortest path to production-grade extensions.

How does Clean Core affect SAP support?

SAP supports its standard product. Modifications inside the core can make support cases harder, because SAP first has to rule out the custom code. Side-by-side extensions leave the standard intact, and you support your own extensions separately.

Starting a Sales Cloud V2, Service Cloud V2 or S/4HANA Public Cloud project? Talk to our architects about a Clean Core approach from day one.