Magento to BigCommerce migration

Stores leave Magento for the same reason they leave for any hosted platform: the cost of hosting, security patching, extension maintenance and PCI scope for a self-hosted checkout has outgrown what the business needs. Magento 1 stores have had no official Adobe support since 30 June 2020, which turns the decision into a deadline.

BigCommerce tends to suit Magento stores whose value sits in catalog structure and URLs: nested categories, many product options, and an established URL scheme that ranks. It is a weaker fit when the business depends on code-level checkout changes, deep Adobe Commerce B2B workflows, or an ERP writing straight into the Magento database. B2B features and multi-storefront availability depend on the BigCommerce plan and edition, so we confirm them in the assessment rather than assume them.

Magento 1 data is usually read directly from the database, including years of leftover extension tables. Magento 2 and Adobe Commerce have native import/export and a REST API, but attribute sets, URL rewrites and extension data are still verified at database level. Adobe Commerce content staging versions EAV rows by row_id, so extraction must pick the currently active version, not a scheduled one. Customer segments, reward points, store credit, gift card accounts and the B2B module each need a decision in the mapping sheet.

Magento's EAV model allows arbitrary attributes per attribute set and per store view. BigCommerce products have core fields, variant options that create SKUs, modifier options that change the order without creating a SKU (engraving text, gift wrap, surcharges), and custom fields for extra specification data. That gives more places to put Magento data than Shopify's three option dimensions, but it still has to be designed.

Configurable products become BigCommerce products with variant options, and each Magento simple child becomes a variant SKU with its own price, weight, stock and image. Magento custom options usually become modifiers. Filterable attributes become custom fields or option values used in faceted search, depending on how the storefront filters are configured. Attributes nobody fills or uses are archived instead of recreated.

Bundle products need a rebuild: depending on pricing and stock logic, they become a product with modifier options that reference other products, a separate kit SKU managed in your ERP, or an app. Grouped products usually become related products or a category. Tier prices and customer group pricing map to BigCommerce customer groups and price lists where your plan supports them, otherwise to an app.

BigCommerce uses a nested category tree, so Magento categories can keep their hierarchy and product assignments, including products that sit in several categories. That is a real structural advantage over collection-based platforms. We still review the tree: Magento stores often carry duplicate categories per store view, disabled branches and anchor settings that only made sense for layered navigation. Brands stored as a Magento attribute can become BigCommerce brands, which also get their own pages and URLs.

Customers, addresses, customer groups and newsletter status migrate. Magento password hashes are not something we assume BigCommerce can accept, so we plan for customers to reset their password on first login, with an email sequence timed around launch; whether any other option exists is checked during the assessment.

Orders are imported as historical records through the BigCommerce API, linked to customers and to products by SKU, which is why products go first. Historical orders keep dates, line items, totals and statuses, without re-triggering payments or notifications. Stored cards and payment tokens are not moved unless the gateway supports a formal token transfer.

Magento URLs come from the url_rewrite table (core_url_rewrite on Magento 1): product URL keys, often ending in .html, sometimes with the category path included, and different per store view. On Shopify almost every one of those changes, because Shopify forces /products/ and /collections/ prefixes. BigCommerce lets you set a custom URL for each product, category, brand and page, so many Magento URLs can be recreated exactly and need no redirect at all.

That changes the work rather than removing it. We decide per URL type whether to keep the Magento path or clean it up, set custom URLs during import, and build 301 redirects only for URLs that genuinely change: merged categories, retired products, store-view duplicates and parameter-based filter URLs. BigCommerce's 301 redirect manager supports manual redirects and dynamic redirects that point to a product or category and follow it if its URL changes later, and it can create redirects automatically when a URL is edited. We check that automatic behaviour during the trial so it does not create redirect chains.

Before launch we crawl the Magento site and pull Search Console pages with impressions; after launch we crawl the same list against BigCommerce, check status codes, resubmit the sitemap and monitor coverage. Keeping URLs reduces risk; it does not guarantee rankings.

Magento extensions and themes do not migrate. Every active module is listed and classified: native BigCommerce feature, app from the BigCommerce marketplace, custom integration against the BigCommerce APIs, or retired. Common cases are search and filtering, reviews, feeds, ERP and warehouse connectors, B2B quoting and loyalty. Extension data such as reviews or loyalty balances is moved only where the target app has an import path.

The theme is rebuilt on Stencil, or on a headless storefront if that is the plan. Checkout changes are made within BigCommerce's checkout customisation options, not by editing core code, so custom Magento checkout steps need a redesign. Cart price rules become BigCommerce promotions and coupon codes. Magento websites and store views for other languages, countries or brands map to BigCommerce multi-storefront, channels or separate stores depending on plan and requirements.

Audit, mapping, trial migration, sign-off, freeze and delta migration, launch, post-launch QA. The audit sizes data, attributes, extensions, integrations and indexed URLs. The mapping sheet assigns every Magento field to a BigCommerce field, option, modifier or custom field, and records which URLs are kept. The trial migration runs into a BigCommerce trial or sandbox store for your team to check. Automated comparison of counts, prices and URLs flags differences; a person decides what is correct. At launch we freeze Magento briefly, migrate the delta of orders, customers and stock, switch DNS, activate redirects and run post-launch QA.