Salesforce Commerce Cloud to Shopify Migration

Cartridges and the cartridge path go first, and they take a habit of thinking with them. Salesforce Commerce Cloud layers code on a search path — something of the form int_instagram:int_socialfeeds:...:app_storefront_base — and a symbol resolves by walking it. Nothing on Shopify resolves code that way. There is no platform-wide layered override mechanism, so every override that currently works by sitting earlier in the path has to be found and re-expressed as ordinary code in one place. By design, those overrides are invisible from the file you think you are reading.

Then hooks.json. Payment processing, order calculation and catalogue transforms are wired in as named extension points implemented in CommonJS and declared there. Shopify Functions are narrow, specific extension points, not an open hook system. Everything registered in hooks.json has to be located, read, and individually assigned a destination: a Function, an app, theme code, or the honest answer that it does not move.

The job framework is the one that gets missed entirely, because it is not visible from the storefront. Batch work runs as Business Manager jobs made of task- or chunk-oriented steps with custom read(), process() and write() implementations declared in steptypes.json. This is the ETL layer: nightly ERP sync, catalogue imports, price feed processing, order export, commonly all of it. Shopify has no equivalent scheduled job framework inside the platform, so that work moves outside it and becomes infrastructure somebody now owns.

Page Designer content has no import path. And Business Manager is one unified admin — Shopify splits the same ground across the admin, the theme editor, the CLI and individual apps. That is a retraining cost for the merchandising team rather than a tooling change, and it is usually left out of migration plans written by engineers.

Inventory every integration by which API generation it speaks before scoping anything, because two are live: OCAPI and SCAPI. "We have an API integration" does not tell you what replacing it costs, and the two are different enough that the answer changes per integration.

Finally, establish whether the site is on SFRA or on legacy Pipelines. A Pipelines site is materially harder, and finding that out late is the difference between a plan and a rewrite.

Salesforce Commerce Cloud has five product types where Shopify has one two-level model: master, variant, variation group, product set and bundle. The variation group is the lossiest of them — a sub-master inside a master, carrying its own imagery and its own pricing, with no Shopify object at all. Anywhere the storefront merchandises a variation group as though it were a product, it becomes a real Shopify product, and the relationship back to its master becomes something you maintain rather than something the platform holds. A master differentiating on more than three axes also meets Shopify’s 3-option ceiling, regardless of the 2,048 variants of headroom sitting behind it.

Price books chain. A price book can declare a parentPriceBook, with its own currency and its own date window, and the effective price resolves through that chain. Shopify has no inheritance chain for pricing. A deep price book hierarchy is flattened by hand — per SKU, per currency, per window — and once flattened, the property that made it maintainable, changing a parent and having every child follow, is gone. That is an ongoing operational cost the migration creates, not a one-off task it completes.

Customer groups can be rule-based and can include anonymous shoppers, which means pricing and promotions can currently vary for a visitor who has never logged in. Shopify customer segments cover registered customers and drive discounting rather than pricing. Any rule that keys on an anonymous visitor’s attributes has no direct destination, and the answer is usually a narrower experience plus a decision about what that costs.

One thing maps genuinely well, and it deserves stating because very little else on this page does: inventory. ProductInventoryList objects map to Omnichannel Inventory locations by external reference, which is architecturally close to Shopify’s location model. Inventory is normally the least painful workstream in a Salesforce Commerce Cloud migration, and it is a reasonable place to start for an early, visible win.

The unconfigured Salesforce Commerce Cloud URL form writes the platform into the path: /on/demandware.store/Sites-{SiteID}-Site/{locale}/{Pipeline}-{Node} — site ID, locale and pipeline node, all visible. Production sites sit behind configured SEO URL rules, but the pipeline addressing persists underneath. Agencies consistently report finding un-rewritten default URLs indexed alongside the pretty ones; we flag that as what practitioners report rather than as vendor documentation, because Salesforce’s own URL rules page would not resolve for us to verify it. Either way it is cheap to check on your own site, and worth checking before the redirect map is signed off.

The consequence is specific to this platform. Because pretty URLs are a configured layer rather than something derived from catalogue structure, the redirect map cannot be generated from the catalogue. It has to be built from the site’s actual URL rule configuration and from crawl data — including whatever un-rewritten pipeline URLs turn out to be indexed, which nobody has in a spreadsheet anywhere.

Locale is typically a path segment. Shopify Markets has its own structure for handling that, and choosing between them is an explicit decision with search consequences rather than a default that carries over. Make it early, because it determines the shape of every redirect for every locale you run.