BigCommerce Migration from Magento: The Developer Execution Breakdown

Migrating from Magento to BigCommerce is not a data dump and a theme swap. The core technical challenge is projecting Magento's Entity-Attribute-Value catalog into BigCommerce's flat relational product model, choosing between Stencil and Catalyst for your storefront, and building a redirect map that covers every indexed URL before DNS cutover. Get those three things right and the rest of the project is manageable. Miss any one of them and you will spend months cleaning up.

Key takeaways

• The EAV-to-relational catalog projection is the hardest part of the migration, not the row count.
• BigCommerce caps products at 600 variants per SKU; audit any configurable product that could breach this before you start.
• Magento extensions do not port to BigCommerce apps automatically. Audit every active extension and confirm a replacement exists before committing.
• Customer passwords never transfer. Plan a forced-reset flow for launch day.
• Every un-redirected URL permanently loses its search equity. Build the redirect map from a Screaming Frog crawl, not from memory.

Why developers underestimate this migration

On the surface, Magento to BigCommerce looks like a familiar SaaS replatform: export CSVs, import CSVs, rebuild the theme. In practice, the data models are structurally incompatible in ways that break automated tools above a few hundred SKUs.

Magento stores product data in the EAV model: catalog_product_entity plus a family of catalog_product_entity_* value tables, attribute sets, and input types. Every attribute is its own row. BigCommerce flattens this into a relational product + variant + custom-field schema, with Product Modifiers for option-driven price and SKU deltas. As one migration specialist puts it, the hard work is the EAV-to-relational projection, not the row count.

Concretely, a Magento configurable product with a parent SKU and 12 child simple SKUs (each with its own color/size combination) becomes a single BigCommerce product record with up to 12 variant rows, each row carrying the option combination, price delta, weight, and inventory. That sounds simpler, and it is, but only after you have correctly mapped every attribute set to a BigCommerce option type.

The 600-variant ceiling: audit before you commit

BigCommerce limits each product to 600 variants. For most DTC catalogs this is irrelevant. For industrial, medical, or high-SKU apparel stores it is a hard wall.

Run this query against your Magento database before you scope the project:

SELECT
  parent.sku AS parent_sku,
  COUNT(child.entity_id) AS child_count
FROM catalog_product_entity child
JOIN catalog_product_relation rel ON child.entity_id = rel.child_id
JOIN catalog_product_entity parent ON rel.parent_id = parent.entity_id
GROUP BY parent.sku
HAVING child_count > 500
ORDER BY child_count DESC;

Any result above 600 needs a catalog redesign decision before migration starts. Options are: split the product into multiple BigCommerce products (one per color family, for example), remove retired variants from the active catalog, or reconsider BigCommerce as the destination if the variant depth is genuinely required across dozens of SKUs.

I have maintained a catalog with over 10,000 active SKUs and the variant ceiling almost never fires for standard apparel or accessories. It becomes a real constraint in industrial parts catalogs where one base part number has hundreds of specification combinations.

EAV projection: the data mapping that counts

Here is the field-level mapping that matters most:

Product Modifiers deserve a note: they handle options that affect price or require customer input (engraving text, custom dimensions) but do not create distinct inventory-tracked SKUs. Use them for options that don't need their own SKU; use Variants for options that do. Getting this split wrong early creates a broken inventory feed and a broken product feed downstream.

Extension audit: the work nobody budgets for

Every Magento extension your store runs must be individually replaced. There is no migration path for PHP extension code into the BigCommerce app ecosystem.

Audit steps:

1. Pull a list of all active modules from app/code and vendor directories.
2. Remove Magento core and framework modules from the list.
3. For each remaining extension, answer: what does it do in production today?
4. Search the BigCommerce App Marketplace for a functional equivalent.
5. For any extension with no marketplace match, decide: custom BigCommerce API integration, third-party SaaS, or feature retirement.

Common gaps that catch teams off guard:

• Custom shipping rate logic built as a carrier module (needs a BigCommerce Shipping Zone rule or a carrier quote API integration)
• Layered navigation customizations (BigCommerce's faceted search is configurable but not as granular as a custom Magento layered nav)
• Magento B2B modules: Company Accounts, Shared Catalogs, Negotiable Quotes (these require BigCommerce B2B Edition, which is a separate license tier)

Multi-currency and abandoned cart recovery, which often require Magento extensions, ship natively in BigCommerce at no extra cost, which is a genuine reduction in per-month app spend.

SEO redirect map: build it from a crawl, not from memory

Magento's default URL surface uses .html suffixes on product and category pages, plus layered navigation filter URLs that generate dozens of parameter variants per category. None of these URL patterns exist in BigCommerce by default.

The correct process:

1. Run Screaming Frog against the live Magento store and export every indexed URL (status 200, crawl depth unlimited).
2. Cross-reference with Google Search Console to identify URLs carrying meaningful organic traffic or backlinks.
3. Build a spreadsheet with three columns: old URL, new BigCommerce URL, redirect type (301 for permanent, 302 only if you expect the old URL to return).
4. Load the map into BigCommerce's URL Redirect Manager before launch. For large catalogs (10,000+ URLs), use the Redirect Manager's bulk CSV import.
5. Post-launch, run the same Screaming Frog crawl against the live BigCommerce store and verify every old URL returns a 301, not a 404.

Any URL without a redirect permanently loses its accumulated search equity. There is no recovery path for a 404 that goes unredirected for more than a few weeks after launch.

Magento's .html suffix and layered navigation URLs (e.g., /category/boots.html?color=182&size=168) need individual decisions. Filter parameter URLs are usually best excluded from the redirect map entirely (they were likely noindex in Magento anyway). Product and category canonical URLs are non-negotiable.

Storefront choice: Stencil or Catalyst

This is the second major architectural decision after the data model work. BigCommerce now offers two distinct storefront paths:

Catalyst, released in 2024, is BigCommerce's official headless framework built on Next.js and React, and it connects to BigCommerce via the GraphQL Storefront API. It is not a faster theme; it is a separate Node.js application that requires its own hosting layer, a CI/CD pipeline, and a team that understands React state management.

For a Magento migration where the goal is escaping infrastructure burden, Stencil is usually the right call. You are already spending significant energy on data migration, redirect mapping, and integration rebuilds. Adding a full headless frontend to that scope is a second major project running in parallel. Unless there is a specific performance or composability requirement that Stencil cannot meet, launch on Stencil and evaluate Catalyst on a defined timeline after the store is stable.

If the Magento store was running a PWA Studio frontend or a fully custom decoupled React app, and your team has the Next.js capability, Catalyst is worth the overhead because you are already committed to that maintenance model.

Data migration tooling: what each option actually handles

Three tooling paths exist for the data transfer:

• Automated SaaS tools (LitExtension, Cart2Cart, NextCart): Fast to configure, adequate for catalogs under 5,000 SKUs with standard product data. They handle products, customers, orders, and categories out of the box. They struggle with custom fields, unusual checkout rules, and data stored outside the standard Magento schema. LitExtension starts at $79 and includes 60 days of post-migration support.
• Manual CSV pipeline: Free in licensing cost, high in developer time. Use BigCommerce's sample CSV templates and map Magento fields manually. Viable for small catalogs where you want full control over every field value.
• Custom API script: The right choice for large or complex catalogs. Use Magento's REST API to extract the full EAV graph (including attribute sets, option values, and media gallery entries), transform it in code, and push to BigCommerce via the V3 catalog API (/v3/catalog/products?include=variants,images,custom_fields,bulk_pricing_rules). This approach handles edge cases that SaaS tools miss and produces an auditable transformation log.

Customer passwords never transfer regardless of which method you use. Every customer account will require a password reset after launch. Build that into your launch-day communication plan.

What to verify before DNS cutover

• [ ] Run a test order end-to-end on staging: add to cart, checkout, payment, confirmation email.
• [ ] Confirm all 301 redirects return the correct status code (use Screaming Frog against staging with the redirect map loaded).
• [ ] Validate inventory levels match the Magento export for the top 50 SKUs by order volume.
• [ ] Confirm customer group pricing rules are active and returning correct prices for logged-in accounts.
• [ ] Test every payment gateway in sandbox mode.
• [ ] Verify structured data (Product schema) renders correctly on product pages using Google's Rich Results Test.
• [ ] Confirm the BigCommerce sitemap is submitted to Google Search Console and returning a 200.

For a deeper look at how catalog data modeling decisions affect downstream SEO, see the glossary entry on EAV vs. relational product models.

Conclusion

The migration from Magento to BigCommerce is winnable on a reasonable timeline if you sequence the work correctly: catalog model audit first, extension gap analysis second, redirect map third, storefront build in parallel. The EAV projection and the 600-variant ceiling are the two issues most project plans underestimate. Fix those on paper before a single row of data moves and the rest of the execution follows a predictable path.