BigCommerce preparation hinges on assigning the right owner to each Source relationship. A stocked choice, a personalization input, a storefront assortment and a buyer-specific price need different evidence before they become destination records.
BigCommerce preparation should define how the Source Store will become a manageable BigCommerce catalog before any migration run begins. Products, variants, options, modifiers, custom fields, metafields, Categories, price lists, Customer groups, channels, Customers, Orders, content, and integrations are separate areas of responsibility. A source platform may combine several of them in one Product or extension record.
The preparation package should state the intended destination owner, provide representative evidence, assign a responsible person, and define a ready condition. This makes the representative migration sample set meaningful and traceable to source evidence.
Define the BigCommerce Operating and Catalog Scope
Record the intended BigCommerce account, enabled capabilities and storefront/channel types, then map the actual Source selling contexts to them. Confirm which relationships the destination can implement and which are included in the agreed migration scope. Native Platform capacity alone does not establish either decision.
| Area | Preparation decision | Evidence |
|---|---|---|
| Catalog identity | Which source records become Products and variants | Product-family map with source IDs and SKU ownership |
| Buyer choices | Which values are variants, modifiers, custom fields, or application data | Representative option matrix |
| Catalog organization | Which source Categories, brands, filters, and landing pages remain | Category and discovery outline |
| Commercial context | Which Customer groups, price lists, bulk pricing, promotions, and currencies matter | Pricing relationship inventory |
| Channel scope | Which Products, Categories, content, currencies, and locales belong to each channel or storefront | Channel assignment matrix |
| Custom data | Which records belong to custom fields, metafields, apps, or external systems | Field and dependency register |
Document whether the source “store” represents one storefront, several regional storefronts, a marketplace channel, a brand, a business unit, or a Customer-specific catalog. Similar Product records may need one shared BigCommerce identity with channel assignments, or separate identities when the commercial ownership differs. The same boundary should be applied consistently to Categories, content, prices, currencies, and Customer access so the target catalog does not mix records that belong to different selling contexts.
Prepare Access, Exports, and Source Definitions
Prepare access to the actual Source Store and the intended BigCommerce destination at the required permissions. For a different Source Platform, collect equivalent catalog and commercial relationships in its own format. Retain dated evidence and original media, plus the available backup or provider recovery coverage, so a live Store change does not erase the reference state.
Collect:
- Source Store and BigCommerce administrator access with appropriate permissions;
- Product, variant, Category, Customer, Order, content, and redirect exports where available;
- Product media and documents when source links may expire or require authentication;
- price-list, Customer-group, bulk-pricing, promotion, and currency evidence;
- channel or storefront assignments and localized content lists;
- custom field, metafield, app, and external-identifier dictionaries;
- reports from ERP, PIM, WMS, CRM, marketplace, or accounting systems that identify shared keys;
- a source change log for records likely to change before the migration window.
| Evidence item | Owner | Ready condition |
|---|---|---|
| Access record | Store administrators | Required source and BigCommerce areas are accessible |
| Export archive | Data owner | Files open, contain expected records, and carry an export date |
| Field dictionary | Catalog or technical owner | Important fields have purpose, type, parent entity, and destination owner |
| Pricing evidence | Commercial owner | Base, group, list, bulk, and promotional contexts are distinguished |
| Channel inventory | Channel owner | Each channel has defined Product, Category, content, locale, and currency scope |
Prepare Products, Variants, Options, and Modifiers
BigCommerce distinguishes sellable variants from shopper modifiers and descriptive Product data. Prepare source examples that reveal those differences.
Include:
- simple Products;
- Products with child SKUs and variant-level price, stock, image, weight, barcode, or external IDs;
- source options that modify a Product without creating independent stock;
- personalization, file upload, date, measurement, or service choices;
- Products with custom fields, metafields, rich specifications, or compatibility data;
- bundles, kits, subscriptions, warranties, or application-owned configurations;
- Products assigned differently across channels;
- Products synchronized with external catalog or inventory systems.
| Source behavior | BigCommerce preparation decision | Evidence to supply |
|---|---|---|
| Choice identifies a separate sellable item | Define Product and variant ownership | Parent/child IDs, option values, SKU, price, stock, images, and external IDs |
| Choice modifies the Product but has no independent stock | Define modifier or other target relationship | Input type, allowed values, price/weight effect, and Order-line example |
| Value describes the Product | Define custom field, metafield, content, or app owner | Field type, controlled values, display and integration consumers |
| Combination follows custom logic | Define application or custom target owner | Rule examples, component IDs, and historical Order evidence |
Include the base variant of a simple Product as well as child variants of a Product with options. A modifier changes a shopper’s input or fulfillment choice without changing the selected SKU; combinations of modifier values do not have independent variant stock. Record required inputs, allowed values and supported price/weight effects. Normalize labels only after confirming that their entity, buyer and Store meaning is equivalent.
Prepare Categories, Pricing, Customer Groups, and Channels
BigCommerce preparation should treat discovery and pricing as related but separate structures.
For Categories, prepare:
- the source hierarchy and Product assignments;
- brand and manufacturer relationships;
- filter or facet values;
- landing-page content and metadata;
- internal-only or obsolete Categories;
- channel-specific Category assignments;
- URLs and redirect priorities.
For pricing, prepare distinct evidence for base prices, sale prices, bulk pricing, Customer-group pricing, price lists, coupons, and app- or ERP-controlled prices.
| Commercial relationship | Preparation question | Ready evidence |
|---|---|---|
| Customer group | Which Customers belong, and what access or price meaning does the group carry? | Customer examples and group-rule summary |
| Price list | Which variants and currencies have records, and which storefront channels or Customer groups receive the list? | Variant/currency coverage, assignment map and expected fallback pricing |
| Bulk pricing | Which quantity thresholds and buyer contexts apply? | Product examples with thresholds |
| Channel assignment | Which Products are assigned to the channel, and where do they belong in its Category tree? | Product/channel assignments and tree/Category membership matrix |
| Promotion | Is the rule current, historical, or obsolete? | Rule owner and retain/rebuild/retire decision |
Prepare Product channel availability and storefront Category-tree membership as separate joins; one does not establish the other. For price lists, retain variant and currency records, the intended storefront-channel/Customer-group assignments and the catalog price used when a variant has no active list price. Record the destination pricing configuration rather than assuming that missing coverage means a zero price or an excluded item. Historical Order prices remain recorded snapshots, separate from future pricing rules.
Prepare Customers and Historical Orders
Prepare Customer samples covering individual buyers, guest Orders, addresses, groups, tax status, company/B2B context, custom fields, marketing preferences, loyalty, subscriptions and external account IDs. Assign account access separately from segmentation: the exact Source-to-Target path and identity systems determine usable password continuity or the reset, activation or first-login plan. A retained group does not prove the buyer can sign in under its rules.
Prepare Order samples that cover:
- paid, pending, canceled, refunded, and partially refunded Orders;
- multiple fulfillment states and shipping methods;
- discounts, coupons, gift certificates, taxes, duties, and manual adjustments;
- variant and modifier selections;
- Customer-group or price-list context;
- channel or marketplace origin;
- ERP, accounting, CRM, and fulfillment references.
| Preparation question | Evidence | Ready condition |
|---|---|---|
| How are duplicate Customers handled? | Duplicate examples and matching keys | Retain-separate and merge rules are documented |
| Which Customer groups remain? | Group list and commercial purpose | Every retained group has an owner and related rule |
| Which Order details must support teams see? | Representative Order packet | Lines, modifiers, totals, statuses, refunds, and references are explained |
| Which external IDs remain operational? | Cross-system key map | Each key is attached to the correct entity level |
| Which sensitive fields are unnecessary? | Approved field scope | Excluded data is documented before migration |
Prepare Content, URLs, and Redirect Inputs
Create a route inventory for Products, Categories, brands, CMS Pages, Blog Posts, campaign pages, files, and localized content. Include traffic, revenue, backlink, paid-media, Customer-service, or compliance importance where known.
For each priority route, record:
- source path;
- intended BigCommerce Product, Category, page, Blog Post, channel, or external destination;
- content owner;
- metadata and internal-link requirements;
- channel and locale scope;
- redirect requirement or retirement decision.
Separate content records from theme and Page Builder presentation. A source page can contain reusable content, Product references, forms, widgets, scripts, and layout definitions that need different destination owners.
Inventory Apps, Metafields, and External Systems
Create a dependency register for apps, custom scripts, custom fields, metafields, webhooks, and connected systems. Include reviews, search, subscriptions, bundles, loyalty, B2B, personalization, tax, shipping, payments, marketplaces, ERP, PIM, WMS, CRM, accounting, analytics, and consent systems.
For each dependency, document:
- business purpose;
- records created or modified;
- related Products, Customers, Orders, or content;
- current data owner and future owner;
- export or API evidence;
- external identifiers;
- whether the dependency will continue, be replaced, or be retired.
For each metafield, record its parent entity, namespace, key, value meaning, permissions, app owner and consuming feature. An app-only field may not be visible to another consumer, and stored data does not automatically supply a storefront display. Assign the compatible target implementation or replacement as well as the data. The register is ready when every material field and dependency has a continuing owner, archive or explicit exclusion.
Select BigCommerce Representative Migration Test Samples
Choose a compact sample set that covers ordinary and exceptional relationships.
| Sample | Preparation purpose |
|---|---|
| Simple Product | Establish the ordinary Product, Category, media, price, and inventory pattern |
| Variant-heavy Product | Expose Product/variant identity, options, stock, images, and external IDs |
| Modifier-driven Product | Expose shopper input that should not become a stock-bearing variant |
| Product with custom fields or metafields | Expose structured custom-data ownership |
| Product with Customer-group or price-list context | Expose conditional commercial relationships |
| Channel-specific Product or Category | Expose channel assignments and localized scope |
| Complex Customer | Expose groups, addresses, custom fields, and external IDs |
| Complex historical Order | Expose modifiers, discounts, fulfillment, refunds, and channel context |
| Priority content route | Expose page, metadata, internal-link, and redirect preparation |
Attach source IDs, source URLs, expected destination owners, external keys, and known exclusions to every sample. The sample ledger should define what the source record represents, which relationships matter, and which evidence accompanies it. Include at least one ordinary record and one exceptional record for each major operating area. When several source structures are materially different, use separate samples rather than asking one Product or Order to represent conflicting patterns.
Plan Order Notification Suppression
Historical Order imports can create misleading customer or staff messages when BigCommerce notification workflows, applications, or connected services react to imported records as though they were new live transactions.
Prepare isolation for the actual Order-import path and its connected consumers. BigCommerce V2 Order creation does not send the typical Order Email, but shipment creation can notify, and apps or webhook consumers may react independently. Identify which messages, stock changes, fulfillment, tax/accounting events or payment actions must be isolated, who owns the controls and the conditions for restoring live behavior. The later live validation belongs to the launch plan; the preparation package supplies the accountable decisions.
Complete the BigCommerce Readiness Gate
| Readiness question | Required evidence | Ready condition |
|---|---|---|
| Is access complete? | Access log | Required source and destination areas are available |
| Are Product relationships classified? | Product-family and option matrix | Variants, modifiers, custom fields, and app data have owners |
| Are pricing and channel relationships documented? | Pricing and channel matrices | Group, list, Product, currency, and channel assignments are explicit |
| Are Customers and Orders represented? | Sample ledger | Important account and historical Order patterns are covered |
| Are priority routes defined? | URL inventory | Each priority source path has a destination or retirement decision |
| Are dependencies owned? | App and integration register | Every important dependency has a continuing owner |
| Are backups and exports current? | Dated archive | Source evidence can be recovered independently |
| Are open decisions controlled? | Decision log with impact, owner and scope decision | Critical gaps are resolved, excluded or held before execution; accepted exceptions have a clear boundary |
Preparation is complete when the team can explain each high-value Source relationship and its intended BigCommerce owner, with destination prerequisites and evidence confirmed. A critical open item must be resolved, explicitly excluded or held before the affected work begins. Noncritical exceptions need an accepted impact, boundary and owner; they cannot silently alter the agreed scope.
Conclusion
BigCommerce preparation should produce an evidence-backed model for Products, variants, modifiers, Categories, pricing, Customer groups, channels, Customers, Orders, content, and integrations. The most important task is not exporting more records; it is defining which BigCommerce object owns each relationship and collecting samples that expose the real complexity.
A disciplined preparation package gives representative migration testing a traceable source sample set and clear readiness ownership.
Common Questions
What should be prepared before exporting a BigCommerce catalog?
Define Product and variant ownership, distinguish modifiers from variants, document Categories and channels, and identify pricing and custom-data relationships. The export is more useful once the team knows what each source value means.
Why should Customer groups and price lists be prepared separately?
A group classifies Customers, while a price list assigns commercial values under defined conditions. Preserving one without the other can leave Customer segmentation or Product pricing incomplete.
Which BigCommerce Products belong in the representative migration sample set?
Include a simple Product, a variant-heavy Product, a modifier-driven Product, a custom-data Product, a conditional-pricing Product, and a channel-specific Product. Add any platform-specific configuration that carries significant revenue or operational risk.
Should every source Category become a BigCommerce Category?
No. Some source groups are navigation links, filters, campaign collections, brand structures, or internal classifications. Assign each grouping according to its continuing purpose.
What Order evidence should be prepared?
Prepare Orders with variant and modifier selections, discounts, taxes, shipping, multiple statuses, refunds, and external-system references. The samples should explain historical meaning without defining future checkout configuration.
When is BigCommerce preparation complete?
It is complete when access and recoverable evidence are available, catalog and commercial relationships have qualified destination owners, routes and dependencies are assigned, representative samples are documented and Order automation controls have owners. Resolve, exclude or hold critical gaps before the affected execution; merely assigning a decision date is insufficient.
How should Order notifications be handled during a historical BigCommerce import?
Prepare controls for the actual import path and connected apps. V2 Order creation omits the typical Order Email, while creating shipments can send messages; webhook consumers may still act on imported records. Assign the isolation of misleading messages and live operational actions, plus the owner and conditions for restoring intended behavior after the historical import.
Does assigning a Product to a channel also place it in that storefront’s category tree?
No. Prepare both the Product-to-channel availability and its membership in the intended storefront Category tree. Include a sample with the channel, tree and Category identifiers so the destination owner can distinguish an available Product from one placed in the expected navigation.
What should be prepared when a price list does not cover a variant?
Record the uncovered variant, its currency context and the catalog pricing expected to apply when no active list price exists. Include the list’s storefront-channel and Customer-group assignments and the responsible pricing owner. Missing coverage needs an explicit commercial decision rather than an assumed zero or identical buyer price.