BigCommerce is a hosted SaaS commerce platform. Evaluating it as a migration destination means deciding how its catalog, buyer pricing and storefront model will support the future store.
Hosting the commerce core reduces the infrastructure work associated with self-hosted systems. The merchant still owns catalog meaning, buyer treatment, storefront configuration and connected operations.
The sections below separate native records from the rules and systems that make them usable. A platform feature does not establish transfer coverage for a particular migration.
Matching Product totals can still conceal failures:
- Shoppers cannot select the intended configuration.
- Wholesale buyers receive the wrong price.
- Old URLs lead to irrelevant destinations.
- App-managed data is absent from the workflow that needs it.
Review the buying, pricing, discovery and operating relationships together.
Where BigCommerce Fits in Platform Migration Planning
BigCommerce combines hosted operations with defined catalog, pricing, Customer, channel and integration structures. Reducing commerce-infrastructure work does not remove the need to interpret those structures before migration.
Source expectations differ:
- Shopify: compare options, variants, metafields, apps, redirects and buyer-pricing assumptions.
- Magento, Adobe Commerce, WooCommerce, OpenCart, PrestaShop or a custom platform: reinterpret configurable Products, fields, Customer groups, Category hierarchies, extensions and external IDs.
- Legacy hosted systems: inspect older URLs, option conventions and checkout-adjacent behavior, even when record volumes look modest.
| BigCommerce planning area | Why it matters during migration |
|---|---|
| Product choices | Classify SKU-bearing variants and their options, buyer-input modifiers, descriptive custom fields, resource metafields and separately owned behavior; confirm handling for each. |
| Category and discovery structure | Category trees, product assignments, navigation, and SEO-sensitive paths affect how shoppers find products. |
| Pricing and customer context | Customer groups, price lists, bulk pricing, and negotiated pricing can change commercial outcomes. |
| Channels and storefront scope | Channel assignments and Multi-Storefront expectations affect where products, categories, currencies, and content appear. |
| Redirect and content continuity | Redirects, pages, Blog Posts, media, and high-value URLs need launch and search continuity planning. |
| Custom data and integrations | Metafields, custom fields, apps, external IDs, ERP references, reviews, subscriptions, or merchandising tools may carry operational meaning. |
Judge the translation by whether it preserves buying, pricing, discovery, support and operational meaning in the future store.
BigCommerce as Hosted SaaS With Structured Commerce Behavior
The commerce core is hosted, while the merchant remains responsible for its catalog rules, pricing, storefront choices and API/app integrations. A separately hosted headless frontend brings its own implementation and operating responsibilities.
Source code, plugins, modules, checkout changes and Product logic need a supported destination or an agreed replacement; they do not follow automatically with the records.
Confirm the features enabled in the intended account and storefront solution. Customer Groups, Price Lists and Multi-Storefront need the actual configuration to support the required outcome, not an assumption based on the platform name.
| Source environment | BigCommerce migration implication |
|---|---|
| Open-source or self-hosted platform | Confirm which source fields, modules, pricing and checkout requirements fit supported migration output, approved mapping/configuration, tailored migration or separately owned target setup. |
| Hosted SaaS platform | Compare option, variant, metafield, app, redirect, and customer-pricing behavior rather than assuming SaaS-to-SaaS equivalence. |
| CMS-connected commerce | Separate product data from CMS Pages, Blog Posts, menus, content URLs, and SEO-sensitive landing pages. |
| Enterprise commerce | Review customer groups, price lists, B2B-like expectations, catalogs, storefront/channel scope, and external-system identifiers. |
| Legacy platform | Watch for outdated URL structures, encoding issues, old custom fields, hard-coded categories, and app-equivalent behavior hidden in templates. |
The stronger BigCommerce migration starts from a distinction between records and behavior. Records describe what exists. Behavior explains how the store sells, prices, displays, redirects, segments, and integrates those records.
Product Choice and Catalog Meaning
Products, images, reviews and Category/channel assignments remain separate catalog relationships. Classify source choices by what they do before mapping them.
- Variants and variant options: identify the sellable combination, such as size and color, with the required SKU, stock, price and media meaning.
- Modifiers: collect buyer inputs or additions such as engraving text, gift wrapping, a service add-on or a file upload without selecting a different fulfilled variant.
- Custom fields: hold descriptive Product information; they do not collect a shopper’s personalization input.
- Metafields: hold programmatic data against the appropriate resource for a known app or integration consumer.
Modifier combinations do not have their own inventory. A Product-list modifier can affect a linked Product’s stock, which is a different relationship.
Subscription choices, warranty plans, bundle components and configuration rules need an explicit target owner. Saving a value does not recreate its workflow.
| Source product pattern | BigCommerce planning question |
|---|---|
| Size, color, material, package, or SKU-level choice | Should it become a variant or variant option? |
| Engraving, file upload, gift note, service add-on, or personalization | Does it need a shopper-input modifier or a separately implemented flow? A descriptive custom field does not collect the buyer’s input. |
| Bundle, kit, product builder, or component logic | Is the behavior supported, target-side setup, or project-specific implementation scope? |
| Product-specific metadata used by apps or ERP | Should it become a metafield, custom field, integration reference, or excluded data? |
| Product assigned to multiple storefronts or channels | Should channel assignment and storefront visibility be validated separately? |
Names, SKUs, descriptions, prices and images are insufficient when buying choices lose their meaning. Use representative catalog patterns:
- Best sellers and variant-heavy or modifier-driven Products.
- Custom-field Products and those with special pricing.
- Products in several Categories or dependent on app behavior.
Categories, Channels, and Storefront Discovery
A Category tree shapes navigation, merchandising, search continuity, campaign landing paths and Product discovery. Decide which source groups should remain shopper paths, which are administrative classifications and which should be simplified before launch.
Channel availability and Category placement are separate:
- Availability: a Product needs assignment to the intended sales channel.
- Discovery: the intended storefront needs the correct Category tree and Product membership.
- Storefront context: confirm its pricing, currencies, content and customer paths.
Category membership alone does not establish channel availability. Removing a Category assignment can leave search or direct-link access available; do not treat that removal as proof of access restriction.
| Discovery area | Migration implication |
|---|---|
| Category tree | Preserve, simplify, or rebuild based on shopper discovery and SEO value. |
| Product-category assignments | Validate high-value products and categories, not only category count. |
| Navigation and menus | Treat storefront structure as launch readiness, not automatically solved by category migration. |
| Channels and storefronts | Confirm product channel assignments, category-tree context, content, currencies, pricing, and URLs for each intended storefront. |
| Redirects | Map old high-value product, category, CMS Page, and Blog Post URLs to useful target destinations. |
Keep high-value discovery paths and deliberately simplify or retire legacy Categories that no longer serve shoppers. Preserving every old path is not the objective.
Pricing, Customer Groups, and Commercial Context
Review pricing as commercial logic:
- Catalog: standard and sale prices, quantity tiers and promotions.
- Buyer: Customer groups, Price Lists, wholesale/distributor tiers and Customer- or segment-specific treatment.
- Special agreements: regional, negotiated or contract prices, including app- or externally managed pricing.
Public retail pricing may need fewer translation decisions than segmented or externally controlled pricing. For each required rule, decide whether the target uses Product prices, an enabled Price List, Customer-group configuration or an owned integration.
Company accounts, buyer roles and negotiated quote or invoice workflows require the selected B2B solution and configuration. Customer Groups and Price Lists alone do not create that company-buying model.
| Pricing context | Planning concern |
|---|---|
| Standard and sale prices | Confirm current product pricing and promotion expectations. |
| Bulk pricing | Validate quantity-based price behavior where it affects key products. |
| Customer groups | Confirm which customers belong to which commercial segment. |
| Price lists | Confirm enabled Price Lists, variant/currency coverage, group/channel assignments and the expected fallback when a price is missing. |
| External pricing systems | Treat ERP, B2B, quote, contract, or custom pricing logic as integration or project-specific implementation review. |
A catalog price can look right while a particular buyer receives the wrong amount. Check the Customer, storefront, quantity and currency together.
When cascading Price Lists are configured, a missing primary-list price can resolve through active fallback layers before catalog pricing. Confirm the actual pricing path rather than assuming immediate catalog fallback.
Content, Redirects, and SEO Continuity
Content and URL continuity matter when indexed pages, campaigns or long-lived links bring visitors to the source store. Redirects should preserve useful destinations and customer intent; their existence alone does not guarantee search performance.
Identify important Product, Category, CMS Page, Blog Post, brand, search-landing and campaign URLs before launch. For each, choose:
- An equivalent page or an approved relevant replacement.
- Rebuilt or consolidated content when the old structure changes.
- Intentional retirement when no useful destination remains.
Use URL and redirect planning to define the destination and exceptions. Confirm which content transfer or rebuild work is included in scope.
| Content or URL item | Migration decision |
|---|---|
| Product URLs | Map to the new product page or approved replacement. |
| Category URLs | Preserve high-value discovery paths and avoid generic destinations where possible. |
| CMS Pages | Decide whether to migrate, rebuild, redirect, merge, or retire. |
| Blog Posts | Preserve where they support organic traffic, buying education, or customer support. |
| Redirects | Validate destination quality, not only whether redirects exist. |
| Storefront content blocks | Identify whether they are theme, widget, page-builder, app, or migration data. |
BigCommerce can support content and redirect management, but migration planning should still separate content preservation from storefront design and theme setup.
Custom Data, Apps, and Integration Boundaries
Separate commerce records from data owned by apps, scripts, extensions or outside systems. API access can enable a connection, but it does not reproduce the process that creates or consumes a value.
Connected data can include:
- Identity and finance: ERP Product IDs, Customer segmentation, warehouse references, accounting codes and marketplace identifiers.
- Buyer relationships: personalization, reviews, subscriptions, loyalty balances and checkout-adjacent fields.
- Operating rules: merchandising, search and shipping data.
For each retained value, identify its parent record, visibility and continuing consumer. An API field or metafield is useful only when the required workflow can interpret it.
Confirm the handling route for each requirement:
- Supported migration data.
- Approved compatible mapping or bounded configuration.
- Tailored migration output beyond that support.
- Separately owned target setup or integration work.
- An agreed exclusion with required history retained.
A custom field, metafield or external ID alone does not require tailored migration. Capability, compatibility and confirmed scope determine the route.
BigCommerce Migration Planning Priorities
Turn the platform model into five decisions:
- Catalog translation: variants, modifiers, descriptive fields, metafields and separately owned buying behavior.
- Commercial continuity: prices, Customer groups, Price Lists, promotions and external pricing references.
- Storefront continuity: Categories, channels, content, URLs and redirects.
- Data ownership: who maintains app, ERP, subscription, search, merchandising or custom-code data, and its agreed handling route.
- Evidence: samples proving Product choice, price visibility, Category discovery, redirect quality, Customer history, Order context and custom-data use.
Prepare source examples and assign ownership before execution. Include approved changes and exceptions; representative samples do not establish complete migration acceptance.
Hosted operations can reduce commerce-infrastructure responsibility while leaving selling, pricing, discovery, segmentation and integration decisions with the merchant. Those decisions define migration scope.
Conclusion
BigCommerce offers a hosted commerce core with distinct catalog, buyer-pricing, storefront and integration structures. A usable migration preserves how shoppers choose, what they pay, how they find content and how connected systems use the data.
Use the BigCommerce fit profiles to decide whether those structures support the intended business. Agree the destination owner for each required relationship before treating a transferred record as a working outcome.
Common Questions
Is BigCommerce a simple hosted platform for migration planning?
No. BigCommerce is hosted SaaS, but migration planning can still be structurally complex when product options, variants, modifiers, customer groups, price lists, channels, redirects, apps, and custom data affect how the store sells.
Why are product options important in a BigCommerce migration?
Product options can affect SKU behavior, pricing, personalization, images, inventory, fulfillment, and the buying path. Classify SKU-bearing choices, buyer inputs and descriptive values separately before mapping them. Variants, modifiers and custom fields serve different purposes; confirm supported handling rather than treating every source option as a custom requirement.
Does BigCommerce migration automatically preserve storefront discovery?
No. Categories, navigation, channel visibility, product assignments, CMS Pages, Blog Posts, and redirects need separate review. A product can migrate correctly while the customer path to that product still changes.
When does BigCommerce migration need project-specific handling?
First confirm supported data handling and compatible mapping. Tailored migration may be needed for essential unsupported app data, bespoke transformations, custom-built platforms or migration-logic changes. Custom fields, metafields and external IDs are not automatic triggers: identify their meaning and consumer. Target implementation or an integration can remain a separate responsibility.
What should be validated early for BigCommerce?
Validate representative products with options, important categories, segmented pricing, customer groups, channel or storefront assignments, high-value URLs, customer/order samples, and any app or custom-data examples that affect business operations.