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, with no removal date. The JSP-based accelerator storefronts (B2C, B2B, and their add-ons) were deprecated as of release 2205. SAP announced in 2025 that the accelerator UI template extensions would leave the September 2027 update release, then withdrew that on June 25, 2026: they will not be removed from a future update release, and there is no fixed de-release date. They still get no new features.
• The AddOn-based OCC extensions keep their removal dates. SAP removes the industry OCC and template add-ons in the Q3 2026 update release, the core OCC add-ons in Q1 2027, and the OCC template extensions (ycommercewebservices and its kind) in Q3 2027. The maintained OCC surface is the standard commercewebservices API, so a storefront on the old OCC stack has a dated migration even though the JSP layer does not.
• Deprecated does not mean dead. Existing accelerator storefronts keep working and keep shipping in update releases; what stops is enhancements. Every new SAP storefront capability lands in composable storefront, so the gap widens with each quarterly release, and every framework update (the next Java and Spring jump comes about two years after the last) has to carry the JSP layer across again. 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, with server-side rendering supported for SEO. The whole declaration is js-storefront/manifest.json:

   json

   {
     "applications": [
       {
         "name": "storefront",
         "path": "storefront",
         "enabledRepositories": ["spartacus-6-cdn"]
       }
     ]
   }
   

   Copy

   Platform customization stays under core-customize/, the frontend under js-storefront/, and the build produces separate artifacts on separate nodes. You are not buying infrastructure complexity with the decoupling; the platform already carries it (the CCv2 runtime configuration guide covers the manifest's sharp edges).

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 cost math: the JSP layer gets no new features, every framework update has to carry it across again, and any dependency on the AddOn-based OCC extensions must be gone before they leave the update releases between Q3 2026 and Q3 2027. 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 OCC add-on removals between Q3 2026 and Q3 2027 are dated, the next framework update will be too, 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.