Composable Commerce in B2B: When It's Right and When It's Not

Composable commerce looks convincing on a whiteboard: pick the best tool for each job, connect them, replace pieces when something better comes along. For a B2B team on SAP Commerce Cloud the useful question is narrower. Which parts of your shop gain from being separate, and can your team carry the extra moving parts?

This guide answers that. It separates headless from composable, shows how SAP Commerce Cloud supports both, and ends with the decision questions we use in architecture assessments. For the technical principles behind the terms, see our explainer on MACH architecture in SAP Commerce Cloud.

TL;DR: Headless separates the storefront from the commerce engine; composable also replaces individual capabilities such as search, CMS or payments with specialised services. On SAP Commerce Cloud both run through the OCC APIs. Composable pays off with high UX ambition, several storefronts or frequent frontend releases. It is the wrong choice for small teams, tight deadlines or a plain reorder portal. Our default: SAP Commerce Cloud as the core, Composable Storefront or a custom frontend, and specialised services added one at a time.

Headless, composable, MACH: three different things

The terms get used as synonyms. They answer different questions.

Headless answers: how does my storefront talk to my commerce engine? Only through APIs. The backend does not render pages, the frontend does not touch the database. That lets you build the storefront in any framework, release frontend and backend on separate schedules and serve web, app and kiosk from the same backend. It also means you need frontend developers, an API layer with authentication and versioning, and your own pipeline and monitoring for the frontend.

Composable answers: how do I assemble the whole stack? Instead of one suite doing everything, you pick specialised services for search, content, payments or personalisation and connect them through APIs. Each can be replaced without rebuilding the rest.

MACH (Microservices, API-first, Cloud-native, Headless) describes the technical principles that make composable possible. You need MACH-style building blocks to compose, but running on them does not make you composable.

So you can be headless without being composable (a React storefront on one integrated commerce engine), and composable without being headless (a server-rendered shop that calls an external search service). Most SAP Commerce Cloud projects today end up in between: a decoupled storefront, an integrated commerce core and two or three specialised services.

How SAP Commerce Cloud supports both

SAP Commerce Cloud is headless by design and composable at the edges.

OCC REST APIs. Products, categories, carts, checkout, orders and customers are exposed as REST endpoints. Any frontend or external system can call them, and you can add custom endpoints through your own extensions. Without this layer, composable would stay a slide.

Composable Storefront. SAP’s Angular-based storefront (formerly Spartacus) talks to Commerce Cloud only through OCC. You can extend it, or replace it with React or Next.js without touching the commerce engine. SAP documents it in the Composable Storefront guide on SAP Help. In September 2026 SAP also announced a partnership with Vercel for Next.js storefronts on Commerce Cloud; we compare the frontend options in Composable Storefront vs React/Next.js.

Side-by-side extensions on SAP BTP. Custom logic such as a special pricing rule or a recommendation service can run on SAP BTP and be called from Commerce Cloud, rather than being built into the core.

Specialised services at the edges. Search (the built-in Solr or an external service), content management (SmartEdit or a headless CMS), payments through gateway integrations, SAP Engagement Cloud (formerly SAP Emarsys) for marketing automation, and SAP Customer Data Cloud for identity and consent.

What Commerce Cloud is not: a set of independently deployable microservices. Cart, pricing, promotions and orders run as one platform. For B2B that is usually an advantage, because that is exactly where contract prices, customer hierarchies and the ERP link live.

When does composable make sense for B2B?

Composable pays off in three situations. If none of them describes you, the extra complexity is unlikely to be worth it.

The storefront is part of your brand, not a catalogue. If buyers should experience a product configurator, rich content or a guided selection rather than a list with an order button, a decoupled frontend gives your designers and developers room that templates do not.

You run several storefronts. B2B and B2C, several brands or countries on one commerce core: decoupling lets each experience evolve on its own while pricing, stock and orders stay in one place.

You release frontend changes constantly. When the business needs changes several times a week, separate release cycles remove the wait for backend deployments. Distrelec is our reference for this: after we decoupled its frontend from SAP Commerce Cloud, time-to-market for frontend changes dropped by 70%.

When is composable the wrong choice?

No dedicated frontend people. A custom frontend is a JavaScript application that someone has to build and maintain. If your team is mostly SAP and backend developers, you will spend more time on the frontend stack than on commerce features.

A tight deadline. Choosing components, wiring them together and building pipelines takes time before the first order goes through. In our assessments this adds several weeks compared with an integrated start. With a hard go-live date, start with Composable Storefront.

A straightforward use case. A reorder portal with standard B2B features does not need a custom frontend. Composable Storefront covers it, and the budget is better spent on clean prices and a working ERP integration.

Where to start composing

Do not compose everything at once. Start where the difference for buyers is largest and the risk to the order flow smallest.

Order	Components	Why here
Start here	Search, payments, commerce analytics	Visible benefit, clear interfaces, easy to roll back
Add next	Headless CMS alongside SmartEdit, personalisation, marketing automation (e.g. SAP Engagement Cloud)	Needs clean data and content workflows first
Consider later	Fully custom storefront, custom PIM instead of the built-in product content, functions moved to BTP services	Highest effort, touches the order flow

Keep the commerce core stable while you do this: cart, checkout, pricing, orders and product management stay in Commerce Cloud. Validate each new integration before adding the next.

The risks nobody puts on the slide

Integration effort. Every component is one more interface, contract and upgrade cycle. Five services mean five vendors and five possible points of failure. The glue between them can cost more than any single component.

Operations. Monitoring one platform is routine. Monitoring ten services needs distributed tracing, alerting across vendors and a team that can find the fault when an order gets stuck between two of them. That is a different skill set from classic commerce development.

Lock-in moves, it does not disappear. You are no longer tied to one vendor, but you are tied to your integration layer. If the glue code is complex, swapping a component is harder than the brochure suggests.

Best of breed is not best overall. The best search, the best CMS and the best payment provider do not automatically add up to the best buying experience. What counts is how well they work together on a real order.

After the on-premise end: three paths

Mainstream maintenance for SAP Commerce on-premise (last release 2205) ended on 31 July 2026; since then, only customer-specific maintenance is available (SAP Help). For many teams that end is the moment to ask whether to go composable. There are three realistic paths:

Path	What it means	Our planning range	Fits when
SAP Commerce Cloud	Move existing logic to the SAP-managed platform	About 3 to 6 months	Customisations are tied to SAP data models, the team knows SAP Commerce
Hybrid	Commerce Cloud as the core, decoupled custom frontend, specialised services over time	About 4 to 8 months	You want frontend freedom without re-implementing commerce logic
Fully composable	Replace the platform with separate services for commerce, content, search and orders	Often 9 to 15 months	Strong in-house team, API-first landscape, unusual requirements

These ranges come from our own assessments and depend on scope; they are not a quote. The Franke platform shows what a focused scope can achieve: Spadoom brought the SAP Commerce Cloud platform live in 90 days, a figure that refers to that commerce launch. If you are still on-premise, our post on what to do now that on-premise support has ended covers the next steps.

A full composable rebuild means re-implementing years of promotion rules, price calculation and B2B logic that Commerce Cloud keeps. That alone is often a larger project than the whole move to the cloud.

How should you decide?

Six questions. Answer them for your current team, not the one you hope to have.

1. Do you have at least two dedicated frontend developers? If not, start integrated.
2. Do you need several distinct storefronts? If yes, composable has a solid case.
3. Is your go-live deadline less than six months away? If yes, start integrated.
4. Is the storefront a brand differentiator or a functional tool? Differentiator: decouple it. Tool: stay integrated.
5. Do your ERP, PIM and logistics systems already offer clean APIs? If data still moves as batch files and spreadsheets, composable adds complexity without its main benefit.
6. Can you run several vendor relationships and a custom frontend for years? Composable is not a one-time build.

For most B2B projects on SAP Commerce Cloud our recommendation is the same: start integrated, decouple the frontend where it helps, and compose further as your team and requirements grow. The OCC APIs keep that option open without touching the commerce engine. Whichever path you take, the order still has to reach the ERP correctly; that is why we plan the storefront and the ERP integration with one team, as described in our post on a B2B webshop on SAP Commerce Cloud with S/4HANA Public Cloud. If you are comparing platforms beyond SAP, read our SAP vs Salesforce vs Adobe Commerce comparison.

---

Want to know which approach fits your situation? We run architecture assessments that look at your team, timeline, ERP landscape and requirements. Talk to our commerce architects or read more about our SAP Commerce Cloud services.

Frequently Asked Questions

What is the difference between headless and composable commerce?

Headless separates the storefront from the commerce backend, which talk only through APIs. Composable goes further: search, content, payments or personalisation are separate, replaceable services. Every composable setup is headless, but a headless storefront on one integrated commerce engine is not composable. SAP Commerce Cloud supports both through its OCC REST APIs.

Is SAP Commerce Cloud headless or composable?

It is headless by design and composable at the edges. The OCC APIs expose products, carts, checkout, orders and customers to any frontend, and search, CMS, payments or marketing can be external services. The commerce core (cart, pricing, promotions, orders) remains one integrated platform, not a set of independently deployed microservices.

Can we start with Composable Storefront and go fully composable later?

Yes, and for most B2B projects we recommend exactly that. Composable Storefront uses the same OCC APIs as any custom frontend, so a later switch to React or Next.js leaves the commerce configuration, data model and ERP integration untouched. Replace one component at a time, starting with the one that causes the most pain.

How many developers does a composable architecture need?

Plan for two to three dedicated frontend developers, one to two commerce or integration developers and someone who owns DevOps and monitoring across several deployment pipelines. An integrated setup with Composable Storefront can often run with a smaller team of SAP Commerce developers. Someone also has to own the overall architecture.

Is composable commerce more expensive than an integrated setup?

Initially, yes: component selection, integration work and extra pipelines add weeks and budget before the first order. It can pay off over three to five years if you really change components or run several storefronts. The main cost driver is not licences but integration and operations: every added service brings its own contract, release cycle and failure mode.

What changed for on-premise customers after 31 July 2026?

Mainstream maintenance for SAP Commerce on-premise (last release 2205) ended on 31 July 2026; only customer-specific maintenance is available now. A move to SAP Commerce Cloud keeps existing business logic and data models, while a full composable rebuild means re-implementing them. A common middle path is Commerce Cloud as the core with a decoupled frontend.