Enterprise replatforming, scoped before it is sold.

Three drivers dominate: total cost of ownership including licence and the specialist development capacity SFCC requires, release velocity when every change needs a cartridge deployment, and licence renewal forcing a genuine build-versus-buy review. The trade is deep enterprise configurability for a platform your team can operate.

For a large share of SFCC brands, yes, and for some, no. Shopify Plus handles high-volume DTC, multi-market selling, and B2B well. Where SFCC still wins is extremely deep custom merchandising logic, very complex multi-brand catalog hierarchies, and organisations already committed to the wider Salesforce ecosystem.

SFCC gives deeper merchandising configurability, a more expressive promotions engine, and multi-brand catalogue hierarchies, at the cost of licence fees, specialist developers, and slower release cycles. Shopify Plus gives faster iteration, a far larger app ecosystem, and a platform your own team can operate, at the cost of some low-level control. The honest split: SFCC wins on configurability, Shopify Plus wins on velocity and cost of ownership.

Shopify Plus and Adobe Commerce are the two most common enterprise destinations. BigCommerce Enterprise and commercetools appear where composable or API-first architecture is the priority. OroCommerce and Virto Commerce come up for heavily B2B estates. Which fits depends far more on your promotions complexity and integration surface than on any feature comparison table.

They are the same platform. Demandware was the original product name before Salesforce acquired it, and the term still appears in older documentation, job specs, and internal naming. If your team says Demandware and your invoices say Salesforce B2C Commerce, you are on one platform, not two.

Sometimes, and we will say so. If your merchandising logic genuinely requires SFCC's depth, you run many brands and locales with divergent catalogs, or the wider Salesforce estate is central to operations, replatforming trades one set of constraints for another. The migration is worth it when the platform is the bottleneck.

They do not transfer. Cartridges are SFCC-specific extension packages, so every piece of custom functionality is re-implemented as Shopify theme code, a Shopify app, Shopify Functions, or dropped. Cataloguing what each cartridge actually does, including ones nobody maintains, is where the real project scope emerges.

Yes, mainly for effort and URL structure. SFRA is the more modern reference architecture and tends to have cleaner separation, which makes auditing customisation easier. SiteGenesis implementations are typically older and more heavily modified, so the customisation inventory takes longer and usually surfaces more surprises.

Shopify Liquid, or a headless front end where the storefront requirements justify it. ISML templating logic frequently encodes business rules that should live elsewhere, so this is an opportunity to move that logic into data and Functions rather than reproducing template complexity on a new platform.

Yes. Shopify Plus supports headless through the Storefront API and Hydrogen, which suits brands already running a decoupled front end on SFCC. It adds engineering ownership, so we scope it as a deliberate choice rather than a default. Many SFCC brands are better served by Liquid than they expect.

Price books become a combination of Shopify markets, price lists, and B2B catalogs depending on how they are used. SFCC price book hierarchies with fallbacks have no exact equivalent, so the mapping is a modelling exercise rather than a data copy, and it is one of the most important decisions in the whole migration.

This is usually the hardest single component. SFCC's promotions engine with campaigns, qualifiers, and complex stacking rules is more expressive than Shopify's native discounts. Complex promotions get rebuilt with Shopify Functions or a promotions app, and a frank inventory of which promotions actually run is essential before estimating.

Not directly. SFCC content assets and content slots become Shopify metaobjects, theme sections, or a headless CMS depending on how editorial teams work. Because slots are often used to drive merchandising rather than just content, the mapping needs merchandising input rather than being treated as a developer task.

Yes, through Shopify Markets for locales and currencies, and either separate stores or a single store with market-specific catalogs for multi-brand estates. SFCC sites sharing a master catalog with site-specific assignments need a deliberate model, since Shopify approaches that differently.

Customers, addresses, and order history extract through OCAPI or SCAPI and import into Shopify. Passwords cannot migrate, as with any platform move, so customers reset at launch. For enterprise brands the customer communication around that reset needs planning with marketing well before cutover.

Shopify's Admin API and Storefront API, plus webhooks and Flow for event-driven work. Every integration written against OCAPI or SCAPI is rebuilt, and enterprise SFCC estates typically carry many, including some running through middleware nobody has reviewed in years.

Scheduled jobs for catalog imports, inventory feeds, and order exports have no direct Shopify equivalent and are rebuilt as scheduled tasks in middleware, an integration platform, or Shopify Flow depending on complexity. This is routinely underestimated because jobs are invisible from the storefront.

Yes, and this is central rather than peripheral. SAP, Oracle, NetSuite, Manhattan, Akeneo and similar systems all need their integrations rebuilt against Shopify APIs. A migration is not finished when the storefront is live; it is finished when order, inventory, and product flows are verified end to end.

Those can stay. Leaving B2C Commerce does not require leaving the wider Salesforce estate. Service Cloud and Marketing Cloud both integrate with Shopify, though the connection is rebuilt rather than inherited. Brands often keep the CRM and marketing layer while replacing only commerce.

Not with complete URL mapping, but SFCC estates are usually large and multi-locale, so the map is correspondingly large. SFCC URL structures with locale and site path segments differ from Shopify's, and hreflang has to be rebuilt across markets. We crawl every indexed URL per locale rather than sampling.

Longer than any other route we run, typically several months. Cartridge inventory, promotions rebuild, price book modelling, and integration count drive it. Anyone quoting an enterprise SFCC replatform in weeks has not looked at the customisation inventory.

Usually yes, and for multi-site estates it is normally the right approach. A single market or lower-risk brand goes first, which proves the integration pattern and the redirect approach before the flagship follows. It does mean running two platforms concurrently, which needs planning around shared inventory.

Licence renewal is frequently what triggers the review, and it sets a hard deadline. We plan backwards from renewal with buffer, because a migration compressed to hit a contract date is where the expensive mistakes happen. Starting the audit early costs little and preserves options.

Phased milestones with sign-off gates, an explicit customisation inventory agreed before build, and integration acceptance tested against real orders rather than demo data. Enterprise migrations fail on scope discovery mid-project, so we front-load the discovery and put it in writing.

Access to Business Manager, a cartridge and customisation inventory, a list of active promotions, your integration map including middleware, and a per-locale crawl of indexed URLs. Those five things determine the estimate, and assembling them is worthwhile even if you ultimately stay on SFCC.