Most articles about moving from BigCommerce to Shopify are written by people who have never done one. You can spot them quickly. They still tell you Shopify caps you at 100 product variants.
Shopify raised that limit to 2,048 in October 2025. If a guide is nine months out of date on the single most important number in the whole migration, it is not a guide. It is filler.
I have run these migrations. BigCommerce to Shopify, WooCommerce to Shopify, Magento to Shopify, and in the other direction too. So this is the version I would give you on a scoping call. What moves cleanly, what quietly does not move at all, and where the money actually goes. Because the data migration is the cheap part, and almost nobody says so.
The reason people leave changed in 2026
For years BigCommerce had one killer argument. No transaction fees. Run any payment gateway you like and BigCommerce takes no cut, while Shopify charges you a penalty for using anything other than Shopify Payments. That was real, it was defensible, and it won BigCommerce a lot of merchants.
In its 2026 pricing update, BigCommerce introduced a fee on payments taken through providers outside its embedded list. In shape, it looks a lot like the thing it spent a decade telling people Shopify did.
Go and read the current BigCommerce pricing page yourself before you make a decision on it. I am not going to quote you percentages I cannot verify at source today, and pricing pages move. But the direction is not in dispute, and the headline reason to stay on BigCommerce rather than Shopify got a lot weaker.
The second push is quieter and it targets growing stores specifically. BigCommerce upgrades your plan automatically when your sales cross a threshold, and in the 2026 restructure those thresholds came down. So the same revenue that kept you on one plan last year can put you on a pricier one this year. If you are growing, you pay for the privilege on a schedule you do not control. Shopify prices on features, not on how much you sold.
Where BigCommerce is still better, and you should know before you move
This is not a one-sided decision. If I scope a migration and find one of these, I will tell you to think harder about it.
Multiple storefronts. BigCommerce lets you run several storefronts on standard plans without paying per store. The equivalent on Shopify effectively means Shopify Plus, which is a different order of monthly cost entirely. If you run three brands from one catalog, do that maths properly before you move. This is BigCommerce’s strongest surviving advantage and it is not close.
Filtered search out of the box. BigCommerce gives you faceted search natively. On Shopify you are either using the free Search and Discovery app, which is fine but basic, or you are paying for a search app every month, forever. That is a real running cost nobody puts in the migration quote.
Complex product options. The big one. It gets its own section, because it is where most BigCommerce migrations go wrong.
What used to be on this list and is not any more: B2B. Shopify opened native B2B to its standard paid plans in 2026. Company profiles, catalogs, volume pricing, payment terms. If you looked at Shopify for wholesale two years ago and walked away, the answer today is different. BigCommerce still leads on quoting, invoicing and buyer portals, so a complex quote-to-cash operation is not a slam dunk. But the gap narrowed a lot.
The thing that actually breaks: modifiers are not variants
If you take one thing from this post, take this.
BigCommerce has two different concepts for product options and they are not the same thing.
Variants are combinations that produce a real, distinct, purchasable SKU with its own inventory. Small blue shirt is a different SKU from large blue shirt. These map onto Shopify variants cleanly. No drama.
Modifiers are the personalisation fields. A text box for the engraving. A file upload for the customer’s logo. A date picker. A checkbox that adds gift wrapping for fifteen dollars. These are not SKUs. They have no inventory.
Shopify has no native equivalent for modifiers. None. They do not become variants, because they are not variants. They have to be rebuilt as line item properties, which means theme work, or an app, or a Shopify Function if the modifier changes the price.
Price-adding modifiers are the worst case. “Add fifteen dollars for engraving” is trivial on BigCommerce and genuinely fiddly on Shopify, because there is no native way to attach a price to a line item property. You are buying an app or writing a Function.
So before anyone quotes you a price, go and count how many of your products use modifiers. That number, not your SKU count, is the true complexity of your migration.
I mean that literally. A 400 product catalog full of personalisation fields is a harder job than a 40,000 product catalog of plain variants. SKU count is the number everyone asks about on the first call and it is close to meaningless on its own. The largest catalog I have moved was around 140,000 SKUs, and the cataloging itself was never the hard part. The hard part is always the products that do something unusual.
The limit that matters is not the one everyone quotes
Here are the current numbers, and I want to be precise, because nearly every competing article gets these wrong.
- Shopify allows 2,048 variants per product. That changed on 15 October 2025 and applies to every plan at no extra cost.
- Shopify still allows only 3 options per product. That has not changed.
- Shopify allows 250 media files per product.
Read those again. The variant ceiling went up twenty times over. The option ceiling did not move at all. So the real constraint on your catalog is not how many combinations you have. It is how many dimensions you have.
Colour, Size and Material is fine. Colour, Size, Material and Fit is four options, and Shopify will not take it. Something has to give. You demote a dimension to a metafield, or turn it into a line item property, or split the product into several products. No automated tool makes this decision well, because it is a merchandising decision, not a data one. A human has to choose.
There is also a trap buried in that 2,048 number. The higher limit is delivered through Shopify’s newer GraphQL product APIs. Shopify’s own changelog warns that apps still built on the older REST product APIs may have a downgraded or broken experience with products over 100 variants. So if you have a big catalog, audit your intended app stack for REST dependency before you commit to it. Discovering this after launch is a genuinely bad day.
URLs: the part that costs you traffic
Do not skip this section. This is where migrations lose rankings.
BigCommerce puts products at the root. Your product lives at /blue-widget/. Your category lives at /mens/shoes/boots/, nested, also at the root. Nothing has a prefix.
Shopify does not work that way. Products live at /products/handle. Collections live at /collections/handle, and Shopify collections are flat. There is no nesting. Your three level category tree collapses into one level.
Two consequences fall out of that and both are expensive.
First, every single product and category URL on your site changes. Not some of them. All of them.
Second, and this is the part people miss, you cannot solve it with a handful of pattern rules. Because BigCommerce URLs carry no prefix, there is no rule that turns /blue-widget/ into /products/blue-widget without also catching /about-us/ and /contact/. You need a genuine one to one redirect map, line by line, for every URL that has ever ranked or been linked to.
Build that map from reality, not from your product export. Crawl the live site. Pull your top pages from Google Search Console. Pull your backlinked pages from Ahrefs or Semrush. Read your server logs. You are hunting for the orphaned page that still ranks, the old post someone linked to in 2019, the image URL that quietly pulls traffic. Your product CSV knows about none of those.
Shopify takes redirects as a CSV import under Navigation, so once you have the map, loading it is quick. Building the map correctly is the actual work.
Google’s guidance is worth following here: expect some ranking fluctuation during a move, and keep your redirects in place for at least a year.
In every migration I have run, the redirect map is the piece that decides whether the client is happy in three months. Nobody has ever come back to me upset that a section of the theme was two pixels out. People come back upset when a product page that used to rank stops existing. The theme is what you look at. The redirects are what pays you.
What does not come with you
Customer passwords. Never. They are hashed at the source and unreadable, by BigCommerce, by me, by anyone. Your customers land in Shopify deactivated. Since Shopify’s new customer accounts are passwordless, the clean answer is to launch on those, so there is no password to migrate and no reset wave to manage. If you do send account invites instead, send them a day or two after launch, not the same afternoon. Do not put a password reset wave and a launch on the same day.
Reviews. Native BigCommerce reviews do not move. You rebuild them in a reviews app. This is not cosmetic. Reviews feed the star ratings in your search results, and losing them costs you clicks on every product page that had them.
Gift cards. Outstanding balances are a financial liability, not a data field. They do not transfer. Export the balances, recreate them, and decide how long you will honour the old codes manually. Treat it as a finance task and get your accountant in the room.
Customer groups and wholesale pricing. BigCommerce customer groups have no direct Shopify equivalent. Shopify models B2B with company profiles and catalogs, which is a different shape entirely. Tiered wholesale pricing is a re-architecture, not a mapping exercise. Scope it separately or it will eat your timeline.
Subscriptions. They do not move. Rebuilding them on a Shopify subscription app is the easy half. Migrating the stored payment tokens for your existing subscribers is the hard half, and it needs a conversation with both payment providers early rather than late.
Where the money actually goes
Here is what surprises people. Moving the data is a small slice of the effort.
The catalog import itself, on a well prepared store, is a day or two of work. What costs real time is the theme rebuild, the modifier re-architecture, the redirect map, and reassembling your app stack on the other side. That is where the weeks go.
So when you see a few hundred dollars quoted for a BigCommerce to Shopify migration, understand what you are being quoted for. That is the price of running a tool. It is not the price of the project. The tool moves rows. It does not decide what happens to your four option products, it does not rebuild your engraving field, and it has no idea which of your old URLs still earns you money.
Briefly on tooling. Shopify’s free Store Importer is fine for a small, simple, single variant catalog and genuinely weak beyond that, particularly on variants. Matrixify is what I reach for on anything complex, mostly because it has a dry run mode that hands you a reviewable file before it commits anything, which on a risky migration is worth more than any other feature on the list. Cart2Cart and LitExtension are one and done services that work well enough for straightforward catalogs. None of them solve modifiers. You solve modifiers.
A sane order of operations
- Count your modifier products. That number sets your real scope.
- Find every product with more than three option dimensions. Decide, per product, what gets demoted. Do this before anyone writes a line of code.
- Audit your intended apps for REST API dependency if you have high variant products.
- Build the redirect map from crawl data, Search Console and your backlink profile. Not from the product export.
- Import into a development store, and run a dry run first if your tool offers one.
- Rebuild reviews, subscriptions and gift card balances as separate workstreams with their own owners.
- Launch. Load the redirects the same hour, not the next day.
- Send account invites a day or two later, once you are not also firefighting.
- Watch Search Console for two months. Some movement is normal. A cliff is not.
The short version
A bigcommerce to shopify move is not really a data project. The data is the easy bit. It is a merchandising decision about your option structure, a rebuild of everything BigCommerce gave you natively that Shopify expects an app to do, and above all a redirect exercise that decides whether you keep the traffic you spent years earning.
Get the redirect map right and the rest is recoverable. Get it wrong and you will feel it for six months.
I have done these migrations, in both directions, and the pattern is always the same. The catalog is fine. The options and the URLs are where the work is.
If you want a second pair of eyes on your option structure before you commit to a platform move, send me your catalog and I will tell you honestly whether this is a two week job or a two month one.
