BigCommerce to Shopify Migration

BigCommerce to Shopify is the easiest migration in this cluster, and that is exactly why it goes wrong.

Both are hosted SaaS platforms with similar concepts, comparable admin interfaces, and overlapping feature sets. Products, variants, categories, customers, orders — everything has an obvious counterpart. The similarity invites a casual approach, and a casual approach walks straight into the handful of places where the platforms really differ.

Those differences are narrow but consequential, and they are where this article concentrates.

Why stores leave BigCommerce

The reasons are usually not about capability, which is worth acknowledging — BigCommerce is a capable platform and plenty of good stores run happily on it.

Ecosystem size. Shopify’s app store and partner ecosystem are substantially larger. Stores that want a specific tool, or want three agencies to choose between, find more of both on Shopify. This is the most common reason we hear.

Theme availability and design ecosystem. More themes, more designers familiar with the platform, more examples to work from.

Checkout and payment ecosystem. Shop Pay and the accelerated checkout options convert well, and the payment ecosystem is broad.

Hiring and handover. Finding developers who know Shopify is easier and cheaper than finding developers who know BigCommerce, which matters for continuity when your current team changes.

Native feature velocity. Shopify ships changes quickly, and the pace of native capability improvements — markets, B2B, checkout extensibility, functions — outpaces what stores often expect.

Where BigCommerce holds up better: some native functionality that Shopify requires apps for, including aspects of faceted filtering and certain B2B and customer-group features, plus no transaction fees on third-party gateways. If those matter to you, weigh them properly rather than assuming Shopify is simply better.

What moves without drama

Most of it, which is the pleasant part of this migration.

Products including variants, images, SKUs, prices, and inventory. Variant structures map more cleanly here than from any other platform.

Customers with addresses and order history. Passwords still do not move — that is universal.

Orders for historical reference.

Categories to collections, though hierarchy needs a decision rather than a copy.

Blog content, with the usual formatting attention.

Basic page content.

If your store is straightforward, a competent team can move the data in days rather than weeks. The project time goes elsewhere.

The differences that actually matter

Custom fields and product-level data. BigCommerce custom fields need mapping to Shopify metafields, with theme work to display them. Routine once identified, and easy to miss because they often render in places nobody thinks to check — a specification table halfway down a product page, for instance.

Faceted filtering. BigCommerce’s native product filtering on larger catalogues is stronger than Shopify’s out of the box. If your customers rely on filtering — and on a large or attribute-rich catalogue they do — budget for a search and filtering app and configure it properly. Discovering this after launch produces an immediate and visible drop in on-site conversion.

Customer groups and group pricing. BigCommerce supports customer groups with group-specific pricing and visibility natively. Shopify handles this through tags, apps, native B2B on Plus, or custom work. If you use customer groups meaningfully, scope this before committing to a plan, because it can be the thing that makes Plus necessary.

URL structure. The platforms structure URLs differently, and Shopify enforces its own prefixes. Your URLs will change, so you need a full redirect map — the same discipline as any other migration, and the place where an “easy” migration most often causes real damage precisely because the ease invites shortcuts.

Price lists. If you use BigCommerce price lists for different customer segments or channels, plan the Shopify equivalent explicitly.

Product options versus variants. BigCommerce distinguishes between options that create variants and options that do not — modifiers that add cost or capture input without generating a SKU. Shopify’s model differs, and personalised or configurable products relying on non-variant options need either line item properties, an app, or custom work.

Multi-storefront. If you run multiple BigCommerce storefronts, understand how that maps to Markets or separate Shopify stores before you start. It is an architecture decision, not a settings change.

App replacements. Your BigCommerce apps do not come with you. Most have Shopify counterparts, often better ones, but each needs identifying, choosing, configuring, and reconnecting to whatever it talks to.

Side by side: where the platforms diverge

A worked example: the “simple” migration that lost conversion

A tools and hardware retailer with around 4,000 SKUs migrated from BigCommerce to Shopify. The data moved cleanly, the theme looked good, redirects were in place, and organic traffic held steady — which everyone took as a successful migration.

Conversion fell 22% and stayed there.

Traffic was fine, so nobody looked at SEO. What had changed was how people found products.

On BigCommerce, their catalogue had been navigated almost entirely through faceted filtering: customers filtered by thread size, material, finish, and load rating to narrow 4,000 products down to the four they might buy. That filtering was native and heavily used — their own analytics had shown filter interactions on the majority of collection page sessions.

The Shopify build had collection pages with basic tag-based filtering on two attributes. Customers arrived on a collection of 400 products with no meaningful way to narrow it, scrolled, and left.

The fix was a proper search and filtering app configured against their full attribute set, with the attributes migrated into metafields so they were filterable, and filter options ordered by how customers actually searched rather than alphabetically. That took three weeks.

Conversion recovered to slightly above pre-migration levels within a month.

Nothing about that project was technically wrong. The data was clean, the redirects were complete, the site was fast. It failed because nobody asked how customers actually used the old store before rebuilding it — and on a platform-to-platform move where everything looks equivalent, that question is the one most likely to go unasked.

The plan, compressed

Because this migration is simpler, the plan is shorter — but none of these steps are optional.

Audit what your customers actually use. Not just what exists. Pull analytics on filter usage, search usage, which categories drive revenue, and how people navigate. This is the step that prevents the failure above.

Inventory custom fields, apps, customer groups, and price lists. Each with a decision.

Check your configurable products. Anything using non-variant options needs a specific plan.

Crawl the site fully before changing anything, with traffic data per URL.

Build the redirect map completely. Products, categories, blog, pages, and any filtered URLs with traffic.

Build and configure, with particular attention to filtering if your catalogue warrants it.

Migrate data to staging and check the hard cases — most variants, longest descriptions, unusual characters.

Verify before launch: test orders, tax and shipping, email flows, tracking, mobile on real devices.

Monitor ninety days, watching conversion and on-site behaviour as closely as traffic. This migration’s characteristic failure mode is a conversion problem with healthy traffic, which SEO monitoring alone will not surface.

Realistic timeline: four to six weeks for a straightforward store, longer if customer groups or configurable products need real work.

Things worth doing while you are here

A migration is a rare licence to fix accumulated problems, and this one leaves room because the data work is light.

Rationalise your catalogue. Products you no longer sell, duplicates, variants nobody orders. Migrating less is faster and leaves a cleaner store.

Rewrite your weakest product descriptions. Not the ones that rank — leave those alone during a migration — but the thin ones nobody has touched in years.

Fix your collection structure. Most stores accumulate categories rather than designing them. Rebuilding gives you a chance to structure around how customers actually shop, which is also an organic search opportunity.

Improve your product imagery standards. Consistent sizing and treatment across the catalogue.

Audit your app list before you rebuild it. Do not port a bloated stack. Decide what earns a place.

Get your metafield architecture right from the start. Retrofitting structured product data later is far more work than designing it now.

Just keep these separate from the migration itself in your own head, and do not let them delay the redirect work — which remains the part that can cause lasting damage.

Should you actually leave BigCommerce?

This deserves more scepticism than the other migrations in this cluster, because BigCommerce stores are usually not migrating away from pain. They are migrating toward an ecosystem.

That can be a perfectly good reason. It is also a weaker reason than “our platform is costing us six figures a year in maintenance”, and it means the cost-benefit needs more careful thought.

Good reasons to move. You need a specific app or capability that exists on Shopify and not on BigCommerce, and it matters to your business. You are struggling to find or keep developers who know your platform, and continuity is at risk. Your checkout conversion is weak and you believe Shopify’s checkout would be better. You want a design refresh and the Shopify theme and designer ecosystem makes that meaningfully easier and cheaper. You are planning international expansion and Shopify’s markets functionality fits your plan better. Your team is small and you want the largest possible pool of help available when something goes wrong.

Weaker reasons. Shopify is more popular. Your competitor uses it. You read that it is better. Your new marketing hire has only used Shopify. None of these are wrong exactly, but none of them justify the cost and risk on their own, and a migration undertaken for reasons this thin tends to be under-resourced — which is how the conversion failure described above happens.

Reasons to stay. You depend on native customer groups and group pricing and do not want to pay for Plus. You use third-party gateways where BigCommerce’s lack of transaction fees saves you real money at your volume. Your catalogue depends heavily on native faceted filtering and you would rather not add an app. Your store works, your team knows it, and nothing is actually broken.

That last one is worth dwelling on. Migrations consume attention as well as budget, and attention is usually the scarcer resource. A team spending three months on a migration is a team not spending three months on merchandising, content, acquisition, or retention — any of which might return more. The platform is rarely the constraint on a store’s growth, and “our platform is fine but unfashionable” is not a constraint at all.

If you cannot write down, in one sentence, the specific thing you will be able to do after migrating that you cannot do now, that is a signal to wait.

Preserving what BigCommerce did well

Something that gets lost in migration planning: your current store has strengths, and nobody documents strengths. The plan captures what must be rebuilt, not what must be matched.

Document how customers navigate. Filter usage, search usage, the path from landing to purchase for your main categories. This is the single most valuable thing to record before you rebuild, and the example above shows what happens without it.

Screenshot your product pages. Every element on them exists because someone put it there. When the new page is built, compare against the old one element by element and ask what happened to each — specification tables, stock messaging, delivery estimates, bulk pricing displays. Things vanish quietly.

Record your best-performing pages in full. Top collection pages, top product pages, top content pages. Save the HTML. You will want to check what they said.

Note your conversion rates by device and by page type before you start. Without a baseline you cannot tell whether the new store performs better or worse, and “it feels about the same” is not a measurement.

Capture your email flows and their triggers. These get rebuilt and subtly changed, and a broken abandoned-cart flow can go unnoticed for months while quietly costing money.

List what customers regularly praise or complain about. Support tickets and reviews tell you which parts of the experience matter to people. Protect the parts they like.

The bottom line

This is the most similar platform-to-platform move you can make, and the risk is complacency rather than complexity.

The data will move fine. What needs real attention is filtering if you have a large catalogue, customer groups if you use them, configurable products using non-variant options, custom fields, and — as always — a complete redirect map built from a full crawl.

And before you rebuild anything, spend an afternoon understanding how customers currently navigate your store. On a migration where every concept has an obvious equivalent, the thing most likely to break is not a feature. It is a behaviour nobody documented.

Frequently asked questions

How long does a BigCommerce to Shopify migration take?

Four to six weeks for a straightforward store, which makes it the fastest migration in this cluster. The data moves cleanly because the platforms share similar concepts, so the timeline is driven by rebuilding what does not transfer: apps, custom fields, filtering configuration, and anything using customer groups or non-variant product options. Stores with large attribute-rich catalogues should add time for search and filtering setup, and stores using customer groups meaningfully should add time for that. The redirect map and pre-launch verification take the same care as any migration regardless of how simple the rest feels.

Will my BigCommerce filtering work the same on Shopify?

No, and this is the difference most likely to hurt you. BigCommerce’s native faceted filtering is stronger than Shopify’s out of the box, and stores with large or attribute-rich catalogues often depend on it far more than they realise. Before migrating, pull analytics on how many collection page sessions involve filtering — if it is a significant share, plan for a search and filtering app, migrate your product attributes into metafields so they are filterable, and configure the filter options against how customers actually search. Treating this as a post-launch improvement produces an immediate conversion drop.

Do I need to worry about SEO on a BigCommerce to Shopify migration?

Just as much as any other migration, and the similarity between platforms makes complacency the main risk. URL structures differ and Shopify enforces its own prefixes, so most of your URLs will change and every one needs a 301 to its closest equivalent. Crawl the entire site before you change anything, with organic traffic per URL, so you have a complete record to redirect against and verify afterwards. Preserve titles and meta descriptions on pages that rank. The ease of the data migration says nothing about the SEO risk.

What about transaction fees — will Shopify cost me more?

Possibly, and it is worth calculating rather than assuming. BigCommerce does not charge transaction fees on third-party gateways; Shopify charges a fee unless you use Shopify Payments. If you are on a gateway you cannot or will not leave, model the cost at your actual volume before deciding, because at higher revenues the difference is material. If Shopify Payments is available in your market and suits you, the fee question largely disappears and you gain the accelerated checkout options, which often improve conversion enough to outweigh the difference.

Can I keep my BigCommerce theme design?

The design can be reproduced, but the theme itself cannot be transferred — themes are platform-specific. You have three options: pick a Shopify theme that resembles your current design closely and adjust it, commission a custom theme that matches your existing design precisely, or treat the migration as an opportunity to improve the design. Most stores choose the first for cost reasons and are satisfied. If you go with a redesign, be aware that changing platform and design simultaneously makes it harder to diagnose any performance change afterwards.

What happens to my BigCommerce apps?

None transfer, so each needs a Shopify replacement chosen, configured, and reconnected to whatever it exchanges data with. In most categories you will find more options on Shopify than you had, which is frequently part of the reason for moving. Two cautions: check that anything holding data you care about — reviews in particular — has a supported import path into your chosen Shopify equivalent before you switch, and treat the rebuild as a chance to audit rather than port. Stores routinely carry unused apps across a migration and pay for them for another two years.

Should I redesign at the same time as migrating?

Better not to, even though the temptation is strong since you are already rebuilding. When you change platform and design together and something performs worse afterwards, you cannot tell which change caused it, and each has a different fix. Migrate onto a theme close to your current design, confirm the numbers hold, then redesign as a separate project with its own baseline. The exception is when your current design is holding you back — in which case accept the diagnostic cost deliberately, and record your current conversion rates by device and page type so you have something to compare against.