Accelerator to Composable Storefront: A Practical Migration Guide

Migrating from Accelerator to SAP Composable Storefront is not a version upgrade. It is a frontend re-platforming: from server-side JSP templates to a headless Angular application. The backend stays; the frontend is rebuilt. Teams that plan it as an upgrade underestimate the effort, and we say that up front because it is the most common mistake we see.

There is also a date now. SAP deprecated the Accelerator UI templates with release 2205 and, according to its published plan, removes them from SAP Commerce Cloud in September 2027 (SAP KBA 3263872). A migration of three to six months that starts in autumn 2026 has enough room; one that starts in spring 2027 does not.

TL;DR: Moving from Accelerator (JSP) to SAP Composable Storefront (Angular, formerly Spartacus) takes three to six months for standard implementations and longer for B2B and multi-site setups. The backend and OCC APIs stay; the whole frontend is rebuilt. Audit your customisations first, close OCC API gaps early, configure server-side rendering from the start and run both storefronts in parallel before cutover. SAP plans to remove the Accelerator templates in September 2027.

Why Can’t You Just “Upgrade”?

It looks as if it should be simple: same platform, new frontend. It is not. Accelerator and Composable Storefront differ at every layer of the frontend: server-side JSP against client-side Angular, direct calls into the model against OCC REST APIs, server sessions against NgRx state. There is no automated migration tool, because at the frontend level the two architectures share nothing. SAP’s own guidance on the move (KBA 3285373) and the Composable Storefront documentation describe the target; the path there is project work.

Whether Composable Storefront is the right target at all, or a custom headless frontend fits better, is a separate decision. We cover it in do you need SAP Composable Storefront? and in Composable Storefront vs React/Next.js.

What’s the Migration Process?

Ten steps. Mobile performance belongs in them from the start, not in a follow-up project.

Step 1: Audit the Accelerator customisations. Catalogue every custom JSP tag, controller, stylesheet and JavaScript file. It is unglamorous work, and it prevents surprises: on one project, this week of auditing turned up 47 custom components nobody had documented.

Step 2: Map them to Composable Storefront equivalents. Most standard components have a counterpart. Custom components need an Angular rebuild.

Step 3: Check OCC API coverage. Features that call services directly may need new OCC endpoints. This catches teams off guard more often than anything else.

Step 4: Set up the Composable Storefront. Scaffold the application, configure the backend connection and set up the CMS mappings.

Step 5: Rebuild the custom components. Prioritise by business impact: checkout customisations and B2B features first.

Step 6: Migrate the CMS content. Remap content slots and components from Accelerator to Composable Storefront mappings.

Step 7: Configure server-side rendering. Set up SSR for search engines and performance. A commerce storefront without SSR is hard to index and slow on first load, so do not skip this.

Step 8: Theme and brand. Apply the visual design: style overrides, typography, colours.

Step 9: Test in parallel. Run both storefronts against the same backend and compare functionality and conversion for two to four weeks. Our most successful migrations all used this parallel run. It costs time, and it is where you catch what QA misses.

Step 10: Cut over. Redirect traffic, monitor closely for two weeks and keep Accelerator available as a fallback.

What Are Realistic Timelines?

• Standard B2C (10 to 20 custom components): 3 to 4 months
• Heavy customisation (30 or more components): 4 to 6 months
• B2B storefront: 5 to 7 months
• Multi-site, multi-language: 6 to 9 months

The biggest variable is the number of custom components, and most teams underestimate theirs. Audit first, then plan. If the storefront move is part of a larger migration off SAP Commerce on-premise, our migration checklist shows how the workstreams fit together.

What Are the Most Common Migration Mistakes?

Trying to replicate Accelerator exactly. Use the migration to simplify. One client insisted on pixel-perfect parity with their Accelerator storefront; three months in, they realised that half of those design decisions had been mistakes the first time round.

Migrating everything at once. Move section by section: product listing, then cart and checkout, then B2B. It looks slower on paper and is faster in practice, because problems surface while their impact is still small.

Ignoring OCC API gaps. Custom features that call services directly need backend work. Spot them early, or they block the frontend team for weeks.

Underestimating the Angular learning curve. Plan four to eight weeks of training or bring in Angular developers. JSP skills do not transfer to this world.

If you are looking for a partner for the move, our overview of the best SAP Commerce Cloud partners in Switzerland lists the criteria that matter, and our SAP Commerce Cloud page shows how we work. Talk to us about your storefront.

FAQ

Until when can we keep the Accelerator storefront?

SAP deprecated the Accelerator UI templates and add-ons with release 2205. According to SAP’s published plan (KBA 3263872), they are removed from SAP Commerce Cloud in September 2027, with an extended adoption period ending in September 2028. Storefronts keep running until then, but without enhancements, so plan the move now.

Can we run both storefronts at the same time?

Yes. Accelerator and Composable Storefront can run against the same Commerce Cloud backend. You can route traffic by URL, domain or percentage, which lets you migrate section by section and compare conversion before the final cutover.

Do our Accelerator customisations carry over?

The frontend code does not: JSP templates, tags, controllers and JavaScript are rebuilt as Angular components. Business logic in the backend stays and is reached through the OCC REST APIs; features that call services directly from the storefront need new OCC endpoints.

How do we protect SEO during the migration?

Keep URL structures where possible and set up 301 redirects where they change. Configure server-side rendering from the start, because a client-side-only Angular storefront is hard to index. Monitor Google Search Console closely during and after the switch.

Should we upgrade Commerce Cloud and migrate the storefront at the same time?

Preferably not. Upgrade the backend first, validate stability, then migrate the storefront. Doing both at once doubles the risk and makes it very hard to tell what broke when something goes wrong.