Migrating from Demandware (SFCC) to BigCommerce
What changes when you move an enterprise store from Salesforce B2C Commerce to BigCommerce: data model, cartridge logic, integrations, and SEO continuity.
Salesforce B2C Commerce (still widely called Demandware) and BigCommerce solve the same problem from opposite directions. SFCC gives you a deeply customisable platform where almost any behaviour can be overridden in a cartridge, at the cost of a licensing model tied to gross merchandise value and a development cycle that requires specialists. BigCommerce gives you a largely fixed core with an extensive API surface, at the cost of some things simply not being overridable.
That difference is the entire migration. Most of the work is not moving data; it is deciding what happens to the logic currently living in your cartridges, because a meaningful portion of it has no direct equivalent and has to be rebuilt as an application sitting outside the platform.
The data model is the easy part, with two exceptions
Products, categories, customers, and orders map across reasonably cleanly. Both platforms model a catalogue in broadly the same way, and BigCommerce's API accepts bulk imports well enough that raw volume is rarely the constraint.
Two areas reliably cause trouble. The first is SFCC custom objects: if your implementation stores business data in custom object definitions rather than in standard entities, none of it has a destination on BigCommerce and you will need either metafields or an external datastore. The second is price books. SFCC supports layered price books with complex precedence rules; BigCommerce handles customer-group and B2B pricing differently, and stores relying on deep price book nesting usually need that logic restructured rather than translated.
Custom objects
Inventory them early. Each one needs a decision: metafield, external service, or dropped. This is the most common source of scope discovered late.
Price books
Map the precedence rules explicitly before assuming customer groups will cover it. Nested price book logic rarely survives contact with a different pricing model.
Content assets and slots
SFCC content slots have no direct BigCommerce equivalent. Plan for widgets, page-builder regions, or a headless content layer depending on how much editorial control the merchandising team needs.
Cartridge logic is where the real estimate lives
Every SFCC implementation accumulates cartridges: some third-party, some written in-house, some inherited from an agency that is no longer involved. Before you can estimate a migration honestly, you need to know what each of them does and whether the target platform can do it natively.
A useful way to sort them is by where the logic has to end up. Some cartridge behaviour is configuration on BigCommerce and disappears entirely. Some becomes a BigCommerce app or a script in the storefront. And some (typically anything that intercepts the checkout or order pipeline deeply) has to move into a service that sits alongside the platform, because BigCommerce does not let you override those paths the way SFCC does.
That last category is what makes or breaks the business case. If most of your differentiation lives in checkout overrides, the migration is expensive and you should know that before committing, not during.
Checkout is the hard constraint
SFCC lets you rewrite checkout more or less arbitrarily. BigCommerce gives you a hosted checkout with defined extension points, or the Open Checkout route where you take on a forked checkout application and maintain it yourself.
Neither is worse in the abstract, but they are genuinely different commitments. Hosted checkout means accepting the platform's flow and losing some customisation you may currently have. Open Checkout gives the control back and hands you an application to maintain indefinitely, including keeping pace with upstream security updates. Teams that pick Open Checkout casually, because it sounds like the flexible option, tend to regret it about eighteen months later.
SEO continuity: the part that is cheap to get right and expensive to get wrong
SFCC and BigCommerce generate different URL structures by default. If you migrate without a redirect map built from a real crawl, you will lose rankings, and the loss will look like a mysterious traffic drop rather than an obvious error.
Build the redirect map from a crawl of the live site, not from the sitemap. Sitemaps routinely omit URLs that still have inbound links: old campaign landing pages, discontinued products with backlinks, paginated category URLs. Every one of those is a 404 waiting to happen.
Keep redirects to a single hop. Chains of two or three redirects are common when a store has migrated before, and each hop dilutes the signal and slows the crawl.
Crawl first, map second
A full crawl of the existing store, including URLs that no longer appear in navigation. Discontinued products with backlinks are worth more than their sales history suggests.
Product schema parity
Verify that Product, Offer and AggregateRating markup survives the template rebuild. Rich result eligibility is easy to lose silently during a replatform.
Stage behind authentication
A staging store that gets indexed creates duplicate content against your own live site, and it happens more often than anyone admits.
A realistic sequence
The migrations that go smoothly tend to follow the same order, and it is not the order that feels most productive at the start.
| Phase | What happens | Why here |
|---|---|---|
| Inventory | Cartridges, custom objects, integrations, price book rules | Determines whether the business case survives. Do it before design. |
| Data mapping | Schema-to-schema mapping with the gaps named | Surfaces the custom-object and pricing problems while they are still cheap. |
| Integration rebuild | ERP, PIM, tax, payment, search | Longest lead time and most external dependencies. Start early, finish late. |
| Storefront build | Templates, content regions, checkout decision | Fast once the data model is settled. Slow and wasteful before it is. |
| SEO map and QA | Redirect map, schema parity, crawl of staging | Needs the final URL structure, so it cannot start earlier. |
| Cutover | DNS, redirect deployment, monitoring | Rehearse the rollback before you need it. |
Common questions
Is BigCommerce actually cheaper than Salesforce Commerce Cloud?
Usually on licensing, and not always overall. SFCC is priced against a percentage of gross merchandise value, so its cost scales directly with your revenue whether or not you are using more of the platform. BigCommerce prices on plan tier with order-volume thresholds, which for a growing store typically lands lower and, more importantly, stays more predictable. Where the saving erodes is rebuild cost. If your SFCC implementation carries substantial checkout customisation or a large body of custom-object business logic, the one-time engineering to reproduce that on BigCommerce can consume several years of licensing savings. The honest way to answer this is to complete the cartridge inventory first and price the rebuild, then compare total cost over three years rather than comparing licence line items. Stores with straightforward catalogues and standard checkouts see the saving quickly; heavily customised enterprise B2B implementations often do not.
What happens to our Einstein product recommendations?
They do not migrate. Einstein is a Salesforce product and its trained models stay with the platform you are leaving. On BigCommerce you would move to either the native recommendation features, a third-party service such as a dedicated search and merchandising vendor, or a custom implementation against your own data. Practically, this means a cold start: whatever you adopt will need a period of traffic before its recommendations are as good as the ones you have been running. Plan for that in the cutover rather than discovering it in the first week, and consider capturing a baseline of recommendation-driven revenue beforehand so you can measure the gap honestly. Some teams run the new recommendation engine in shadow mode before cutover to shorten the warm-up, which is worth doing if your timeline allows it.
Can we migrate in phases rather than all at once?
Partially, and the useful split is usually by region or brand rather than by function. If you run multiple storefronts, moving one smaller site first gives you a genuine rehearsal with real traffic and real orders, and the lessons transfer. Splitting a single storefront by function (catalogue on one platform, checkout on another) is technically possible but creates a synchronisation problem that tends to cost more than the risk it removes. What you can reliably phase within a single store is the integration work: bringing ERP or PIM connections onto the new platform ahead of cutover, running them in parallel, and validating the data flow before anything is customer-facing. That reduces the size of the cutover itself, which is where most of the risk actually sits.
Services related to this guide
Tell us what you are running now
A written migration plan covering catalogue and customer data mapping, URL and SEO continuity, integration inventory, and a phased cutover sequence. Delivered before any build work is quoted.