Adobe Commerce & Magento, BigCommerce, eCommerce platform migration

A Magento to BigCommerce migration is achievable for any catalog, but B2B stores fail more often than B2C ones because Magento and BigCommerce model configurable products, customer groups, and price rules differently. The theme and content migrate easily. The pricing logic and product structure do not, and that gap is where most projects lose weeks.

We have run replatforms in both directions, and we do not have a platform to defend here. This is a candid look at what actually breaks.

Whether you are running Adobe Commerce or Magento Open Source, the core data model is the same, which is why an adobe commerce to bigcommerce migration and a Magento Open Source migration face identical structural problems. The difference between the two Magento editions shows up in features like content staging and catalog price rules with complex conditions, both of which are Adobe Commerce only. If you are on Open Source, some of the gaps in this guide will not apply to you, because you never had that functionality to lose. If you are on Adobe Commerce, plan for it.

Most migration content covers theme conversion and content import. That is the easy half of the project. The half that determines whether your B2B customers can still place a bulk order correctly on day one is the data model, specifically how each platform handles product variation, customer-specific pricing, and URL structure.

Why Companies Move From Magento to BigCommerce

The reasons companies pursue a Magento to BigCommerce move are usually operational, not aesthetic. Five come up most often in our client conversations:

1. Hosting and PCI overhead. Magento’s self-hosted architecture (even on Adobe’s cloud infrastructure) puts more infrastructure and security burden on the merchant than BigCommerce’s SaaS model does.
2. Total cost of ownership. Adobe Commerce licensing, combined with developer hours for patches and upgrades, adds up faster than most finance teams expect at renewal time.
3. Release cycle fatigue. Magento’s major version upgrades are notoriously heavy. Teams tired of multi-month upgrade projects look at BigCommerce’s continuous deployment model as a relief.
4. Native B2B tooling. BigCommerce B2B Edition packages a buyer portal, quoting, and company account hierarchy out of the box, which some Magento merchants have been assembling from extensions for years.
5. Developer availability. The Magento developer pool has been shrinking relative to demand, and staffing an in-house Magento team has gotten harder and more expensive.

None of these are wrong reasons. They are also not the whole story, because none of them tell you whether your specific catalog will survive the move intact. That depends on what is underneath the product pages.

Which Data Model Differences Cause Migration Problems?

Every magento bigcommerce data migration runs into the same three friction points: how products with variations are structured, how customer-specific pricing is calculated, and how many customer groups a single account can belong to. Get these wrong, and the storefront looks finished while the pricing engine underneath is quietly broken.

The root cause is philosophical. Magento was built to support arbitrarily complex, rules-based catalogs, and it exposes that complexity to the merchant. BigCommerce was built for a SaaS constraint model, where most flexibility comes from a defined set of features (variants, option sets, price lists) rather than an open rules engine. Neither approach is wrong. They just do not map to each other one for one.

This matters most in three places, and we will walk through each one:

• Product structure (configurable products vs. variants)
• Pricing logic (catalog price rules vs. price lists)
• Customer segmentation (a customer’s relationship to groups and companies)

A tool-driven magento bigcommerce data migration will move product titles, descriptions, and images without much trouble. It will not make a judgment call about which of your forty attribute combinations should become variant options and which should become separate products. That decision needs a human who understands both platforms and your catalog.

How Do Magento Configurable Products Map to BigCommerce Variants?

Here is where a migration guide has to get specific, so let’s use a real example: a work glove sold in four sizes (S, M, L, XL) and three materials (leather, nitrile, cotton blend).

In Magento, this is a configurable product. The parent is a shell with no price or stock of its own. Size and material are attributes with global scope, and each of the twelve size-and-material combinations exists as its own simple product with its own SKU, price, and inventory record. The configurable parent’s displayed price is pulled from its in-stock children, not stored anywhere on the parent itself. If you need a customer-specific price on the XL nitrile glove only, you set it on that one simple product.

In BigCommerce, this becomes a single product with two variant options (size and material), generating the same twelve SKU-level variants. The mechanics look similar on the surface, but the constraints differ. BigCommerce variants inherit most product-level data (images, description, SEO fields, custom fields) from the parent product by default. Only a limited set of fields (SKU, price, weight, dimensions, inventory) can vary at the variant level unless you build variant-specific content manually.

Here is what has to be decided before a single record moves:

• Which Magento attributes become BigCommerce variant options, and which become separate products entirely. If a Magento attribute has more than a handful of values, or drives fundamentally different content (not just a price or SKU change), it may migrate cleaner as a standalone product than as a variant option.
• What happens to variant-specific images. Magento’s per-attribute image assignment maps to BigCommerce’s variant image feature, but the two are configured differently and need to be rebuilt, not exported and reimported.
• Whether any child products carry custom options in Magento. BigCommerce variants cannot carry the equivalent of Magento’s custom options (free text fields, file uploads) at the variant level. Those need a modifier-based redesign.
• How stock status logic will behave. Magento’s configurable stock status is a multi-criteria calculation involving both the parent and children. BigCommerce ties stock more directly to the variant itself. Merchants relying on Magento’s more nuanced out-of-stock behavior for the parent product will need to rebuild that logic in storefront rules.

None of this is a checkbox on a migration tool’s feature list. It is a catalog architecture decision, made product family by product family, and it is the single most time-consuming part of any Magento to BigCommerce migration involving a catalog larger than a few hundred SKUs.

Why Does B2B Pricing Break During a Replatform?

This is where B2B catalogs specifically run into trouble, because B2B pricing is rarely just “wholesale gets 10% off.”

Magento’s pricing stack has two layers: customer groups (which control catalog visibility and can carry storewide, category, or product discounts) and catalog price rules, which sit on top and let you build conditional pricing (this customer group, this attribute set, this date range, this quantity break) without limit on complexity. Adobe Commerce merchants often have dozens of catalog price rules layered to produce customer-specific net pricing that no single screen fully displays.

BigCommerce’s pricing stack has customer groups (available from the Growth plan up, supporting storewide, category, and product-level discounts) and price lists, available on the Performance/Enterprise plan, which allow variant-level price overrides tied to a customer group and channel. The constraint that catches migrations off guard: a customer group can be assigned to only one price list at a time, and price lists and customer group discounts cannot be combined on the same group. You choose one mechanism per group, not a layered stack of both.

What does not map cleanly:

• Complex conditional rules. A Magento catalog price rule that says “10% off attribute set X, for customer group Y, from March through May, on orders over $500” has no single BigCommerce equivalent. You will rebuild this as a combination of a price list and a promotion, or in some cases, a custom app.
• Per-customer pricing (not per-group). If Magento pricing was ever set at the individual customer level rather than the group level, BigCommerce will require you to create a customer group of one, which works, but it changes how the account is administered going forward.
• Multi-currency price list behavior. BigCommerce price lists for transactional currencies are not currency-converted automatically; a $10 price set in a CAD price list stays $10 CAD regardless of the exchange rate. Rules layered on top of price list prices are converted. Merchants used to Magento’s currency-agnostic rule application need to test this carefully.

BigCommerce B2B Edition adds company accounts, buyer roles, and sales rep quoting on top of this pricing model, and for many merchants it replaces extensions that were bolted onto Magento to achieve similar functionality. It does not replace catalog price rules. If your pricing logic depends on conditional rules rather than flat group discounts, budget real time to redesign it, not just migrate it.

URL Structure: How to Migrate Without Losing Your Rankings?

Every Magento to BigCommerce migration changes your URL format, so redirects need a plan.

Magento builds product URLs from a URL key plus, optionally, the category path, commonly producing something like /women/tops/hoodies/product-name.html. Category paths can be toggled on or off storewide, and every rewrite is tracked in the url_rewrite table, which is your single source of truth for what currently resolves.

BigCommerce generates URLs differently: typically /product-name/ for products and /category-name/ for categories, without the .html extension and without Magento’s nested category path convention by default.

The redirect-mapping method that actually works:

1. Export every live URL from Magento’s url_rewrite table, not just the ones you think matter. Include products, categories, CMS pages, and any legacy redirects already in place from a prior migration.
2. Pull your top-performing URLs from Google Search Console (by impressions and clicks over the last 12 to 16 months) and flag them for manual verification. These are the URLs where a mismatched redirect costs you visible rankings, not just broken links.
3. Build a mapping spreadsheet with three columns: old URL, new URL, redirect type. Nearly everything should be a 301. Do not default to redirecting everything to the homepage; a 301 to an unrelated page is barely better than a 404 in Google’s eyes.
4. Implement the mapping in BigCommerce’s URL redirects tool before launch, not after, and test a sample against staging.
5. Resubmit your sitemap in Google Search Console post-launch and monitor the Coverage report weekly for the first month for unexpected 404s or redirect chains.

Category structure deserves separate attention. If your Magento category tree does not map one to one onto BigCommerce’s category model, decide the new structure before generating redirects, not after. Redirecting into a structure you are about to change again wastes the crawl budget you are trying to protect.

Magento Extensions You Will Not Be Able to Replace

Rather than naming specific extensions, which turn over too quickly to be a reliable reference a year from now, here is what to look for by category, and what to do about each:

• Advanced search and layered navigation. Elasticsearch-based Magento extensions with deep attribute-level filtering often exceed BigCommerce’s native filtering. Solution: evaluate a headless search provider if your catalog has more than roughly 20 filterable attributes.
• Business intelligence and advanced reporting. Adobe Commerce’s native BI tooling and third-party analytics extensions frequently have no BigCommerce equivalent. Solution: plan for an external BI tool connected via API from day one, not as an afterthought.
• Content staging and scheduled catalog updates. This is an Adobe Commerce-only feature with no BigCommerce parallel. Solution: rebuild the workflow using scheduled tasks through the API, or accept manual publishing.
• Deep ERP and ERP-adjacent integrations. Custom Magento connectors built against specific ERP field structures generally need to be rebuilt against BigCommerce’s API, not migrated. We cover this in more depth in our BigCommerce ERP integration guide.
• Custom checkout and payment logic. Highly customized Magento checkout extensions (split payments, custom approval workflows) usually require a Checkout SDK build on BigCommerce rather than a like-for-like extension swap.
• Complex tax logic beyond Avalara or Vertex. Both major tax engines support both platforms, but any custom tax rule logic built directly into Magento will need to be reconstructed.
• B2B quoting and approval workflows beyond B2B Edition’s scope. B2B Edition covers standard sales rep quoting and company hierarchies. Highly specific approval chains (multi-level, dollar-threshold-based) may still need a custom build.

The pattern across all seven categories is the same: BigCommerce’s app ecosystem covers common cases well and custom logic poorly. If your Magento build leaned heavily on custom development rather than off-the-shelf extensions, expect proportionally more rebuild work.

A Realistic Magento to BigCommerce Migration Timeline

There is no single honest number for how long a Magento to BigCommerce migration takes, because the answer depends on catalog complexity and pricing logic, not SKU count alone. What we can give you is a phased range and the variables that move each phase:

1. Discovery and data model mapping: 2 to 6 weeks. This is the configurable-product-to-variant mapping exercise and the pricing logic audit described above. Catalogs with complex catalog price rules or heavy custom options push toward the long end.
2. Platform build and app configuration: 4 to 10 weeks. Wider ranges apply to stores needing B2B Edition configuration, custom apps for pricing gaps, or headless search.
3. Data migration and QA: 3 to 8 weeks. Product and customer data migration is faster than most people expect. Pricing and variant QA, checking every price list against every customer group, is what extends this phase.
4. URL redirect implementation and SEO QA: 2 to 4 weeks, run in parallel with the phase above, not after it.
5. Launch and post-launch monitoring: 4 to 8 weeks of active monitoring for 404s, pricing discrepancies, and ranking movement before calling the project stable.

Total: most B2B migrations we scope land between 4 and 8 months from kickoff to stable post-launch, not the 6 to 8 weeks some migration tool marketing implies. The variable that moves this the most, in our experience, is not catalog size. It is how many conditional pricing rules exist and how well documented they are before discovery starts.

When Is a Magento to BigCommerce Migration the Wrong Choice?

This is the section most migration guides skip, and it is the reason we think this one is worth reading before you sign a statement of work. Replatforming from Adobe to BigCommerce is not the right call for every B2B merchant, and we would rather say so now than after a deposit.

Three scenarios where we would advise against it:

1. Your pricing logic depends on more than a handful of conditional catalog price rules. If net customer pricing is the product of ten or more layered, condition-based rules, replatforming adobe to bigcommerce means rebuilding that logic from scratch with a fundamentally different pricing model. The rebuild cost can exceed the platform savings you were chasing, sometimes for several years.
2. You are deeply invested in the Adobe ecosystem. If your Adobe Commerce instance is wired into Adobe Experience Manager, Adobe Target, or Adobe’s Customer Data Platform, replatforming adobe to bigcommerce breaks those integrations, and BigCommerce has no direct equivalent to Adobe’s suite-level data continuity. The cost of that disconnection is often underweighted in the initial business case.
3. Your catalog relies on nested or highly conditional product relationships, such as configurable products that contain bundle products with dynamic, rule-based pricing. BigCommerce’s variant and bundle models are more constrained by design, and recreating this exact behavior may not be possible without a custom app layer that offsets much of the cost savings you were pursuing.

If any of these describe your store, the more productive next step is an audit of what you actually have today, not a migration kickoff. We have written more on this decision process in our previous blog, “The Most Common Reasons Businesses Migrate from Adobe Commerce to BigCommerce”, which digs further into the cases where staying on Adobe Commerce, or moving to a different platform entirely, makes more financial sense. It is also worth reading our broader ecommerce replatforming pillar page if BigCommerce is one of several platforms still on your shortlist, and our BigCommerce to Magento migration guide if you are evaluating the reverse move for context on how the data model problem looks from the other direction.

Support