Salesforce Commerce Cloud.
What no one tells you
before you go live.

Salesforce Commerce Cloud is one of the most capable enterprise commerce platforms in the world. It's also one of the most misunderstood. Brands choose it for the logo, the promise of Einstein AI, and the Salesforce ecosystem. The punishment starts long before go-live. Some teams never get there at all. SFCC demands hardcore software developers who live inside the Salesforce ecosystem. Without them, cost overruns begin in the first sprint, timelines slip in the first month, and some engagements simply don't reach launch.

One thing most people don't say out loud. You are building on Demandware. Salesforce acquired Demandware in 2016 for $2.8 billion and rebranded it Salesforce Commerce Cloud that same year. The core infrastructure, the cartridge model, ISML templating, Business Manager, the pipeline architecture - all of it is Demandware's DNA. Salesforce has invested heavily on top of it, particularly with Einstein AI and Composable Storefront. But enterprise SFCC is still, fundamentally, a Demandware platform. Developers who have never lived inside that ecosystem routinely underestimate the learning curve.

Salesforce is also building something called Commerce on Core, their newer commerce product built natively on the Salesforce platform (Force.com) rather than the legacy Demandware infrastructure. Salesforce has referred to this as their DTC Commerce offering. As of now, it is not a replacement for enterprise B2C Commerce Cloud. It targets mid-market use cases and B2B self-service scenarios. If you are an enterprise brand evaluating SFCC today, you are still evaluating the Demandware-lineage platform. Know what you are buying.

We've implemented SFCC at Columbia Sportswear, one of the largest outdoor apparel companies in the world, and at Empower Global, a platform built to elevate Black-owned brands. Different scale, different business models, same lesson. The platform delivers when you respect what it is.

This is what we've learned about operating SFCC at scale.

The architecture decision you have to get right first

SFCC gives you two fundamental architectural paths. SFRA (Storefront Reference Architecture) is the traditional coupled approach where frontend and backend live together inside the SFCC platform. Composable Storefront (built on Salesforce's PWA Kit and Managed Runtime) decouples the frontend entirely, delivering it as a React-based progressive web application connected to SFCC via API.

This decision shapes everything downstream. Team structure, developer hiring, integration complexity, time to market, and ongoing maintenance cost all trace back to which architecture you chose on day one.

When SFRA is the right answer

SFRA makes sense when your team's existing SFCC expertise is cartridge-based, when your integration surface area is narrow, and when you need to be live fast. SFRA has been battle-tested across hundreds of enterprise deployments. The third-party cartridge ecosystem for SFRA is mature. Payment processors, tax engines, loyalty platforms, and product recommendation tools all have SFRA-native integrations. You're not building from scratch.

The risk with SFRA is long-term performance ceiling. Coupled architecture means that frontend improvements require backend deployments. Page speed optimization hits structural constraints. As composable becomes the platform's strategic direction, SFRA will eventually require migration anyway.

When composable is the right answer

Composable Storefront makes sense when performance is a hard requirement, when your team has strong React expertise, and when you need maximum flexibility to compose best-of-breed solutions across search, CMS, and personalization layers. Page load times on a well-built PWA Kit implementation are genuinely faster. The development experience is modern. The frontend is fully portable.

The risk with composable is integration maturity. The third-party ecosystem for PWA Kit is still developing. What was a cartridge install in SFRA becomes custom development in composable. And Salesforce's hybrid implementation (running SFRA and composable simultaneously) solves the migration problem in theory but creates operating complexity that compounds the longer you run it.

Integration architecture is where SFCC projects fail

SFCC doesn't live in isolation. It connects to your ERP for inventory and pricing. It connects to your OMS for order management and fulfillment routing. It connects to your CRM for customer data and personalization. It connects to your PIM for product content. Get those integrations wrong and the platform that looked so powerful in the demo becomes a liability in production.

At Columbia, we implemented Order Dynamics as the OMS and built an entirely new, event-driven cloud-based integration layer connecting the SFCC storefront to backend systems across marketing, customer loyalty, and business intelligence. The integration architecture spanned 21 global eCommerce sites launched simultaneously. The integration complexity wasn't an obstacle to the SFCC deployment. It was the deployment. The storefront was the easy part.

The three integration mistakes we see most often

Synchronous integrations on the wrong data flows. Real-time inventory queries from the storefront to ERP at checkout create latency and failure points. Inventory availability should be pushed to SFCC on a schedule and cached. Reserve the synchronous calls for the moments that actually require them, specifically order placement and payment capture.

OMS as an afterthought. Salesforce Order Management is a capable OMS and integrates naturally with SFCC - we implemented it at Empower Global alongside Commerce Cloud, Marketing Cloud, Service Cloud, and Loyalty Cloud. But even a native integration still requires significant configuration for multi-location fulfillment, split-ship logic, and return routing. Brands that treat OMS as a later phase and wire SFCC directly to ERP for order management build technical debt that costs two to three times more to unwind than it would have cost to do it right the first time.

No event-driven fallback strategy. Integrations fail. Your architecture needs to handle ERP downtime without surfacing a broken checkout experience. Design for degraded mode from day one. Cache what can be cached. Queue what must be real-time. Define the fallback for every integration point before you go live, not after your first production incident.

Einstein AI is real. But it requires real data to work.

Einstein for Commerce is genuinely powerful. Product Recommendations, Predictive Sort, Commerce Insights, and Einstein Search Dictionaries can meaningfully move conversion rates, average order value, and search-to-purchase rates. We have seen it work. We have also seen brands spend six figures on Einstein enablement and see nothing meaningful move because the underlying data wasn't ready.

Einstein learns from behavioral signals. Clicks, views, adds to cart, purchases, search queries, and session sequences all feed the models. If your catalog is poorly structured, your search terms aren't mapped, or your behavioral data stream is incomplete, Einstein's outputs reflect that quality. Garbage in, garbage out applies as precisely to AI personalization as it does to any other data system.

What you need before Einstein delivers

• ■
  A clean product catalog. Every product needs accurate attributes, complete categories, and proper variant linkages. Einstein's recommendation models use catalog structure as a core signal. A flat, inconsistently attributed catalog produces recommendations that feel random because they are.
• ■
  Sufficient behavioral history. Einstein needs volume to find patterns. New storefronts, recently migrated catalogs, and low-traffic segments don't give the models enough signal. Plan for a 60 to 90 day data accumulation period before recommendations reach meaningful accuracy.
• ■
  Search dictionary investment. Einstein Search Dictionaries dramatically improve search relevance by handling typos, synonyms, and brand-specific terminology. But they require ongoing curation. Someone on your team needs to own this. No one does, and search becomes your highest abandonment point.
• ■
  Placement strategy, not just activation. Where you place recommendations matters as much as what recommendations surface. Product detail page placement drives cross-sell. Cart page placement drives upsell. Homepage placement drives discovery. Each requires a different strategy and different success metrics.

Multisite and global architecture. Plan it before you build it.

SFCC's multisite capabilities are one of its greatest competitive strengths. A single SFCC instance can power dozens of storefronts across brands, regions, languages, and currencies with centralized catalog management and localized customer experiences. At Columbia Sportswear, we helped architect and launch 21 global eCommerce sites simultaneously from a shared SFCC foundation - sites spanning multiple regions with near-100% uptime from day one.

But multisite done wrong is worse than no multisite at all. The governance decisions you make in the first implementation determine how expensive every future storefront launch becomes.

The governance decisions that compound over time

Shared versus site-specific catalog structures. If you build a monolithic catalog that every site shares without variation logic, you create constraints when different regions need different pricing, content, or assortment. Build catalog architecture with multi-site variation in mind from the start, even if you're only launching one storefront initially.

Shared code versus site-specific cartridges. Every site-specific customization added directly to the base cartridge path creates debt. Build a clear cartridge inheritance model on day one. Base cartridges for shared functionality. Site cartridges for localized variation. Custom cartridges for brand-specific logic. Violating this model for speed in early implementations makes later sites exponentially more expensive.

Content management architecture. SFCC's Page Designer and Content Assets work well at single-site scale and become unwieldy at global scale without a governance model. Define who can edit what, what content is shared versus localized, and how content approvals flow across teams before you launch. Retrofitting this is painful.

The SFRA to Composable migration. What Salesforce doesn't tell you.

Salesforce has been clear that Composable Storefront is the platform's strategic direction. PWA Kit and Managed Runtime represent where SFCC's investment is going. That means if you're on SFRA, migration is not a question of if but when.

Salesforce's hybrid implementation path lets you run SFRA and Composable simultaneously, migrating page by page or flow by flow. In theory, this minimizes risk. In practice, the hybrid state is the riskiest state to be in long-term.

Running hybrid means maintaining two authentication systems simultaneously. Starting with SFCC version 25.3, this requires Hybrid Authentication to manage both the traditional SFRA session cookie and the SLAS JSON Web Token in sync across every request. That synchronization is not trivial, and the window for session-state bugs that affect conversion is open the entire time you're in hybrid mode.

Our recommendation is to treat hybrid as a transition state with a hard end date, not an operating model. Define the scope of the composable migration, set a deadline for exiting hybrid, and resource accordingly. Brands that let hybrid implementations drift become permanently expensive to operate.

Performance at scale is not automatic

SFCC handles peak traffic well. The Managed Runtime infrastructure auto-scales. Salesforce's CDN handles global delivery. But auto-scaling infrastructure doesn't compensate for application-level performance problems, and SFCC implementations can accumulate those problems quietly until a high-traffic event like a product launch or holiday period exposes them all at once.

The performance work that happens before launch, not after

• ■
  Page Designer component performance audits. Heavily templated SFCC pages built with multiple Page Designer components can generate excessive API calls. Audit every storefront template for API call volume before launch. Consolidate calls. Cache aggressively at the component level.
• ■
  Image optimization strategy. SFCC's Dynamic Imaging capabilities are powerful but require deliberate configuration. Unoptimized image delivery is one of the most common causes of poor Core Web Vitals scores on SFCC storefronts. Set image size, format, and quality presets explicitly. Don't rely on defaults.
• ■
  Load testing before every peak event. Test your integration layer, not just the storefront. SFCC infrastructure scales. Your ERP, OMS, and payment gateway may not. A checkout timeout at peak traffic is a revenue event. Load test the full stack.
• ■
  Sandbox-to-production parity. SFCC sandboxes have different performance characteristics than production. Performance testing in sandbox tells you about relative performance between code changes, not absolute production performance. Test in a production-like environment before major releases.