Salesforce Commerce Cloud to Shopify Plus

Salesforce Commerce Cloud to Shopify Plus is an enterprise replatforming project, and almost nothing about it resembles the other migrations in this cluster.

The store is not the scope. The scope is an ecosystem: an ERP, an order management system, a PIM, a CRM, tax and fraud services, a customer service platform, possibly a POS estate, and a set of integrations built over years by teams who have since moved on. The storefront is the visible part of a much larger dependency graph.

These projects run six to eighteen months, involve procurement and legal and IT governance, and succeed or fail on discovery and integration planning rather than on anything a developer does in a theme.

Why enterprises make this move

The reasons are consistent and largely commercial.

Total cost of ownership. SFCC’s licensing model, typically a percentage of gross merchandise value plus implementation and agency costs, becomes expensive at scale. Combined with the specialist development resource required, the annual run rate is often several times what Shopify Plus would cost. For a finance team, this is usually the headline.

Speed of change. SFCC development cycles are long. Releases are planned, tested, and scheduled, and marketing teams wait. Businesses that need to move quickly find the release cadence a genuine competitive constraint, and this is often the argument that carries the commercial leadership even when the CFO is persuaded by cost.

Talent scarcity and cost. The pool of experienced SFCC developers is small and expensive, concentrated in a handful of agencies. Shopify’s talent pool is vastly larger and cheaper, which matters for both delivery and continuity.

Implementation burden. SFCC implementations are large projects requiring specialist partners. Ongoing change carries similar overhead.

Platform innovation pace. Shopify ships frequently, and native capability in checkout, markets, B2B, and functions has expanded considerably. Enterprises weigh whether they want to build capability or receive it.

Simplification. Some organisations are deliberately reducing the complexity of their technology estate, and replacing a heavily customised platform with an opinionated one is a strategic choice rather than only a cost one.

The counter-argument, stated fairly: SFCC is a mature enterprise platform with deep capability in complex merchandising, sophisticated promotion engines, and highly customised experiences. Organisations with truly complex commerce logic, tight Salesforce ecosystem integration, or requirements that depend on control Shopify does not offer may be right to stay. The question is whether your complexity is essential or accumulated — and in our experience a meaningful share of it is accumulated.

Where these projects actually succeed or fail

Not the storefront. Five areas, in order of risk.

Integration architecture. This is the project. Your ERP, OMS, PIM, CRM, tax engine, fraud tooling, service platform, and fulfilment systems all connect to SFCC through integrations that must be rebuilt against Shopify’s APIs. Some were built against SFCC-specific interfaces or direct data access and have no straightforward equivalent. Each needs designing, building, testing, and cutting over — and integration work typically consumes more of the budget and timeline than everything else combined.

Specific things to establish early: which direction each integration runs, at what frequency, what volume, what the failure handling looks like, and whether Shopify’s API rate limits accommodate it. Rate limits catch enterprise projects by surprise with some regularity, and discovering a volume problem in testing is far better than in production.

Promotion and pricing logic. SFCC’s promotion engine is sophisticated, and enterprises use it. Stacking rules, exclusions, qualifying conditions, customer-segment targeting, and complex campaign logic. Shopify’s native discounting is simpler; Shopify Functions on Plus allow custom discount logic, which covers a great deal, but the mapping is not one-to-one. Inventory every active promotion type and map each explicitly. This is the second-largest source of scope surprise after integrations.

Merchandising and search. SFCC offers fine-grained merchandising control — sorting rules, boosting, category-specific ranking, and search configuration. Replicating this on Shopify usually means a search and merchandising platform plus configuration work. Scope it as a workstream, not a setting.

Multi-site and multi-region architecture. SFCC’s site model supports many storefronts from one instance with shared catalogue and independent configuration. On Shopify this becomes Markets, expansion stores, or a combination, and the decision has consequences for operations, reporting, inventory, and SEO. Design this deliberately and early, because changing it later is a second migration.

Organisational change. Underestimated consistently. Your merchandising team knows SFCC’s tools. Your customer service team knows its order management screens. Your finance team knows its reporting. Everyone needs retraining, processes need rewriting, and runbooks need replacing. Budget time and attention for this, and involve those teams in discovery rather than presenting them with a finished platform.

What Shopify Plus does and does not give you

What it gives you. A checkout that converts well and that you can customise within defined boundaries through Checkout Extensibility. Shopify Functions for custom discount, shipping, and payment logic. Native B2B. Markets for international. A large app ecosystem. Substantially lower running costs. A far larger talent pool. Frequent platform improvements you receive rather than build. And no infrastructure responsibility.

What it does not give you. Unlimited control over checkout behaviour — Extensibility has boundaries, and if your current checkout does something unusual, verify it is reproducible before you commit. Database-level access. The promotion engine sophistication of SFCC out of the box. Merchandising control at SFCC’s granularity without additional tooling. And the particular depth of native integration with the wider Salesforce ecosystem, which for organisations standardised on Salesforce for CRM and service is a real consideration worth weighing rather than dismissing.

Where the honest uncertainty sits. Both platforms change. Shopify’s enterprise capability has expanded quickly, and specific gaps that existed two years ago may have closed. Verify current capability against your actual requirements rather than relying on any comparison, including this one — that is not a disclaimer, it is the single most useful piece of advice in this article.

How these projects run

Discovery: six to twelve weeks. Every integration documented with direction, frequency, volume, and owner. Every promotion type catalogued. Merchandising rules recorded. Catalogue architecture checked against Shopify’s constraints using real data. Multi-site requirements mapped. Compliance and security requirements established. Output is a written architecture document, not a slide deck.

Architecture and planning: four to eight weeks. Plan selection, store structure, integration patterns and middleware decisions, data model and metafield design, promotion approach, search and merchandising tooling, and the phasing plan.

Build: three to nine months. Storefront, Plus development for custom logic, integration builds, and app configuration. Integrations set the critical path almost always.

Data migration and testing: four to eight weeks, overlapping build. Catalogue, customers, order history. Then end-to-end testing across the full system landscape, not just the store — an order should be traceable from placement through ERP, fulfilment, and finance.

Phased launch, usually. Enterprises rarely switch everything at once. Common patterns: launch one region or brand first, or launch a smaller storefront to validate the architecture before the flagship. Phasing costs time and buys enormous risk reduction, and it is almost always the right choice.

Hypercare and stabilisation: four to twelve weeks post-launch. Dedicated resource, monitoring, and fast response. Then ninety days of SEO monitoring on top.

Total: six to eighteen months. Anyone proposing three months for an enterprise SFCC migration has not seen the integration inventory.

A worked example: the phased launch that saved the project

A multi-brand apparel group ran four storefronts across three regions on SFCC, integrated with an ERP, a separate OMS, a PIM, a tax engine, and a customer service platform. Annual platform and agency cost was well into seven figures.

Discovery took ten weeks and found two things that reshaped the plan.

First, their OMS integration assumed order data structures specific to SFCC and required transformation logic nobody had documented. The original integration developer had left three years earlier. Reverse-engineering it took four weeks on its own.

Second, their promotion engine was running 140 active promotion types, of which discovery established that 31 were actually used in the past two years. The rest were legacy configurations nobody had retired. Mapping 31 promotion types to Shopify Functions and native discounts was tractable. Mapping 140 would not have been, and the original scope assumed all of them.

They launched their smallest regional storefront first, seven months in. It surfaced three integration defects, a tax calculation edge case affecting one market, and an inventory synchronisation timing problem under load — all of which would have been considerably worse on the flagship brand during a trading peak.

Those were fixed over six weeks. The remaining three storefronts launched across the following four months.

Total elapsed time: thirteen months. Running costs fell by roughly 65%. Their marketing team went from a multi-week release cycle to shipping campaign pages themselves.

The phasing was the decision that made it work. It also meant running two platforms in parallel for four months, which was operationally awkward and which some stakeholders resisted. That awkwardness was the price of not discovering the integration defects on their largest brand in November.

What to insist on

If you are commissioning this work, these are the non-negotiables.

Paid discovery with a written architecture document as the deliverable. Anyone who will quote a fixed price for the whole project before discovery is either padding heavily or planning to raise change requests.

A named integration architect. The integrations are the project; they need an owner with authority.

A complete integration inventory before scope is fixed, with direction, frequency, volume, and failure handling for each.

A promotion audit. How many promotion types are configured, how many are actually used, and how each maps. Retiring unused legacy configuration is often the single largest scope reduction available.

A phasing plan with an explicit rationale for the sequence.

End-to-end test scenarios covering the full system landscape, signed off by the teams who operate each system.

A hypercare plan with named people and response expectations.

An explicit rollback position for each phase. You probably will not use it. Not having one changes how people make decisions under pressure, and not for the better.

The enterprise SEO problem

Enterprise SFCC sites present migration SEO challenges the smaller platforms do not, and they are worth treating separately.

Scale. A multi-brand, multi-region SFCC estate can have hundreds of thousands of indexed URLs across locale variants, refinement combinations, and category hierarchies several levels deep. Manual classification does not scale, so you need a data-driven approach: pull organic traffic and links per URL, set thresholds, handle everything above them individually, and rule-map the rest.

Locale and hreflang. SFCC sites typically serve multiple locales with URL patterns encoding language and region. Moving to Shopify Markets or expansion stores changes those patterns, and your hreflang annotations must be rebuilt correctly across every language and region pair. Errors here cause the wrong regional page to rank in the wrong market, which is both an SEO problem and a revenue one — customers landing on a storefront that cannot serve them.

Refinement URLs. SFCC’s faceted navigation generates URLs for filter combinations, and depending on configuration a great many may be indexed. Most should not be, and this is a chance to fix that. But check which of them earned traffic and links first — some refinement pages rank for valuable long-tail terms and deserve deliberate destinations, often a Shopify collection built specifically to replace them.

Category depth. SFCC hierarchies are often deeper than Shopify collections naturally accommodate. Flattening the structure is usually beneficial, but every removed level is URLs that need destinations, and the decision affects internal linking and crawl paths as well as redirects.

Redirects at scale. Shopify’s redirect system handles large maps via bulk import, but at enterprise volumes you should verify in batches rather than trusting a single large upload. Some organisations also handle a portion at the CDN or edge layer — establish early which layer owns which redirects, because a split with no clear ownership produces gaps.

Phased launches complicate SEO. If you launch one region first, you have two platforms serving related content simultaneously. Canonicals, hreflang, and sitemap scoping all need to be correct during the interim period, not just at the end. Plan the SEO configuration for each phase explicitly rather than only for the final state.

Brand and domain consolidation. These projects sometimes coincide with a decision to consolidate domains or subdirectories. That is a second major SEO change, and combining it with the replatform makes attribution of any decline impossible. Separate them if you can.

Governance: the part nobody writes about

Enterprise migrations fail for organisational reasons more often than technical ones. A few things that materially change the odds.

One accountable executive sponsor. Not a committee. Someone who can resolve a disagreement between merchandising and IT in an afternoon rather than a fortnight.

Representation from every team that operates the platform. Merchandising, customer service, finance, fulfilment, marketing, and IT. Each has workflows that must exist on the new platform, and each will discover a requirement nobody else knew about. Finding those in discovery is cheap; finding them in hypercare is not.

A written decision log. Enterprise projects run long enough that people forget why a decision was made, and personnel change mid-project. A log prevents relitigating settled questions and protects you when someone new arrives with strong opinions.

A change control process agreed before you need it. Discovery will change scope. Testing will surface requirements. Agree how changes get assessed, priced, and approved while everyone is still calm.

Explicit training ownership. Someone must own the retraining of every affected team, with a timeline. This is routinely assumed to be the agency’s job, is rarely in their scope, and is discovered in the week before launch.

Runbook rewriting as a tracked deliverable. Your customer service team has documented procedures referencing SFCC screens. Those procedures need rewriting, and nobody volunteers for it.

A decision about what you are deliberately not replicating. Every enterprise migration finds functionality that exists, is barely used, and would be expensive to rebuild. Decide consciously to drop it, document the decision, and tell the affected team — rather than leaving it to be discovered as a gap after launch.

The bottom line

This is a systems integration programme with a storefront attached, and it should be resourced and governed as one.

The commercial case is usually strong: substantially lower running costs, faster change, and a far larger talent pool. The risk is concentrated almost entirely in integrations, promotion logic, merchandising control, and organisational readiness — and every one of those is manageable if discovery is thorough and unmanageable if it is not.

Spend properly on discovery. Audit your promotions ruthlessly, since much of your apparent complexity is probably legacy configuration nobody has retired. Phase the launch. And involve the merchandising, service, and finance teams early, because the platform they have to operate afterwards is the actual deliverable.

Frequently asked questions

How long does an SFCC to Shopify Plus migration take?

Six to eighteen months, with the range driven almost entirely by integration complexity rather than storefront work. Discovery alone warrants six to twelve weeks and is the phase most worth funding properly. Build typically runs three to nine months, with integration rebuilds on the critical path. Most enterprises then phase the launch across several months, starting with a smaller storefront or region to validate the architecture. Treat any proposal under three months as evidence the integration inventory has not been examined — the storefront is rarely what takes the time.

Will Shopify Plus handle our promotion complexity?

Often yes, but establish it during discovery rather than assuming, and start by auditing what you actually use. SFCC’s promotion engine is more sophisticated than Shopify’s native discounting, but Shopify Functions on Plus allow custom discount logic that covers a great deal. The more useful finding in most audits is that a large share of configured promotion types are legacy configuration nobody has used in years — we routinely find fewer than a third in active use. Catalogue every promotion type, identify which have run recently, and map only those. That exercise alone frequently removes more scope than any technical decision.

What happens to our ERP and OMS integrations?

They get rebuilt against Shopify’s APIs, and this is the largest and riskiest part of the programme. For each integration, establish direction, frequency, data volume, transformation logic, and failure handling before scope is fixed. Two things cause the most trouble: integrations built against SFCC-specific interfaces or direct data access with no clean equivalent, and undocumented transformation logic written by people who have since left. Also verify that Shopify’s API rate limits accommodate your volumes — this catches enterprise projects out with some regularity, and finding it in testing is far better than in production.

Is Shopify Plus actually cheaper than Salesforce Commerce Cloud?

Usually substantially, though compare total cost of ownership rather than licence fees alone. SFCC typically charges a percentage of gross merchandise value plus implementation and specialist agency costs, and experienced SFCC development resource is scarce and expensive. Shopify Plus charges a platform fee plus transaction costs, and the development talent pool is far larger and cheaper. Enterprises commonly report running-cost reductions in the range of half to two-thirds. Offset that against a significant one-off migration cost, and model over three years — which is where the case usually becomes clear.

Should we launch everything at once or phase it?

Phase it, in nearly all cases. Launching a smaller region or brand first validates the integration architecture, surfaces defects, and exposes operational gaps while the stakes are manageable — and integration defects, tax edge cases, and synchronisation timing problems under load are exactly the issues that do not appear in testing. The cost is running two platforms in parallel for some months, which is operationally awkward and tends to attract internal resistance. That awkwardness is considerably cheaper than discovering a fulfilment synchronisation problem on your largest brand during peak trading.