A Shopify to BigCommerce migration takes 8 to 16 weeks for a typical mid-market store with 2,000 to 15,000 SKUs, one to three apps that do not have a direct BigCommerce replacement, and SEO value that must be preserved through redirect mapping. The timeline widens to 20 weeks or more when subscriptions, custom Liquid theme work, or heavy metafield usage enter the scope. This guide exists because the top-ranking migration article currently sitting at support.bigcommerce.com covers the happy path well but does not go deep on the platform-specific traps that cost time on real projects. The traps are where the invoice surprises come from, so they are where this article goes deep.
The broader BigCommerce guide covers the context of why a merchant would migrate, and the Stencil versus headless article covers the architecture decision that often accompanies a migration. Cost models for migrations land in the customization cost breakdown, typically in the $25,000 to $100,000 band for mid-market scope.
What transfers automatically and what does not
Products, customers, and orders transfer via CSV export from Shopify or via the BigCommerce migration app, which supports direct Shopify-to-BigCommerce product and category imports. What does not transfer automatically: customer passwords (hashed passwords are not portable across platforms, so customers need to reset passwords after the cutover, and the comms plan for that reset is the single biggest user-experience risk in any migration), theme files (Shopify Liquid templates do not run on BigCommerce Stencil and must be rebuilt), app state (any data sitting inside Shopify apps belongs to those apps and either needs app-level export or manual re-entry), metafields in the exact Shopify shape (metafields need mapping to BigCommerce custom fields, modifiers, or price list attributes), and customer reviews if they live inside a Shopify app.
Orders are the hardest data class because of dependencies: an order references a customer, a product, a variant, and a payment record. Migrating orders with full history usually requires the BigCommerce Order API or a specialist migration tool. CSV import does not cover orders. Many merchants accept a read-only archive of Shopify orders in lieu of full migration to avoid the engineering cost, which is defensible for orders older than 6 to 12 months where operational need is rare.
URL structure differences
Shopify uses a fixed URL structure: products live at /products/handle, collections at /collections/handle, pages at /pages/handle, and blog posts at /blogs/blog-name/article-handle. BigCommerce gives configurable SEO URLs, typically /product-slug/ for products and /category-slug/ for categories by default, without a fixed prefix. The difference matters because every indexed Shopify URL needs a 301 redirect to a corresponding BigCommerce URL to preserve SEO equity.
The cleanest redirect strategy is to match the Shopify handle directly to the BigCommerce slug where possible, so /products/royal-blue-mug on Shopify maps to /royal-blue-mug/ on BigCommerce. That mapping holds for maybe 80 to 90 percent of a catalog. The remaining 10 to 20 percent have Shopify handles that conflict with BigCommerce URL rules, duplicate after deduplication, or reference products that were consolidated during the migration. Those exceptions need manual review and individual redirect creation.
Blog and page URLs are the second redirect priority. A store with an active blog sees most of its long-tail organic traffic on blog articles, and losing those URLs costs real revenue. Export the Shopify blog URL list, match each article to its BigCommerce blog post, and create the 301 in BigCommerce. The platform supports redirect import via CSV which accelerates this step for stores with over 100 redirects.
Variant limits: 100 Shopify versus 600 BigCommerce
Shopify's historical variant limit of 100 per product and three option dimensions is one of the most-cited reasons merchants migrate to BigCommerce. BigCommerce allows up to 600 variants per product, which accommodates catalogs that have been constrained on Shopify. BigCommerce also caps option values at 250 per option, a separate limit that matters for stores with deep color swatches or size scales. Exceeding 250 option values on a single option returns a 403 error from the Catalog API.
Shopify announced a 2,000-variant rollout in 2025 with limited availability for development stores, but the vast majority of production Shopify stores still operate under the 100-variant cap in 2026. Merchants who structured their catalog around the 100-variant constraint (for example, splitting a product line into separate products to avoid exceeding the limit) can consolidate on BigCommerce, which simplifies catalog management but requires rethinking the SKU-to-product mapping during migration.
A related gotcha is that BigCommerce differentiates between options (the dimensions: color, size, material) and modifiers (one-time customizations: engraving text, gift wrap add-on) where Shopify collapses both into variants. Migrating a Shopify product with per-unit engraving often becomes a BigCommerce product with a modifier rather than a variant, which changes the SKU strategy and the inventory tracking pattern.
Liquid to Handlebars template mapping
Shopify themes use Liquid, a template language with constructs like {% for %}, {% if %}, and {{ variable | filter }}. BigCommerce Stencil themes use Handlebars, a different template language with {{#each}}, {{#if}}, and {{variable}} syntax plus BigCommerce-specific helpers. The two are not interchangeable, and automated translation tools that promise to convert one to the other produce syntactically valid output that rarely runs correctly against the different underlying data shapes.
The common path is to rebuild the theme on Stencil rather than translate. Starting point is either Cornerstone (BigCommerce's free reference theme, a reasonable baseline for most DTC stores) or a commercial Stencil theme from the marketplace. A frontend developer who has worked with both Liquid and Handlebars can port the visual design faithfully in 3 to 6 weeks depending on complexity. The time is not spent on syntax translation. The time is spent mapping Shopify object structures (product, variant, collection, metafield) to the corresponding BigCommerce structures in the theme data.
Specific template sections that take the longest to port: product pages with variant logic (the Shopify variant picker behaves differently from the BigCommerce option and modifier UI), cart pages with line-item properties (Shopify's line item properties map to BigCommerce cart line item extensions, which work differently), checkout (covered separately in the checkout article because of SDK and OOPC constraints), and any custom section that used Shopify sections or metaobjects. Shopify themes references are at shopify.dev for comparison during migration planning.
Shopify metafields to BigCommerce custom fields and modifiers
Shopify metafields are typed key-value stores attached to products, variants, collections, customers, and orders. A store using metafields heavily has built a data model that does not map one-to-one onto BigCommerce. Three target structures handle most metafield migrations. Simple string metafields on products become BigCommerce product custom fields. Per-variant metafields become either variant-level custom fields or modifier data depending on use case. Metafields that drive storefront display become either Page Builder widget data or theme-level data files depending on render context.
The mapping exercise is a discovery deliverable, not a build-time decision. A store with 200 products and 15 metafields per product has 3,000 metafield values to classify and migrate. Skipping the classification step usually produces a BigCommerce product record that is technically populated but does not render correctly on the storefront because the theme does not know how to look up the new field location. Build time for the metafield migration alone is typically 40 to 120 engineering hours depending on the metafield usage depth.
Shopify apps with no direct BigCommerce equivalent
Four Shopify app categories routinely cause migration scope creep. Subscriptions (ReCharge, Bold, Shopify Subscriptions) have BigCommerce alternatives (Rebillia, PayWhirl, Stripe Billing integrations) but the data migration between platforms is subscription-by-subscription and the customer notification plan is delicate. Reviews (Loox, Judge.me, Yotpo) export reviews via CSV but lose photo attachments and some metadata unless the destination app supports those fields specifically. Checkout scripts and Shopify Functions have no direct BigCommerce equivalent and the logic must be rebuilt using Checkout SDK, Script Manager, or custom middleware. Multi-language or multi-currency via Shopify Markets requires either BigCommerce Multi-Storefront or a different internationalization pattern depending on business requirements.
The discovery deliverable is an app-by-app audit: what the app does, what BigCommerce alternative covers the functionality, what data has to move, and what the user-visible change is at cutover. A good audit catches cases where the Shopify app is not actually being used productively (roughly 20 to 30 percent of app subscriptions across typical stores are orphaned) and can be removed rather than migrated.
A worked 301 redirect mapping
The redirect mapping is the single most important SEO deliverable in a migration. Done well, the store preserves 90 plus percent of its organic traffic through the cutover. Done poorly, the store loses 20 to 40 percent of organic traffic in the first 30 days and takes months to recover. The mechanical work is a CSV with from-URL and to-URL columns imported into BigCommerce's 301 redirect tool.
| Shopify URL pattern | BigCommerce target pattern | Notes |
|---|---|---|
| /products/{handle} | /{product-slug}/ | Usually one-to-one; slug inherits handle by default during import |
| /collections/{handle} | /{category-slug}/ | Requires manual mapping when collections are split or merged |
| /collections/{handle}/products/{product} | /{product-slug}/ | Shopify doubles up; BigCommerce does not; collapse to product |
| /pages/{handle} | /{page-slug}/ | One-to-one; check for BigCommerce reserved slugs |
| /blogs/{blog}/{article} | /blog/{article-slug}/ | Blog URL structure flattens on BigCommerce |
| /cart | /cart.php | Cart URL differs; keep the redirect for any indexed cart links |
| /account | /account.php | Account URL differs; critical for crawled links |
The CSV is generated from a Shopify URL inventory (use Screaming Frog to crawl the live Shopify store before cutover, which captures both indexed and internally-linked URLs). The inventory is the master source of truth for the mapping. Products not in the inventory should not be in the CSV. URLs in the inventory that have no BigCommerce target need a manual decision: redirect to the nearest category, to the homepage, or to a custom 410 if the content is genuinely gone.
The 30, 60, 90 day post-migration QA checklist
Launch is the start of the work, not the end. Three review windows catch the issues that surface at different time scales. Day 1 to 30 surfaces the immediate cutover issues. Day 31 to 60 surfaces the drift and reconciliation issues. Day 61 to 90 surfaces the SEO and performance issues that take time to manifest.
Day 1 to 30 checklist
Test a live order through every payment method. Verify tax calculation on at least five representative states. Verify shipping rate calculation on at least five representative destinations. Spot-check 20 imported products against their Shopify source for data fidelity. Send the password reset comms to the customer base and monitor reset completion rate. Watch Google Search Console for crawl errors and 404 spikes. Verify that the 301 redirect CSV imported correctly and that a sample of high-traffic URLs actually redirect. Watch the webhook delivery dashboard for the ERP integration and resolve any failed deliveries within 24 hours.
Day 31 to 60 checklist
Reconcile the first full month of orders against the ERP to verify the integration is not dropping data. Check inventory drift between BigCommerce and the source of truth (PIM or ERP) and patch any gaps in the webhook handlers. Review search ranking trajectory in the top 50 revenue keywords and flag any that have dropped more than 5 positions for further investigation (usually a missing or misconfigured redirect). Audit the customer support ticket volume for migration-related issues. Verify that the abandoned cart flow, welcome email flow, and transactional email flow all fire correctly for customers who created new accounts post-migration.
Day 61 to 90 checklist
Review Core Web Vitals against the Shopify baseline from before the cutover. Run a full accessibility audit and resolve WCAG 2.2 AA findings. Review the order conversion rate against the Shopify baseline and flag any degradation for root-cause investigation. Clean up any duplicate content that slipped through the redirect mapping. Remove any deprecated Shopify apps from the customer email workflow if they still have tokens active. Complete the post-migration retrospective with the full team and document the lessons for the next replatform.
Case study
A Seattle-based apparel brand doing approximately $6 million in annual revenue migrated from Shopify Plus to BigCommerce in February 2026. The business had 1,400 SKUs across 180 products (hitting the 100-variant cap on several products), five Shopify apps including ReCharge for subscriptions and Judge.me for reviews, an active blog with 240 articles, and an organic traffic base generating 38 percent of monthly revenue.
Scope was $58,000 for the core migration plus $14,000 for a subscription-app bridge. Timeline was 12 weeks. The build shipped in 13 weeks at $67,000, with the one-week overrun driven by a metafield mapping for product care instructions that did not surface in discovery. Organic traffic dropped 7 percent in the first 30 days post-cutover, recovered to parity by day 45, and exceeded the pre-migration baseline by day 75. The business credits the redirect mapping quality and the BigCommerce custom field flexibility for the recovery speed. The post-migration retainer runs at $2,800 per month covering subscription integration maintenance, ongoing theme work, and quarterly SEO monitoring.