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 operating boundaries first.
| 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 the source and BigCommerce access needed to retrieve and interpret the in-scope data. Retain dated copies so the team can explain the source state even if the live Store changes.
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 |
Normalize option names and values before import. Inconsistent names can create separate option sets and weak filtering even when the underlying business concept is the same.
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 Products or variants, currencies, Customers, or channels use it? | Price-list export and assignment map |
| Bulk pricing | Which quantity thresholds and buyer contexts apply? | Product examples with thresholds |
| Channel assignment | Which Products and Categories belong to each channel? | Channel catalog matrix |
| Promotion | Is the rule current, historical, or obsolete? | Rule owner and retain/rebuild/retire decision |
Do not merge historical Order prices with active pricing configuration. Historical Orders need their recorded values; the future BigCommerce pricing model needs independently prepared rules and assignments.
Prepare Customers and Historical Orders
Prepare Customer samples that cover individual buyers, guest Orders, multiple addresses, Customer groups, tax status, company or B2B context, custom fields, marketing preferences, loyalty, subscriptions, and external account IDs.
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.
The dependency register is ready when no important custom value is described only as “from an app.”
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.
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 | Critical items have owners and due dates |
Preparation is complete when the migration team can explain how every high-value source relationship should be represented in BigCommerce without relying on undocumented assumptions. Open items may remain, but each must have an owner, a defined evidence requirement, and a decision date that occurs before the affected migration work begins.
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 works, source evidence is current, Products and commercial relationships have destination owners, priority URLs are mapped, dependencies are inventoried, and representative migration samples are documented.