BigCommerce migration services: to or from BigCommerce

Stores move to BigCommerce when they want a hosted platform without flattening their catalog. A Magento or WooCommerce store with a deep category tree, many product attributes, B2B price lists or several storefronts often maps more directly to BigCommerce than to platforms built around flat collections. Some teams also choose it as a backend for a headless storefront.

Stores leave BigCommerce for other reasons: a move to Shopify for its app ecosystem or a team's familiarity with it, a move to a self-hosted platform for full code control, or a regional platform that suits their market better. Whether the move makes sense depends on the catalog, the integrations and the team that will run the store, not on feature checklists alone, and we look at those first.

BigCommerce offers CSV exports for products, customers and orders in the control panel, and a REST API (with both older V2 and current V3 endpoints) that exposes the catalog, customers, orders, redirects, price lists and more. For a full migration we rely on the API, because CSV exports flatten variants, modifiers and custom fields in ways that lose structure.

What does not come out: customer password hashes, stored payment methods, and most data held by apps from the BigCommerce App Marketplace, such as reviews apps, subscriptions, loyalty or search configuration. Each app vendor's export or API has to be checked separately. Stencil theme files can be downloaded, but they only work on BigCommerce, so the storefront is rebuilt on the target.

Data goes into BigCommerce through CSV imports, migration apps listed in the BigCommerce marketplace, or scripted imports through the API, which we use for large catalogs, order history and anything the CSV cannot express. The catalog model matters. Variant options create sellable variants with their own SKU, price and stock; modifiers capture choices that do not create a variant, such as engraving text or a gift message; custom fields hold simple name-value specifications. Deciding which source attribute becomes which of these is the core mapping work.

Categories can be nested, so a source category tree often transfers without being flattened. Customer groups and price lists support group-specific or currency-specific pricing, which we map from the source platform's pricing rules. Customers arrive without usable passwords unless the source and the chosen method support something else, which we check per project, and historical orders are imported as records for customer history and reporting.

Moving to BigCommerce, the typical work is splitting source attributes between variant options, modifiers, custom fields and filterable attributes, remodelling bundles or configurable products that do not match the option model, and translating customer-group pricing into price lists. Product descriptions with theme markup or shortcodes from the old platform are cleaned up, and order statuses are mapped to BigCommerce's status set.

Moving from BigCommerce, the reverse applies. On a target like Shopify, the category tree becomes collections plus navigation, modifiers become options, line-item properties or an app, and custom fields become metafields. Price lists and customer groups need an equivalent on the target (native B2B features, an app, or a simpler model). Multi-Storefront setups must be mapped to the target's model of markets or separate stores.

Apps are replaced, not moved. Moving in, we list the plugins or apps that do real work in your current store and find the BigCommerce feature or marketplace app that covers each, noting what needs custom development. Moving out, we list the installed apps, what data each one holds and whether it can be exported.

The storefront is built with Stencil themes, customized from a marketplace theme or built from scratch; a headless setup replaces the theme layer with a separate frontend. Payment gateways, shipping rules, tax settings, ERP, PIM, feeds and marketing integrations are configured and tested on staging with real orders before launch. Checkout customization options depend on your plan and setup, and we confirm them before promising any specific checkout behaviour.

BigCommerce lets you set custom URLs for products, categories, brands and pages, and to choose URL formats in its SEO settings. That flexibility helps when migrating in: many old URLs can be matched or kept close, which reduces redirects. It does not happen automatically, though, and it has to be decided in the mapping before import. 301 redirects are managed in the control panel and through the API, and BigCommerce can create redirects automatically when a product or category URL changes.

Moving out, every BigCommerce URL that matters is mapped to the target's structure, including brand pages, blog posts and URLs that already redirect. We crawl the old site before migration, carry over page titles, meta descriptions and image alt text, crawl the new store on staging, and monitor Search Console after launch. We check coverage and redirects; we do not promise rankings.

Customer passwords are handled as a reset or reactivation step unless we confirm a supported alternative for your specific source and target. Stored cards and subscription tokens depend on the payment gateway and never move as part of a data export. Some features, such as 301 redirects, are not available on trial stores, and API limits, storefront counts and B2B features vary by plan, so we check your plan during the audit rather than quoting general numbers.

Multi-currency and multi-language setups need care in both directions: price lists, currency settings and storefront translations do not map one to one onto other platforms. Headless builds add a separate frontend project with its own routing and redirect handling.

A named lead owns the project. We audit the source (catalog structure, attributes, pricing rules, customers, orders, apps, integrations and indexed URLs), write a mapping you approve, and run a trial migration into a non-production BigCommerce store or the target platform's staging store. You check it record by record. After sign-off we plan launch: content freeze, final migration, a delta migration of new orders and customers, redirects, DNS and payment tests.

Scripts and automated comparisons check counts, prices, stock and URLs, and a person approves every production decision. After launch we review orders, emails, feeds and redirects, and fix what the first days of traffic uncover.