BigCommerce data-model planning should begin with meaning, not record counts. Products, categories, customers, orders, CMS Pages, Blog Posts, redirects, and supporting fields may all have familiar names, but BigCommerce represents commerce through structured catalog, pricing, channel, customer, content, and integration surfaces that may not behave like the Source Platform.
A source store can appear complete after migration while still being commercially wrong. Product choices can be assigned to the wrong structure. Category paths can exist without preserving discovery. Customer records can arrive without the pricing context that made them valuable. Redirects can resolve but send shoppers to weak destinations. Custom fields and metafields can be present but disconnected from the app, ERP, search, merchandising, or storefront behavior they once supported.
The safest BigCommerce migration plan translates source records into BigCommerce meaning before treating the scope as final.
Why BigCommerce Data Meaning Needs Separate Review
BigCommerce is a hosted SaaS Target Platform with defined commerce structures. That structure can simplify governance after migration, but it also requires more explicit translation decisions. A Source Platform may have allowed product options, personalization fields, customer groups, price rules, landing pages, and app-owned behavior to overlap. BigCommerce usually asks those meanings to become more explicit.
The key question is not whether a source record has a BigCommerce destination. The better question is whether the migrated destination preserves the business use of that record.
| BigCommerce area | Migration meaning to confirm |
|---|---|
| Product choices | Whether the source choice should become a variant, variant option, modifier, custom field, metafield, app configuration, or another defined target structure. |
| Category structure | Whether source categories preserve catalog organization, navigation, merchandising, and SEO-sensitive discovery. |
| Pricing context | Whether base prices, bulk rules, price lists, customer group logic, and external pricing references remain meaningful. |
| Channel scope | Whether products, categories, pricing, content, and URLs belong to the correct storefront or channel context. |
| Customer and order records | Whether customer identity, account context, group membership, order history, and service value remain useful. |
| Content and routes | Whether CMS Pages, Blog Posts, redirects, and page destinations preserve customer intent. |
| Custom and app data | Whether custom fields, metafields, app-owned records, and outside-system identifiers need direct field mapping or filtering, data restructuring, or Target Store setup. |
This review prevents a shallow migration approval. The merchant should not only ask, “Did the record move?” The merchant should ask, “Does BigCommerce now hold this record in the structure that supports selling, service, pricing, discovery, and integration continuity?”
Product Structure: Products, Variants, Options, and Modifiers
BigCommerce product structure requires careful interpretation because source platforms use product choices differently. Some stores use variants for every selectable choice. Others use custom option fields, plugins, apps, product builders, bundle systems, or theme logic. BigCommerce separates several product-choice concepts, and that separation affects inventory, pricing, fulfillment, storefront display, and reporting.
A product variant usually represents a sellable version of a product. Size, color, material, package, model, finish, or unit may belong to variant structure when the choice affects SKU, inventory, image, weight, price, availability, or fulfillment. Variant options describe the selectable dimensions that create those variant combinations.
Modifiers are different. A modifier can represent a customer-facing choice that changes the buying experience without necessarily creating a separate stock-tracked product. Examples may include personalization text, engraving, gift messages, optional product extras, file upload fields, warranty selections, or non-inventory customization. When source options are moved into the wrong structure, the product page may look complete while operational behavior becomes wrong.
| Source product choice | BigCommerce interpretation question | Meaning lost if misread |
|---|---|---|
| Size or color with SKU and stock | Should it become a variant and variant option? | Inventory and order line meaning may be weakened. |
| Engraving or gift message | Is it closer to a modifier or custom field? | Buyer input may become a fake stock-tracked option. |
| Bundle or kit selection | Is it supported, app-owned, or custom logic? | Pricing, fulfillment, and inventory expectations may break. |
| Warranty or compatibility field | Is it display information, product metadata, or app behavior? | Important commercial context may be preserved as text but lose function. |
| Upload field or personalization workflow | Is target-side app setup or data restructuring needed? | A product may migrate but fail the original buying workflow. |
Product data should be sampled across real catalog patterns. A simple product, a variant-heavy product, a modifier-heavy product, a bundled product, and a product with custom data reveal more than a product count.
Custom Fields, Metafields, and Product Metadata
BigCommerce custom fields and metafields serve different purposes and should not be treated as interchangeable containers. Product custom fields can hold additional Product information intended for storefront use. Metafields are programmatic key-value data attached to resources such as Products, variants, Categories, and brands; they are useful for applications and integrations and are not automatically presented as ordinary storefront or control-panel content.
That distinction matters during migration. A source attribute can look like “custom data” while serving a very different role:
| Source-data purpose | BigCommerce destination question |
|---|---|
| Customer-facing specification | Should it become a Product field, custom field, structured page content, or another storefront-visible value? |
| Sellable choice | Does it define a variant, variant option, or modifier rather than descriptive metadata? |
| Search or filtering input | Which BigCommerce or application structure will actually consume it for discovery? |
| Internal operational reference | Should it remain hidden in a metafield or in the continuing external system? |
| ERP, PIM, or accounting key | Which resource owns the identifier, and how will the connected system find it? |
| Application-owned behavior | Does the destination application support import, or does the workflow need redesign? |
The target field should be chosen by use, visibility, and ownership. Moving every source attribute into Product custom fields can expose internal data or create an unmanageable storefront. Moving everything into metafields can preserve values that no administrator, theme, or application can use. A disciplined mapping records the intended consumer, the resource relationship, and whether the value remains customer-facing, operational, integration-owned, or excluded.
Categories, Category Trees, Navigation, and Discovery
Category migration into BigCommerce should not be treated as a simple folder transfer. Categories, category trees, product assignments, menu logic, storefront discovery, and SEO-sensitive routes can all influence customer navigation. A source category may have served several roles at once: admin organization, public landing page, merchandising collection, campaign grouping, menu entry, search filter, or SEO page.
BigCommerce planning should separate those roles. A category may need to become a BigCommerce category. A menu relationship may need target-side storefront setup. A high-value landing page may require content preservation or a redirect plan. A collection-like source structure may need mapping, manual rebuilding, app support, or exclusion.
| Source structure | BigCommerce planning question |
|---|---|
| Product category | Should it become a BigCommerce category or category-tree entry? |
| Collection or smart group | Is it a category, a merchandising rule, a storefront setup need, or an app-equivalent requirement? |
| Navigation menu | Does it belong to catalog data or theme/storefront setup? |
| SEO landing page | Should it migrate as content, category context, redirect target, or rebuilt page? |
| Campaign or temporary category | Should it be migrated, retired, redirected, or excluded? |
For multi-storefront or channel-aware merchants, category meaning also depends on where products are meant to appear. A category that is useful in one storefront may be confusing in another. Product assignments, naming, routes, and redirect destinations should therefore be reviewed in the relevant selling context.
Pricing, Customer Groups, and Price Lists
Pricing is one of the most important BigCommerce data-model differences because it can exist at several levels. A source store may have base product prices, sale prices, bulk pricing, customer-group pricing, wholesale tiers, regional pricing, negotiated buyer prices, price-list behavior, app-managed rules, or external pricing systems.
BigCommerce migration planning should not flatten those relationships into one product price unless the business truly wants a simpler pricing model after migration. Pricing context should be reviewed as a relationship between products, customers, groups, price lists, quantity conditions, storefronts, channels, apps, and external systems.
| Pricing source | Meaning to preserve |
|---|---|
| Product base price | The default selling value. |
| Bulk pricing | Quantity-based pricing expectations. |
| Customer-group price | Buyer-segment or wholesale logic. |
| Price list | More structured audience, channel, or business pricing context. |
| App-managed pricing | Business logic that may remain application-owned or require an external pricing owner. |
| External pricing system | Identifier and synchronization continuity, not only visible price output. |
A migrated Product may show the right base price while still carrying the wrong commercial meaning for a wholesale buyer, Customer group, channel, or regional storefront. Sensitive pricing cases therefore belong in the relationship model as explicit Product–Customer Group–Price List–channel combinations rather than being inferred from the base Product price.
Channels, Storefronts, and Selling Context
BigCommerce channel and storefront structures can affect Product availability, Category presentation, currency context, site relationships, menus, pricing assumptions, redirects, and customer experience. Channel meaning is therefore part of the data model, not only an implementation setting.
Source Platforms may express channel logic through multiple stores, websites, marketplaces, regions, language versions, domains, integrations, or custom code. BigCommerce needs an explicit target interpretation for each relationship: which Products are assigned to which channels, which Category tree supports each site, which content and routes belong to each storefront, and which prices or customer rules apply in that context.
| Source meaning | BigCommerce relationship to define |
|---|---|
| Regional or brand storefront | Channel, site, domain, Category tree, content ownership, and redirect destination. |
| Marketplace or social channel | Product assignment, external listing ownership, identifiers, and synchronization responsibility. |
| Store-specific catalog subset | Product-channel assignment and the Category structure visible in that storefront. |
| Store-specific pricing | Price list, customer group, channel context, external pricing system, or another defined owner. |
| Localized content or navigation | Storefront-owned content, theme configuration, translated content, or a separate implementation layer. |
Shared Product records can remain shared while their assignments and presentation differ by channel. Flattening those relationships can make the administration look complete while a storefront receives the wrong assortment, category path, price context, or redirect destination. The migration map should therefore record both the shared record and every channel-specific relationship that must survive.
Customers, Accounts, and Order History
Customer and order data should be interpreted as commercial and service context. A customer record may include identity, addresses, account status, customer group assignment, custom attributes, consent, order relationships, and pricing expectations. An order may preserve product names, SKUs, quantities, discounts, taxes, shipping, billing, fulfillment, payment labels, notes, refunds, and external references.
The migration plan should ask what the business needs customer and order history to support. Customer service, repeat purchasing, wholesale access, support lookup, reporting, refund review, and integration reconciliation may require different levels of detail.
A source account system may not translate exactly into BigCommerce account behavior. Passwords, group memberships, loyalty data, subscriptions, quote workflows, company accounts, customer approvals, or external CRM references may need separate review. Some values can be mapped. Some may use direct field mapping or filtering. Others may require data restructuring or an application-specific migration path. Some may need target-side app setup or remain outside the migration scope.
Orders require the same discipline. Historical order data should remain readable and useful, but live payment setup, checkout behavior, shipping configuration, tax settings, notifications, and fulfillment workflow belong to Target Store setup.
Content, Pages, Blog Posts, Redirects, and Route Meaning
BigCommerce content and URL continuity should be treated as part of data-model translation because pages, Blog Posts, redirects, product paths, category paths, and storefront destinations shape customer trust and search continuity. A redirect may technically work while still weakening the customer journey if it sends an old product, category, or content URL to a broad or unrelated destination.
CMS Pages and Blog Posts should be reviewed by purpose. Some pages support trust, policies, brand explanation, buying guidance, campaign traffic, or SEO discovery. Some Blog Posts may carry long-tail search value or product education. Some source pages may no longer deserve migration but still require a redirect to a useful destination.
| Content or route type | Migration decision |
|---|---|
| Product URL | Preserve or redirect to the closest matching product. |
| Category URL | Preserve discovery intent where possible. |
| CMS Page | Migrate, rebuild, consolidate, redirect, or retire. |
| Blog Post | Preserve if it carries traffic, education, trust, or internal-link value. |
| Campaign page | Decide whether the campaign remains active, needs redirect, or should be retired. |
| Storefront-specific route | Confirm the correct storefront or channel destination. |
Route identity belongs in the BigCommerce data model because redirects connect source intent with a usable destination. Strong redirect relationships preserve customer journeys rather than functioning as isolated technical mappings.
Apps, Integrations, and External-System Data
BigCommerce migrations often intersect with external systems. ERP, PIM, CRM, accounting, tax, shipping, subscription, personalization, search, reviews, loyalty, warehouse, marketplace, or marketing systems may rely on identifiers and custom fields that are not visible in a normal storefront review.
The data-model question is whether BigCommerce needs to own the data, display the data, pass the data to an app, preserve it for reconciliation, or ignore it because the workflow will be rebuilt. These are different outcomes.
| External dependency | BigCommerce migration concern |
|---|---|
| ERP or accounting | Product IDs, SKUs, order references, customer identifiers, and tax/discount context. |
| PIM | Attribute ownership, product copy, images, variants, and custom fields. |
| CRM or marketing | Customer identity, consent, segmentation, order history, and custom attributes. |
| Subscription or loyalty app | App-owned records, behavior, and continuity expectations. |
| Search or merchandising app | Filter attributes, custom fields, product tags, rules, and ranking behavior. |
| Shipping or tax system | External identifiers and checkout-adjacent behavior. |
If the data already has a suitable BigCommerce destination, direct mapping or filtering may be enough. If it is application-owned, externally controlled, or dependent on a non-native relationship, define the destination application, external system, or data restructuring before finalizing the source-to-target map.
BigCommerce Data Scope Should Be Judged by Business Use
A BigCommerce migration scope should be judged by post-migration use. Products, Customers, Orders, Categories, CMS Pages, Blog Posts, and redirects may fit ordinary record destinations, but their meaning can still depend on Product-choice structure, Category trees, channel assignments, customer groups, price lists, custom fields, metafields, applications, and external identifiers.
A useful translation map separates these outcomes:
| Mapping outcome | BigCommerce meaning |
|---|---|
| Native record and relationship | The source meaning fits a BigCommerce Product, variant, modifier, Category, Customer, Order, content record, redirect, or another supported relationship. |
| Storefront or channel configuration | The record exists, but its use depends on channel assignments, Category trees, sites, themes, menus, price context, or other Target Store configuration. |
| Application or integration ownership | The data remains owned by an ERP, PIM, CRM, subscription, loyalty, search, or other connected system and needs a stable cross-system identifier. |
| Purpose-built data transformation | The source structure must be reshaped because its meaning does not align with the available target record or relationship. |
| Exclude, archive, or redesign | The value is obsolete, duplicated, tied to retired logic, or no longer has a continuing business owner. |
This model keeps the migration focused on meaning translation and prevents a large record count from being mistaken for a usable BigCommerce data model. The strongest scope explains what each important source meaning becomes, which relationship preserves it, who owns it after launch, and what should deliberately remain outside the Target Store.
Conclusion
BigCommerce data-model differences matter because the platform gives migrated records structured commercial meaning. Products, variants, modifiers, categories, customer groups, price lists, channels, customers, orders, CMS Pages, Blog Posts, redirects, custom fields, metafields, apps, and external identifiers should be reviewed according to how the business will use them after launch.
The strongest BigCommerce migration plan preserves not only data presence but data behavior. It separates native records from channel and storefront configuration, integration-owned values, data restructuring, and deliberately excluded expectations before the target data model is finalized.
Common Questions
Why are BigCommerce product options important during migration?
Product options can represent different business meanings. Some choices should become variants, some may be closer to modifiers, some may be custom fields, and some may depend on apps or custom logic. If the meaning is misread, product pages may appear complete while inventory, pricing, fulfillment, or customer selection behaves incorrectly.
Are BigCommerce custom fields and metafields enough for all source custom data?
No. They can preserve certain additional data, but they do not automatically reproduce source-platform behavior. App-owned records, external-system identifiers, bespoke product logic, and custom transformations may require data restructuring, application migration, or Target Store setup.
Do BigCommerce categories preserve source navigation automatically?
Not always. Categories, category trees, menu structure, SEO landing pages, and storefront/channel context should be reviewed separately. A Category record can exist while the buyer discovery path still depends on target navigation, channel context, content, or redirect relationships.
How should price lists and customer groups affect migration planning?
They should be treated as relationships, not isolated fields. A product price may look correct while a customer group, price list, quantity rule, or storefront condition still needs review.
How should app-owned or integration-owned data be represented in BigCommerce?
First identify the continuing system of record. Preserve a BigCommerce field, metafield, or external identifier only when the target application or integration will use it. Subscription contracts, loyalty balances, search rules, marketplace state, and similar application records should follow the destination application’s supported data path rather than being flattened into generic Product or Customer fields.
How should channel-specific catalog meaning be preserved in BigCommerce?
Identify which Products, prices, Categories, content, and visibility rules belong to each channel before mapping. Shared records can remain shared, but channel-owned differences should not be flattened when they influence what buyers see or what staff operate.