The $500k storefront you already paid for once

Because it isn't an upgrade. SAP's Accelerator storefront is being retired, and Composable Storefront is a ground-up rewrite in a different stack, not a version bump. The presentation code your integrator already built, and you already paid for, gets rebuilt from zero. Vendor implementation guidance puts a single B2C Composable build at $350K-$500K in year one, on top of $80K-$250K just to customise it. You are re-buying a storefront you already own.

What are you actually re-buying?

The two storefronts share a name and a backend, and almost nothing else. The Accelerator is a set of server-rendered JSP templates you fork and customise. Composable Storefront, the productised release of the Spartacus project, is a decoupled Angular application that talks to SAP Commerce over its web services. Moving between them is not a reskin. Every template, custom component, checkout tweak and promotion layout your team hardened over the years is re-implemented in a different language against a different rendering model. The backend logic survives; the entire front end does not.

That is why the bill looks like a new build: it is one. As of 2025, vendor and SI implementation guidance lists $80K-$250K to customise a Composable Storefront, scaling with how far you deviate from the standard build, and $350K-$500K for year one on a minimal single B2C storefront with standard checkout, a basic catalog and one ERP integration. The timelines read like a greenfield project too: 4-8 months for a mid-market single storefront, and eight to eighteen for an enterprise multi-country, multi-brand rollout. None of that spend buys a capability you did not already have live on the Accelerator.

Where does the money actually go?

It helps to put the two side by side. The left column is what you have running today and have already paid for. The right column is what the re-platform asks you to fund a second time.

Even the vendor-friendly framing concedes the scale. The same guidance notes that starting from the Composable base saves $100K-$200K against building a headless front end from scratch, which is just another way of saying the front-end rebuild is a six-figure exercise before you have added a single thing a customer will ever notice.

What does the feature-parity gap cost you?

The rebuild would be easier to swallow if it were a straight port. It is not. The SAP CX implementer Cloudflight documents that Composable Storefront does not reach full parity with the Accelerators, with the gaps concentrated in personalization, promotions, loyalty programs and B2B features. Those are not edge cases. They are the parts of a storefront most directly wired to revenue and to the promotions calendar your commercial team actually runs each quarter.

The loyalty behaviour you had configured, already an awkward thing to carry on the books given the deferred-revenue gap loyalty programs open on the balance sheet, now has to be rebuilt or bridged rather than carried across. And if you serve both B2C and B2B from one Commerce instance, note that a single Composable Storefront cannot front both at once: each store needs its own storefront instance, so the doubling shows up in build, hosting and headcount, not just in the first invoice.

Why do you keep paying for the same thing?

Because the storefront was never yours to keep. It lives inside a vendor's product line, on that product's lifecycle, and when the vendor retires the old template model the clock on your original investment runs out with it. The re-buy is not a bug in any one release; it is the shape of the arrangement. Every few years an end-of-life notice quietly converts a working, paid-for capability back into a capital request, and that request lands on the desk of the same vendor that issued the notice.

It is the same class of hidden line item as the Salesforce storage bill nobody models upfront, or the way SAP has always expected you to bring your own Z-tables for returnables and empties: costs that are invisible at signing and unavoidable later. What makes a storefront EOL sting more is the size and the timing. It is a single, lumpy, high-six-figure re-implementation that arrives on the vendor's schedule rather than yours, usually in the same year finance had earmarked the budget for something that would have grown the business.

The way out is not a smoother migration project; it is a different ownership boundary. When the storefront is your own code sitting against a stable commerce API, presentation decoupled from the engine and running on your own event bus, a vendor's template EOL becomes a dependency upgrade you schedule at your convenience, not a storefront you re-purchase. That is the entire argument for an architecture where the storefront is code you own rather than a licensed template you rent.

The next end-of-life date is already sitting in a roadmap slide somewhere, whether or not it carries a number yet. Teams that hold the storefront as owned code will step over it as routine maintenance; everyone else will reopen the capital request they just closed, re-argue the same business case, and pay something close to what a new storefront costs for the storefront they already have. The only decision still open is which of those two positions you want to be standing in when the notice lands.