A BigCommerce destination can contain the expected Products and Customers while fulfilling the wrong variant, showing fallback prices to a wholesale buyer, or serving the wrong assortment on a second storefront. Prevention must keep sellable identity, buyer treatment, and channel context connected through the systems that consume them.
The common failure is a lost relationship, not simply a missing record:
- Variant choices and modifiers can look similar in the Source but differ in fulfillment.
- Customer Groups and Price Lists can influence buyer treatment without forming one pricing field.
- Channels, sites, Category trees, content, inventory locations and storefront frameworks define where the result must work.
Each pitfall names a recurring failure, its prevention control and the evidence that shows it is contained. Apply it to the enabled BigCommerce features and agreed migration scope; native capability does not establish transfer support.
Use the BigCommerce preparation checklist to assemble the inputs before mapping. An agreed remapping or exclusion can meet the intended outcome; a required unresolved relationship remains a gap.
Pitfall 1: Confusing Variants, Modifiers, and Product Fields
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.
Keep the native meanings distinct:
- Variants: combinations of variant option values that carry sellable identity and commercial data.
- Modifiers: shopper customization or additions that do not change the fulfilled variant.
- Custom fields and metafields: descriptive or operational values with their own consumers.
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.
Keep option values, SKU, stock, price, weight, images and external identifiers attached to the correct variant. Preserve modifier selections on the Order line without inventing stock for their combinations.
A Product-list modifier can affect a linked Product’s inventory. Verify that separate relationship instead of treating it as independently stocked modifier combinations.
Recommendation example
Illustrative 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 reviewed choice resolves to the intended fulfilled variant; modifier selections remain on the Order line and descriptive fields create no false stock or variants. Include any linked-Product stock effect in the check. A sample Pass covers the reviewed cases, not the whole catalog.
Pitfall 2: Importing Categories Without 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 the discovery dependencies separately:
- Which values power faceted search, and which Categories need content, sorting, images or redirects.
- How Stencil, Catalyst or a headless storefront consumes those catalog relationships.
- Which Products belong to a Category and which are available in a channel.
Category import cannot configure the storefront or prove channel availability.
Recommendation example
Illustrative 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: Losing Buyer Pricing Behind Customer Groups
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.
Price Lists can assign variant prices by Customer Group, channel or both. Without the applicable assignment and price records, the list is not a complete pricing model.
Confirm required pricing features in the actual Target Store. Feature availability and transfer coverage remain separate decisions.
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
Keep the buyer-price relationship explicit:
- Context: Customer Group, Category access, channel, currency and the applicable Price List assignment.
- Resolution: primary-list status and priority-order setting. With an active primary and priority order enabled, a missing variant/currency price checks active fallback layers in order before catalog pricing.
- Quantity: use the applicable price-record tiers. Product bulk pricing and Customer-group discounts do not automatically stack with Price List prices.
Test a direct price and relevant missing-record cases through the actual buyer’s cart. If B2B companies participate, confirm their membership and Independent or legacy Dependent mode; a company is not automatically equivalent to a Customer Group.
Separate historical Order prices from active price-list records. Keep external contract or ERP pricing identifiers when another system remains authoritative.
Recommendation example
Illustrative example: for a VIP buyer on a regional storefront, retain group membership, Category access, variant-and-currency prices and the group/channel assignment. If fallback layers are enabled, include their active order and expected cart price when the primary record is missing.
Pass condition
The reviewed signed-in buyer receives the intended assortment and variant price on the intended channel. Out-of-group buyers and missing-record cases follow their expected assignment or fallback, with correct quantity thresholds. Retain the buyer, currency and quantity evidence; one sample cannot approve every context.
Pitfall 4: Flattening Channel and Site Context
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 |
|---|---|
| Channel-sensitive records use the primary context because a required channel identifier or assignment is missing. | The required channel context has not been established. |
| 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:
- Selling contexts: storefront, marketplace, POS, marketing or custom channels actually used.
- Website ownership: the site and domain tied to each storefront channel.
- Assignments and consumers: Products, Category trees, prices, currency, menus, Orders and apps that depend on that context.
Where the Source uses channel IDs, map them to the intended destination channels and retain references needed by integrations. Otherwise define destination assignments from the actual Source business context. Do not leave default-channel fallback unexplained.
The cart and checkout must follow the approved storefront journey, retaining the intended brand or region. An intentionally shared checkout domain is a configuration decision, not evidence of a channel error by itself.
Recommendation example
Illustrative example: two brand storefronts and an Amazon channel share catalog data:
- Retain one Product catalog where appropriate.
- Assign Products and Price Lists to the correct storefront channels.
- Use the intended Category tree and site for each brand.
- 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: Losing Inventory Item and Location Identity
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 replaces independently stocked variant quantities.
- BOPIS or pickup locations are absent from the location map.
- External warehouse IDs are discarded after opening quantities are imported.
Prevention
Match opening stock to the configured Product or variant item and intended BigCommerce location. Preserve independently stocked variant quantities instead of substituting a parent total; retain location IDs, SKUs and external inventory keys.
Keep quantity separate from channel, pickup and fulfillment rules. Inventory writes are asynchronous and not channel-aware. Coordinate opening balances with live changes, then confirm the settled item-location quantity and effects on other selling contexts.
Distinguish the opening quantity from other stock evidence:
- Historical movements and reservations.
- Damaged stock and supplier availability.
- Other states excluded by the agreed sellable-stock definition.
Do not sum those values into opening sellable inventory without an approved rule.
Recommendation example
Illustrative example: a retailer has one central warehouse and three pickup stores. Map each Source location to its agreed BigCommerce destination, retain variant-level quantities and warehouse keys, and check pickup or channel rules separately from raw stock.
Pass condition
After updates settle, reviewed inventory items show the expected location quantities. Pickup or fulfillment recognizes the correct stock owner, and the continuing system updates those same item-location records without duplicates or unintended effects elsewhere. Retain the evidence for both opening stock and the next update.
Pitfall 6: Leaving Redirects Until the End
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
Build a route inventory with an explicit owner for each destination:
- A Product, Category, page or Blog Post.
- A site route or storefront application.
- Relevant replacement content or an intentional retirement.
Keep the original URL and its intended user journey beside that decision.
Use URL and redirect planning to prioritize revenue routes, organic traffic, backlinks, Customer bookmarks and active campaigns. Keep channel and site context when one Source pattern needs different destinations.
A headless application must consume the route or redirect information and return the intended behavior. Storing the route does not make the application follow it.
Recommendation example
Illustrative example: for a multistorefront merchant:
- Map priority Product and Category URLs for each brand site.
- Send retired campaign pages to relevant replacement content.
- 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 Data Without Its Consumer
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
Choose custom-data destinations by owner and use:
- Product custom fields for suitable storefront-visible Product information.
- Resource metafields for operational or app values in the agreed consumer format.
- External systems for records they continue to govern.
Confirm support for the required resource and field before treating that choice as migration scope.
Preserve the usable relationship, not merely the stored value:
- Translate record references to destination IDs. Retain original IDs as evidence or agreed external keys where needed.
- Confirm the resource, namespace/key, permissions and the theme, app, API or integration that consumes the value.
- Encode logical numbers, dates or structured data in the agreed string format and test consumer interpretation.
Storefront access also requires permissions and rendering. Keep private operational data private; public exposure is not a preservation test.
Recommendation example
Illustrative example: choose the resource from the consumer:
- Public material specification: a Product custom field when the storefront should display it.
- Variant warehouse code: a variant metafield in the warehouse consumer’s agreed format.
- Subscription state: the subscription application that owns it.
Pass condition
The agreed value is on the correct resource and the intended consumer can read and interpret it with appropriate access. No unresolved namespace, parent-level substitution or Source ID remains in a destination relationship. Original IDs may remain as intentional external keys.
Pitfall 8: Mistaking Historical Records for Live Readiness
What goes wrong
Matching counts can conceal missing history:
- Buyer context: identity, addresses, group assignment and consent.
- Purchased meaning: Order-line variants, discounts, taxes, shipping and refunds.
- Operational evidence: consignments, shipments, statuses and external references.
Historical payment or shipping labels are then mistaken for live checkout or 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 the agreed history by function:
- Customers: identity, addresses, attributes, consent, group and external IDs where included. In multistore setups, reconcile channel identity and account access; the same email can identify different Customers.
- Orders: purchased lines, variants, prices, adjustments, taxes, shipping addresses and channel origin.
- Support and finance: consignments, shipments, refunds, statuses, notes and external references.
An agreed transformation or archive can preserve the required use without an identical target schema. Profile migration also does not prove usable passwords; confirm the actual path’s login, reset or activation outcome.
Keep history separate from current payment, checkout, shipping, tax and fulfillment configuration. Use migration reconciliation to explain differences against the agreed historical result.
Check side effects on the actual import path. V2 Order creation omits the usual Order Email, while shipment or app activity can trigger other effects. Confirm notification, stock and integration controls so imported history is not processed again as new sales.
Recommendation example
Illustrative example: for a partially shipped regional Order, retain the agreed evidence:
- Customer, group, channel and purchased variants.
- Shipping addresses, consignments and shipment tracking.
- Discount, tax, refund evidence and the ERP Order ID.
Configure future regional checkout and shipping separately.
Pass condition
Reviewed Customers remain identifiable and commercially classified, and support or finance can interpret the required history. Import side effects follow the agreed controls; current operations use their own approved configuration. Missing critical evidence remains a gap even when an owner is assigned.
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 buyer groups and Category access with applicable Price Lists, active fallback layers, variant/currency records, quantity rules and channel assignments. |
| Operational identity | Retain Source identifiers as evidence, map variant, location, Customer, Order and channel relationships to destination identities, and preserve agreed external-system keys. |
| Historical separation | Preserve Order evidence without treating it as live checkout or fulfillment configuration. |
Review the controls together: one variant error can spread into prices, stock, storefront choices, Order evidence and external identifiers. Name the owner and proof for every affected layer, using BigCommerce validation priorities for the evidence plan.
A sample Pass establishes control only for the reviewed cases. Wider scope and exceptions need their own proof before launch.
Conclusion
BigCommerce migration pitfalls arise when sellable identity, buyer treatment, storefront context and continuing consumers become disconnected. Category trees, channels, sites, locations, redirects, custom data and historical records must retain the relationships that make them useful.
Define those relationships before large-scale mapping, then prove the agreed result through the responsible storefront, team or system. Owners and correct labels support prevention; observed outcomes establish control. Historical-data acceptance and live readiness remain separate decisions.
Common Questions
What is the difference between a BigCommerce variant and modifier?
A variant identifies the sellable combination and can carry SKU, price, inventory, images and other commercial data. A modifier customizes or adds to the fulfilled item without selecting a different variant; its combinations do not have independent inventory.
A Product-list modifier can affect a linked Product’s stock. Validate that separate relationship rather than treating modifier combinations as stocked variants.
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. Their purpose is to preserve the agreed historical transaction evidence. Presence alone does not prove that history is usable. Current checkout, payment, shipping, tax, location and fulfillment behavior need separate configuration and integration ownership.
Why can a buyer in the correct group still see an unexpected price?
The intended Price List assignment or variant/currency record may be missing. With an active primary and priority order enabled, missing prices pass through active fallback layers in order before catalog pricing. Quantity rules can also change the result.
Check the actual group/channel assignment, primary status, fallback coverage and tier boundaries against the buyer’s cart. Group membership alone cannot prove the amount, and Product bulk rules or group discounts do not automatically stack with Price List prices.
Does a successful inventory write prove stock is ready?
No. Inventory processing can be asynchronous, and writes are not confined to a storefront channel. Confirm the settled quantity for the configured Product or variant item and location, coordinate live changes, and check that other selling contexts were not affected unintentionally.
Must imported metafields be publicly visible to prove they were preserved?
No. Prove the intended app or integration can read and interpret the value on the correct resource with the required permissions. Public storefront exposure is a separate decision. Keep private operational data private and validate its agreed string format through the continuing consumer.