5 min read

Salesforce

August 25, 2025

SFRA Explained - Why Salesforce Commerce Cloud Needed a Fresh Start

SFRA was Salesforce’s commitment to building e-commerce sites that could survive and thrive in 2018 and to its credit it was the best choice for an upgrade through 2022 if you could afford it. But its time has come and gone.

Why Salesforce Commerce Cloud Needed a Fresh Start & What Is SFRA

If you’re still hearing SFRA tossed around in boardrooms, vendor pitches, and engineering meetings (and you’re not entirely sure what it means) you’re not alone. There’s a lot of chatter, some misplaced nostalgia for last decade’s technology, and very little that’s jargon-free or actually useful. This is a super brief attempt to clear some of that up.

The Basics: What Is SFRA?

SFRA stands for "Storefront Reference Architecture." (Personally I thought it was Salesforce Reference Architecture, but I guess it can be both). It’s Salesforce’s modern template for building e-commerce sites. In practice, it’s the foundation their Commerce Cloud expects you to use if you want speed, maintainability, and (frankly) access to the latest features fed to you from the Commerce Cloud product team. Where previous generations gave you a “starter kit” built for desktop shopping and slow update cycles, SFRA is in theory designed from the ground up to tackle modern site problems in a modern way. But modernity is the problem. What was modern in 2018 quickly becomes outdated by 2025.  For context on the pace of change - Tiktok was only launched into the US in 2017. In web terms 2018 is forever ago.

Why SFRA Exists

You have to have a sense of the history of Demandware to really answer this question. Demandware’s winning idea was that you could put ecommerce into the cloud and customers would still use it. But the founding technology of Demandware was Intershop which itself was formed in 1992.  That is literally the pre-history of ecommerce and a tribute to Stefan Schaumbach that the whole thing basically still worked..

So what had changed in 2018? Customers had been shopping on their phones for the past five years or so. Brands had become more demanding of the pace of change. They wanted to do more to stay ahead. Having a mobile website was table stakes now. So SFCC needed an architecture that was more flexible than SiteGen, and more mobile friendly.  SiteGenesis, the old architecture, just wasn’t built for teams who want to tweak a cart one week, redesign the homepage the next, and roll out Apple Pay without crossing their fingers every time they push code. Too many tied-together scripts, too much legacy debris.

SFRA was Salesforce’s answer to both the technical and commercial headaches. They looked at two major pain points; a need for real mobile performance, and a requirement for modularity. Then, they rewrote the blueprint. It was still what we now call monolithic but it was a leap forward in the way information moved around SFCC and got to the user.

How SFRA Works in the Real World

This isn’t just a change in code style. SFRA brought:

  • Components you can actually pick apart and rebuild, rather than cycling through a house of cards with every update.
  • Tools and structures familiar to modern developers. (You’re using Bootstrap (hooray for 2018), modern JavaScript (hooray again), a sensible view layer.)
  • Page layouts and features that are built around standard requirements for what customers do on mobile, tablet, and desktop without the team needing to hack at breakpoints.
  • Quick connectors for payments, search, reviews, and analytics, saving your team months of vendor mediation and double-work.
  • Templated, but not cookie-cutter. You don’t have to look like a Salesforce demo unless you want to.

What It Changed for Digital Teams

Deploying any change used to mean crossing your fingers and hoping three other things didn’t break. With SFRA, you’re dealing with modules: change the cart, and the homepage doesn’t fall over. Want to swap a payment provider? You don’t have to undo half the checkout flow.

Most teams believed they would see faster build times, easier onboarding for new engineers, and a long-term drop in maintenance costs. It’s not zero-maintenance, it never is, but you're not weighed down by years of tech debt with every new sprint. It didn’t always quite work out as neatly as that. And the giant SIs charged a lot of money for not a whole lot of actual work to get there. But hey, it’s progress.

The Big Picture: SFRA was good, but too expensive

If you’re an e-commerce leader today and your site hasn’t at least moved to SFRA, that last point was probably key. Like many advances in Salesforce land it was weighed down by the greed of big system integrators who saw an opportunity to get replatform money for upgrade workloads. 

So, often because of the time projects took and the cost of getting help, up to 50% of SFCC customers did not upgrade. (There are no official numbers but anecdotally that’s not far off.)

Should I go SFRA or composable storefront today?

Nobody wins by sticking with tech whose best years are behind it. Speed is measurable. Cost of ownership is never going down on old stacks. Customer expectations get higher each season, not lower. In its day SFRA gave you a modern toolset for an environment where agility mattered more than keeping the lights on. But it’s 2018 technology. It works today - there are some great highly performant SFRA sites out there - but doesn’t offer any forward looking benefits at all. It won’t help you develop skills in managing your data, it won;t help you move faster on content, it won’t help you escape the cadence of Salesforce on product updates. It’s better than SiteGenesis. But that was 2018’s problem, not 2025’s. And truthfully, building SFRA in 2025 is just wastefully expensive. Though the absolute cost has come down a lot in the past few years, you will be upgrading to composable in 2027 so you are just throwing money down the drain.. 

But doesn’t composable storefront require SFRA?

No. SFRA is an entire reference architecture. But SFCC has had solid APIs available to it forever. If you are on SiteGen today you can build some of the elements of SFRA architecture into your SFCC backend - hooks and custom endpoints, even controllers - that mean you can drive your composable site without a huge back-end re-architecture in the short term. In fact one of the arguments for composable is the opportunity it gives teams to upgrade the back-end themselves over time in a controlled way and improve the way they have constructed Salesforce with much lower risk to the production site. And the time to do that - now they aren’t dealing with merchant requests and technical spinning plates all day long.

SFRA was Salesforce’s commitment to building e-commerce sites that could survive and thrive in 2018 and to its credit it was the best choice for an upgrade through 2022 if you could afford it. But its time has come and gone. And a composable storefront allows you to skip comfortably past SFRA right to a modern (for now!) stack. Salesforce is investing heaviest now in composable SFCC. The price of a build is six figures rather than seven. And it sets up SiteGen customers to take advantage of AI innovations as they emerge from Salesforce and beyond. 

Modern SFCC customers have to move faster than SFRA and templated architectures will allow them. In 2026 you will be glad you took the plunge and skipped past SFRA to composable storefront. 

If you need the gritty details, Let’s Talk.

John Duncan

Co Founder at SFCC composable storefront leader

Read more

All Articles
How Does Composable Help Marketers and Merchants

5 min read

July 15, 2025

Composable

Ecommerce

How Does Composable Help Marketers and Merchants

Your Digital Team is Better Than Your Tech Stack

Marketers and merchandisers in enterprise retail are often stuck in a weird paradox: they have powerful ideas, agile teams, and massive goals, but a tech stack that moves like it's 2012. If launching a promo takes 3 JIRA tickets and 2 weeks of dev time, you're not just behind, you're bleeding money.

Enter composable commerce: a modular, API-first approach to building digital storefronts. While it sounds like a developer’s dream (and it is), the biggest wins actually show up for marketers and merchants.

Here’s how.

1. You Can Get Sh*t Done Fast

Composable means your frontend is decoupled from your backend. So when merch or marketing wants to:

  • Launch a campaign,
  • Update a product carousel,
  • Swap out homepage banners for seasonal offers,
  • Build a landing page for that influencer collab…

...they can do it without dev involvement (or with minimal support). Teams can use low-code/no-code tools integrated into the stack (like CMSs or visual merch tools) to make changes in hours, not weeks. And dev teams, before you get too upset, these guys have been using tag managers and personalization tools behind your back to do things they shouldn't for about 10 years now. This is better-safer-transparenter than that.

Result: Faster go-to-market, more A/B testing, more wins.

2. Personalization and Segmentation Actually Work

Legacy monoliths often treat personalization like a bolt-on feature, not a core capability. Composable stacks let you plug in best-in-class personalization engines (we have hard-core expertise in or Dynamic Yield) that actually talk to your content and commerce layers in real-time.

Marketers can then:

  • Target based on customer behavior, not just segments
  • Trigger experiences dynamically
  • Swap components (not entire pages)

Now, it better be built correctly by a partner who knows what they are doing. (cough). And that partner better be in the weeds with your team on what it has to do where (double cough). And you better be willing to out some work into making it work rather than think it automagically improves conversions (whooping cough). But a composable architecture does unlock all this.

Result: Better CX, higher conversion rates, more data to refine.

3. You Own the Brand Experience, Not the Platform

Composable gives you control over your frontend experience. Sure you have, like templates with like Bootstrap n stuff that you can play with. But repeat after me - ISML is DISML. With composable you are a world of React and Typescript and kittens. You get to control how the site looks, feels, and behaves instead of being locked into the templates someone thought were state of the art back in 2014.

This means your brand team can:

  • Tell a story that actually feels premium
  • Maintain consistency across channels
  • Create immersive content experiences

…without getting a “that’s not possible with our CMS” reply from IT.

Result: Experience-driven commerce, not catalog-driven commerce.

4. Operational Flexibility = Less Burnout

Move fast and break stuff they say. Yeah, great advice for a 20 year old building an app no one wil likely ever have to use. We don;t get that luxury. Marketers and merchandisers are constantly caught between "move fast" and "absolutely don’t break stuff."

Composable gives us a middle ground:

  • You can make changes and roll something back within about 10 seconds.
  • Repair or update to one part of the site does not have to impact another. And you will have built testing and QA workflows to automatically make sure that is the case. Or at least you will if you use 64labs (cough - sorry I can;t quite get rid of this).
  • You can schedule campaigns without syncing 5 different systems. Decide on your preferred workflow, how the various elements need to work together. And build that. Composable is made to compose.
  • You can preview content as it will actually appear — not just in staging environments that look nothing like the real site.

Result: Less stress, more autonomy, more velocity, more control.

{{banner}}

5. No More Big Bang

Worried about an old school Big Bang launch of composable? Don't be. You can put a full composable site out to a subset of users for as long as you want before you have to commit ? Don’t be. Most enterprise teams go with a split launch - maybe 5% of users to start. They iron out any kinks. Then when they realize how much the ROI will be if they switch over like right now, they switch.

You can go incremental of course.

You can plug in a headless CMS (like Contenstack or Amplience), run it headlessly within your legacy stack for a while, and prove ROI before ripping anything out. Or un composable with a new CMS in one region for six months to give yourselves some experience of both before rolling out globally.

Result: Low risk, high reward — easy to minimize risk and you keep IT on your side.

In a world where campaigns move at the speed of culture and conversion windows last minutes, composable lets marketers and merchandisers do what they do best: create, launch, measure, and optimize without waiting for devs, approvals, or outdated systems to catch up.

Why Salesforce Commerce Cloud Is Still the Best Enterprise eCommerce Platform

5 min read

August 8, 2025

Salesforce

Ecommerce

Why Salesforce Commerce Cloud Is Still the Best Enterprise eCommerce Platform

SFCC in 2025: Enterprise Stability Meets Composable Flexibility

Salesforce Commerce Cloud (SFCC) has evolved from its Demandware roots into a modern enterprise platform capable of powering fully composable, headless storefronts. Today, leading brands pair SFCC’s robust backend with modern front-end frameworks like Next.js and Vercel and headless CMS platforms such as Contentstack or Amplience to unlock faster performance, better developer agility, and richer customer experiences.

64Labs is the global leader in composable SFCC builds, delivering projects for enterprise retailers such as Horizon Hobby, Moncler, Sweaty Betty, and Duluth Trading all with measurable performance and revenue gains.

A Quick History of SFCC

Salesforce acquired Demandware in 2016, gaining one of the most mature cloud-native commerce platforms on the market. At a time when competitors still relied on on-prem or heavily customised systems, Demandware offered scalability without infrastructure headaches.

While its CMS and search were limited in those early years, its stability, global readiness, and proven operational model made it the Porsche of eCommerce platforms - engineered for performance, enduring in design, and able to stay relevant as the world caught up.

What Salesforce Commerce Cloud Is Today

At its core, SFCC remains a stable, scalable SaaS commerce engine. It handles:

  • Product catalog and pricing logic
  • Promotions and inventory management
  • Complex checkout workflows
  • Multi-brand and multi-region orchestration

The real shift in recent years? SFCC now fits seamlessly into composable architectures, enabling brands to swap in best-of-breed tools while retaining a bulletproof commerce core.

From SiteGenesis to SFRA to Composable

  • SiteGenesis – Legacy server-rendered architecture, fast for its time but inflexible and hard to maintain.
  • SFRA (Storefront Reference Architecture) – Introduced modularity, responsive design, and cleaner code for the monolithic era.
  • Composable Storefront – Built on modern JavaScript tooling with PWA Kit, SCAPI, and API-first integration, allowing front-ends on React or Next.js to be deployed on platforms like Vercel.

This evolution lets enterprise teams:

Why Composable SFCC Works for Enterprise Brands

Salesforce Commerce Cloud shines when:

  • Running multi-brand portfolios with shared components
  • Managing global pricing, tax, and inventory logic
  • Integrating with complex ERP, CRM, and marketing stacks
  • Passing stringent enterprise security and compliance requirements

When paired with a composable approach, SFCC gives brands backend stability and frontend freedom - the best of both worlds.

The Limits and How to Overcome Them

SFCC’s native CMS and search still lag behind best-in-class options. That’s why most of our composable builds integrate platforms like Amplience or Contentstack for content, and tools like Algolia for search.
Pricing can be a sticking point, but in 2025, negotiation flexibility is far greater - especially if you have the right partner guiding your roadmap.

Final Thoughts

Salesforce Commerce Cloud has come a long way since the Demandware days. It’s no longer just a managed backend for templated storefronts. It’s evolving into a flexible foundation for composable architectures, with room to plug in modern tools and scale globally.

For teams who need stability but don’t want to sacrifice flexibility, SFCC remains one of the few options that can support both. But to unlock its full potential, the architecture around it - including frontend, CMS, and integrations - needs to reflect modern composable thinking. And to get that, you need a partner that really lives this stuff. 64labs is far and away the leader in composable on SFCC. If you aren't being asked to bring us into conversations about your composable roadmap in some form someone isn't doing their job.

Thinking about building a composable storefront on Salesforce Commerce Cloud? We’ve helped some of the biggest names do it right. Let’s talk.