For a move into BigCommerce, choose the Next-Cart approach by asking which Product choices determine the fulfilled SKU and which buyer relationships determine the price. Variant inventory, shopper modifiers, company accounts and Customer groups are different structures. Their required representation defines scope; who executes that scope is a second decision.
The right BigCommerce migration approach depends on how much of the source store can become supported BigCommerce data without losing business meaning. A simple product catalog may fit a straightforward path. A variant-heavy catalog, segmented pricing structure, multi-channel setup, custom fields whose required handling exceeds supported mapping scope, app-owned records, external identifiers, or SEO-sensitive redirect plan may require stronger preparation, Add-ons, Managed Migration, or Custom Migration review.
Service-path choice should not begin with store size alone. BigCommerce complexity often comes from product choices, pricing rules, channel assignments, storefront continuity, customer segmentation, integrations, and target-side configuration. A large store can still follow a manageable path when the data is supported and reviewable. A smaller store can need Custom Migration when app or custom data is central to operations.
Within Next-Cart Migration Services, BigCommerce evidence should determine whether supported scope is enough, execution should be expert-led, or platform-specific structures require Add-ons or Custom Migration.
What Migration Approach Means for BigCommerce
A BigCommerce migration approach is a decision about scope, responsibility, support level, and validation depth. The approach should define which records should move into BigCommerce, which target-side settings must be configured in BigCommerce, which Add-ons are needed for supported adjustments, which requirements need Custom Migration, and which Demo Migration samples must pass before Full Migration.
BigCommerce modifiers do not select a different fulfilled variant, and modifier combinations do not provide inventory-tracked SKUs. A Product-list modifier can affect a linked Product’s inventory, which is a different relationship. For B2B, confirm the actual company mode: Independent companies can share a Customer group or use default pricing without one, while legacy Dependent-company relationships behave differently. Price-list values and their Customer-group or channel assignments need their own acceptance criteria.
| Work type | BigCommerce example | Service-path implication |
|---|---|---|
| Supported migrated records | Products, categories, customers, orders, images, content pages, redirects, and supported related fields. | May fit Standard Migration or Managed Migration depending on execution and validation needs. |
| Supported adjustments | Product, Customer, Order, content, or redirect data needs a defined data type condition, value expression, or source-field destination. | May require Data Filter, Data Transformation, or Advanced Data Mapping. |
| Custom or unsupported requirements | App-owned data, unsupported custom fields requiring non-standard interpretation, external identifiers, bespoke pricing logic, feed data, or special transformation. | Requires Custom Migration review. |
| Target-side setup | Storefront theme, checkout settings, payment setup, tax rules, shipping settings, apps, channels, and live integrations. | Must be configured and tested in BigCommerce rather than treated as migrated records. |
The right path protects the merchant from two opposite mistakes: choosing too light a path for complex business data, or escalating every platform-specific detail to Custom Migration when a supported Add-on or target-side setup task is enough.
When Standard Migration May Be Enough
Standard Migration may be enough when the BigCommerce scope is supported, the source data is clean, and the merchant can prepare inputs and validate the result confidently. This usually means products, categories, customers, orders, images, pages, redirects, and related fields can be migrated without bespoke transformation or unsupported app-data handling.
Standard Migration is strongest when product choices are simple or clearly structured, pricing is not heavily segmented, channel expectations are limited, customer data is mostly standard, and the merchant can review Demo Migration samples without intensive coordination.
| Standard Migration readiness signal | BigCommerce-specific reason |
|---|---|
| Products have clear SKUs, options, variants, images, and categories. | Catalog review can focus on supported BigCommerce product structures. |
| Modifiers or shopper customization are limited or easy to identify. | The catalog is less likely to need special interpretation. |
| Pricing is mostly base price, sale price, or simple supported discount context. | Advanced price-list or B2B pricing complexity is limited. |
| Channels are simple or not part of launch complexity. | Product visibility and storefront scope are easier to validate. |
| Customers and orders are ordinary historical records. | Buyer lookup and order history can be checked through representative samples. |
| Redirects and content scope are clear. | SEO continuity can be reviewed without custom content transformation. |
Standard Migration becomes risky when the merchant cannot explain how source product options, pricing, channels, or app data should appear in BigCommerce. A supported record type does not automatically mean every source behavior is supported.
When Managed Migration May Be Safer
Managed Migration may be safer when the BigCommerce scope is supported but experts should perform the agreed Migration Actions. Variant-heavy catalogs, priority redirects and channel-sensitive prices can increase execution workload. The merchant still defines how choices and buyer prices should behave and retains final acceptance.
Managed Migration provides expert execution within the same supported capability as Standard Migration. It does not make app records, unsupported company relationships or bespoke transformations standard. Custom Migration addresses those tailored requirements and supports either Self-Execute or Expert Handle; target app, storefront and integration implementation must be included explicitly.
| Managed Migration fit | BigCommerce scenario |
|---|---|
| Supported scope with many review points | Products, variants, categories, images, customers, orders, pages, and redirects need coordinated review. |
| High-value SEO continuity | Experts execute agreed actions; the merchant owns acceptance of redirects, URLs and metadata and the wider launch sequence. |
| Variant-heavy catalog | Product choices are supported but need disciplined sample review. |
| Multi-channel or pricing sensitivity | Channel assignments, price lists, or customer group pricing require structured validation. |
| Limited merchant bandwidth | The merchant needs included expert-led execution while retaining final result verification. |
Choose Managed Migration when expert execution is needed within supported scope. The customer still supplies representative variants, modifier relationships, company contexts and price expectations, retains manual access and verifies the outcome.
When Add-ons Can Solve the Need
Add-ons are useful when the requirement is supported, bounded, and specific. Data Filter can select BigCommerce Products, Customers, or Orders through data-type-specific field-based conditions. Data Transformation can apply expressions to supported field values, while Advanced Data Mapping can remap a supported standard source field to a compatible supported BigCommerce target field while keeping the value unchanged. These controls do not replace Custom Migration for unsupported records, external systems, bespoke logic, or app-owned data that BigCommerce does not receive as ordinary migration data.
| Add-on need | BigCommerce example | Boundary check |
|---|---|---|
| Data Filter | Migrate supported Products, Customers, Orders, CMS Pages, or Blog Posts that meet defined data-type-specific field-based conditions. | The field, condition, and inclusion or exclusion rule must be explicit. |
| Data Transformation | Apply expressions to transform supported BigCommerce-bound field values during migration. | Input values, expected outputs, and exceptional cases must be testable. |
| Advanced Data Mapping | Remap supported standard source fields to different supported BigCommerce target fields while keeping the values unchanged. | Mapping cannot create unsupported BigCommerce behavior or target structures. |
| Handle bounded special needs | Use one of the defined supported filtering, transformation or field-mapping controls for the specified data. | If custom logic or unsupported records are involved, Custom Migration is safer. |
Good Add-on requests are written as precise acceptance criteria. Weak Add-on requests use broad language such as “make it match the source store” without defining the supported fields or behavior.
Advanced Database Mapping is not supported with BigCommerce as Target, even when the selected Source can use it. For custom fields or metafields, first check whether supported Advanced Data Mapping can reach a compatible field; otherwise review Custom Migration. Selected Standard Add-ons follow Data Filter, Data Transformation, Advanced Data Mapping, then Advanced Database Mapping only where eligible. Mapping routes the source or already transformed value unchanged, and Tax is outside both mapping Add-ons. Several supported controls do not automatically create custom scope.
When Custom Migration Should Be Considered
Custom Migration should be considered when the BigCommerce migration requirement goes beyond supported standard behavior. The trigger is not the merchant’s size. The trigger is custom data, unsupported source structures, bespoke transformation, app records, external identifiers, Custom Platform handling, or custom migration logic adjustment.
BigCommerce custom needs often appear around product options, custom fields, metafields, pricing, ERP data, subscriptions, reviews, marketplace feeds, B2B-like structures, customer segmentation, loyalty records, and headless or app-connected storefront behavior.
| Custom Migration trigger | Why it changes the approach |
|---|---|
| Source product options do not fit cleanly into variants, variant options, or modifiers. | The catalog may need bespoke interpretation before BigCommerce can use it. |
| App-owned subscriptions, loyalty, bundles, reviews, feeds, or marketplace records are expected. | The data may not belong to standard platform records. |
| Custom fields or external identifiers must remain usable for ERP, CRM, accounting, or support. | Supported mapping may not preserve business meaning. |
| Advanced pricing logic depends on custom or external rules. | Price lists or bulk pricing may not fully represent the source behavior. |
| Source content depends on page builders, scripts, or custom storefront logic. | BigCommerce content and redirects may require special handling or manual rebuild. |
| A Custom Platform is part of the source or target situation. | Source structures may need direct analysis before mapping can be trusted. |
Custom Migration should be scoped through examples. The merchant should provide representative products, customers, orders, content records, custom fields whose required handling exceeds supported mapping scope, app exports, external identifiers, and expected outcomes. Without examples, custom discussion stays too abstract to produce a reliable service path.
For Custom Migration, agree the tailored records and choose Self-Execute or Expert Handle for the Migration Actions. Selecting CSV, XLS or XML as Source Platform requires Custom Migration; the standard included file workflow covers Products only. Customers, Orders, company records and app data need separate agreement. This differs from a native-platform File Upload connection, and a catalog export alone does not establish complete B2B or subscription scope.
What Demo Migration Should Decide
Demo Migration helps evaluate the limited standard records available in the active BigCommerce path. It cannot run Add-ons or Customization and excludes Reviews and Coupons. Use available samples to identify mismatches in catalog or buyer context; assign unsupported company, app, custom-field and pricing requirements to paid-scope validation or target implementation checks. The contexts below define evidence needs rather than promise that every structure is testable in Demo.
| Demo Migration sample | Decision it should support |
|---|---|
| Simple product | Baseline product, category, image, price, and inventory mapping. |
| Variant-heavy product | Whether options and variants behave correctly. |
| Modifier-like product | Whether shopper customization needs another path. |
| Product with custom fields whose required handling exceeds supported mapping scope or metafields | Which standard fields are available; Add-on or custom output requires paid-scope proof. |
| Price-list or bulk-pricing example | Which available standard prices can be checked; price-list assignments and custom pricing need separate proof. |
| Channel-specific product | Whether channel assignment and visibility need review. |
| Customer with group or custom field | Whether customer identity and segmentation are preserved. |
| Discounted or refunded order | Whether historical order context remains readable. |
| Priority URL or content page | Whether SEO and redirect expectations need adjustment. |
The approach needs revision if available samples expose catalog or buyer mismatches, or if essential app, pricing or company requirements have no agreed proof. A standard Demo pass cannot resolve an untested custom requirement. Correct the scope and assign the required paid or target-side checks before Full Migration.
Entity Points and BigCommerce Scope Planning
Entity Points help plan selected data type volume, but they do not prove that source data fits BigCommerce. For BigCommerce, eligible Product, Customer, Order, and Blog Posts records may consume Entity Points the first time they migrate, while records already counted within the same purchased migration and fixed path remain counted once; channel, price-list, modifier, and app complexity is assessed separately. New eligible records may consume Entity Points when migrated for the first time.
For BigCommerce, Entity Points should be reviewed alongside structure and complexity. A small source store may need Custom Migration if it depends on app-owned fields, external IDs, custom pricing, or storefront logic. A larger store may fit Standard Migration or Managed Migration when the records are supported and the merchant can validate them.
| Scope signal | What it helps estimate | What it does not prove |
|---|---|---|
| Product count | Catalog volume and possible Entity Points usage. | Whether variants, modifiers, custom fields, images, categories, and channels map correctly. |
| Customer count | Buyer-record volume. | Whether groups, custom fields, duplicates, external IDs, and buyer relationships remain useful. |
| Order count | Historical order volume. | Whether refunds, discounts, payment context, fulfillment, and custom statuses remain readable. |
| Blog Posts count | Content volume when relevant. | Whether URLs, redirects, metadata, and content presentation are launch-ready. |
Entity Points should support planning, not replace service-path evaluation.
How Migration Actions Affect BigCommerce Launch Planning
After a paid migration has produced a result, changes in the Source Store or revised migration requirements may call for further activity into BigCommerce. The action should match the intended treatment of that earlier paid result and its configuration, not merely the availability of another run. Demo Migration findings belong in the preparation of the first paid configuration; they do not make a Demo result a paid continuation baseline.
| Current option | BigCommerce-specific use | Required revalidation |
|---|---|---|
| Continue the Migration with Last Saved Configuration | Use when the source store has new eligible Products, Customers, Orders, or Blog Posts and the accepted filters, mappings, channel assumptions, redirect handling, and catalog structure remain valid. | Recheck new records, affected variants or modifiers, channel visibility, Order history, and priority URLs. |
| Continue the Migration with a New Configuration | Use when filters, mappings, Product-option interpretation, customer segmentation, redirect handling, price-list assumptions, or channel/storefront scope need to change. | Revalidate both the changed rules and representative records that were previously accepted under the older configuration. |
| Perform a New Migration | Use when the earlier target result should not remain the working baseline, the BigCommerce target environment is reset or materially reworked, or the project needs a clean migration outcome under a newly approved scope while the purchased Source Platform-to-Target Platform path remains unchanged. | Repeat the full acceptance set for catalog, Customers, Orders, content, redirects, channels, and custom requirements. |
This distinction is important when the Source Store adds new Orders and Customers during the BigCommerce launch window while the main catalog remains unchanged.
Select the source-data window separately from the action. “Migrate only newly added entities” covers records added after the last successful run, not updates to existing variant stock, Customer-group pricing or company records. “Continue the previous migration” applies to the appropriate earlier migration state; an action does not choose either option automatically. After configuration changes, review earlier and later outputs together. A new action does not automatically erase protected target data.
Migration Actions do not recreate BigCommerce apps, theme code, checkout configuration, channel integrations, payment settings, or external-system workflows. When later source changes affect those areas, the merchant must coordinate target implementation and revalidation separately from the data action.
Execution responsibility still follows the selected Migration Service. Customers using Standard Migration or Custom Migration with Self-Execute perform available actions themselves. Under Managed Migration or Custom Migration with Expert Handle, execution of the agreed action is included within the accepted scope, while the customer remains responsible for final verification and the migration outcome.
Signals That the Chosen Approach Is Too Light
A BigCommerce approach is too light when it treats platform-specific complexity as ordinary record transfer. The warning signs usually appear in catalog meaning, pricing, channel scope, redirects, customer segmentation, or app data.
| Warning signal | Likely response |
|---|---|
| Product choices cannot be classified as variants, variant options, modifiers, setup, or custom scope. | Rework catalog scope before selecting the final path. |
| Price lists, customer-group pricing, or bulk pricing are business-critical but not sampled. | Add pricing samples and review Add-ons or Custom Migration needs. |
| Channel assignments or product visibility differ by storefront. | Strengthen channel preparation and validation. |
| Redirects, CMS Pages, or Blog Posts are high-value but loosely scoped. | Treat content and SEO continuity as launch-critical evidence. |
| Custom fields, metafields, app data, or external IDs are central to operations. | Verify whether supported field remapping can preserve the requirement; review Custom Migration when supported mapping is not sufficient. |
| Demo Migration uses only simple products and clean orders. | Expand the sample set before Full Migration. |
| Source data continues changing near launch without a later-action plan. | Define timing, migration action, ownership, and revalidation. |
These signals should be handled before Full Migration. Waiting until launch makes it harder to distinguish migration issues from target-side BigCommerce setup gaps.
Choosing the Practical Path
The practical BigCommerce approach is the lightest path that still protects the business outcome. Standard Migration may be enough when supported records and customer-led validation are realistic. Managed Migration fits when experts should execute agreed actions within supported scope. Add-ons are appropriate when supported records need record filtering, field-value transformation, or field remapping. Custom Migration is necessary when unsupported, custom, app-owned, external-system, or bespoke transformation needs must be evaluated.
A reliable approach can be summarized in four statements:
- which records should migrate into BigCommerce;
- which BigCommerce settings, apps, channels, or storefront behaviors must be configured separately;
- which Add-ons or Custom Migration requirements are in scope;
- which standard Demo samples inform the decision and which enhanced, custom or target-side outputs need separate proof.
Proceed when those statements are accepted and each essential requirement has the right evidence path. Add-ons and Customization need paid-result validation, while target apps, pricing configuration and storefront behavior need implementation owners. If a requirement is still unclassified, refine scope before treating the approach as settled.
Conclusion
BigCommerce migration approach selection should be grounded in how the merchant expects BigCommerce to operate after launch. Standard Migration, Managed Migration, Add-ons, and Custom Migration each have a role, but none should be chosen from record counts alone. The right approach accounts for catalog structure, variants, modifiers, price lists, channels, customers, orders, redirects, content, apps, Entity Points, later migration actions, and Demo Migration evidence.
A practical service path protects both migration execution and business validation. It should explain what migrates, what must be configured in BigCommerce, what needs Add-ons, what requires Custom Migration, and what must be proven before launch.
Common Questions
When is Standard Migration enough for a BigCommerce migration?
Standard Migration may be enough when the BigCommerce scope is supported, product structures are clear, pricing and channels are manageable, customers and orders are straightforward, redirects and content are scoped, and the merchant can validate the result confidently.
When should Managed Migration be considered for a BigCommerce migration?
Choose Managed Migration when BigCommerce’s migration scope is supported but experts should execute the agreed Migration Actions. Variant, redirect, pricing and channel complexity can increase that workload. The merchant still defines expected buyer behavior, owns business approvals and verifies the result; wider launch management or implementation must be agreed separately.
How are Add-ons different from Custom Migration in a BigCommerce migration?
Add-ons adjust supported record filtering, field-value transformation, or field remapping. For BigCommerce, Custom Migration should be reviewed when multi-storefront assignments, B2B records, app-owned data, external identifiers, or bespoke catalog and Customer transformations cannot be handled through supported mapping or bounded Add-ons.
What should Demo Migration prove for BigCommerce before Full Migration?
It should show how available standard Products, variants, Customers, Orders and content are represented and help identify gaps. It cannot prove Add-on or Customization output and excludes Reviews and Coupons. Modifier, price-list, company, app or integration requirements beyond the standard sample need agreed paid proof or separate target checks.
Which Migration Action fits a BigCommerce launch update?
Use Continue the Migration with Last Saved Configuration when an earlier paid setup remains valid, or Continue the Migration with a New Configuration when supported rules change. Perform a New Migration is available for a first paid run or a new result on the same purchased path. Select the source-data window separately; newly added entities exclude updates to existing records. Revalidate affected and earlier outputs together. A different Source-to-Target path requires a separate purchase.
Can a BigCommerce modifier replace an inventory-tracked variant?
A modifier does not choose a different fulfilled variant and its combinations cannot serve as inventory-tracked SKUs. A Product-list modifier may affect a linked Product’s inventory, but that does not make modifier combinations variants. Define the intended SKU and stock relationship first, then confirm supported mapping or scope tailored interpretation.
Does every BigCommerce B2B company need its own Customer group?
No. Confirm the company mode in the actual target. Independent companies can share a Customer group or use default pricing without one; legacy Dependent-company behavior differs. Company membership, price-list assignments and Customer groups must be assessed separately rather than promised as one automatic mapping.
Can Advanced Database Mapping preserve BigCommerce metafields?
BigCommerce is not a supported Target for Advanced Database Mapping. A database-capable Source does not change that. Use Advanced Data Mapping only when the required compatible field is supported, and review Custom Migration for essential metafields or app relationships beyond that scope. Validate enhanced or tailored outputs through the agreed paid result.