Migrate From BigCommerce to Shopify: A Planning Guide

Migrate from BigCommerce to Shopify and the honest first finding is not a completion percentage — it is that the two platforms model a catalogue differently enough that no migration tool can copy the whole thing across unchanged. BigCommerce’s product options and modifiers, its customer groups and its B2B Edition data each have a structure Shopify does not share. A migration tool such as LitExtension or a bulk-data tool such as Matrixify moves products, customers and orders with little manual work, per each tool’s own documentation. What it does not do, on either path, is resolve a structural mismatch for you. The number worth benchmarking here is not speed. It is which of your store’s entities fall on the wrong side of that mismatch, identified before cutover rather than after.

What Actually Moves When You Migrate From BigCommerce to Shopify?

A migration from BigCommerce to Shopify moves products, customers and order history with comparatively little manual work on most tools; it does not, on either LitExtension or Matrixify’s own documentation, move BigCommerce’s free-text and file-upload modifiers, customer-group pricing logic or B2B Edition workflow data without a separate rebuild step.

Read the row, not the column: the entity that is blank or partial across both tools is the one that becomes a manual project, whichever path you choose.

The pattern in that table is not random. BigCommerce’s product options — a dropdown, a swatch, a radio button that sets a fixed SKU combination — are structurally close enough to a Shopify variant that a migration tool maps one onto the other directly. BigCommerce’s modifiers are a separate feature built for customisation that does not change the SKU: a free-text engraving field, a checkbox add-on, a file upload for custom artwork. Shopify’s variant system has no equivalent concept, because a Shopify variant is defined as a distinct, inventory-tracked SKU, not an arbitrary customer input attached to one. A modifier-heavy BigCommerce catalogue — personalised or made-to-order products, mostly — loses that customisation capability on day one of the new store unless it is rebuilt in Shopify as line-item properties or through a dedicated app such as Bold Product Options, and neither LitExtension’s nor Matrixify’s own documentation claims to do that rebuild for you.

How Should You Read the Migration-Coverage Numbers?

Migration-tool coverage is read as a checklist, not a scoreboard. A tool that migrates six of eight entity types has not migrated “most of the store” — it has left two entity types for someone to handle by hand, and which two matters more than how many.

Build the same table against your own catalogue before choosing a path. List every modifier type your BigCommerce store actually uses, every customer group and what it changes, and whether B2B Edition is active, then check each against what the tool’s own documentation — not a reseller’s summary — claims to move. A store selling standard configurable products with simple size or colour options is close to the straightforward case a migration tool is built around; a store with engraving fields, group-specific catalogues or an active B2B Edition rollout is not, regardless of what either tool’s marketing page implies about “full migration.”

Neither LitExtension nor Matrixify publishes a single completion percentage for a BigCommerce migration, and no independent third party audits one. That is why the honest read of “coverage” is entity by entity rather than a headline benchmark figure: a generic tool-to-tool comparison tells you what a vendor built the tool to move on a typical store. It does not tell you whether your store is typical.

How Do BigCommerce Customer Groups Map Onto Shopify?

They do not map onto a single Shopify feature — they split across two different mechanisms depending on what the group actually does.

BigCommerce customer groups do two jobs at once: they can set group-specific pricing (a wholesale group sees lower prices than retail), and they can control catalogue visibility (a group sees only the products assigned to it), per BigCommerce’s own customer-groups documentation. Shopify has no single native object that does both. The closest match is Shopify B2B’s company accounts and price lists — Shopify B2B covers the feature itself in more detail — but that is a company-account model built for business buyers, not a general customer-tagging system, and it requires B2B to be turned on rather than shipping as a default consumer-store feature.

A BigCommerce group used purely for a loyalty-tier discount on consumer accounts, with no purchase-order or net-terms behaviour attached, is the case migration tools handle worst: it is neither a standard customer record nor a true B2B company, so it usually gets rebuilt through a discount app that reads customer tags, applied at checkout rather than at the catalogue level. A BigCommerce group used for genuine wholesale — negotiated pricing, restricted catalogue visibility, a purchase-order workflow — maps more cleanly onto Shopify B2B’s company accounts and price lists, because both features were built to solve the same underlying problem. The step that gets missed is treating every customer group the same way during migration and defaulting all of them into Shopify B2B, when a loyalty tier and a genuine wholesale account need two different rebuilds, not one.

Where Do Teams Get the BigCommerce-to-Shopify Redirect Step Wrong?

The step most teams get wrong is not forgetting redirects entirely — it is redirecting the URLs they remembered and missing the ones a bulk rule cannot catch.

BigCommerce and Shopify structure product, category and brand URLs differently, so even a fully migrated catalogue lands on new paths after cutover. Google’s own site-move documentation states plainly that “301 and other permanent redirects don’t cause a loss in PageRank,” so the redirect itself is not the risk — the risk is coverage. A pattern-matching bulk redirect rule handles the predictable case, product and category URLs that follow a consistent structure, well. It does not handle BigCommerce’s brand pages, which sit on their own URL pattern separate from the product catalogue, or any custom landing page built outside the standard template — both of which a bulk rule silently skips because they do not match the pattern it was written for.

The sequence that catches what a bulk rule misses: export the old BigCommerce site’s full indexed-URL list from Google Search Console’s Index Coverage report before cutover, not after, and export the Links report separately, ranked by referring domain count. Redirect the pages carrying external links first and individually, since a link pointing at a URL that now 404s is a link Google can no longer credit to the new domain no matter how the rest of the site redirected. Then check brand pages and any custom landing page against the bulk rule by hand — the two categories most BigCommerce-to-Shopify redirect projects miss, because neither migration tool’s own redirect feature is built to know a brand page exists as a distinct URL type until someone tells it to look.

What Does a BigCommerce B2B Edition Migration Actually Need?

A BigCommerce B2B Edition migration needs two separate plans, not one — the price-list and company data that Shopify B2B can hold, and the quote-request and purchase-order workflow that almost never has a direct Shopify equivalent.

BigCommerce B2B Edition ships buyer-specific catalogues, quote requests, purchase-order checkout and invoicing built into the platform’s own admin, per BigCommerce’s own B2B documentation. Shopify B2B, covered in full in Shopify B2B, ships company accounts, tiered price lists, quantity rules and net payment terms — a comparable set of capabilities, built on a different data model. Matrixify’s own documentation lists dedicated Companies and metafield sheets, which makes it the practical route for moving negotiated price lists and company records rather than rebuilding them from scratch. Neither LitExtension’s nor Matrixify’s own documentation claims to migrate the quote-request or purchase-order workflow state itself — an open quote sitting in a buyer’s BigCommerce account does not arrive in Shopify as an open quote; it has to be resolved on the old platform before cutover or manually recreated after.

Verification here is a company-by-company check, not a spot check on a handful of orders. Once migrated or rebuilt company accounts and price lists are live in Shopify, pull a sample of the highest-volume B2B accounts specifically and place a real test order against each one’s assigned price list — checking that the price shown matches the negotiated rate on file, not the standard storefront price — before any wholesale buyer sees the new store. That reconciliation step, run on a schedule rather than once at go-live, is ops automation work, not a migration-tool feature, because no migration tool checks its own output against what the business actually expected to see.

Which Migration Path Fits a Store at This Size?

A store above the published $3M floor, with modifiers, customer groups or B2B Edition in active use, needs more than an entity-by-entity comparison to decide — it needs to weigh the manual-rebuild cost against each path’s price.

LitExtension prices each migration by the number of entities moved — run its own estimate for your store. Matrixify is priced per app plan rather than per migration and suits an ongoing bulk-data workflow, including the Companies and metafield sheets a B2B migration needs, better than a one-time cutover. Neither tool prices in a reconciliation job, a modifier rebuild, or redirect mapping for brand pages and custom landing pages — those sit outside both tools’ own scope, on both paths.

The choice is less about which tool claims the most entities and more about which entities your own store actually has that a straightforward migration leaves out. A catalogue built entirely on true variant options, standard consumer customer accounts and a URL structure that maps cleanly to product and category pages is close to the case both tools are built around. A catalogue carrying modifiers, active customer groups or B2B Edition data is not — the manual-rebuild hours those gaps create routinely exceed what a $59 starting price implies, and pricing the migration against an entity-by-entity comparison before choosing a tool is what keeps that gap from showing up as a surprise on the first invoice. Migrate From WordPress to Shopify covers the same discipline for a different source platform, where the specific gaps — reviews, discount codes — differ, but the method of finding them before cutover does not.

A BigCommerce-to-Shopify migration is not a one-time project once cutover is done. The entities that need a rebuild rather than a straight import — modifiers, group pricing, B2B workflow state, the redirect map — are also the entities most likely to drift out of sync if nobody owns checking them against reality afterward: a price list that migrated correctly on day one and silently stops matching a renegotiated wholesale rate three months later, a redirect rule that stopped matching a URL pattern nobody noticed changed. Building the scheduled check that catches that drift, rather than relying on a buyer to report the wrong price, is ops automation work — the same discipline that gets a migration through cutover cleanly is what keeps the resulting store correct afterward.