Migrate
BigCommerce to Shopify Migration
Options generate variants and modifiers do not — and none of BigCommerce’s 12 modifier types has a catalog-native home on Shopify. That remapping, not the import, is the project.
Migrating from BigCommerce
What breaks
Multi-Storefront is the architectural one. BigCommerce runs genuinely separate storefronts off a single catalogue, each with its own domain, theme, currency and pricing. Shopify has two things that resemble it and neither is it: Markets localises one storefront, and Plus expansion stores are separate instances. If your storefronts currently share a catalogue and diverge on theme and price, one of those two models has to absorb that, and both change how the business operates day to day rather than just how it is built.
Complex Rules have no counterpart at all. BigCommerce evaluates combinations of modifier selections to change price, weight, availability or the product image. Shopify has no engine that evaluates combinations of non-variant inputs. Rules like that end up as variants if the whole combination space can be enumerated inside three options, as theme-side line-item properties with the pricing solved somewhere else, or as an app.
Multi-tenant category trees, assignable per channel, collapse to one collection set for the store. If different channels currently see different category structures over the same products, that difference has to move into navigation, collection membership, or separate stores.
And the theme is a rebuild, with three named structural breaks rather than a vague "themes are different". Stencil is Handlebars; Shopify is Liquid, and there is no transpilation path between {{#if}} and {% if %}. Stencil configures through file-level config.json and schema.json; Shopify sections carry an inline schema block inside each section file. And Stencil has a Grunt and Sass build pipeline with nothing to migrate into, because Shopify compiles Liquid server-side. We found no Stencil-to-Liquid converter — which is not a proof that none exists, but it is the basis on which you should plan.
Data model differences
The core mismatch is that BigCommerce splits product inputs in two and Shopify does not. Options generate variants: BigCommerce’s own documented example is a sneaker with 4 options producing 270 variants. Shopify allows 2,048 variants, so the count is fine — but it allows only 3 options, so that sneaker natively exceeds the ceiling before a single variant is counted.
Modifiers are the other half, and the harder one. They are non-variant inputs across 12 types — date, checkbox, file, text, multi_line_text, numbers_only_text, radio_buttons, rectangles, dropdown, product_list, product_list_with_images and swatch — with file uploads capped at 8MB, and BigCommerce is explicit that a modifier cannot produce a variant. None of the 12 has a catalog-native home on Shopify. They become line-item properties rendered by theme code, or a paid app, and whatever price adjustment a modifier carried has to be re-implemented separately from the catalogue.
This is the most under-estimated part of a BigCommerce migration, and the reason is that it looks like importing products. It is not. It is a per-SKU merchandising decision — for each product, which inputs become options, which become metafields, which become line-item properties, and which stop existing. That decision lands on your team, and Shopify’s own escape hatch does not automate it: Combined Listings requires manually configuring separate products into a group, and is capped at 2,000 combined variant option values.
URL structure changes
BigCommerce autogenerates a flat, root-level slug and lets you override it completely. The default product URL is example.com/blue-widget — no forced segment, no prefix. Shopify’s prefixes are fixed and not redirectable: /products/, /collections/, /pages/ and /blogs/, with only the handle after them editable. Which means every product and every category URL on the store changes. The redirect map here is the entire catalogue plus the entire category tree, not a list of exceptions — so it is a volume problem with a known shape, which is the easier kind.
There is one thing that gets better, and it is worth naming because it is counter-intuitive. BigCommerce’s flat namespace has to be unique across all entity types: a product and a category cannot both claim /nike. Shopify’s prefixes partition the namespace, so /products/nike and /collections/nike coexist without conflict. Shopify’s rigidity removes a whole collision class that BigCommerce stores work around today. That is our reading of two documented behaviours rather than a claim either vendor makes — but if you have been suffixing category slugs to dodge collisions, you can stop.
Common apps
| App | Shopify equivalent |
|---|---|
| Complex Rules | No equivalent — nothing on Shopify evaluates combinations of non-variant inputs |
| Product modifiers (12 types) | Line-item properties via theme code, or a paid app. No catalog-native home. |
| Multi-Storefront | Markets (one storefront localised) or Plus expansion stores (separate instances). Neither is the same architecture. |
| Multi-tenant category trees | One collection set per store |
| Stencil / Cornerstone theme | Rebuilt in Liquid. No Stencil-to-Liquid converter found. |
| Page Builder regions (config.json / schema.json) | Sections and blocks with an inline schema in each section file |
Questions
Questions we get asked
Can our modifiers just become variants?
Some can. If a modifier’s choices are a fixed enumerable set and the product still fits inside three options and 2,048 variants, it can become an option. Most cannot, by definition: text, multi_line_text, numbers_only_text, file, date and product_list modifiers are inputs, not SKUs, and there is no variant that corresponds to "customer typed their name here". Those become line-item properties, which means the theme renders them and something other than the catalogue applies the price.
What happens to Complex Rules?
They are rewritten as something else or they stop existing. Shopify has no rule engine that reads a combination of modifier selections and changes price, weight, availability or image. Enumerate the rules first — most stores have far fewer live rules than they think, and a rule count is the single most useful number for scoping a BigCommerce migration.
We run four storefronts off one catalogue. How does that map?
Two options, and they are genuinely different. Shopify Markets keeps one storefront and localises it — one theme, one catalogue, per-market pricing and domains. Plus expansion stores give you separate instances, which is closer to Multi-Storefront in feel but not in operation: settings, products, collections and inventory are not synced between Shopify stores, so four storefronts becomes four catalogues to keep aligned, permanently.
Is this migration worth doing at all?
Sometimes it is not, and BigCommerce is the platform in this family where that answer comes up most. The two are close enough in tier that if your merchandising leans hard on modifiers and Complex Rules, you are paying to lose capability and then paying again to rebuild the workaround. The cases where moving reads well are usually about the app ecosystem, the checkout, or the people who have to operate the store — not about the catalogue, where BigCommerce’s model is in places richer than Shopify’s.
Why is there no timeline on this page?
Because the driver is the number of products carrying modifiers and Complex Rules, not the number of products. A 40,000-SKU catalogue of plain options can move faster than a 400-SKU catalogue of configurable ones. We would rather count your modifiers than publish a range.
Moving from BigCommerce?
We’ve mapped what breaks and what doesn’t — tell us about your store and we’ll scope the actual work.