Storefront Strategy After the Accelerator: Your Options and the Clock

For a decade, "which storefront?" was a genuine multiple-choice question on SAP Commerce projects: accelerator templates, industry accelerators, the young Spartacus, or something custom. That era is over, and the question has become "which way off the accelerator, and by when?" This guide replaces two CX Works pieces from the multiple-choice era with the decision as it actually stands now, including the dates that turn strategy into scheduling.

The Facts That Frame Everything#

• The accelerator UI is deprecated. The JSP-based accelerator storefronts (B2C, B2B, and their add-ons) were deprecated as of release 2205. Per SAP's published plan, the last 2211 update release containing the deprecated accelerator extensions ships in Q2 2027, and from Q3 2027 the update releases no longer include them.
• The OCC template extensions are sunset on the same schedule. The old ycommercewebservices-style template extensions and their add-ons go with the accelerator; the maintained OCC surface is the standard commercewebservices API.
• Deprecated does not mean dead, yet. Existing accelerator storefronts keep working; what stops is enhancements, and eventually the extensions themselves in new update releases. A team that never adopts an update release past Q2 2027 can technically keep running, while giving up the security patches and the JDK/Spring currency that staying supported is all about. That is not a strategy; it is a slow leak.
• Composable storefront is SAP's designated path: the Angular-based, OCC-driven, server-side-rendered frontend that grew out of Project Spartacus. One licensing fact the old articles predate: the actively developed composable storefront is no longer the open-source Spartacus. Since version 5.0 it ships as licensed libraries for SAP Commerce Cloud customers through SAP's repository-based shipment channel; the open-source Spartacus repository remains public but frozen at the 4.x line. The "it's open source" reason to choose it is obsolete; the architectural reasons survive.

Why the Decoupling Argument Won#

Whatever option you pick below, it will be headless, and it is worth being clear-eyed about why SAP retired the coupled model, because these are also the criteria for judging the alternatives:

1. Independent release cycles. A JSP storefront ships inside the platform build: every button-color change rides a 40-minute CCv2 build and a platform deployment. A decoupled frontend deploys in minutes, all day long, without touching commerce. Teams routinely go from weekly storefront releases to daily ones on this change alone.
2. Separate teams, separate skills. Frontend engineering hired in this decade works in TypeScript and a component framework, not JSP tags. The coupled model forced full-stack unicorns or miserable frontend developers; decoupling lets each team be ordinary experts.
3. Upgrades shrink. The storefront is the most customized layer of any commerce project, and in the coupled model all of that customization sat inside the platform upgrade's blast radius. Move it behind OCC, and platform upgrades stop touching your UI (the OCC contract, not the template code, becomes the compatibility surface; harden it accordingly, as the OCC contracts guide on this site describes).
4. The platform automation supports it natively. CCv2 builds and deploys JavaScript storefronts on dedicated nodes from the same repository (js-storefront/), with server-side rendering supported for SEO. You are not buying infrastructure complexity with the decoupling; the platform already carries it.

The Options, Honestly#

Composable storefront#

What it is: SAP's Angular storefront libraries: CMS-driven pages (SmartEdit works, with preview), B2C and B2B feature coverage that long ago reached and passed accelerator parity, SSR, and an update cadence aligned with the platform.

Why it is the default answer: it is the only frontend SAP ships features for, it consumes the CMS so business users keep their tooling, its release notes and compatibility matrix are maintained against the platform's, and the ecosystem (partners, documentation, trained developers) is the largest of any option. The extension model matured with the 5.x/6.x line: you build an Angular app that depends on the libraries, never a fork, and you extend through outlets, configurable modules, and dependency injection: which is what keeps upgrades cheap.

The honest costs: it is Angular, and a frontend team standardized on React or Vue will not enjoy the news; it is licensed with the platform rather than open source; and deep visual divergence from its component structure costs real effort (though far less than the JSP equivalent ever did).

Custom headless storefront#

What it is: your own frontend (Next.js, Nuxt, Remix, native apps) against the OCC REST APIs, possibly assembled with a commercial frontend-as-a-service layer.

When it is right: the frontend is your differentiator and you have the team to own one; you are multi-framework by policy; or you are composing commerce into a larger digital experience where the storefront shell is not commerce-shaped at all.

The honest costs: you own everything composable gives you for free: CMS integration (SmartEdit support in a custom frontend is genuine work, and many custom builds end up pairing a headless CMS with commerce instead), B2B flows (quotes, org management, and checkout variants are years of edge cases), SSR and SEO plumbing, and permanent OCC contract maintenance. The industry's scar tissue here is uniform: teams that budgeted "a storefront" and discovered they had budgeted a third of one.

Staying on the accelerator (the managed decline)#

Legitimate only as an explicitly temporary state: a platform being replaced entirely in eighteen months, or a B2B site with a captive user base and near-zero frontend change. If that is you, write down the exit date, stop investing in the JSP layer beyond keep-the-lights-on, and understand the deadline math: staying past the removal means freezing your update-release adoption, which collides directly with the platform's security and framework-currency expectations. For everyone else, the accelerator is not on the options list anymore; it is the thing the options list replaces.

A word on industry accelerators#

The industry accelerators (travel, telco, financial services) were always separate artifacts with their own compatibility matrices, and their storefront layers share the accelerator technology and its fate. If you run one, your migration includes re-sourcing the industry-specific functionality (services and data model usually survive; the UI does not) and the compatibility check belongs at the top of your assessment, not the middle.

Choosing, By Situation#

Two closing disciplines regardless of the branch taken. First, put the decision on the same calendar as your update-release plan: the Q2/Q3 2027 boundary is a platform-currency deadline, and frontend migrations reliably take longer than their first estimate. Second, treat OCC as the product boundary from day one of whatever you build: versioned contracts, regression fixtures, named owners per surface. Every option above lives or dies on that boundary, and it is the one investment that pays out identically no matter which storefront wins.