Salesforce Storefront Next: The Complete 2026 Guide

You inherit a B2C Commerce storefront built on SFRA. The lead developer left eight months ago, the cartridge stack has eleven layers of overrides, and a one-line copy change took your team two days because nobody could find which ISML template actually rendered the PDP header. You post a job for a new SFRA developer and get four applicants in three weeks. Two of them have never touched ISML.

This is the situation Storefront Next was built to end. It is the fourth generation of Salesforce B2C storefront architecture, going generally available in the Summer '26 release, and it throws out the parts of SFRA that made hiring painful while keeping the runtime that made it scale.

A quick history of how we got here

Salesforce B2C Commerce, which most people still call Demandware or SFCC out of habit, has cycled through four storefront generations.

SiteGenesis arrived in the early 2010s. It was the original reference application, and it was a sprawling mess of controllers and pipelines that taught a generation of developers what not to do.

SFRA, the Storefront Reference Architecture, landed in 2018 as the cleaner successor. It used ISML templates and a Demandware-flavored MVC pattern, and for years it was the default. The problem is that ISML is a proprietary templating language, and the talent pool for it has been shrinking since roughly 2022. You are competing for a small number of specialists, and the cost shows up on every invoice.

Composable Storefront, also known as PWA Kit, came in 2021. It was React-based, which sounded like the right call. In practice it was client-heavy and hook-driven, which means it shipped large JavaScript bundles to the browser and asked the browser to do most of the rendering work. Core Web Vitals suffered. SEO teams complained. The architecture was modern on paper and slow in production.

Storefront Next is the 2026 answer, and it is the first generation that feels like it was designed by people who had actually run all three previous versions in anger.

What Storefront Next actually is

Storefront Next is a React storefront framework that renders server-first and runs on the same Managed Runtime that hosted PWA Kit. The stack is deliberately mainstream, which is the whole point. A developer who has never seen a Salesforce product should be able to read the codebase and recognize almost everything in it.

Here is the stack:

• React 19 with React Router 7 in framework mode, configured for server-first SSR.
• Vite for builds and Vitest for tests, replacing the old webpack and Jest setup that PWA Kit shipped with.
• A TypeScript-first codebase, not TypeScript bolted on as an afterthought.
• Tailwind CSS 4 for styling.
• shadcn/ui for components, which means Radix accessibility patterns and CVA-based variants.
• Managed Runtime as the host, the same scalable serverless Node.js environment PWA Kit used.
• SCAPI, the Shopper Commerce API, for product, cart, checkout, and order data.

If you have built a modern React app in the last two years, none of this is exotic. That is the design goal stated plainly. The framework stops being a specialist skill and becomes a thing any competent React developer can pick up.

Why server-first is the headline change

The single most important difference between Storefront Next and PWA Kit is the rendering model, and it is worth being specific about why.

PWA Kit rendered on the client. The server sent a thin HTML shell plus a large bundle of JavaScript, and the browser then fetched data and assembled the page. On a fast laptop on office wifi, fine. On a mid-range phone on a spotty connection, which is what a large share of your shoppers actually use, the experience degraded. The browser had to download, parse, and execute a lot of JavaScript before anyone saw a product.

React Router 7 in framework mode renders the page on the server for the initial load. The shopper receives real HTML with content already in it. The data flow is loader-driven, so each route declares what it needs and the framework fetches it server-side before rendering. You get middleware chains for cross-cutting concerns and streaming with Suspense for progressive rendering of slower sections.

The practical results are the ones your stakeholders care about. Better Lighthouse scores. Better SEO, because crawlers see fully rendered content instead of an empty shell. Faster perceived page load, because the first paint contains the actual product instead of a spinner. You will notice the difference the first time you run a Lighthouse audit on a PDP and the performance number is not embarrassing.

Commerce Apps and the end of cartridge surgery

If you have spent any time in SFRA, the cartridge stack is where your scars come from. Customizations were layered as cartridges, each one overriding files from the cartridge below it, and the order of the stack determined what actually ran. Debugging meant tracing a single template through five or six override layers to find the one that won. Installing a third-party solution meant dropping its cartridges into the path and praying the override order did not break something else.

Storefront Next replaces that model with a framework called Commerce Apps. It is a plug-and-play packaging system. ISV solutions and native Salesforce features install as unified packages, and setup happens through clicks directly in Business Manager. No file-system surgery. No re-ordering a cartridge path and redeploying to find out whether you guessed right.

This matters for two groups. Admins get a setup experience that does not require a developer for routine installs. Architects get a dependency model that is legible, because you can look at the installed apps in Business Manager and actually know what is running.

The AI-first tooling

Storefront Next ships alongside a set of AI capabilities that change how the storefront gets built and operated. These are not bolt-on chat widgets. They sit in your development workflow.

The B2C DX MCP Server

The B2C DX MCP Server goes GA in Summer '26, and it is the piece most developers will feel immediately. MCP, the Model Context Protocol, is the standard that lets an AI assistant talk to an external system through defined tools. This server connects assistants like Claude, Cursor, and GitHub Copilot directly to your B2C Commerce environment.

What that buys you is real action, not autocomplete. From inside your IDE, in natural language, an AI assistant can deploy cartridges, create SCAPI endpoints, and push to Managed Runtime. You describe the endpoint you want and the assistant scaffolds and deploys it. The grunt work of remembering exact CLI flags and config shapes moves to the model.

A word of caution here, because it should be obvious and somehow never is. An assistant that can deploy to your runtime can also deploy something wrong to your runtime. Treat these tools like a junior developer with commit access. Review before you ship, especially against anything that touches production.

Figma-to-Component

The Figma-to-Component toolset converts design files into Storefront Next components directly. A designer hands you a Figma frame, and instead of a developer rebuilding it by hand from a screenshot, the tool generates the component scaffold. It does not eliminate the developer, and anyone who tells you it does has not used it. It removes the tedious first pass of translating boxes and spacing into JSX.

Agentforce on the storefront

Agentforce agents can operate against the storefront through SCAPI. An agent can query the product catalog, manage promotions, and handle customer service interactions. The same API that powers the storefront UI powers the agent, which means the agent sees the same prices, inventory, and promotions a shopper does. For commerce teams already building with Agentforce, this closes the gap between the conversational layer and the catalog.

Migration: the decision tree

The question on every commerce team's roadmap right now is whether to move, and from where. The answer depends on what you are running today.

If you are on SFRA

Skip PWA Kit entirely. Do not migrate SFRA to Composable Storefront as a stepping stone. Go straight to Storefront Next.

The timeline is comparable to the old SiteGenesis-to-SFRA migrations, which is to say roughly twelve weeks for a mid-sized catalog. That is a real project, not a weekend. Budget for it like a replatform, because it is one. The upside is that you land on the architecture Salesforce is actively investing in, with a hiring pool that includes any React developer instead of the dwindling set of ISML specialists.

If you are on PWA Kit

Salesforce has published a documented migration path from PWA Kit to Storefront Next. The two main differences you will manage are the rendering model and the tooling.

The rendering model shifts from client-first to server-first, which means rethinking where data fetching happens. Logic that lived in client-side hooks moves into route loaders. The tooling shifts from webpack to Vite and from Jest to Vitest. Your build config and test setup get rewritten, but the underlying React knowledge carries over. This is a lighter lift than the SFRA migration because you are already in React and already on Managed Runtime.

Is SFRA dead?

No, and anyone telling you it is shut off next quarter is selling something. SFRA is not deprecated. It still runs and Salesforce still supports it.

What has changed is where the investment goes. Salesforce's primary product investment has moved to Storefront Next, and new features land there first. Over time, staying on SFRA means watching the gap between your platform and the current one widen. You are not on a sinking ship. You are on a ship that has stopped getting upgrades.

When you should stay on SFRA, for now

There are legitimate reasons to wait, and pretending otherwise would be dishonest.

Stay if your storefront is already six months out from a major redesign. Migrating twice in a year is a waste of money and goodwill. Fold the platform change into the redesign instead.

Stay if you have deep, complex ISML customizations and no React team to speak of. A migration with no one who can read the target stack is how twelve-week projects become nine-month ones.

But be honest with yourself about the hiring math. If you are recruiting new developers in 2026, the ISML talent pool is genuinely shrinking, and it is not coming back. Every year you stay, the cost and difficulty of staffing SFRA work goes up. That is not a Salesforce marketing line. It is what the job market looks like right now.

The deployment difference you will feel daily

One practical detail deserves its own mention because it changes the rhythm of a workday. SFRA deployments are slow. A full push can run from several minutes into hours depending on what you are uploading and how the code version replication behaves. You learn to deploy and then go do something else.

Storefront Next deployments measure in tens of seconds. Not minutes. Not hours. You make a change, deploy, and look at it. The feedback loop tightens to the point where you actually want to iterate, and tight feedback loops are how good storefronts get built.

What to do this week

Pick the one action that matches where you are.

If you are on SFRA, spin up a sandbox and stand up the Storefront Next starter on it. Do not plan the full migration yet. Just get the stack running so your team can see the deployment speed and the developer experience firsthand. The decision gets easier once people have touched it.

If you are on PWA Kit, read the official PWA Kit to Storefront Next migration guide end to end, then take one route in your app and port it. The product detail page is a good candidate because it exercises loaders, SCAPI calls, and SSR all at once. One ported route tells you more about your migration effort than any estimate.

If you are still on SiteGenesis in 2026, the polite thing to say is that this guide is the least of your concerns. Start the conversation about replatforming today, and plan to land on Storefront Next rather than SFRA so you only do this once.

About the Author

Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.