Salesforce Commerce Cloud (formerly Demandware) was, for a decade, the default choice for enterprise fashion, beauty, and lifestyle brands that had outgrown mid-market platforms. That default is breaking down. Brands running real revenue on SFCC are increasingly moving to Shopify Plus, and the reasons are specific: licensing cost that scales against you as you grow, a development model built around custom cartridges that turns every release into a negotiation, and a shrinking pool of engineers who actually want to work in it. This is a practical guide to what an SFCC-to-Shopify migration actually involves — what replatforms cleanly, what takes real engineering work, what it costs, and the mistakes that turn a 6-month project into a 14-month one.
Why enterprise brands are actually leaving SFCC
The headline reason is cost, and it's a specific structural problem, not just "SFCC is expensive." Salesforce Commerce Cloud licensing is typically priced as a percentage of gross merchandise value — commonly cited in the 1-3% of revenue range depending on your contract and negotiating leverage. That model looks fine when you sign it at your current revenue. It looks very different three years later when the brand has grown 3x and the platform bill has grown with it, without your infrastructure actually getting three times more expensive to run. Growth is supposed to improve your unit economics, not tax them — SFCC's pricing model works against that.
The second reason is development velocity. Business logic in SFCC lives in cartridges and controllers — a customization model that made sense a decade ago but is genuinely difficult to test in isolation, slow to extend, and creates a specific kind of technical debt where every customization you added to differentiate your storefront becomes a tax on every future platform upgrade. Teams report release cycles measured in quarters, not weeks, largely because changes have to thread through a layered cartridge inheritance chain that's hard to reason about.
The third reason is talent. Business Manager's admin interface hasn't meaningfully modernized, SFRA/cartridge development is a shrinking specialty, and the developers who know it well are expensive and hard to hire. Shopify Plus, by contrast, draws from a much larger and still-growing talent pool, uses standard web technologies (Liquid, React for headless, REST/GraphQL APIs) that most engineers already know, and ships platform updates without requiring you to re-certify custom code against a new SFRA version.
What actually needs to be replatformed
An SFCC migration is not a lift-and-shift — nothing about SFCC's architecture maps directly onto Shopify's, so every major system gets rebuilt, not copied. The core pieces:
- Product catalog. SKUs, variants, pricing, images, and category/collection structure all need to be exported from SFCC (typically via its Data Loader or a custom export job) and reshaped into Shopify's product/variant model, which has different assumptions about how variants and options work than SFCC's catalog does.
- Customer data. Accounts, saved addresses, and — this is the sensitive one — stored payment methods. Payment tokens generally do not migrate directly between processors; customers usually need to re-enter payment details on first order post-migration, which needs to be planned for in the comms and UX, not discovered at launch.
- Order history. Historical orders typically migrate as read-only records for customer service and reporting purposes, not as live orders Shopify can act on. One documented migration moved 100,000+ SKUs and five years of order history using SFCC's Data Loader — that scale of historical data migration is normal for enterprise catalogs, but it needs its own dedicated workstream, not a bolt-on at the end of the project.
- Custom business logic. This is the hardest part and the one most often underestimated. Pricing rules, promotion logic, loyalty program integration, custom checkout steps, and B2B-specific logic (tiered pricing, approval workflows, custom quoting) built as SFCC cartridges have no direct Shopify equivalent — they get rebuilt as Shopify Functions, checkout extensions, or custom apps against Shopify's Admin/Storefront APIs.
- Third-party integrations. ERP, PIM, OMS, tax engines, loyalty platforms, and marketing tools connected to SFCC via custom cartridges need new connectors into Shopify's API surface — this is usually a bigger chunk of the timeline than the storefront rebuild itself for a mature enterprise stack.
Realistic timeline and cost
For most fashion, lifestyle, and beauty brands moving off SFCC, migrations land in the €250,000-€800,000 range and take 6-10 months, with the full spread running €150,000 to well over €1,200,000 depending on catalog complexity, the number of custom cartridges being rebuilt, and whether you go native Shopify Plus or a headless build on top of it.
Breaking that down by scope:
- Standard Shopify Plus migration (catalog, customer data, standard checkout customization via Shopify Functions, core integrations): typically 4-6 months.
- Headless or highly customized builds (custom storefront on Hydrogen/Remix, complex B2B logic, multiple regional storefronts): 6-12 months, and the cost climbs accordingly.
- Data migration and integration rebuild specifically tends to consume more of the timeline than most brands expect going in — plan for it to be 30-40% of total project effort, not an afterthought behind the storefront redesign.
The payoff that makes this worth the upfront cost: brands moving off SFCC commonly report a 3-5x reduction in three-year total cost of ownership, materially faster storefront performance, and release velocity that moves from quarters to weeks once the cartridge-based development model is gone.
The pitfalls specific to this migration path
A few failure patterns show up disproportionately in SFCC migrations specifically, separate from generic replatforming risk:
- Underestimating the promotion and pricing engine rebuild. SFCC's promotion engine is deep — tiered discounts, bundle logic, customer-group-specific pricing, coupon stacking rules. Teams that treat this as "we'll just use Shopify discount codes" discover mid-project that half their real-world promotion logic has no native Shopify equivalent and needs custom Shopify Functions.
- Treating B2B logic as an afterthought. If your SFCC storefront has B2B-specific behavior — negotiated pricing, approval workflows, purchase orders — this needs to be scoped against Shopify's B2B feature set (now on every paid plan as of 2026) or Shopify Plus's deeper B2B tooling from day one, not bolted on after the B2C storefront ships.
- Payment token migration surprises. Assuming stored customer payment methods will "just move." They generally don't, across almost any platform pair, and a plan for re-capturing payment details gracefully (rather than a blank checkout error on first post-migration order) needs to exist before launch.
- Underscoping the integration layer. ERP, PIM, tax, and loyalty integrations built as custom SFCC cartridges over years accumulate business logic nobody fully remembers writing. Budget real discovery time to audit what every integration actually does before estimating the rebuild — a surprising amount of "integration work" is actually "figuring out what the old integration was silently doing."
- Running catalog and content migration as one undifferentiated task. Product data, collection structure, blog/CMS content, and customer accounts have different risk profiles and different tools. Treating them as one generic "data migration" line item is how teams miss that CMS content needs manual editorial review while catalog data can be scripted.
- No parallel-run period. Enterprise SFCC migrations benefit from running the new Shopify store in a genuine staging/UAT environment against real order and traffic simulation before cutover — not just a demo walkthrough — because catalog-scale bugs (a pricing rule that's off by a currency rounding edge case, a variant combination that doesn't map cleanly) only surface at real data volume.
Native Shopify Plus vs. headless — which fits an SFCC-scale brand
Most brands migrating off SFCC default to assuming they need a headless rebuild because SFCC was itself a heavily customized, API-driven setup. That assumption is worth challenging before committing budget to it.
Native Shopify Plus (Liquid storefront, Shopify Functions for custom logic, Shopify Flow for automation) now covers a large share of what previously required deep SFCC customization — checkout extensibility, B2B on every paid plan, custom pricing logic via Functions — without the ongoing engineering overhead of maintaining a fully custom headless frontend. For most catalog-driven B2C and B2B-adjacent brands, native Shopify Plus is faster to ship, cheaper to maintain, and gets you most of the differentiation that actually matters to customers.
Headless (Hydrogen/Remix or a custom frontend against Shopify's Storefront API) earns its cost when you genuinely need a fully custom, app-like storefront experience, multiple brand storefronts sharing one backend with radically different UX, or content-commerce experiences that a themed storefront can't deliver. It's a real option, not the default one — brands that pick it because "SFCC was custom, so the replacement should be too" often end up rebuilding SFCC's maintenance burden on a new stack instead of escaping it.
How to actually run the migration
A migration that stays on schedule follows a specific sequence, not a big-bang cutover:
- Discovery and audit first. Full inventory of every cartridge, integration, and custom promotion rule before any Shopify build work starts. This phase alone often takes 3-6 weeks for a mature enterprise SFCC instance, and skipping it is the single biggest predictor of scope creep later.
- Prioritize by business logic, not by page. Rebuild the checkout and pricing/promotion engine early — these are the highest-risk, highest-effort pieces — rather than starting with the homepage and product pages, which are comparatively straightforward.
- Migrate data in stages with validation gates. Catalog first, validated against the live SFCC store for parity. Customer accounts next, with a clear, communicated plan for payment re-capture. Order history last, since it's read-only and lower-risk if it slips.
- Run a genuine parallel period. Stage the full Shopify store against real traffic patterns and a subset of real orders before full cutover, not just a QA pass by the project team.
- Plan the DNS and redirect cutover as its own workstream. Every SFCC URL needs a mapped Shopify equivalent with 301 redirects in place before traffic switches — an enterprise catalog can carry tens of thousands of indexed URLs, and losing that mapping is how a successful technical migration turns into an SEO and revenue problem in month one.
The brands that do this well treat it as a 6-12 month program with clear phase gates, not a single project with one launch date — and they budget the integration and business-logic rebuild as the largest line items, because that's where SFCC-to-Shopify migrations actually spend their time.
If any of this sounds like your situation, talk to us. We'll tell you exactly where your revenue is leaking and what it would take to fix it. Explore Strategy & Consulting →

