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.
Define how the actual Source selling model will become a manageable BigCommerce store. Catalog identity, buyer choices, commercial rules, storefront scope, account/history records and integrations need separate owners, even when the source combines them in one Product or extension.
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 choices identify variants, which inputs belong to modifiers, and which values describe Products or belong to applications | 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 |
First define what the source “store” represents:
- One storefront or several regional storefronts.
- A marketplace channel, brand or business unit.
- A Customer-specific catalog.
Then agree shared BigCommerce Product identities with channel assignments, or separate identities where commercial ownership requires them. Apply the same boundary to Categories, content, prices, currencies and Customer access.
Prepare Access, Exports, and Source Definitions
Prepare authorized access to the actual Source Store and the intended BigCommerce destination. When the Source Platform differs, collect its equivalent catalog and commercial evidence in the form actually available.
Retain dated originals, media and the available backup or provider recovery evidence. Record coverage and recovery limits so later live changes cannot 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 with options. Modifiers collect inputs or customize fulfillment without selecting another SKU; their combinations do not own independent variant stock.
Record required inputs, allowed values, supported price/weight effects and deliberately unavailable combinations. A Product-list modifier’s linked-stock effect is a separate relationship.
Normalize labels only after confirming equivalent entity, buyer and Store meaning. Document how the target will preserve intentionally unavailable choices during later maintenance.
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.
Prepare separate pricing evidence:
- Base and sale prices.
- Quantity tiers, Customer-group rules and Price Lists.
- Coupons and promotions.
- 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/currencies are covered, which channels or Customer groups receive the list, and are priority order or fallback layers enabled? | Primary/fallback and variant/currency coverage, assignments, active layer order where enabled, and expected buyer prices |
| Bulk pricing | Which quantity thresholds and buyer contexts apply? | Product/variant examples at tier boundaries under the applicable list or catalog rule |
| 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 |
Keep availability and pricing evidence separate:
- Availability: Product-to-channel assignment and membership in the intended storefront Category tree; one does not establish the other.
- Pricing: variant/currency records, primary-list and Customer-group/channel assignments, enabled priority order, active fallback-layer sequence and expected final prices.
When cascading pricing is enabled, missing primary coverage can resolve through fallback lists before catalog pricing. Agree the actual outcome; do not assume zero, exclusion or an identical buyer price.
Historical Order prices remain snapshots of past transactions, separate from future pricing rules.
Prepare Customers and Historical Orders
Prepare actual Customer examples for:
- Identity: individual buyers, guest Orders, addresses and external account IDs.
- Commercial context: groups, tax status and company/B2B relationships.
- Preferences and applications: custom fields, marketing preferences, loyalty and subscriptions.
Agree matching at the intended account/channel boundary; an email alone may not identify one Customer across storefronts.
Account access is separate from segmentation. The exact Source-to-Target path and identity systems determine password continuity or the reset, activation or first-login plan. A retained group cannot prove successful sign-in.
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 | Source IDs, intended channel/account context and agreed merge/retain-separate rules are documented; email alone is insufficient |
| 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 reusable content from implementation:
- Content and Product references.
- Forms, widgets and scripts.
- Theme/Page Builder layouts.
A single source page may need different destination owners for these parts.
Inventory Apps, Metafields, and External Systems
Register apps, scripts, custom fields, metafields, webhooks and connected systems where used. Group the business dependencies:
- Buyer journeys: reviews, search, subscriptions, bundles, loyalty, B2B and personalization.
- Transactions and channels: tax, shipping, payments and marketplaces.
- Operational data: ERP, PIM, WMS, CRM and accounting.
- Measurement and preferences: analytics and consent.
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:
- Parent entity, namespace and key.
- Value meaning/format, permissions and app owner.
- Intended consuming feature and compatible target implementation or replacement.
An app-only field may be unreadable to another consumer; stored data does not automatically provide storefront display.
The register is ready when each material field or dependency has a qualified destination and required consumer, or an agreed archive/exclusion. A name in the owner column cannot close missing consumer evidence.
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/URLs, expected destination owners, external keys and known exclusions to every sample. State what the record represents, which relationships matter and which source evidence accompanies it.
Cover the ordinary and exceptional patterns actually used in each material operating area. Separate materially different Product or Order structures instead of asking one record to represent conflicting patterns.
Define the expected outcomes and reviewers through migration acceptance criteria.
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 controls for the actual import path. V2 Order creation does not send the typical Order Email; shipment creation can send notifications, and apps or webhooks can act independently.
Assign the isolation of:
- Misleading Customer or staff messages.
- Stock changes and fulfillment actions.
- Tax/accounting events and payment actions.
Record control owners and the conditions for restoring live behavior. The launch plan owns later live validation; this preparation gate requires the isolation decisions and evidence.
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, descriptive fields and app data have qualified destination owners and agreed handling |
| Are pricing and channel relationships documented? | Pricing and channel matrices | Group/list/Product/variant/currency/channel assignments, fallback layers where enabled, and expected prices 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 | Required dependencies have qualified owners/consumers; archives or exclusions are explicitly agreed |
| Are backups and exports current? | Dated archive | Required reference evidence is recoverable; backup/export coverage and gaps are explicit |
| 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 high-value Source relationships have qualified BigCommerce owners, confirmed prerequisites and usable evidence.
- Critical open items: resolve, explicitly exclude or hold them before the affected work begins.
- Noncritical exceptions: agree impact, boundary and owner so they cannot silently change scope.
Conclusion
The preparation package should connect source catalog, buyer pricing, storefronts, accounts, history, content and integrations to explicit BigCommerce owners. Collect samples that reveal the relationships, not simply more exports.
Carry the traceable sample set and agreed outcomes into the migration validation checklist. Preparation establishes readiness to execute; later evidence must prove the complete agreed result and exceptions.
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 shipment creation can send messages; webhook consumers may still act independently.
Assign control owners for misleading messages and live operational actions, with evidence 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 variant/currency gap, assigned primary list, Customer-group and storefront-channel context, and pricing owner. Where cascading pricing is enabled, include active fallback layers and their order before the final catalog fallback.
Agree the expected buyer price under the actual configuration. Missing primary coverage does not imply zero, exclusion or an identical price for every buyer.