BigCommerce is a fine platform until you outgrow it. The catalog model is sensible. The API is well-documented. The pricing is published. For merchants doing $5-30M, it works. The pain starts above that.

We have moved nine BigCommerce stores to Shopify Plus in the last three years. The reasons are remarkably consistent — and remarkably different from why people leave Magento or WooCommerce. This is the playbook for the move: what is actually different in the catalog model, how URLs map (and where they don't), the channel-selling consolidation, and what a clean 8-14 week migration looks like. Not sure you need Plus rather than another Shopify plan? See what Plus adds and what stays the same.

Why merchants leave BigCommerce

Four reasons come up in every BigCommerce → Shopify Plus discovery call we run.

The first is channel fees. BigCommerce's plan fee rises with your sales: each of its self-service plans has a sales limit. Past it, a Core or Growth store moves up a plan, and a Scale store, the largest of the three, pays a percentage on the sales above its limit. Performance, the plan above Scale, has custom pricing. BigCommerce's pricing page has the current figures, all before payment processing fees. Shopify lists the Plus plan's monthly fee for each contract term on its help center's Shopify Plus plan page, and says more complex, higher-volume businesses might pay a variable platform fee. For merchants doing $10M+, the math has been net-favorable to Shopify.

The second is theme constraints. BigCommerce's Stencil framework is competent but the marketplace is small — about 220 paid themes against more than 1,300 in Shopify's Theme Store. Custom theme work is supported but the build tooling lags. We have had clients spend six weeks waiting for a Stencil-compatible designer to be available; the same brief on Shopify finds three qualified builders within a week.

The third is the app ecosystem ceiling. BigCommerce has good apps for the basics — reviews, shipping, returns, search — but the long tail is shallow. Niche use cases (subscription billing with hold/skip, B2B price lists with company-level approval workflows, headless commerce with Hydrogen-style frontend) are well-served on Shopify and require custom builds on BigCommerce.

The fourth is B2B v3 limitations. BigCommerce shipped B2B Edition with company hierarchies, sales reps, quote requests, and net-terms. It works for simple B2B operations. The moment requirements include per-line custom pricing approval, multi-step quote workflows, or integration with an ERP that wants the order in a specific format, the gaps surface. Shopify's B2B is built into every plan from Basic up, with company accounts, catalogs, net terms and PO numbers, and on Shopify Plus you can add custom checkout fields with checkout UI extensions and checkout rules with Functions.

A note on what is NOT a reason: SEO performance. BigCommerce's SEO is fine. Migrations don't fix SEO problems they create new ones, and any merchant pitching "we want to migrate to fix our rankings" is going to be disappointed.

Catalog model differences

This is the hardest part of a BC → Shopify Plus migration and the most underestimated. BigCommerce and Shopify model products differently in three ways that matter.

First, option sets. BigCommerce lets you define an "option set" once — say, "Size: S, M, L, XL" — and apply it to many products. Update the option set, every product picks up the change. Shopify's closest match is to connect a product's options to a category metafield: the option values are shared, and renaming one, say black to graphite, updates every product it's connected to. Each product still carries its own variants. If you have 200 products sharing a "Size + Color" option set with 30 variants apiece, that is 6,000 variant rows on Shopify. That's well inside Shopify's limit of 2,048 variants per product, but some third-party themes stop at 100 variants, so check yours.

Second, modifiers vs variants. BigCommerce modifiers are per-product custom inputs (text, dropdown, file upload) that affect the cart but don't create separate SKUs. They map to either a Shopify variant (if they affect price/inventory) or a metafield + line-item property (if they are just data attached to the cart). The conversion is per-product, not programmatic.

Third, brands. BigCommerce has a separate "brand" entity with its own URL space (/brands/nike, /brands/adidas). Shopify has a vendor field on products and you can build /collections/nike-handle for the same purpose. The redirect map needs to handle /brands/* → /collections/* explicitly.

How BigCommerce's catalog maps to Shopify's: products stay products; option sets shared across products become each product's own variants; modifiers become a variant with a metafield, or a product option; brands become the vendor field or a brand collection; and custom fields become metafields.
The option set / modifier split on BC has to flatten into Shopify's per-product variants

We treat catalog modeling as its own discovery phase, separate from migration execution. Two weeks minimum for a 5K-SKU catalog. The output is a CSV — actually, several CSVs, one per Shopify object — that we can import in a known order: products, variants, metafields, then collections, then redirect rules.

The trap nobody flags upfront is custom fields. BigCommerce stores them as key/value pairs on products. Shopify's metafields are also key/value but they require a namespace and a typed definition to render properly in the admin and on the storefront. Migrating "color_family: Red" from BC to Shopify means: define a metafield namespace (product_attributes), define a key (color_family) with type single_line_text_field, and import the value into the typed metafield. If you skip the definition step, the data lands but doesn't show up in the admin, and your theme can't query it without manual API calls.

URL pattern mapping

BigCommerce has a more relaxed URL grammar than Shopify, which is both good (slugs can be cleaner) and bad (the redirect map has more edge cases).

BigCommerce lets each store pick its URL format. Its recommended setting, SEO Optimized (Short), serves products at /{product-name}/ and categories at /{category-name}/; the long format adds /products/ or /categories/ in front, and other settings put the category in a product's URL or follow a custom pattern. Admins can also give a single product a custom URL. We have seen catalogs that mix several of these, often inherited from a previous platform migration where someone wanted "cleaner" URLs. Shopify does not allow any of this — every product lives under /products/{handle}/, no exceptions. The redirect map must handle every pattern the old store used.

Category nesting is the other URL gotcha. BigCommerce supports nested categories: /categories/men/jackets/leather/. Shopify does not (collections are flat). The decision: pick the deepest leaf as the destination, redirect all parent paths up the tree to it, and use Shopify's menus (Content > Menus in the admin, separate from collections) to recreate the visual hierarchy. The SEO impact is minor — Google was indexing the leaf URLs anyway.

BigCommerce URL patterns and where they go on Shopify: /products/{slug}/ to /products/{handle}, /categories/{slug}/ to /collections/{handle}, /{product-name}/ to /products/{handle}, /{category}/{product}/ to /collections/{c}/products/{p}, /blog/{slug}/ to /blogs/news/{handle}, /brands/{slug}/ to a brand collection, and the account and sign-in pages, /account.php and /login.php, to /account, which Shopify sends on to its customer accounts.
BigCommerce's looser slug rules need normalizing before they map

The blog port is straightforward, but not by CSV. BigCommerce blog posts at /blog/{slug}/ map cleanly to Shopify /blogs/news/{handle}/, and Shopify has no CSV import for blog posts: they move with a migration app or through Shopify's API. Strip any inline shortcodes from the editor on the way (rare on BC, common on WooCommerce).

Account URLs need a few redirect rows of their own. On a Stencil storefront, BigCommerce's account page is /account.php and its sign-in page is /login.php. Redirect both to /account, and Shopify sends customers on to its customer accounts, as it does for its own account URLs, such as /account/login. What no redirect fixes is a link to one order: the orders you import get new IDs on Shopify, so an old link to an order can't land on the same order. Point those links at the customer's account instead, where the order list is.

Channel selling: multi-storefront → Shopify Markets

BigCommerce's multi-storefront feature is genuinely good. One catalog, multiple storefronts (different domains, currencies, locales, themes), shared inventory, separate checkout. Merchants who use it heavily find the Shopify equivalent — Shopify Markets — to be both more and less.

More, in that Shopify Markets handles currency, locale, payment-method routing, and tax collection automatically once configured, and integrates with Shopify Functions for region-specific logic. Less, in that you cannot have entirely different themes per market on a single Plus store. The same theme renders for every market with locale-specific content blocks. For brands that ran wildly different storefronts on BigCommerce — different product photography, different tone, different category structure — Shopify Markets feels constraining.

The pragmatic call: most BigCommerce multi-storefront setups don't need entirely different themes. The differences are usually currency display, language, and a handful of country-specific products. Shopify Markets handles all of that. If the storefronts genuinely need different themes (different visual brands, fundamentally different category structure), that is the case for multiple Shopify Plus stores rather than one with Markets.

Tax handling deserves a callout. BigCommerce ships with Avalara integration optional; Shopify's built-in tax calculation, Shopify Tax, covers sales in the United States, the European Union, the United Kingdom and Canada. Shopify Tax is free until your store reaches a sales threshold; after that, a percentage fee applies to orders with calculated tax, up to a maximum per order, and above $25 million in sales, Shopify sets the price through your Customer Success Manager. Run the math before assuming Shopify Tax is automatically the right choice; for high-volume merchants Avalara on Shopify Plus is sometimes cheaper at scale.

Customer + order import

Customer migration has one constraint: passwords don't port. Shopify can't import passwords from another store, because they're encrypted outside Shopify. That matters less than it used to: with Shopify's current customer accounts, customers sign in with their email and a one-time code, so there's nothing to reset.

The right pattern: import all customers WITHOUT triggering a welcome email. On cutover day, send a one-time mass email explaining the migration ("we have moved to a new platform; next time, sign in with your email and the one-time code we send you").

Order history porting is more important than customers realize. Shopify takes historical orders through its Admin GraphQL API: Shopify documents its orderCreate mutation (an API call that writes data) for importing orders from an external system. Its options decide whether inventory changes and whether customers get order and shipping confirmations; for an import, leave the confirmations off. Import them with a custom tag (migrated-from-bigcommerce) so you can filter them out of reports. Fee-bearing actions like refunds on these orders need to be handled out-of-band; Shopify will decline to refund a card it never charged.

The third import is product reviews. If BigCommerce was using its native reviews, the data lives in the product_reviews table accessible via the v3 API. Export it, transform it to whatever Shopify reviews app you're standardizing on (Judge.me, Yotpo, Stamped, Loox), import on cutover day or shortly after. Hold the reviews import until after the catalog is verified — the review imports reference product handles, and if a handle has changed since you exported, the review attaches to the wrong product or floats in limbo.

Apps that don't port

The app port is where merchants underestimate scope most consistently. BigCommerce lists over 1,200 apps in its marketplace; Shopify's App Store has thousands. The mapping is rarely 1:1.

Three categories of friction.

First, apps that have parallel implementations on both platforms but with different feature sets. Shipping calculators (ShipperHQ exists on both, but the Shopify version has more carriers); reviews (Yotpo/Stamped on both, but the data models differ); subscriptions (ReCharge on Shopify is the de facto standard; BigCommerce uses Bold or Rebillia, both with different schemas). Plan a feature-by-feature comparison before assuming "we use X on BigCommerce, we will use X on Shopify."

Second, BigCommerce-native features that don't exist on Shopify out of the box. The brand entity (mentioned above). Customer groups with native price overrides (Shopify has B2B with price lists, but the model differs). The "complex shipping" rule engine that BigCommerce ships natively (Shopify uses Functions that hide, rename or discount delivery options, or third-party apps).

Third, custom integrations. Most BigCommerce stores doing >$5M have at least one custom integration: ERP sync, marketplace feeds (Amazon, Walmart, eBay), 3PL handoff, custom CRM. None of these port automatically. Each is its own re-build on the Shopify side, typically 2-6 weeks of dev work depending on complexity. Budget for it from day one.

The pragmatic discovery question we ask in week one: "List every BigCommerce app you currently pay for, plus every custom integration that touches the BigCommerce API." The list is always longer than the merchant remembers. Walking through it line by line — keep / replace / drop — sets the realistic scope of the migration.

SEO + cutover

The SEO playbook for BigCommerce → Shopify is structurally similar to Magento or WooCommerce. The redirect map is the spine. Submit the new sitemap on cutover day. Watch GSC daily for the first two weeks, weekly for weeks three through six. Expect a 30-50% impressions trough in week one and a near-full recovery by week four if the redirect map is correct.

The BigCommerce-specific quirks: brand URLs (/brands/*) need explicit redirects to Shopify collections; naked-slug product URLs need explicit redirects (BigCommerce admins love them, Shopify doesn't allow them). Category nesting flattening means /categories/men/jackets/leather/ → /collections/leather-jackets, with /categories/men and /categories/men/jackets either redirecting to a parent collection or, if they were thin, left to answer 404 (not found).

The other BC-specific habit: review your structured data carefully. BigCommerce themes vary widely in what schema they emit; some emit Product + AggregateRating cleanly, some don't emit AggregateRating at all, some emit duplicate Product schema (one from the theme, one from a "rich snippets" app the merchant added years ago). The migration is a forcing function to clean this up. We always validate the new Shopify schema with the Rich Results Test on a representative product sample before cutover.

For a deeper field manual on the SEO side specifically, WooCommerce SEO guide covers the same territory with a different platform's quirks — the GSC monitoring playbook applies cleanly to BigCommerce too.

Timeline + budget

A clean BC → Shopify Plus migration for a 5K-15K SKU catalog typically runs 8-14 weeks. Larger catalogs take longer. The phases:

An 8–14 week migration in six phases: discovery (audit and scope), catalog (model and import), theme (build), app port (decisions), staging (QA and redirects) and cutover (DNS and monitoring).
Six phases — discovery owns the first three weeks because catalog modeling is the long pole

Discovery is three weeks. Catalog model walkthrough, URL audit, app inventory, custom integration scoping. The deliverable is a written migration spec the merchant signs off on before any code gets written.

Catalog import is two weeks. CSV preparation, dry-run imports to a development store, validation pass. The imports themselves take hours; the prep takes weeks.

Theme rebuild is three weeks for a "modern but not bespoke" theme — Dawn-based, with the merchant's brand applied. Custom themes (truly bespoke design + interactions) push to 6-10 weeks and shift the critical path.

App port and custom integration is two weeks running in parallel with the theme. Some apps install in an hour; the long tail (custom ERP sync, marketplace feeds) eats most of the time.

Staging + QA is one week. The merchant logs in to a development store, validates the catalog, runs test orders, signs off on the redirect map.

Cutover is the day itself plus a week of monitoring. Monday morning DNS flip, weekly GSC reviews for six weeks. Final sign-off when the impression curve recovers.

For budget, we scope and quote each migration after a short discovery call: the cost depends on catalog complexity, theme work, and the custom integration count, and larger catalogs and bespoke design cost more. The Shopify Plus plan's own fee is on Shopify's pricing page, plus transaction fees.

The biggest cost-saving lever is honest scope. Merchants who try to combine "migrate from BigCommerce" with "redesign the brand" with "implement the new B2B portal we have been talking about" end up with a 9-month project that should have been an 8-14 week migration followed by two follow-on projects. Sequencing matters. Migrate first, then rebuild on the new foundation. We push back on combined scope every time.

If you are evaluating a BigCommerce → Shopify Plus move and want a real estimate against your catalog and your app stack, talk to us. We will do the discovery walk-through and tell you what the cutover actually costs. For the cross-platform context, Magento → Shopify Plus playbook covers the same migration mechanics from a different starting platform, and the migration services overview is the end-to-end view of what an engagement looks like.