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 preserves the Source Store’s business meaning through supported data, agreed adjustments and separate target setup. Review requirements by function:
- Catalog: variants, shopper modifiers and fields whose required handling may exceed supported mapping.
- Commercial context: segmented pricing, channels and Customer or company relationships.
- Continuity: app-owned records, external identifiers and SEO-sensitive redirects.
These requirements may change preparation, Add-ons, execution workload or Custom Migration scope; none selects a service by itself.
Store size alone cannot select the service:
- A large, supported catalog can remain manageable when it is reviewable.
- A smaller store may need tailored handling when essential app or custom data exceeds supported scope.
Storefront continuity, integrations and target configuration still need accountable owners.
Within Next-Cart Migration Services, compare the service options by supported scope and execution responsibility. BigCommerce’s required structures determine the work; the service determines who performs the agreed migration actions.
What Migration Approach Means for BigCommerce
Define the approach through separate decisions:
- Transfer scope: records and relationships supported on the actual Source-to-BigCommerce path.
- Adjustments: supported Add-ons or requirements that need Custom Migration review.
- Implementation: BigCommerce settings, apps and storefront behavior configured separately.
- Responsibility and proof: who executes, what support applies, and which Demo or later paid results must be checked.
This keeps validation depth tied to the requirement rather than to a service name.
Two native distinctions often change BigCommerce scope:
- Variant versus modifier: modifiers do not select a different fulfilled variant or create independently stocked combinations. A Product-list modifier can affect a linked Product’s inventory through a different relationship.
- Company versus Customer group: Independent companies can share a group or use default pricing without one. Legacy Dependent-company relationships differ, so confirm the actual B2B mode.
Price-list values, buyer or channel assignments and any enabled fallback layers require their own acceptance criteria.
| Work type | BigCommerce example | Service-path implication |
|---|---|---|
| Supported migrated records | Products, categories, customers, orders, images, content pages, redirects and related fields, where supported by the exact migration path. | 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, custom fields, external identifiers, feed data, bespoke pricing or transformation whose required handling exceeds standard support and available Add-ons. | 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 fits supported scope when the merchant can prepare inputs, execute the available Migration Actions and validate the result. Products, categories, customers, orders, images, pages, redirects and related fields must each be supported on the actual path; the service name does not establish coverage.
The readiness signals below concern manageable Product choices, pricing, channels, ordinary Customer history and clear content or redirect scope. Their value depends on the merchant being able to review representative Demo results and complete the required later validation.
| 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 changes execution responsibility within the same supported capability as Standard Migration. It does not make app records, unsupported company relationships or bespoke transformations standard.
Custom Migration handles agreed tailored requirements with 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. |
The customer retains manual access and final verification under Managed Migration. Supply representative variants, modifier relationships, company contexts and expected buyer prices so expert execution can be judged against the intended result.
When Add-ons Can Solve the Need
Use supported migration Add-ons when a requirement can be expressed as a bounded record condition, value expression or compatible field destination. The table distinguishes those controls; they do not supply unsupported records, external-system workflows or bespoke app logic.
| 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 supports it. For custom fields or metafields, check whether Advanced Data Mapping exposes the required compatible destination; otherwise review Custom Migration.
Selected Standard Add-ons process in this order:
- Data Filter selects records.
- Data Transformation changes supported values.
- Advanced Data Mapping routes source or already transformed values unchanged.
- Advanced Database Mapping handles eligible database routing only on supported paths; it cannot be used with BigCommerce as Target.
Tax as a Data Type is outside both mapping Add-ons. Combining several supported controls does not itself create custom scope.
When Custom Migration Should Be Considered
Consider Custom Migration scope when essential data or behavior exceeds standard support and available Add-ons. The trigger may be an unsupported source structure, app record, external-system requirement, bespoke transformation, Custom Platform or migration-logic adjustment. Merchant size and the label “custom field” do not decide it.
Common areas to investigate include:
- Catalog and data: Product options, custom fields, metafields, ERP data and pricing.
- Buyer relationships: B2B structures, Customer segmentation, subscriptions and loyalty.
- Connected channels: reviews, marketplace feeds, headless storefronts and app behavior.
Classify the required output before deciding whether supported handling, separate implementation or tailored migration is necessary.
| 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. | Review Custom Migration only if supported mapping cannot preserve the required value, relationship and 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. |
Scope tailored work through representative evidence:
- Products, Customers, Orders and content records that show the required structure.
- Fields beyond supported mapping, app exports and external identifiers with their relationships.
- Expected outputs that show how the result must be used.
Without concrete examples, the request remains too abstract to approve.
For Custom Migration, agree the tailored records and choose Self-Execute or Expert Handle for the Migration Actions.
CSV, XLS and XML as Source Platform selections require Custom Migration, with Products only in the included file workflow. Customers, Orders, company records and app data need separate agreement. This differs from a native-platform File Upload connection; a catalog export cannot establish complete B2B or subscription scope.
What Demo Migration Should Decide
Review Demo Migration limits before treating a sample as proof. Demo uses the limited standard data available on the active path; Add-ons and Customization cannot run, and Reviews and Coupons are excluded.
Use available records to expose catalog or buyer mismatches. Essential company, app, custom-field or pricing outputs beyond that sample need agreed paid-result or separate target-implementation checks. The table names evidence needs, not guaranteed Demo coverage.
| Demo Migration sample | Decision it should support |
|---|---|
| Simple product | Baseline product, category, image, price, and inventory mapping. |
| Variant-heavy product | Whether supported options and variants are represented correctly in the available standard sample. |
| 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 | Which channel assignment and visibility assumptions need separate proof if absent from the standard sample. |
| Customer with group or custom field | Which supported Customer identity or group fields can be reviewed; unavailable segmentation needs separate proof. |
| 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 estimate eligible Product, Customer, Order and Blog Posts volume; they do not prove structural fit. A counted record consumes points when first migrated successfully within the same purchased migration and fixed path. Reprocessing that counted record does not charge it again; newly eligible records can consume points on first successful migration.
Assess channels, price lists, modifiers and app complexity separately.
Use the volume signals below alongside the catalog, buyer and implementation requirements already identified. Essential app fields, external IDs, custom pricing or storefront logic can make a small store complex; supported, reviewable records can keep a larger store within Standard Migration or Managed Migration.
| 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 | Reuse an earlier paid result when the accepted filters, mappings, channel assumptions, redirects and catalog structure remain valid. New eligible Products, Customers, Orders or Blog Posts are one use case; the source-data window is a separate decision. | Recheck new and reprocessed records, affected variants or modifiers, channel visibility, Order history and priority URLs against the combined result. |
| 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.
Keep these decisions separate from the Migration Action:
- Source coverage: identify new records and updates to existing variant stock, Customer-group pricing or company data. A newly-added-only window does not cover those updates.
- Earlier state: confirm which prior migration state and relationships the next activity can continue.
- Target impact: protect accepted target changes and review earlier and later outputs together; a fresh action does not automatically erase protected data.
An action does not select the source window or authorize target clearing by itself.
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 continues to follow the selected service:
- Customer-led: Standard Migration or Custom Migration with Self-Execute.
- Expert-led within agreed scope: Managed Migration or Custom Migration with Expert Handle.
The customer remains responsible for final verification and acceptance.
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. | Define buyer, variant, currency, quantity, assignment and enabled fallback evidence; review Add-ons or Custom Migration only for handling beyond supported scope. |
| 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. | Improve the available standard sample and assign paid or target-side proof for requirements Demo cannot exercise. |
| 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
Choose the lightest approach that can deliver the agreed outcome:
- Standard Migration: supported scope with realistic customer-led execution and validation.
- Managed Migration: the same supported capability with experts executing agreed actions.
- Add-ons: available record filtering, value transformation or compatible field remapping.
- Custom Migration: essential handling beyond standard support or available controls.
Target-side setup remains a separate responsibility unless explicitly included.
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 these statements are accepted and every essential requirement has a defined evidence path:
- Paid results must prove Add-on and Customization output.
- Implementation owners must prove target apps, pricing configuration and storefront behavior.
Use BigCommerce validation priorities to plan that evidence. Unclassified requirements keep the approach open.
Conclusion
A BigCommerce migration approach should explain what transfers, what needs supported adjustments or tailored handling, and who executes. Variants, modifiers, buyer prices, channels and connected records matter because they preserve business meaning, not because they increase a record count.
Keep target configuration, Entity Points capacity, Demo limits and later migration activity in that decision. A workable path includes both execution responsibility and the evidence needed 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?
Reuse the last saved configuration when an earlier paid setup remains valid, or continue with a new configuration when supported rules need review. Perform a New Migration applies to a first paid run or a fresh result on the same purchased path.
Choose the source-data window separately: newly-added-only processing excludes updates to existing records. Revalidate affected earlier and later 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.