Shopify 9 min read

Shopify to BigCommerce Migration: What Breaks

QodeBites card: what crosses the platform line in a Shopify to BigCommerce migration - products, customers and orders - versus what is rebuilt: apps, theme, wallets and automations

A Shopify to BigCommerce migration is the rare replatform where the data is the easy part. Both platforms are hosted SaaS, both hand you a catalogue export, and neither asks you to run a server. What does not cross the line is everything you built around the data — your apps, your theme, your checkout behaviour, your automations, and every wallet your returning customers already trust.

That is the trade: you keep your products and your customer list, and you re-buy your stack. Whether it is worth it comes down to a short list of things BigCommerce does natively that Shopify either charges for, gates behind Plus, or leaves to the app market. If your reason is not on that list, you are paying replatform cost to solve a problem a configuration change would have fixed.

What a Shopify to BigCommerce migration actually changes

Moving between two hosted platforms is a lateral move, not a change of ownership. Nobody hands you a server, a patch schedule or a hosting bill — which is the entire character of a move like leaving Shopify for self-hosted Magento. Here the infrastructure question simply does not arise.

So the risk sits somewhere else. It is that a dozen small capabilities you stopped noticing — a subscription app, a loyalty balance, a one-tap wallet, an automation that quietly tags suspicious orders — all disappear on cutover day, and each one needs a replacement, a rebuild, or a decision to live without it.

Decision diagram splitting migration reasons into four platform limits that justify moving to BigCommerce and four build limits that travel with you and should be fixed on Shopify instead
Only platform limits are solved by replatforming. Build limits follow you to the new platform.

The four reasons the move actually holds up

In practice only a handful of reasons survive scrutiny, and all of them are structural — things BigCommerce does inside the platform that Shopify either prices separately or hands to apps.

You run several storefronts from one catalogue

BigCommerce’s multi-storefront is native: one backend and one product catalogue serving several storefronts, each with its own domain, currency, price list and content. On Shopify the equivalent is separate stores, Shopify Markets, or Plus-tier expansion stores — each with its own approach to keeping catalogues in sync. If you genuinely operate several brands or regions off one inventory, this is the most defensible reason on the list.

Your payment gateway is not Shopify Payments

Shopify applies an additional transaction fee when you sell through a third-party gateway instead of Shopify Payments. BigCommerce does not charge transaction fees on top of any gateway. If Shopify Payments is not offered in your market, or you are contractually tied to a local acquirer, that fee is a permanent line item that scales with revenue rather than a one-off cost. For merchants outside Shopify Payments’ footprint this is often the real arithmetic behind the whole question.

You need B2B pricing without a Plus contract

Customer groups and price lists are native BigCommerce features: segment customers, give each group its own prices, hide categories per group. Shopify’s comparable depth lives in B2B on Shopify, which is a Plus feature, or in apps below that tier. If you are a wholesaler on a standard plan fighting your own pricing model with apps, the native model is a genuine fit — we compared the top of that market in BigCommerce Enterprise against Shopify Plus.

You have hit something Shopify structurally will not allow

The checkout is the clearest example. Shopify’s is deliberately locked down, and what you can and cannot change in it is a short, published list. BigCommerce gives more template-level control over the storefront and is more open at the checkout layer. A genuine structural requirement that Shopify refuses is a real reason to move. “We want it to look different” is not.

Notice what is absent from that list: app costs, theme frustration, a slow store, a support experience, or a poor conversion rate. Those travel with you.

What does not survive the move

Here is the honest inventory. The left column is what everyone budgets for; the right column is what actually sets the timeline.

Asset What happens to it What it costs you
Products, variants, images Transfer as data, but the model is re-shaped Catalogue mapping time
Customer records Transfer; passwords do not A forced reset for every account
Order history Imports as records, not as live orders A dual-admin window for returns
Apps None transfer Re-procure or rebuild each one
Theme (Liquid) No path to Stencil A full front-end rebuild
Shop Pay and accelerated wallets Shopify only Returning customers lose one-tap checkout
Shopify Flow automations Shopify only Rebuilt in new tooling or done by hand
Shopify POS Shopify only A separate retail decision
Subscriptions and loyalty balances Live in apps, not the platform Re-established with a new vendor
URLs Every path changes A complete redirect map

Two of those rows are the ones that actually hurt.

The theme is a rebuild, not a port. Shopify themes are Liquid with Online Store 2.0 sections; BigCommerce themes are Stencil, built on Handlebars. There is no converter, because the two template languages express different object models. Budget a storefront build, not a re-skin.

The wallets are the quiet one. Shop Pay exists only on Shopify. Every returning customer who has ever checked out in one tap will, on the morning of cutover, be asked to type their card number in again. That line rarely appears in a migration plan, and it lands squarely on your most loyal segment.

The catalogue re-shapes more than you expect

BigCommerce separates options, which generate SKUs, from modifiers, which change price or behaviour without creating one. Shopify models nearly everything as a variant. So a catalogue that exploded into variants for gift wrapping, engraving or a delivery upgrade usually collapses considerably on arrival — which is good housekeeping, and a mapping decision you want to make deliberately before the import rather than halfway through it.

Diagram contrasting Shopify's variant grid where every option combination creates a SKU with BigCommerce's split between options that generate SKUs and modifiers that do not
Shopify makes every combination a variant. BigCommerce splits SKU-generating options from modifiers, so inflated catalogues collapse.

Your URLs get shorter, and that is a redirect project

Shopify forces a prefix on almost everything: products sit under /products/, categories under /collections/, editorial under /blogs/, static content under /pages/. BigCommerce lets you set the path, so most merchants flatten the structure on arrival and /products/blue-linen-shirt/ becomes /blue-linen-shirt/.

That is an improvement, and it is also a change to every indexed URL you own. Two Shopify paths can collapse onto one BigCommerce destination where a product sat inside several collections, so the map is not reliably one-to-one. The discipline does not change with direction: crawl first, map every live URL, and ship the redirects with the launch rather than after it. The method is written up in building a 301 redirect map that survives a replatform, and the platform-level differences are worth reading first in our Shopify vs BigCommerce SEO comparison.

URL mapping diagram showing Shopify prefixed paths for products collections and pages being rewritten as flat BigCommerce paths, with two collection paths collapsing onto a single destination
Every path changes shape, and collection-nested products can collapse many-to-one. The redirect map is the whole SEO risk.

The cheaper test to run first

Before scoping anything, write down the single thing driving the move. Then decide whether it is a platform limit or a build limit.

Most reasons merchants give are build limits. A theme that will not do what you want is a theme problem. A checkout that converts poorly is usually a shipping, payment-method or form-length problem, none of which change when the platform does. A stack that costs too much in subscriptions is an app-consolidation problem — and consolidating is a fraction of a replatform in both cost and risk.

Platform limits are the ones a migration genuinely solves: the transaction fee on a third-party gateway, native multi-storefront, native B2B pricing below the Plus tier, and a checkout requirement Shopify structurally refuses. Four things. If your reason is not one of them, the honest recommendation is to stay and fix the build, which is exactly what a free Shopify store audit is for.

If you are going anyway, the order of operations

The mechanics are direction-agnostic. We documented them in detail for the opposite move, and the step-by-step of a BigCommerce to Shopify migration applies almost line for line in reverse. The short version:

  1. Inventory before you touch anything. Crawl the live site, export the full URL list, and write down what every installed app actually does. The app inventory is the step everyone skips and everyone regrets.
  2. Rebuild the storefront natively in Stencil. Do not try to reproduce your Liquid theme; design for what the new platform does well.
  3. Decide the catalogue mapping first. Options versus modifiers is a modelling decision, and making it during the import is how catalogues end up wrong in both systems.
  4. Move data in staged, verified passes and reconcile counts after each one, rather than in a single import you then have to trust.
  5. Build and test the redirect map against the crawl, not against a spreadsheet of what you believe exists.
  6. Cut over on a plan that has a rollback, and keep the old admin readable for as long as your returns window runs — pre-migration orders are records in the new system, and refunds against the original transactions still belong to the old gateway.

Frequently asked questions

Will I lose SEO moving from Shopify to BigCommerce?

Not inherently. Rankings are lost by breaking URLs, not by changing platform. Every path changes in this move, so the redirect map is the entire risk surface: ship it with launch, keep it permanently, and expect a few weeks of re-crawl noise before positions settle.

Do my customers have to reset their passwords?

Yes. Passwords are stored as one-way hashes and no platform exports them, so accounts arrive without credentials. Plan the reset as part of your launch communications rather than letting customers discover it at checkout.

Can I keep my Shopify apps on BigCommerce?

No. Apps are built against a specific platform’s APIs and admin, so each one becomes a fresh decision: find an equivalent, rebuild the function, or drop it. Inventory them before scoping the project — the list is always longer than anyone remembers.

Is BigCommerce cheaper than Shopify?

It depends on your gateway and your app spend, which is why a like-for-like figure cannot be given honestly. The one structural saving is the absence of a transaction fee on third-party gateways; against it sit a storefront rebuild, re-procured apps, and BigCommerce’s own plan pricing, which is tiered on sales volume. We set out the cost lines on both sides in the Shopify vs BigCommerce comparison.

The takeaway

A Shopify to BigCommerce migration is a stack swap wearing the costume of a data project. The catalogue and the customer list cross the line without much drama. The apps, the theme, the automations and the wallets do not, and rebuilding them is where the budget actually goes.

Four reasons justify the move: native multi-storefront, no transaction fee on a third-party gateway, native B2B pricing without a Plus contract, and a structural checkout requirement Shopify will not meet. If one of those is genuinely your reason, plan the URLs first and the theme second. If it is not, the cheaper answer is almost always to stay and fix what you have.

Share X in wa
Mohamed ElQadi
Mohamed ElQadi Tech Lead @ Qode Bites

I help business owners untangle the mess between their website and their revenue — performance, conversion, and the unglamorous fixes that move numbers. Egypt + US.

Follow QodeBites on LinkedIn →
• FREE PLAYBOOK

The E-Commerce
Growth Playbook

17 moves that turn a store into a revenue machine — the exact levers our team pulls for the brands we build and grow.

  • Convert more of the traffic you already pay for
  • Speed wins that lift revenue on every visit
  • Retention flows that make the second sale cheaper
  • Ad math so you scale in profit, not blind

Get the free PDF

Enter your details and we’ll send it straight to your screen.

No spam — the guide now, and the occasional useful email. Unsubscribe anytime.

More Insights

Discover more articles, expert perspectives, and practical insights on software development, product design, emerging technologies, and digital innovation.

Ready to light it up?

Start a Project

Your Trusted Growth Partner
For Startups And Enterprises

From first concept to final deployment, Qode Bites delivers everything needed to take your idea live — with seamless setup, performance-ready infrastructure, and expert support every step of the way. Book a free 30-minute strategy call.

What We'll Cover

  • Current store performance
  • UX and conversion bottlenecks
  • Growth opportunities
  • Recommended action plan
Book a Strategy Call

June

FriSatSunMonTueWedThu

Sat, June 2