BigCommerce migration failures often come from preserving records while losing the relationship that gives them storefront or operational meaning. Product variants and modifiers can look similar in the source but behave differently in fulfillment. Customer groups and price lists can both influence what a buyer sees, yet they are not one pricing field. Channels, sites, category trees, content, inventory locations, and storefront frameworks add further context.
The following pitfalls focus on recurring mistakes that leave a BigCommerce Store populated but commercially inconsistent. Each prevention control names the relationship that must survive and the narrow condition that proves the pitfall is under control.
Pitfall 1: Treating Variants, Modifiers, and Product Fields as the Same Choice Model
What goes wrong
Source options are mapped into whichever BigCommerce field appears most convenient. Stock-bearing child SKUs become modifiers, personalization becomes variants, and technical specifications become buyer-selectable choices.
BigCommerce variants are combinations of variant option values and can carry first-class commercial data. Modifiers represent shopper choices that customize or add to the fulfilled item but do not change which variant is picked from inventory. Product custom fields and metafields serve other descriptive or operational purposes.
Early warning signs
| Early warning sign | What it indicates |
|---|---|
| Size and color combinations with distinct stock are created as modifiers. | Inventory-bearing choices are being detached from variant identity. |
| Engraving, date, file upload, or warranty choices are created as variants. | Non-inventory personalization is being turned into artificial SKUs. |
| Source child SKUs are lost because the parent Product is treated as the only inventory unit. | Fulfillment and stock continuity will break at the variant level. |
| Product specifications are visible only inside descriptions or shopper choices. | Structured attributes are being mixed with selling controls. |
Prevention
Classify each source value by fulfillment behavior. Use variants for independently identifiable sellable combinations, modifiers for purchase-specific customization that does not select another stocked variant, and custom fields or metafields for descriptive or operational data.
Preserve variant option values, SKU, inventory, price, weight, images, and external identifiers as one relationship. Preserve modifier selections with the Order line and do not assign inventory to modifier combinations.
Recommendation example
For tailored trousers, represent waist and inseam sizes as variants when each combination is stocked and fulfilled separately. Keep monogram text as a modifier and fabric-care instructions as Product custom data.
Pass condition
Every sampled choice resolves to the correct fulfilled variant, modifier selections remain visible on the Order line, and descriptive fields do not create false variants or inventory records.
Pitfall 2: Preserving Categories While Breaking Category Trees and Storefront Discovery
What goes wrong
Source Categories are imported as one flat or global hierarchy without considering BigCommerce category trees, channel context, menus, faceted search, sorting, or storefront framework. Products remain assigned to Categories, but shoppers encounter missing branches, irrelevant filters, or the wrong tree on a storefront.
A source Category can also represent a brand, campaign, internal grouping, or SEO landing page rather than durable catalog hierarchy.
Early warning signs
- One Category tree is assumed to serve every storefront or channel.
- Product assignments are reviewed without checking which tree the storefront uses.
- Brand, attribute, and campaign values are all converted into Categories.
- Navigation and faceted search are expected to derive automatically from imported Category rows.
Prevention
Classify source groupings by purpose. Build or assign the intended category tree for each storefront context, preserve Product-to-Category relationships, and keep brand, filter, campaign, and navigation meanings separate.
Define which values power faceted search and which Categories need content, sorting, images, or redirects. Treat Stencil, Catalyst, and headless storefront discovery as implementations that consume catalog relationships rather than automatic results of Category import.
Recommendation example
For a merchant with retail and wholesale storefronts, use separate channel-appropriate category trees where the buyer journeys differ, retain shared Product identity, and preserve Product attributes or custom data used by filters instead of duplicating them as Categories.
Pass condition
Each storefront uses the intended category tree, Products appear in the correct branches, navigation reaches those branches, and filters rely on consistent data rather than accidental Category duplication.
Pitfall 3: Separating Customer Groups From the Price Lists That Give Them Meaning
What goes wrong
Customer groups migrate as labels, while price lists, variant-level price records, Category access, or channel assignments are handled separately. Buyers appear in the correct group but still receive catalog prices, the wrong currency, or access to the wrong assortment.
BigCommerce price lists can override variant pricing and can be assigned through customer groups, channels, or a customer-group-and-channel combination. A price list without its assignment is not a complete pricing model.
Early warning signs
| Early warning sign | What it indicates |
|---|---|
| Group migration is considered complete when Customers display the correct group name. | The commercial meaning of the group has not been preserved. |
| Prices are mapped only at Product level even when variants differ. | Price-list coverage will be wrong for specific sellable units. |
| Price-list assignments omit channel context. | A valid price may appear in the wrong storefront or fail to appear where required. |
| Bulk pricing and price-list overrides are combined without precedence rules. | Competing price mechanisms may produce inconsistent outcomes. |
Prevention
Model group, Category access, price list, variant price record, currency, channel, and assignment as connected structures. Preserve the exact relationship that determines which signed-in shopper receives which variant price on which storefront.
Separate historical Order prices from active price-list records. Keep external contract or ERP pricing identifiers when another system remains authoritative.
Recommendation example
For a VIP group shopping on a regional storefront, preserve group membership, Category access, the price list, variant-level price records, currency, and the assignment linking that group and channel.
Pass condition
A representative signed-in Customer sees the intended assortment and variant prices on the intended channel, while Customers outside the group receive the correct fallback pricing.
Pitfall 4: Treating Channels, Sites, and Storefronts as Decorative Labels
What goes wrong
Products, Categories, Customers, prices, currencies, menus, and content are migrated without preserving the channel and site relationships that define where they appear. The Store has one correct default storefront, while secondary brands, regions, marketplaces, or headless experiences inherit incorrect catalog and configuration.
In BigCommerce, a channel represents a selling context, while a site represents a merchant-controlled website tied to a storefront channel. Channel-specific assignments and settings therefore influence more than a display label.
Early warning signs
| Early warning sign | What it indicates |
|---|---|
| Records default to the primary channel because no channel ID is supplied. | Channel ownership is missing from migrated records. |
| Product and price-list assignments are reviewed globally rather than by storefront. | Storefront-specific assortment and pricing differences are being flattened. |
| Domains, sites, menus, currencies, and category trees are documented separately. | The complete storefront relationship is not being managed as one system. |
| Apps and integrations assume every Order or Product interaction belongs to the default channel. | Downstream systems will misclassify origin and context. |
Prevention
Define the channel model before final mapping. Identify each storefront, marketplace, POS, marketing, or custom channel; the site and domain tied to each storefront; and the Product, Category tree, pricing, currency, menu, Order, and app context that belongs to it.
Preserve channel IDs and source channel references in integration mappings. Do not use the default channel as an unexplained fallback.
Recommendation example
For two brand storefronts and an Amazon channel, keep one shared Product catalog where appropriate, assign Products and price lists to the correct storefront channels, use the intended category tree and site for each brand, and preserve marketplace Order origin separately.
Pass condition
Products, prices, menus, Category trees, Orders, and integrations resolve to the intended channel and site. No secondary storefront depends on default-channel behavior by accident.
Pitfall 5: Importing Inventory Without Location and Channel Context
What goes wrong
One stock quantity is copied to the Product or variant even though the source tracks warehouses, retail stores, pickup points, suppliers, or channel allocations. The total looks plausible, but pickup availability, fulfillment, and external synchronization reference the wrong location or sellable unit.
The problem becomes more serious when the source has variant-level stock but the target mapping uses the parent Product, or when a WMS remains authoritative after migration.
Early warning signs
- Inventory files contain SKU and quantity but no location identifier.
- Parent Product quantity is used for Products with real variants.
- BOPIS or pickup locations are absent from the location map.
- External warehouse IDs are discarded after opening quantities are imported.
Prevention
Map inventory to the exact Product variant and BigCommerce location that owns it. Preserve location identifiers, variant SKUs, external inventory keys, and any channel or pickup relationship required by the continuing workflow.
Separate current sellable inventory from historical movement, reserved stock, damaged stock, supplier availability, and other states that do not belong in the opening quantity.
Recommendation example
For a retailer with a central warehouse and three pickup stores, map each source location to the corresponding BigCommerce location, preserve variant-level quantities and warehouse keys, and keep channel or pickup availability rules separate from the raw quantity.
Pass condition
Sample variants show the intended quantity at each location, pickup or fulfillment services recognize the correct stock owner, and the continuing inventory system updates the same variant-location records without duplicates.
Pitfall 6: Treating Redirects as a Final Technical Import
What goes wrong
Redirects are generated after Product, Category, page, and storefront routes have already been finalized. Old URLs are mapped mechanically to the nearest target path without preserving user intent, channel, site, locale, or content ownership.
BigCommerce can manage redirects and site routes, but a redirect file does not resolve missing content, incorrect Category trees, storefront-framework differences, or channel-specific destinations.
Early warning signs
| Early warning sign | What it indicates |
|---|---|
| Redirect planning includes Product URLs but excludes Categories, pages, Blog Posts, filtered routes, and campaign content. | The redirect inventory does not represent the full traffic surface. |
| One destination is used across storefronts even when each site has a different route structure. | Channel-specific journeys are being collapsed. |
| Redirects point to pages that are unpublished or absent from the active storefront. | The mapping is technically present but unusable for customers. |
| Legacy query parameters and app-generated paths are ignored. | Important noncanonical and integration-created routes may fail silently. |
Prevention
Create a route inventory tied to destination ownership. Map each important source URL to a Product, Category, page, Blog Post, site route, storefront application, replacement content, or deliberate retirement decision.
Prioritize revenue, organic traffic, backlinks, Customer bookmarks, and active campaigns. Keep channel and site context explicit when the same source pattern needs different destinations.
Recommendation example
For a multi-storefront merchant, map the top Product and Category URLs separately for each brand site, connect retired campaign pages to relevant replacement content, and preserve headless application routes where the storefront owns them outside the core catalog.
Pass condition
Priority URLs reach useful content on the intended site and channel, no redirect points to an unavailable destination, and omitted paths have an intentional retirement decision.
Pitfall 7: Copying Custom Fields and Metafields Without Application Ownership
What goes wrong
Source custom fields, app data, integration flags, SEO values, and external identifiers are all mapped into Product custom fields or metafields. Values arrive without clear types, permissions, namespaces, consumers, or parent resources.
BigCommerce supports metafields on several resources and Product custom fields for storefront information, but those structures do not automatically recreate the app, theme, integration, or workflow that used the source data.
Early warning signs
- The destination is chosen from the source field label rather than its consumer.
- Variant-level values are attached to the parent Product.
- App-owned fields are recreated under unrelated namespaces.
- Source IDs that referenced Products, Customers, media, or Orders are copied literally.
Prevention
Classify custom data by owner and purpose. Use Product custom fields for suitable storefront-visible Product information, resource metafields for typed operational or application data, and external systems for records they continue to govern.
Translate references to destination IDs, preserve namespaces and permissions, and record the theme, app, API, or integration that consumes each field.
Recommendation example
Store a public material specification as a Product custom field when the storefront should display it. Preserve a variant-level warehouse code as a variant metafield and keep subscription state under the subscription application that owns it.
Pass condition
Custom data appears on the correct resource, is consumed by the intended storefront or system, and contains no orphan namespaces, parent-level substitutions, or copied source IDs.
Pitfall 8: Treating Customer and Order Presence as Operational Continuity
What goes wrong
Customer and Order counts match, but identity, addresses, group assignment, consent, Order-line variants, discounts, taxes, shipping, refunds, consignments, shipments, statuses, and external references are incomplete. Historical payment and shipping labels are then mistaken for current checkout and fulfillment configuration.
This failure weakens support and finance even when the Store can place new Orders successfully.
Early warning signs
- Customer identity is matched only by email.
- Group assignment is reviewed without checking pricing and Category access.
- Orders are sampled only by number and total.
- Multi-address, refunded, partially shipped, or channel-origin Orders are absent.
Prevention
Preserve Customer identity, addresses, attributes, consent, group, and external IDs according to the business purpose. Preserve historical Order lines, variants, prices, adjustments, taxes, shipping addresses, consignments, shipments, refunds, statuses, notes, channel origin, and external references at the level required by support and finance.
Keep historical evidence separate from current payment, checkout, shipping, tax, and fulfillment configuration.
Recommendation example
For a partially shipped regional Order, preserve the Customer and group, purchased variants, channel, shipping addresses, consignments, shipment tracking, discount, tax, refund evidence, and ERP Order ID. Configure future regional checkout and shipping separately.
Pass condition
Customers remain identifiable and commercially classified, historical Orders remain understandable across support and finance, and current operations do not rely on imported labels as configuration.
Cross-Pitfall Prevention Priorities
| Priority | Required control |
|---|---|
| Choice ownership | Separate variants, modifiers, custom fields, metafields, and app data by behavior. |
| Storefront context | Preserve channel, site, category tree, menu, route, and pricing relationships. |
| Commercial context | Connect Customer groups to Category access, price lists, variant prices, and channels. |
| Operational identity | Keep variant, location, Customer, Order, channel, and external-system identifiers stable. |
| Historical separation | Preserve Order evidence without treating it as live checkout or fulfillment configuration. |
Conclusion
BigCommerce migration pitfalls emerge when related records are imported independently. Variants, modifiers, category trees, Customer groups, price lists, channels, sites, inventory locations, redirects, custom data, Customers, and Orders all carry context that must remain connected.
The strongest prevention approach defines those relationships before large-scale mapping. When every record has the correct owner, channel, commercial context, external identity, and pass condition, the migrated Store can operate consistently across storefronts and systems.
Common Questions
What is the difference between a BigCommerce variant and modifier?
A variant represents the sellable combination that can carry SKU, price, inventory, images, and other commercial data. A modifier changes or customizes the fulfilled item but does not select a different inventory-tracked variant.
Why can migrated Categories still fail on a BigCommerce storefront?
Category records must also belong to the intended category tree and storefront context. Navigation, faceted search, sorting, content, and channel assignment are separate relationships.
Do Customer groups automatically recreate group pricing?
No. Group pricing can depend on price lists, variant-level price records, Category access, currency, channel, and price-list assignments. The group label alone is insufficient.
How does Multi-Storefront affect migration scope?
Products, Category trees, price lists, currencies, menus, sites, routes, Orders, and apps can have channel-specific meaning. The migration model must preserve those assignments instead of defaulting everything to the first storefront.
Should all source custom fields become BigCommerce Product custom fields?
No. Some values belong to resource metafields, variants, apps, external systems, or storefront implementation. The destination depends on the field’s owner, consumer, visibility, and parent resource.
Do imported Orders configure BigCommerce checkout and fulfillment?
No. Imported Orders preserve historical transaction evidence. Current checkout, payment, shipping, tax, location, and fulfillment behavior requires separate BigCommerce configuration and integration ownership.