WooCommerce to BigCommerce migration

The reasons are similar to any move off WooCommerce: owning WordPress core and plugin updates, hosting capacity, security and PCI scope becomes expensive as the store grows. BigCommerce hands hosting, checkout security and platform updates to the vendor. Stores often choose it over other hosted platforms because its catalog model sits closer to WooCommerce: nested categories, products in several categories, options that do not all create SKUs, and custom URLs for products and categories.

It is not automatically the right move. If most of your organic traffic comes from WordPress content, if you rely on deep checkout customization in PHP, or if a single WooCommerce extension is core to how you sell, check the BigCommerce equivalent first. Sometimes the answer is a cleaner WooCommerce setup, or WordPress kept for content with BigCommerce for commerce. We say that in the assessment when it applies.

In WooCommerce, attributes are either global taxonomies (such as pa_size) or local to one product, and variations are child posts. BigCommerce separates two kinds of options. Variant options create a SKU per combination with its own price, stock and image. Modifier options change the order line (engraving text, gift wrap, a paid add-on) without creating a SKU.

The mapping follows that split. Attributes used for variations become variant options. Product add-on data from plugins such as WooCommerce Product Add-Ons usually becomes modifiers, with price adjustments checked one by one. Variations set to "Any" value for an attribute are expanded into explicit variants, which changes SKU and inventory counts, so we reconcile them deliberately.

Attributes not used for variations, and Advanced Custom Fields data, become BigCommerce custom fields (name and value pairs shown on the product page) or, where structure matters, product metafields read by the theme or integrations. Grouped products are rebuilt as related products or bundles, and external/affiliate products need a theme change. Weight, dimensions, tax class, sale prices and stock settings are mapped field by field.

BigCommerce has a category tree, and a product can belong to several categories, so WooCommerce product categories usually map across with their hierarchy intact. That makes this route more direct than a move to a collection-based platform, but we still review the tree: empty categories, duplicates and categories used only as filters are cleaned up with your approval, because each removed URL needs a redirect target.

Product tags have no direct navigational equivalent; they become search keywords, custom fields or categories depending on how they were used. Brands managed by a WooCommerce brands plugin or taxonomy map to BigCommerce's native brand entity, with brand pages and descriptions.

Customer accounts, addresses and customer groups can be imported into BigCommerce, and WooCommerce roles used for wholesale or trade pricing are mapped to customer groups with their price rules. Customer passwords are a separate question: WordPress stores hashes (phpass or bcrypt depending on version), and whether they can be carried over depends on the migration method BigCommerce supports at the time. We plan for a password reset flow unless a supported method is confirmed during the assessment.

Order history is imported so customers and your team keep past orders. BigCommerce assigns its own order IDs, which matters for accounting, ERP and customer service, so we keep the WooCommerce order number as a reference and agree how it will be searched. Order statuses are mapped to BigCommerce statuses, and totals, taxes and counts are reconciled after the trial run. Refunds for old orders stay with the original gateway, and stored cards are never moved silently.

WordPress permalinks are configurable, so a WooCommerce store might use /product/{slug}/, /product-category/{parent}/{child}/ or a custom base. BigCommerce lets you set custom URLs for products, categories, brands and pages, which often makes it possible to keep product slugs close to the originals. We still assume nothing: each important URL is compared old against new, and any change gets a 301 redirect, managed in the BigCommerce admin.

The redirect list is built from a crawl of the live store plus Search Console, analytics and backlink data, and covers products, categories, tags, blog posts, pages and indexed archives. Redirects point to the closest relevant page, not the homepage. SEO titles and descriptions from Yoast or Rank Math, image alt text and canonical intent move with the content. After launch we recrawl the old URL list, check chains and 404s, and submit the new sitemap in Search Console. That protects URL continuity; no migration can promise unchanged rankings.

BigCommerce has web pages and a basic blog, but not WordPress's editor, custom post types or page builders. Posts and pages can migrate as content, with layouts rebuilt in the Stencil theme or Page Builder. If content drives significant traffic, keeping WordPress for content next to BigCommerce is an option we weigh with you from the data.

Every active plugin gets a decision: native BigCommerce feature, app, custom API integration, or dropped. Reviews are exported and imported into BigCommerce's native reviews or a review app. WooCommerce Subscriptions depend on whether your gateway can move stored payment methods to a BigCommerce subscription app; otherwise customers re-subscribe. Memberships, points, wholesale rules and gift cards come from plugins with their own tables and are assessed one by one. Payments, shipping, tax, ERP, email marketing and product feeds are reconnected and tested in the trial migration.

We audit the WordPress database and plugin list, not only the WooCommerce CSV export, because much plugin data sits in postmeta and custom tables. The result is a field-level mapping you approve: variant options versus modifiers, custom fields, categories, customer groups, order statuses and content.

A trial migration goes into a BigCommerce sandbox or staging store and is reconciled: product, SKU and order counts, prices, stock, a set of products checked by a person, and redirects tested against the crawl list. Automation compares source and target; a person approves what reaches production. At launch we agree a short freeze, run a delta migration of new orders, customers and stock, switch DNS and activate redirects, then run post-launch QA on orders, emails, feeds and Search Console.

Password transfer is not something to assume. Active subscriptions depend on your gateway. Order IDs change, so old numbers need a reference field. Page-builder layouts and WordPress custom post types are rebuilt, not migrated. Some WooCommerce extensions, especially custom checkout logic, have no one-to-one BigCommerce equivalent and need an app, API work or a changed process.