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

You customise SAP. A year later, the upgrade breaks your changes. Your team spends weeks fixing it. Sound familiar?

That is the cost of custom code inside the SAP core. It adds up fast. After a few projects, every quarterly update turns into a mini-project of its own.

Clean Core stops this cycle. The idea is simple: keep the SAP core standard. Build your custom logic next to it, not inside it. That is how we work at Spadoom — on every project.

What Clean Core actually means

No custom code inside SAP. Your business logic lives in separate extensions that talk to SAP through stable APIs.

SAP Sales Cloud V2 and SAP Service Cloud V2 are built for this. They expose clean REST APIs and an event system designed for side-by-side extensions. SAP updates the core on their schedule. Your extensions keep working.

This is not a workaround. SAP designed it this way.

How we build extensions: SAP CAP on Cloud Foundry

We use the SAP Cloud Application Programming model (CAP) — SAP’s open-source framework for building services on SAP BTP.

CAP runs on Cloud Foundry inside SAP BTP. Three things make this a solid choice:

• No infrastructure headaches. Cloud Foundry handles scaling, routing, and deployment. Your team writes business logic, not ops scripts.
• SAP connections built in. CAP plugs directly into XSUAA (auth), SAP Event Mesh (events), the Destination Service, and the Sales/Service Cloud V2 APIs.
• Standard tech stack. Node.js or Java. OData and REST. CDS for data modelling. No exotic lock-in.

The result: extensions you can deploy, test, and update independently of SAP’s release calendar.

A real example: Sales Cloud V2

Say a customer needs custom validation on the opportunity object, plus a few extra fields for their workflow.

We deploy a CAP service on Cloud Foundry. It adds the validation logic and fields. It listens to opportunity events via SAP Event Mesh — no polling, no scheduled jobs. A custom Fiori UI sits inside the Sales Cloud shell. Sales reps see one seamless interface.

The Sales Cloud V2 core? Untouched. SAP pushes an update next quarter? No regression testing needed, because there is nothing custom in the core to break.

Same approach for Service Cloud V2. Custom escalation rules, enriched case data, connections to external ticketing tools — all CAP extensions, all on Cloud Foundry, all outside the core.

Why this matters for your budget

Without Clean Core, every SAP release costs you. Your team tests custom code, adapts it, fixes what broke. Every time.

With Clean Core, an SAP release is just a deployment. You test your extensions against the API contract — which SAP keeps backwards-compatible. Upgrades that used to take months now take days.

Over three to five years, the savings add up. Less time on maintenance means more time building features that actually grow your business.

How Spadoom works

Clean Core is not an option we offer. It is how we build, full stop.

Every project starts with one question: does this really need a core change, or can we build it as an extension? Almost always, the extension wins — technically cleaner and cheaper to maintain.

We build and support CAP extensions across the SAP CX stack: Sales Cloud V2, Service Cloud V2, plus integrations with SAP Commerce Cloud, SAP Emarsys, and ERP systems. All on BTP Cloud Foundry.

Starting a new Sales Cloud or Service Cloud project? Planning a migration from an older SAP CRM? Talk to our architects about Clean Core. Get in touch.