Salesforce B2C Commerce Cloud is a cloud commerce platform: retailers run their storefronts on it across mobile, social, and in-store channels, with personalisation and shopper analytics built in.
But choosing SFCC is only step one. There’s a second big decision to make: on what architecture will you build your channels? When you’re introduced to Salesforce B2C Commerce Cloud, you’ll hear terms such as SiteGenesis, SFRA, and (more recently) PWA. But what are the differences? What should you watch out for?
Timeline
Here’s how storefront architecture on Salesforce B2C Commerce Cloud has moved over the years:

SiteGenesis

Let us start with the oldest (and least exciting option): SiteGenesis. If anyone still suggests that you start your journey with SiteGenesis, ask them why.
Why would I say this, even though minor updates are still happening to it? Looking at the timeline above, it is clear that newer options are available. And why these options are better suited for new projects should become clear as you continue to read this article.
It’s the old way of doing things (for SFCC)
The biggest reason not to use SiteGenesis, or to migrate away from it, is that it relies on outdated techniques and older frameworks.
An example is the SCSS, which uses “responsive design.” Not saying that this is a bad thing, as it was “the” way to do it in 2014. But this was replaced by a mobile-first methodology a few years later (which MFRA is based on, but we’ll get to that later!)
Responsive Design still has a place, especially if most of your visitors are on desktop rather than mobile. But for most merchants, mobile visitors outnumber desktop by a wide margin.
Third-party integrations
Salesforce B2C Commerce Cloud comes with a lot of features out-of-the-box. But it can’t do everything, so it depends on third parties to create “cartridges” that extend that base (payment providers, shipping providers, OMS, ERP, …).
Note
The above is also true for other platforms besides SFCC.
It’s no longer required to build for SiteGenesis; SFRA compatibility is enough. This shows that Salesforce wants to push new (and existing) clients away from using SiteGenesis.
Pipelines VS Controllers


Pipelines disappeared with MFRA. This is a legacy way of development within Salesforce B2C Commerce Cloud and has been replaced by JavaScript (controller-type) development.
It is time to migrate if you are still using SiteGenesis with pipelines in your project/site since new features will not be available in this framework.
Note
It’s also substantially harder to find developers who know how to work with pipelines, and pipeline-based development isn’t supported by the latest development tools.
M(S)FRA

This part of the article will cover both MFRA and SFRA as they are the same. You can see MFRA as the ALPHA/BETA version of SFRA or simply as a rebranding.
Around the time of Salesforce’s 2016 acquisition of Demandware, the platform saw an increased need for high-quality mobile experiences. SiteGenesis was not up for the task, so a new mobile-first foundation — known at the time as MFRA — was built using technologies such as Bootstrap, HTML5, and CSS3, making it much easier to create mobile experiences. It shipped publicly as SFRA in 2018.
These technologies also brought better storefront performance and UX along with them.
Best Practices
Salesforce studied SiteGenesis sites already running in production and used what worked to shape SFRA’s page designs and user flows.
Development & Updates
The base SFRA repository itself is frozen, but new features still ship for the platform — just as separate “cartridges” instead of changes to the base template.
That way, customers and partners only pull in the features they actually need, instead of ripping out unwanted code later.
Salesforce is also actively pushing customers towards SFRA, even though a newer headless architecture exists (PWA Kit). Why, when something newer is on the table? Keep reading.
Third-party integrations (M(S)FRA)
I will keep this short. Third parties are actively integrating with SFRA and updating their cartridges!
So choosing to go with SFRA now will be a good base for years to come. But be sure to continue reading, as PWA Kit itself may be attractive for your organisation!
PWA Kit & Managed Runtime

The PWA Kit was, for years, the newest addition to the SFCC family — and Salesforce still doesn’t market it as an SFRA replacement. You might be wondering why. There’s a good reason for that, and it hasn’t changed.
Headless solution
Unlike SiteGenesis and SFRA, the PWA Kit runs on a separate server. It connects to your Salesforce B2C Commerce Cloud environment through the SCAPI (a REST API) — not OCAPI, which is what this article originally said here. Earlier PWA Kit versions leaned on the OCAPI for a few gaps in the hooks system; by now, everything runs through SCAPI. OCAPI itself was officially deprecated in April 2026, so it is no longer part of this picture at all, headless or otherwise.
The rest of this site now groups PWA Kit and Managed Runtime under one label: the Composable Storefront. It isn’t a fourth product bolted onto this comparison — it’s shorthand for the same stack described in this section. If you’re coming from SiteGenesis or SFRA and wondering what skills carry over, this site has a dedicated walkthrough.
It is an entirely different type of architecture than the “monolithic” approach we are used to within SFCC.
But what does “headless” actually mean here? I cover it in this blog post and in this YouTube video on going headless with Salesforce B2C Commerce Cloud.
There’s also a podcast episode on the “Unofficial Salesforce Commerce Cloud Podcast” about headless and the PWA Kit.
Managed Runtime
When talking headless, you need to think about the hosting for your storefront. Salesforce provides hosting for the “body”, but what about the “head”?
No worries on that front! Salesforce provides Managed Runtime, included in the licence.
Managed Runtime provides the infrastructure to deploy, host, and monitor your PWA Kit storefront.
React.JS
The PWA Kit also brings a different working language: it’s built on React, a mainstream library rather than the “niche” flavour SFCC developers are used to.
It will be easier to find and educate developers in this setup.
Warning
Developers will still need to learn the SCAPI endpoints, which have a steady learning curve. OCAPI knowledge has not become useless overnight either. It stays relevant for older SFRA/SiteGenesis integrations still running in maintenance mode, at least until Salesforce switches those off for good.
Note
The PWA Kit is only responsible for the front end. Back-end integrations — importing products, prices, inventory — still need to be done the “old-fashioned” way.
Progressive Web Apps
I won’t dive deep into what Progressive Web Apps are — there’s plenty written about that already, and about how they compare to native apps.
There’s a podcast episode on this topic too!
Third-party integrations (PWA Kit & Managed Runtime)
That gap has narrowed since this article was first written, but it hasn’t closed. A handful of vendors now build packages aimed specifically at the PWA Kit — Adyen’s headless integration is one example — and Salesforce keeps filling first-party gaps itself: Hybrid Auth replaced the old Plugin SLAS setup, and a July 2026 release note adds default Order Management actions (tracking, cancelling, returning) to PWA Kit — provided your storefront is connected to a Salesforce Order Management org. Still, no official Salesforce source grades how mature this ecosystem actually is, and from what this site has seen, broad, SFRA-style plug-and-play coverage still isn’t there. Budget the extra time and vendor conversations an SFRA project rarely needs.
Missing out-of-the-box features
A few SFRA features still don’t have a clean PWA Kit equivalent. Here’s where each one actually stands in 2026:
- A/B Testing — still genuinely missing. The only bridge is a SCAPI Custom API you build yourself around the same
ABTestMgrscript API SFRA uses. Personalisation(Added in 2023)Page Designer(Added in 2023)- Sitemap — not built in, but no longer a dead end: this site documents a working backend-plus-proxy pattern built on the SCAPI
uploadCustomSitemapAndTriggerSitemapGenerationendpoint. - SEO URL Configuration — SCAPI’s
getUrlMappingendpoint now resolves the same Business Manager URL rules SFRA uses, but you still have to wire it into your own routing. There’s no zero-config equivalent yet. - Page Meta Tag Rules — Salesforce’s continued SCAPI expansion is making custom endpoints for this increasingly unnecessary.
That’s a shorter, more nuanced list than it was in 2022. Some gaps are closed outright, some have an official pattern to lean on, and A/B testing is still squarely on you to build. Budget accordingly.
Comparison
One thing to flag before the summary: this article compares SiteGenesis, SFRA, and the PWA Kit specifically. Salesforce’s newest recommended headless option, as of 2026, is actually Storefront Next — a different frontend stack (React Router 7, React 19, Vite) sitting on the same SCAPI and Managed Runtime backend described above. It’s new enough that this comparison doesn’t cover it, but check it before you commit to the PWA Kit on a greenfield project.
The following overview compresses the information above.

