Migrating from BigCommerce to Adobe Commerce means exporting catalog and customer data through the BigCommerce API, translating BigCommerce’s option and variant model into Magento’s product types, rebuilding the storefront on a Hyva theme, and mapping every old URL to a 301 redirect. Data transfers; the frontend and apps are rebuilt, not ported.
Brands outgrow BigCommerce for predictable reasons: they hit the platform’s customization ceiling, need deeper B2B, or want control BigCommerce’s SaaS model does not give them. Moving to Magento or Adobe Commerce buys that control, but it is a rebuild, not a copy-paste. This guide covers what actually transfers, the data-model translation the automated tools get wrong, and the redirect work that decides whether you keep your rankings and your AI citations.
Why brands move from BigCommerce to Magento, and when not to
Be honest about the reason before you commit, because the migration is significant work.
The good reasons to move: you need custom checkout logic, complex B2B features like company accounts and negotiable quotes, deep ERP or PIM integration, or catalog and pricing rules BigCommerce cannot express. Magento and Adobe Commerce are open and self-hosted, so almost anything is possible, which is exactly why large and complex merchants run on it.
The reasons to stay put: if BigCommerce is handling your catalog and checkout fine and you just want a faster storefront or a redesign, a replatform is an expensive way to get there. We build on BigCommerce too, and the honest answer for some merchants is to optimize what they have rather than take on a full Magento and Adobe Commerce build. A replatform should solve a problem the current platform structurally cannot, not chase a feeling.
What transfers, and what you rebuild
The single biggest misconception is that migration moves your whole store. It moves your data. Everything else is rebuilt.
| Element | Transfers via migration | Rebuilt from scratch |
|---|---|---|
| Products, SKUs, prices, inventory | Yes, via API | No |
| Categories and catalog structure | Yes, with remapping | No |
| Customers (without passwords) | Yes | Passwords must be reset |
| Order history | Optional, often selective | No |
| SEO metadata and URLs | Data yes, redirects manual | No |
| Storefront theme and design | No | Yes, ideally on Hyva |
| Apps and integrations | No | Yes, as Magento extensions |
| Checkout and payment config | No | Yes |
Passwords are the classic surprise. BigCommerce stores them hashed, and you cannot move a usable password hash into Magento, so every customer resets on first login. Plan the communication for that. Order history is a choice: full history is nice but heavy, and many merchants migrate a recent window and archive the rest.
Checkout and payment configuration is another rebuild that trips up teams expecting a copy. BigCommerce’s hosted checkout and its payment app connections do not exist in Magento, so you re-implement payment methods, tax rules, and shipping logic in the new platform. This is usually a good thing, because it is the moment to fix the checkout compromises the SaaS platform forced on you, but it is work to budget for rather than assume.
The data model translation nobody warns you about
This is where automated migration tools quietly produce a mess, and where competitor guides stay vague. BigCommerce and Magento model product variations differently, and the translation is the hard part of the whole project.
BigCommerce uses product options, variants, and modifiers. Options with variants generate purchasable SKUs; modifiers add choices that may or may not create a new SKU. Magento uses configurable products built from simple products, plus custom options for non-SKU choices, and it groups attributes into attribute sets.
Mapping between them is not one to one:
- BigCommerce variant options usually become Magento configurable product attributes, with each variant becoming a child simple product.
- BigCommerce modifiers that do not create SKUs map to Magento custom options.
- BigCommerce shared option sets need to become Magento attribute sets, planned deliberately rather than auto-generated, or you end up with hundreds of redundant attributes.
Get this wrong and you get duplicate attributes, broken variant selection, and a catalog that technically imported but does not work on the storefront. This is the same class of problem we document for Magento configurable, bundle, and grouped product rendering, and it is why a clean attribute plan comes before any import runs. An automated tool will happily create the mess; a real migration maps the model first.
Export the right way: API, not CSV
Use the BigCommerce V3 API for the export, not the CSV download. CSV exports truncate or omit metafields, custom fields, and the full variant relationships, which is exactly the data you need for a faithful catalog. The BigCommerce catalog API exposes the complete product graph including options, variants, and modifiers.
Automated services like Cart2Cart and LitExtension can move the bulk of products, categories, customers, and orders, and they are a reasonable starting point for a straightforward catalog. For anything with complex variants, B2B pricing, or custom fields, expect to supplement the automated pass with a scripted import that applies your attribute-set plan. The tool moves rows; it does not make modeling decisions.
The 301 redirect map: your most important SEO task
If you do one thing perfectly during a migration, make it the redirect map. Every BigCommerce URL that has traffic, rankings, or links must resolve to its Magento equivalent with a 301 redirect. Products, categories, CMS pages, blog posts, and search URLs all count.
Build the map before writing storefront code:
- Export every BigCommerce URL from the API and from Search Console.
- Match each to its new Magento URL, deciding your Magento URL structure up front.
- Load the map as 301 redirect rules so they go live the moment you cut over.
- Crawl the live site after launch to catch redirect chains and misses.
Google’s guidance on a site move with URL changes is the authoritative reference, and skipping this step is the most common way merchants lose organic traffic in a replatform.
There is a 2026 dimension the older guides miss. If your BigCommerce pages are cited by AI Overviews, Perplexity, or ChatGPT, those citations are tied to specific URLs. Break the URL and you break the citation, and AI engines will not automatically re-attribute to the new page. Preserving redirects protects AI visibility the same way it protects rankings, which matters more every quarter and is the core of our work on making a Magento catalog citable by ChatGPT and Perplexity. Structured data carries over the same principle, and rebuilding it correctly is covered in our guide to structured data on Magento and Hyva.
Rebuild the frontend on Hyva, not a ported theme
You cannot move a BigCommerce Stencil theme to Magento. The frontend is a rebuild, and this is the moment to build it right.
The best choice for a modern Magento frontend is a Hyva theme. Hyva replaces Magento’s heavy Luma stack with lightweight Alpine.js and Tailwind, which delivers strong PageSpeed and Core Web Vitals out of the gate. Since you are rebuilding the storefront anyway, starting on Hyva rather than legacy Luma means you never inherit the performance debt Luma carries. The build process and stack are laid out in our guide to what Hyva theme development actually involves.
Treat the rebuild as a design and UX opportunity, not a pixel-for-pixel copy of the BigCommerce storefront. You are paying for the rebuild regardless; use it.
Apps to extensions: the parity gap
BigCommerce apps do not transfer. Every app you rely on for reviews, search, subscriptions, email, or shipping needs a Magento equivalent, and the equivalents are not always one to one. Inventory this early.
Some functions that are a single BigCommerce app become native Magento features or a well-supported extension. Others need custom development. Bemeir’s ecosystem of 60-plus technology partners across payments, search, reviews, and shipping means we can usually map an app to a Magento-native or partner solution, but the gap analysis has to happen during scoping, not after launch when a merchant discovers a critical workflow is missing.
A migration sequence that reduces risk
- Confirm the business case: a structural reason to leave BigCommerce, not a redesign wish.
- Inventory apps and integrations, and map each to a Magento plan.
- Design the attribute-set and product-type model before any import.
- Export via the BigCommerce API and run a test import into a staging Magento.
- Build the 301 redirect map in parallel.
- Rebuild the storefront on Hyva.
- Reconfigure checkout, payments, tax, and shipping.
- Cut over, deploy redirects, force password resets, and crawl to verify.
How this compares to other replatforms
The mechanics here echo other migrations, with platform-specific twists. Moving off BigCommerce is a jump from SaaS to a self-hosted platform, which adds hosting and maintenance responsibility you did not have before. A Shopify or Shopify Plus migration is a similar SaaS-to-Magento shift, while a move to or from Shopware involves a different data model again, which we detail in our Magento to Shopware 6 migration guide. If you are still weighing Magento Open Source against Adobe Commerce for the destination, our edition comparison lays out the tradeoffs.
FAQ
How long does a BigCommerce to Magento migration take?
For a mid-size catalog with standard requirements, expect a few months from scoping to launch, driven mostly by the storefront rebuild and the data-model work, not the raw data transfer. Complex B2B, heavy customization, or large order-history migrations extend that. The catalog export itself is the fast part; modeling and the frontend are where the time goes.
Will I lose my SEO rankings when I migrate?
Only if the redirect map is incomplete. A full 301 redirect map covering products, categories, CMS, and blog URLs preserves the link equity and rankings tied to your old URLs. Redirect gaps are the number one cause of traffic loss in a replatform, so this task deserves more attention than any other SEO step.
Can I move my customers’ passwords from BigCommerce?
No. Password hashes cannot be transferred usefully between platforms, so customers reset their password on first login to the new store. Customer records, addresses, and order history can migrate; the credential itself cannot. Plan a clear communication so the reset does not read as a security problem.
Do my BigCommerce apps work on Magento?
No. Apps are platform-specific. Each BigCommerce app needs a Magento equivalent, which may be a native feature, a marketplace extension, or custom development. Do this gap analysis during scoping, because a missing critical workflow discovered after launch is expensive to fix under pressure.
Should I rebuild on Hyva or Luma?
Hyva. Since the frontend is a full rebuild anyway, there is no reason to start on legacy Luma and inherit its performance problems. A Hyva build gives you strong Core Web Vitals from day one, which protects both conversion and rankings on the new store.
Planning your move
A BigCommerce to Magento migration succeeds or fails on the parts the automated tools skip: the product-model translation, the redirect map, and the app parity analysis. Get those right and the data transfer is routine. Bemeir has run replatforms across BigCommerce, Shopify, and Magento as the first US-based Hyva Gold partner, and we scope the hard parts first. If you are considering a move off BigCommerce, talk to Bemeir.
