Reading time: 6 min | Series: Part 1 of 3
SAP Commerce Accelerator end of life is scheduled across 2027 and 2028, and it affects every storefront still built on the legacy JSP-based Accelerator templates, whether you run SAP Commerce on-premise or in SAP Commerce Cloud (the platform formerly known as Hybris). Your front end will be rebuilt whether you plan for it or not, and the decision that matters is what you rebuild it on top of.
This is the first of three posts. Part 1 answers the questions we hear most about the end-of-life dates. Part 2 covers SAP Commerce Cloud alternatives and how to choose. Part 3 covers the cost and timeline of an Accelerator migration. For the wider picture, including the SAP ECC support deadline and why SAP can stay in your system of record, see our earlier post, When to Migrate Off SAP Commerce Cloud: Options and Guide.
SAP has published a three-step schedule for deleting the deprecated Accelerator UI extensions and add-ons:
Source: SAP KBA 3263872 and the SAP Commerce Cloud deprecation status page.
The Accelerator is SAP's JSP-based, server-rendered storefront. It shipped for over a decade as the standard way to launch a multi-site, multi-currency store on SAP Commerce, and most implementations were built on it. Its replacement, SAP Composable Storefront (formerly Spartacus), is an Angular-based headless storefront that talks to SAP Commerce over REST APIs called OCC.
Both, in sequence. SAP deprecated the Accelerator UI extensions and add-ons in the 2205 release (May 2022). Deprecated meant the code stayed in the product, so almost nobody moved. The schedule above is the deletion. Q3 2027 is when the code leaves the product.
Both. SAP Commerce on-premise reached the end of mainstream maintenance on July 31, 2026, and that date has passed. The Accelerator schedule is a separate deadline that reaches cloud customers too. If you already moved to Commerce Cloud and filed "platform migration" under done, take another look at your backlog. Most migrated storefronts are still Accelerator-based, and they fall under the Q3 2027 date like everyone else.
The scope runs wider than the storefront templates:
Your site keeps serving pages. What ends is security patches, bug fixes, new features, and the ability to deploy new builds on supported releases. At that point you are running an unmaintained fork of a storefront in production, with a payment form on it. Your security team will find out eventually, and the conversation goes better if you start it.
SAP's supported replacement is Composable Storefront, and it is the lowest-friction path if you are keeping SAP Commerce and your team is comfortable with Angular. Other routes exist: a custom head built on OCC APIs, a third-party storefront framework, or a full replatform. Part 2 compares the options.
Rebuilding an Accelerator storefront on Composable Storefront is not a port. Nobody's Accelerator is vanilla. Ten-plus years of enterprise life produce custom cart workflows, checkout adaptations, product configurators, punchout, and a dozen integrations that were only ever meant to be temporary. Rebuilding all of that in Angular is rarely a one-to-one exercise. You are rewriting the front end from scratch, then re-earning your Core Web Vitals, because server-rendered JSP and a single-page Angular app fail in completely different ways.
The expensive part of a replatform is therefore already on your roadmap. The usual argument for staying put is that migrating costs too much, and that argument carries much less weight when the front-end rebuild, integration re-testing, content re-modeling, and QA cycle all happen regardless. The comparison you are really making is a rebuild on the same backend against a rebuild on a backend that costs less to run for the next decade. Some organizations will run that comparison and stay on SAP, which is a fine outcome when someone decided it on purpose.
Authoring is where much of the day-to-day pain sits. With the WCMS Cockpit gone and SmartEdit as the remaining editing environment, merchandising teams absorb a lot of the friction in the SAP Commerce stack. A decoupled front end paired with a third-party CMS addresses that directly, and it works with whatever commerce engine sits behind the API. That lets you settle the CMS question first and take the backend question afterward.
The Accelerator deadline looks like a technical debt problem and works as a strategy window that closes in 2027.
Jared Shaner, VP Strategic Accounts
The partner bench adds its own pressure. Every SAP Commerce customer is being pushed through the same door on the same schedule, and the pool of experienced Composable Storefront implementers will not grow to match demand. Teams that start in 2026 get good people at reasonable rates. Teams that start in 2027 get whoever is left, at whatever they are charging by then.
Write down which Accelerator customizations carry real business value, which are workarounds you would gladly drop, and who in the business depends on the authoring tools being replaced. That list shapes every decision that follows. Then move to Part 2 to compare your options. If your team wants to work through the SAP side first, our team is here.
Are you leading the way or falling behind?
Learn where your B2B business stands compared to industry competitors.
Request a Proposal
