How to Migrate a Large Catalog from BigCommerce to Shopify Without Losing Products

Large BigCommerce to Shopify migrations fail in the middle for a predictable reason: a catalog is not counted in products, it is counted in rows, and a single product with many variants and images can occupy dozens of spreadsheet rows. A catalog of 34,000 export rows may be only a few thousand products - but if your import file or tool limit is measured in a different unit, the job stops partway and the counts stop matching. The data is usually intact; the counting model is wrong. The fix is to reconcile row math and structural limits before import, validate with a dry run, and migrate in batches, with 301 redirects staged for every URL that changes. Plan for one to three dry-run cycles before a clean cutover.

Key Facts

• One product becomes many rows in Shopify's CSV format: one row per variant, plus an additional row for each extra image (up to 250 images per product). '34,000 rows' and '34,000 products' are almost never the same number.
• Migration tools cap jobs in products, not rows - Matrixify's Big plan handles up to 50,000 products per job, counted as products with their variants.
• Shopify now allows 2,048 variants per product for all merchants (raised from 100 in October 2025), and stores holding 500,000+ variants are throttled to 10,000 new variants per day unless on Shopify Plus.
• Shopify's URL prefixes (/products/, /collections/) are fixed, so every BigCommerce URL changes. Standard plans allow up to 100,000 redirects, Plus allows 20 million, and both support bulk CSV import.
• Metafields, SEO fields, and variant images are where large migrations most often lose data silently - and customer passwords never migrate at all.

Why Large Migrations Stop in the Middle

The most common cause is confusing rows with products. Shopify's product CSV format expands each product into one row per variant, with additional rows for each extra image - so a 3,000-product catalog with rich variants easily becomes 30,000-plus rows. On the BigCommerce side, the export isn't even consistent: the row structure depends on your export template's settings, which control whether variants appear inline or as separate rows. When the export, the import file, and the tool's plan cap are each counted in different units, the job hits a boundary it cannot reconcile and halts.

But row math is only the first failure mode. Large imports die in several distinct ways, and each one looks like "the migration stopped" from the outside:

• File mechanics. A single product CSV can't exceed 15 MB, so large catalogs must be split - and an import that hits the ceiling simply doesn't finish. Imports also can't be canceled once they begin, and overwrite imports can silently delete data: including some columns while omitting related ones (for example, SKUs without their option columns) wipes existing variants.
• Structural mismatches. Shopify allows a maximum of three options per product - the import errors with 'can only specify a maximum of 3 options' - while BigCommerce products routinely carry more option types. Those products need restructuring (options merged, split into separate products, or moved to line-item properties) before they can import at all. And although the variant cap is now 2,048, apps still on legacy product APIs misbehave above 100 variants.
• Rate limits at scale. Shopify's documented throttle is 10,000 new variants per day once a store holds 500,000+ variants (Plus exempt) - but in recent client migrations we've seen throttling bite earlier and harder than the published rule. Either way, a very large catalog imports across days by design: a job that 'stops' overnight may just be waiting for tomorrow's allowance.
• Image fetching. Import files reference images by URL, and Shopify fetches them at import time. If the source URLs are slow, blocked, or already dead because the old store was shut down too early, products arrive without images - a silent loss usually discovered weeks later. Keep BigCommerce (and its CDN) alive until images are verified on Shopify.

Three of those four are boundaries, not losses: the products are still sitting safely in BigCommerce, and the import simply stopped at a limit someone didn't know existed. The exception is the overwrite footgun, which genuinely deletes data. That distinction shapes the whole playbook - a stalled import is a scheduling problem you can retry, while a partial overwrite is an incident you can only prevent, which is exactly what the gate system below is built to do.

Know Shopify's Real Limits Before You Start

A lot of migration advice online cites limits that no longer exist - the variant cap alone was raised twentyfold in October 2025. These are the numbers that actually govern a large import today, each from Shopify's own documentation. Pin them somewhere visible; every one of them is a place an import can stall:

• 3 options per product, maximum. Unchanged for years, and the hard wall BigCommerce catalogs hit most often.
• 2,048 variants per product - but apps still on legacy product APIs misbehave above 100 variants, which matters when choosing tooling.
• 15 MB per product CSV file. Larger catalogs split into multiple imports.
• 10,000 new variants per day once a store already holds 500,000+ variants, per Shopify's documented rule. Shopify Plus is exempt, and it's counted in variants, not products. Treat this as a ceiling, not a promise - real imports can get throttled sooner.
• 100,000 URL redirects on standard plans; 20 million on Plus.

Choosing the Migration Path

Shopify's own Store Migration app does not support BigCommerce - its importer covers WooCommerce, Squarespace, Wix, and marketplaces, but BigCommerce merchants need a third-party tool. Shopify's own migration guide points to Matrixify, which connects directly to the BigCommerce API and migrates products, collections, customers, orders, and auto-generates URL redirects in one flow. Matrixify's Big plan handles up to 50,000 products per import job - counted in products with their variants, not spreadsheet rows - and its dry-run mode converts and validates the file without writing anything to Shopify, which is exactly the validation loop a large catalog needs.

Two alternatives are worth knowing. LitExtension and Cart2Cart both support BigCommerce as a source and price by entity count rather than a plan cap, and both offer a free demo migration - useful for a low-risk first look at how your data maps. Whichever tool you use, prefer the API connection over a raw CSV export: Matrixify itself warns that the CSV route reproduces products less faithfully, with weaker variant and image fidelity. And for catalogs entangled with custom fields, bundles, or ERP integrations, a scripted migration against Shopify's GraphQL API - the kind of work a migration partner does - beats forcing an off-the-shelf tool through data it wasn't designed for.

How to Reconcile the Counts Before You Import

Separate three numbers before touching Shopify: total products, total variants, and total rows in your export. Each maps to a different limit, and mixing up which limit uses which unit is how imports stall:

• Products map to your migration tool's per-job cap - 50,000 on Matrixify's Big plan, entity counts on LitExtension and Cart2Cart.
• Variants map to the per-product ceilings (2,048 variants, 3 options) and, at extreme scale, to the daily creation throttle.
• Rows map to file mechanics: how many 15 MB CSV chunks a manual import needs, and whether your BigCommerce export template emits variants inline or as separate rows.

Confirm that image and variant rows are expected to multiply the row count, then set the batch size so no single job approaches a hard cap. Only then run the dry run.

How to Validate and Cut Over Safely

Run the dry run, compare product and variant counts between source and target, and inspect a sample for the three places large migrations lose data silently: metafields, SEO titles and descriptions, and variant images. Fix mismatches, then re-run. Repeat until counts reconcile cleanly - usually within one to three cycles. Follow Shopify's recommended order of operations: products first, then customers, then historical orders, so order records can attach to both.

Budget for what cannot migrate, so it doesn't surprise you at cutover. Customer passwords never transfer between platforms - customers will reset on first login, which is worth a planned email. Product reviews, wishlists, and loyalty balances need dedicated apps with their own export/import paths. And freeze catalog changes on BigCommerce before the final export: every product edited after the export is a discrepancy you'll be hunting post-launch. Then schedule the final batches during low traffic. This staging discipline is the same reason a well-run replatform takes about 90 days rather than a weekend.

One post-launch item most migration checklists skip: treat the new store as a new performance baseline. A different theme and a rebuilt app stack mean your store speed numbers reset at cutover, and the first weeks after launch - while you're already watching Search Console - are the right time to catch a slow hero image or a heavyweight app before it settles in as the new normal.

SEO: Redirects Are the Whole Ballgame

Shopify's URL structure is fixed: products live under /products/, collections under /collections/, and those prefixes can't be changed even on Shopify Plus. BigCommerce allows custom URL paths, so on a large catalog, essentially every URL changes - which makes a complete 301 redirect map mandatory, not optional. Shopify supports bulk-importing redirects via CSV, with room for 100,000 redirects on standard plans and 20 million on Plus. Note that Shopify redirects only fire when the old URL would otherwise 404, and some system paths can't be redirected at all.

Be honest about the recovery timeline, because much of the internet isn't. Google's official site-move guidance says indexing a medium-sized site's move takes a few weeks, larger sites take longer, temporary ranking fluctuation is normal, and redirects should stay live for at least a year. Independent data is sobering: a 2026 study of over 1,000 domain migrations found only about a quarter fully recovered within 90 days. A same-domain replatform with a complete redirect map is a much gentler move than those domain migrations - but plan for weeks to a few months of fluctuation, not days, and treat anyone promising a fixed recovery window with suspicion.

The 5-Gate Shopify Migration Checklist

This is the gate system Byteex runs on catalog migrations: nothing ships until the previous gate passes, and every gate produces a number you can compare against the source.

Work with Byteex

A stalled migration is rarely a broken export; it is usually a limit or counting problem hiding thousands of variant and image rows. Byteex runs the 5-Gate Migration Checklist on every replatform we handle: we reconcile your product, variant, and row counts before anything imports, protect your rankings with a complete redirect map, and batch the cutover so you do not lose a single SKU. Book a discovery call and we will pressure-test your catalog before you migrate.