Salesforce Commerce Cloud Frontend Options in 2026: SFRA, PWA Kit, Storefront Next, or an FMP Decouple
- 1.The 2026 decision point for SFCC merchants
- 2.SFRA: the incumbent, still shipping
- 3.PWA Kit: composable, but still Salesforce-owned
- 4.Storefront Next: Salesforce's new answer (GA 2026-07-06)
- 5.The FMP-decouple path: a composable frontend on top of SFCC
- 6.Options at a glance
- 7.What this means for SFCC merchants
- 8.FAQ
Salesforce Commerce Cloud merchants have not had a real frontend decision to make for years. SFRA was the default, PWA Kit was the composable upgrade path for teams with a React team on staff, and everything else was a custom build. That changed on July 6, 2026, when Storefront Next went GA. SFCC merchants now have four distinct paths for the presentation layer, and each one has a different answer to the questions that actually matter: how much effort, how much lock-in, how ready the storefront is for AI agents, and how fast you can change your mind later.
This is a decision guide, not a verdict. SFRA, PWA Kit, and Storefront Next are all Salesforce-native choices with real trade-offs. The fourth path, decoupling the frontend onto a separate Frontend Management Platform (FMP) while SFCC stays your commerce backend, is a complementary option worth understanding alongside the other three, not a replacement pitch.
The 2026 decision point for SFCC merchants
If your storefront runs on SFRA today, you are not forced to move. But three things changed the calculus this year: Storefront Next's GA, continued Managed Runtime cost pressure on PWA Kit deployments, and rising demand from marketing teams for launch speed that server-rendered ISML templates were never built for. Add agent-readiness (structured data, schema.org, API surfaces that AI shopping agents can parse) as a fourth pressure, and most SFCC merchants now have a real architecture decision on the table for the first time since PWA Kit launched.
SFRA: the incumbent, still shipping
SFRA (Storefront Reference Architecture) is server-rendered, ISML-templated, and deeply familiar to the Salesforce implementation partner ecosystem. It is stable, well-documented, and cheap to staff. What it is not: fast to iterate on. Every landing page or campaign variant runs through a developer ticket and an ISML template change. For merchants with low frontend ambition and high stability requirements, SFRA remains a defensible choice in 2026. For anyone chasing Core Web Vitals or weekly campaign cadence, it is the ceiling, not the floor.
PWA Kit: composable, but still Salesforce-owned
PWA Kit moved SFCC merchants to a React-based storefront running on Salesforce's Managed Runtime. It is a real step up in developer experience over SFRA, and it introduced merchants to component-based frontend thinking years before Storefront Next existed. The catch: Managed Runtime is still a Salesforce-controlled hosting layer, release cadence is tied to Salesforce's train, and the composability is bounded by what the Commerce API and Managed Runtime expose. Teams that adopted PWA Kit early are asking a fair question in 2026: was this composable, or just React inside a new box.
Storefront Next: Salesforce's new answer (GA 2026-07-06)
Storefront Next is Salesforce's most direct answer yet to the PWA Kit friction points, and worth piloting for merchants who want to stay fully within the Salesforce stack. As of this writing it has been generally available for under three weeks, so production reference cases, migration tooling maturity, and long-term roadmap commitments are still thin. It reduces some of the Managed Runtime operational overhead PWA Kit carried, but it remains a single-vendor stack: your frontend release cycle, hosting choices, and extensibility ceiling are still set by Salesforce. That is a reasonable trade for merchants who value one vendor relationship over frontend independence. It is worth testing on a non-critical storefront section before a full commitment, simply because the platform is new.
The FMP-decouple path: a composable frontend on top of SFCC
The fourth option does not touch your SFCC backend at all. You keep Commerce API/Open Commerce API as your commerce logic, order management, and pricing engine, and you decouple the presentation layer onto a dedicated headless frontend for Salesforce Commerce Cloud that speaks to SFCC via its API rather than living inside Salesforce's hosting and release model. This is the model behind our Agentic Frontend Management Platform: the frontend becomes independently deployable, independently agent-ready, and independently upgradable, while SFCC keeps doing what it does well as a commerce backend. Behind that decoupling sits Composability & Orchestration: the data-orchestration layer that keeps SFCC's Commerce API, PIM, and OMS in sync with the new frontend without custom glue code. It is not a rip-and-replace of Salesforce. It is a way to decouple the two release cycles that Storefront Next and PWA Kit keep bundled together.
Options at a glance
- Effort to adopt. SFRA: Low, already running. PWA Kit: Medium-high, React rebuild. Storefront Next: Medium, new platform, GA Jul 2026. FMP Decouple: Medium, frontend rebuild, backend untouched.
- Vendor lock-in. SFRA: High, ISML + Salesforce hosting. PWA Kit: Medium-high, Managed Runtime required. Storefront Next: High, single-vendor stack. FMP Decouple: Low, backend-agnostic frontend layer.
- Agent-readiness. SFRA: Low, limited structured-data control. PWA Kit: Medium. Storefront Next: Unclear, too new to verify. FMP Decouple: High, built API-first with schema.org support.
- Who owns the release cycle. SFRA: Salesforce release train + SI partner. PWA Kit: Salesforce Managed Runtime. Storefront Next: Salesforce roadmap. FMP Decouple: Merchant + chosen frontend vendor.
- Time to change course later. SFRA: Slow, tightly coupled. PWA Kit: Medium. Storefront Next: Unknown yet. FMP Decouple: Fast, frontend and backend decoupled.
What this means for SFCC merchants
- If you are stable on SFRA with low frontend ambition, there is no urgent reason to move in 2026. Revisit when campaign velocity or Core Web Vitals become a business problem, not before.
- If you are on PWA Kit and frustrated by Managed Runtime cost or release friction, evaluate Storefront Next and an FMP decouple side by side before committing to either.
- If you are evaluating Storefront Next, pilot it on one storefront section first. Three weeks of GA history is not enough to bet a full replatform on.
- If agent-readiness (structured product data, schema.org, API-first architecture for AI shopping agents) is a 2026-2027 priority, weigh that explicitly. It is the dimension where the four options differ most.
- If you want to keep SFCC as your commerce backend indefinitely but decouple frontend release cycles from Salesforce's roadmap, the FMP path is built for exactly that constraint.
FAQ
Is Storefront Next a replacement for PWA Kit? Salesforce positions it as the newer frontend option for SFCC, but PWA Kit is not deprecated as of this writing. Merchants on PWA Kit today can stay there; new builds are the more natural fit for evaluating Storefront Next first.
Do we have to migrate off SFCC to use a Frontend Management Platform? No. The FMP-decouple path keeps SFCC as your commerce backend via its Commerce API. Only the presentation layer moves to a separate, independently deployable frontend.
How mature is Storefront Next right now? It went GA on July 6, 2026. At three weeks old, expect thin third-party tooling, limited public migration case studies, and a still-evolving roadmap. Treat it as a strong pilot candidate, not yet a default choice for a full replatform.
Which option is fastest to change later if we pick wrong? An FMP decouple, because the frontend and backend release cycles are already separated. SFRA is the slowest to change because ISML templates and hosting are tightly coupled to the Salesforce release train.