Migrating away from Salesforce Commerce Cloud to a custom store

What Salesforce Commerce Cloud is, and who it suits

Salesforce B2C Commerce, still called Commerce Cloud and known for years as Demandware, is an enterprise ecommerce platform delivered as software as a service. Salesforce bought Demandware in 2016 for about 2.8 billion US dollars and folded it into its cloud.¹ You do not host it, patch it or run the servers. Salesforce does, across many data centres, and it is built to carry very large catalogues, many storefronts, several brands and several regions from one place. For a retailer operating at that size, with a big internal team and an integrator on retainer, it is a capable platform and it earns its keep.

I build custom shops on Solidus, the open source Rails ecommerce framework, so you know where I stand before I say a word against the platform. That is exactly why I want to be fair about it. If you are a genuine enterprise that needs multi brand, multi region commerce at scale, with the people and the budget to run it, Salesforce may be the right home and this article is not written to talk you out of it. The honesty is the point: I would rather lose the work than move a business that should stay.

This guide is for a different shop. It is for the mid sized business that was put on Salesforce Commerce Cloud, often by a system integrator who knew the platform, and is now paying enterprise money and living with enterprise complexity it never actually needed. If every year the bill grows faster than the team, and nobody in the building can change the checkout without raising a ticket with an agency, this is for you.

Who outgrows it, and who should stay

The clearest signal is the bill. Salesforce prices B2C Commerce as an annual contract, and the public pricing page lists its editions, Growth, Plus and Premium, as billed annually with pricing available only on request.² It does not publish a rate card, and I will not invent one. What matters for this decision is the shape of the model, not a number: the contract is priced against the volume of sales that flow through the platform, so the more you sell, the more you pay. Growth is taxed. A good year on the shop is a bigger invoice from the platform, whether or not the platform did anything new to deserve it.

For a true enterprise that is a reasonable trade. The platform carries real cost and real risk off your plate, and a share of a very large number can still be good value against running it yourself. For a shop doing a few million a year with a conventional catalogue, it often is not. You pay the enterprise share and use a fraction of the enterprise capability.

So here is the honest test. Stay on Salesforce if you run several brands or several regions that genuinely share one commerce engine, if you have an internal commerce team, and if the platform's scale and support take work off you that you could not easily do another way. Look hard at leaving if you are one brand in one or two markets, if the integrator holds all the keys, if your real complaint is that the shop is expensive and closed, and if the features you actually use would fit a shop you owned outright.

What you own, and what the platform keeps

The first thing to settle before any move is what is yours to take. On Salesforce the answer splits cleanly in two, and it is not the split most owners expect.

Your business data is yours. The catalogue, the customer records and the order history can all be exported, and I come to exactly how below. What is not portable is almost everything that makes the shop run: the storefront code, the checkout, the hosting, the integrations and, in practice, the day to day control. The storefront is built from cartridges in a proprietary architecture, the checkout is the platform's, the servers are Salesforce's, and the keys to the admin are very often held by your system integrator rather than by you. You own the contents of the house. You rent the house, and someone else has the only set of keys.

What moves cleanly	What needs mapping work	What is locked to the platform
Catalogue: products, variants, categories, prices, images	Order history, mapped to the new data model	The storefront cartridges and ISML templates
Customer records and addresses	Promotions and coupon logic, best rebuilt	The checkout flow and hosting
Content assets and static pages	Redirect map from old URLs to new	Saved cards and tokens held by the gateway
Inventory and price books	Customer passwords, which never export in the clear	The platform itself, and the revenue share

That middle and right columns are where the honest work and the honest limits sit. Passwords are stored hashed and cannot be carried across as usable passwords, which is true of every serious platform and is covered in depth in the pillar on what moves and what does not. Saved cards belong to the payment gateway, not to Salesforce, and whether they move at all depends on the gateway, not on the shop.

The export and the API, and what they really give you

Salesforce gives you three honest routes to your own data, and each has limits worth knowing before you plan around them.

The first is Business Manager, the platform's admin. It can import and export a site as XML archives, built against published schemas: catalog.xsd for the catalogue, customer.xsd for customers, order.xsd for orders, with coupon codes as the odd exception that comes out as CSV.³ A site export is a full snapshot of configuration and data that can be restored to the same or another instance, which is how integrators move a shop between sandboxes. Imports run in a chosen mode such as merge, Business Manager analyses the file before it commits, and, importantly, an order import does not update existing orders, so the history is a one way read of the past rather than a live sync.⁴ For a migration that is fine: you want a faithful copy of the past, not a two way bridge.

The second route is the API, and here Salesforce is mid transition. The older Open Commerce API, OCAPI, has a Data API that exposes catalogues, customers and orders for exactly this kind of extraction.⁵ As of April 2026 OCAPI is deprecated: Salesforce recommends its newer Salesforce Commerce API, SCAPI, for all new work.⁶ Deprecated does not mean switched off. The versioning policy sets no end of life date, commits to at least two years of notice before any retirement, and keeps OCAPI getting security and bug fixes in the meantime, just no new features.⁷ For a one off export that stability is on your side. If you are building anything long lived against the platform, build it on SCAPI.

The third thing to plan for is throttling. The storefront APIs sit behind load shedding and rate limits, and when you push too hard the platform answers with an HTTP 429 and a Retry-After header rather than more data.⁸ On top of that, B2C Commerce enforces governance quotas on API calls and on how long server side scripts may run.⁹ None of this blocks a migration, but it does mean a bulk pull of a large catalogue and years of orders has to be paced, batched and retried politely, not fired off in one loop. I plan exports to run overnight, in pages, with back off built in.

One more practical point sits under all three routes: you may not be able to do any of it yourself. On most Salesforce shops the integrator holds Business Manager access and the API credentials. Part of leaving is getting your own data out, and that can mean asking the party you are leaving to hand over the keys, or to run the final export for you. Put that request in writing early, because it tends to move slowly.

The traps that bite as you grow

Every platform has a few traps that only show up once you are committed. On Salesforce these are the ones I would flag before you sign anything, and the ones that make the strongest case for owning your shop instead.

The revenue share is the first and the heaviest. Because the contract scales with sales, the platform takes a bigger cut of a bigger business, and it does so whether or not your margins grew with your revenue. A good Black Friday is a good Black Friday for Salesforce too. On an owned shop the platform cost is roughly flat: hosting and maintenance do not care whether you turned over four million or nine. The whole point of moving is to stop paying a percentage of your own success.

The second is the one most owners underrate: you rarely hold the keys yourself. The cartridge and integrator model means the knowledge of how your shop works lives with an agency, and so does the admin access. That is comfortable while the relationship is good and expensive when it is not. Before you do anything else, find out who can log in to Business Manager as an administrator, and whether that is you.

The third is the storefront lock. Salesforce storefronts are built on the Storefront Reference Architecture, SFRA, as a stack of cartridges on top of a base cartridge you are told never to edit directly.¹⁰ The templates are written in ISML, a proprietary extension to HTML that exists only on this platform, and a working storefront needs at least one custom cartridge of your own.¹¹ None of that code comes with you when you leave. The design can be rebuilt, but it has to be rebuilt, and nobody should pretend the front end ports across.

The fourth is payments, and it is the one to flag first because it is the hardest. Saved cards and tokens live with the payment gateway or service provider wired into the checkout, not inside the Salesforce site archive. Whether a customer's saved card can move depends entirely on the gateway and its certification, and sometimes the honest answer is that customers re enter their cards. This is its own subject, and the payment tokens and saved cards spoke covers it properly. Decide the payment question before you decide the migration date.

The fifth is quieter but costs real money: URLs and search rankings. Your Salesforce storefront has a URL structure, and some of those addresses carry years of links and rankings. Move the shop without a complete redirect map and you throw that away on cutover day. Every old URL needs a permanent redirect to its new home, which is a mapping exercise I treat as part of the products and catalogue migration, because the product and category pages are where most of the value sits.

The honest move onto an owned Solidus store

A move off Salesforce onto a custom Solidus store is not a button, and I will not pretend it is. It is a build and a data migration run in parallel, and it is worth it when the shop you end up owning does what you need for a flat cost rather than a rising one.

The data itself follows the paths the rest of this series already maps in detail, so I will link rather than repeat. Customer accounts and addresses come across as records, with passwords reset rather than carried, in the way the customer accounts spoke describes. The catalogue, the part that migrates most cleanly, follows the products and catalogue guide. Order history comes across as a read only record of the past, enough for customer service and for a customer to see what they bought, as set out in the order history spoke. Payments and saved cards are the hard part, decided first, per the payment tokens spoke.

What you gain on the other side is ownership in the plain sense. Solidus is a Rails application under an open source licence, so there is no platform fee, no revenue share and no edition that unlocks your own checkout. The storefront, the checkout and the business logic are ordinary application code that your developer can read and change, and the shop runs on hosting you choose. If you want the longer argument for why that ownership matters, and who really holds your records on a hosted platform, who actually owns your business data makes the case. For how the numbers compare over time, the five year total cost of ownership works it through, and the broader platform comparison puts Salesforce next to the others.

A worked example

Let me make it concrete with an invented business, because a real example is clearer than a list of principles.

Calder Vale is a skincare brand in Leeds, selling direct to consumers across the UK and into Germany. It was put on Salesforce Commerce Cloud four years ago by an integrator, when the founders were told they needed an enterprise platform to look credible to retailers. The shop has done well: online turnover has grown from about 4 million to about 9 million pounds. That growth is the problem. Because the platform contract scales with sales, the bill has grown with the revenue, and the annual platform cost now swallows a chunk of margin that the founders would rather spend on product and people. They use one storefront, in two languages, with a fairly ordinary catalogue and no second brand in sight. They are paying for an engine built to run twenty brands and driving one.

When I look at a shop like Calder Vale, the first questions are not about design. They are the hard ones. Who holds the Business Manager keys, the founders or the agency? Which payment gateway is in the checkout, and will it move saved cards to a new shop or not? Are there any subscriptions or recurring charges running, because those are the hardest thing to move and have to be mapped before a date is set. Only once those answers are in hand does the rest follow: a Solidus build with the brand's real design, the catalogue exported through the Data API and the site archive, customers and order history migrated as the spokes describe, a full redirect map from the old URLs, and a rehearsed cutover in the quiet month after the Christmas peak.

The honest pitch to Calder Vale is not that Solidus is grander than Salesforce. It plainly is not. It is that they would own a shop that does what they actually use, on a cost that stops rising just because they had a good year.

When staying is the right call

I would be doing you a disservice if I only argued one way. There are shops I would tell to stay exactly where they are.

If you genuinely run several brands or several regions on one commerce engine, and switching that off would mean rebuilding and then running all of it yourself, the platform is doing real work for you. If you have an internal commerce team that lives in the tools every day, the complexity is not a tax, it is capability you use. If your order volumes are large enough that Salesforce's scale and support are worth more than the share you pay, the maths can favour staying. And if the revenue share, for your numbers, comes to less than what an owned build plus a capable team would cost you to run, then moving would cost you money and I would say so.

The question is never whether Salesforce is a good platform. It is a good platform. The question is whether you are the business it was priced for.

If the bill has stopped making sense

If the platform invoice has started to grow faster than the shop, and you cannot change your own checkout without raising a ticket, it is at least worth putting real numbers next to the alternative. Bring your contract, your last year of platform costs and your payment setup to a free workshop, and the first two weeks of work are on me. I will tell you honestly whether a move pays off for your shop or whether you are better off where you are. Sometimes the answer is to stay, and I will say that too.

eWeek, Salesforce Moves into E Commerce with Demandware Buy (acquisition of Demandware for about 2.8 billion US dollars, 2016), https://www.eweek.com/cloud/salesforce-moves-into-e-commerce-with-demandware-buy/ ↩
Salesforce, B2C Commerce pricing (editions Growth, Plus and Premium, billed annually, pricing on request), accessed 14 November 2026, https://www.salesforce.com/products/b2c-commerce-pricing/ ↩
Salesforce Trailhead, Business Manager Import and Export (site import and export as XML snapshots against published schemas for the catalogue, customers and orders, coupon codes as CSV, restorable to another instance), accessed 14 November 2026, https://trailhead.salesforce.com/content/learn/modules/b2c-import-export/b2c-business-manager-import-export ↩
Salesforce Trailhead, Configure Import and Export (import analysis and merge mode, order import does not update existing orders), accessed 14 November 2026, https://trailhead.salesforce.com/content/learn/modules/b2c-import-export/b2c-configure-import-export ↩
Salesforce Developers, B2C Commerce OCAPI Data API (data resources for catalogues, customers and orders), accessed 14 November 2026, https://developer.salesforce.com/docs/commerce/b2c-commerce/references/ocapi-data-api ↩
Salesforce Developers, The Advantages of SCAPI (OCAPI deprecated as of April 2026, SCAPI recommended for new projects), accessed 14 November 2026, https://developer.salesforce.com/docs/commerce/commerce-api/guide/why-use-scapi.html ↩
Salesforce Developers, OCAPI Versioning and Deprecation Policy (no end of life date set, at least two years of notice before retirement, security and bug fixes only after deprecation), accessed 14 November 2026, https://developer.salesforce.com/docs/commerce/b2c-commerce/references/b2c-commerce-ocapi/versioninganddeprecationpolicy.html ↩
Salesforce Developers, Load Shedding and Rate Limiting (HTTP 429 with a Retry-After header when a rate limit is reached), accessed 14 November 2026, https://developer.salesforce.com/docs/commerce/commerce-api/guide/throttle-rates.html ↩
Salesforce Developers, Governance and Quotas (quotas on API calls, resource consumption and script execution), accessed 14 November 2026, https://developer.salesforce.com/docs/commerce/commerce-solutions/guide/b2c-governance-and-quotas.html ↩
Salesforce Developers, SFRA Features and Components (cartridge stack over a base cartridge that should not be edited directly), accessed 14 November 2026, https://developer.salesforce.com/docs/commerce/sfra/guide/b2c-sfra-features-and-comps.html ↩
Salesforce Trailhead, Reference Architecture and Cartridges (ISML as a proprietary extension to HTML, a working storefront needs a custom cartridge), accessed 14 November 2026, https://trailhead.salesforce.com/content/learn/modules/b2c-cartridges/b2c-cartridges-ref-architecture ↩