Choose a Next-Cart Migration Service for Wix by settling scope and execution separately: can the selected path produce the required data, and who should perform the agreed Migration Actions? Native Wix features and record volume alone do not decide either question.
Volume and complexity can point in different directions. Illustrative cases include:
- A small catalog whose choices, stock, membership or app relationships need separate qualification.
- A larger catalog whose supported records and relationships are clear enough for the merchant to execute and validate.
Use the actual requirements to choose handling and responsibility.
Separate the Wix outcome into three responsibilities:
- Migrated records: Products, Customers, Orders, supported CMS Pages, images and metadata require qualification in the active path.
- Blog continuity: Blog Posts are not supported migrated output to Wix in the approved path; define separate content, rebuild and route handling.
- Live site operation: assign Wix configuration, design, access, apps, CMS permissions, code and integrations separately unless expressly included.
For Wix, decide scope before execution: identify the supported records, eligible enhancements or tailored requirements, then choose who performs the agreed Migration Actions. The customer supplies business meaning, retains manual access and verifies the final result even when execution is expert-led.
Choose Scope Before Execution Responsibility
Compare service scope and execution ownership before choosing the Wix path. Establish the supported records, any eligible Add-ons or genuinely tailored handling, the executor, and who provides setup and acceptance evidence.
Confirm the actual catalog generation and Product lineage before selecting the transfer representation. Catalog V1 and V3 use different structures; a V3 API does not prove support for every field or path.
In V3, options create sellable variants; modifiers collect customization without independently managed price or stock.
Illustrative example: a free engraving instruction and a stocked size need different meanings. Confirm the supported Wix representation before assigning execution responsibility.
| Workstream | Wix example | Service-path implication |
|---|---|---|
| Supported migrated data | Products, categories or legacy catalog collections, Customers, Orders, CMS Pages, images and supported metadata. | May fit Standard Migration or Managed Migration depending on complexity and execution support needs. Wix Blog continuity is planned separately from migrated output. |
| Supported data adjustments | Applying data-type-specific conditions, transforming field values through expressions, or choosing different destinations for supported source fields. | May fit Data Filter, Data Transformation, or Advanced Data Mapping when requirements stay within supported behavior. |
| Custom or unsupported data | App-owned records, custom fields requiring non-standard interpretation beyond supported mapping, external IDs needing unsupported handling, Velo/API logic, CMS collection complexity, or bespoke transformations. | Requires Custom Migration review. |
| Wix target setup | Payments, checkout, shipping, tax, pickup, delivery, discounts, app setup, domain, site design, and member settings. | Must be configured and tested in Wix, not assumed from migration output. |
Avoid two opposite scope errors:
- Assuming hosting makes every Wix requirement ordinary record transfer.
- Escalating an ordinary setup duty or an eligible filtering, transformation or field-mapping rule to Custom Migration.
The exact data path and required behavior decide which boundary applies.
When Standard Migration May Be Enough
Standard Migration fits supported, compatible Wix data handling when the merchant can prepare inputs, execute the agreed actions and verify the result. Confirm required Add-ons and relationship meaning in the actual catalog generation. A complex label or large record count alone does not require another service; separately assign Wix setup and any site work.
Standard Migration can still produce a strong Wix result when expectations are realistic. The merchant should understand that migration can transfer supported records, while site design, live checkout behavior, domains, payment setup, shipping rules, tax configuration, member access, and app setup must be handled in Wix.
| Standard Migration signal | Wix-specific reason |
|---|---|
| Products have simple options or clear variant structures. | Supported catalog records can be reviewed without bespoke transformation. |
| Catalog groupings have a supported Wix representation. | Catalog data is supported; page and menu reconstruction remains separately owned. |
| Inventory follows the actual catalog generation’s compatible stock model. | The merchant can verify intended stock and locations, with any external authority and reconnection separately assigned. |
| Customers and orders are mainly needed for lookup and service history. | Historical records do not require advanced account, member, loyalty, or app behavior. |
| CMS Pages are limited or easy to review, and Wix Blog continuity has a separate plan. | Supported content migration does not dominate launch risk, and Blog content is not assumed to migrate as target output. |
| Site design and checkout setup are handled directly in Wix. | The migration scope stays separate from target implementation. |
Use the unmet responsibility to choose the next step:
- If supported action execution is the gap, consider Managed Migration.
- If required handling exceeds supported capability, seek Custom Migration review.
- If samples, future ownership or acceptance criteria are unclear, resolve them before treating the service choice as final.
When Managed Migration Fits
Managed Migration fits supported Wix scope when expert execution of agreed Migration Actions is needed.
Product, variant, Customer, Order, URL and supported-content interpretation remain customer-side review responsibilities. Expert execution does not automatically include launch coordination, Wix site building or final acceptance.
| Managed Migration fit | Wix scenario |
|---|---|
| Supported scope with many review areas | Products, collections, customers, orders, CMS Pages, URLs, and images all need structured review, while Wix Blog continuity needs separate content and redirect planning. |
| Launch timing is sensitive | The source store remains active while the Wix site is being prepared. |
| Content and SEO matter | URLs, redirects, landing pages, CMS Pages, Wix Blog continuity, and internal links need careful sequencing. |
| Internal bandwidth is limited | The merchant needs expert supported actions and can still assign setup, coordination and final acceptance owners. |
| Demo Migration must drive decisions | Customer-side sample interpretation needs coordination; expert supported actions do not automatically include that review. |
Select Managed Migration for expert execution of supported Migration Actions. Assign Wix setup, app behavior, content and SEO decisions, launch coordination and acceptance separately. Unsupported app extraction, bespoke Velo logic or relationships beyond compatible supported mapping need Custom Migration review even when expert execution is wanted.
Use Supported Add-ons for Bounded Changes
Use Standard Add-ons for eligible bounded changes:
- Data Filter: include or exclude records through supported field conditions for an in-scope data type.
- Data Transformation: change supported values through expressions.
- Advanced Data Mapping: route a supported source or transformed value to a compatible Wix field without changing it again during mapping.
These capabilities do not create unsupported data extraction, app behavior or custom business logic.
Wix does not support Advanced Database Mapping as Target. Wix API and Wix File Upload are distinct Source setups whose directional eligibility must be checked independently; neither grants database mapping into a Wix Target. Use eligible compatible Advanced Data Mapping fields where available, and scope unsupported extraction or bespoke logic separately.
Across eligible migration paths, the fixed Standard Add-on order is:
- Data Filter: select records.
- Data Transformation: change supported values.
- Advanced Data Mapping: route compatible source or transformed values.
- Advanced Database Mapping: perform eligible database routing after the earlier applicable stages. This stage is unavailable for a Wix Target.
Combining eligible Add-ons does not itself require Custom Migration. The Tax data type is excluded from both mapping Add-ons; a tax-related field on another supported data type still needs its own field-level qualification.
| Add-on need | Wix example | Boundary check |
|---|---|---|
| Data Filter | Apply supported Product, Order, Customer, or supported-content field conditions so only matching records migrate. | Filtering should not remove records needed for support, SEO, or launch verification. |
| Data Transformation | Apply expressions to transform supported Wix-bound field values during migration. | The expression and outputs must remain bounded and supported. |
| Advanced Data Mapping | Remap supported standard source fields to different supported Wix Product, Customer, Order, content, or metadata target fields while keeping the values unchanged. | Mapping cannot create unsupported Wix behavior or custom app logic. |
| Tailored or Custom Add-on need | A Standard Add-on function needs project-specific modification, or bespoke Add-on functionality is required. | This work is reviewed and quoted through Custom Migration rather than treated as Standard Add-on scope. |
State the exact condition, expression or source-to-target field route and the intended Wix result.
Illustrative qualified requirement: an exposed source item code needs a prefix before routing to a compatible Wix SKU field. This requires eligible transformation and mapping fields; validate the stored value, variant association and downstream lookup. A familiar field name alone does not establish support.
When Custom Migration Should Be Considered
Custom Migration should be considered when required Wix handling exceeds supported migration and Standard Add-ons. Examples include unsupported app records, custom-field relationships, bespoke transformations, Custom Platform extraction and source-code-dependent logic. An external identifier alone need not be custom when an eligible compatible supported field preserves the accepted meaning; native CMS or app capability alone does not establish coverage.
Investigate requirements outside ordinary record handling by function:
- Selling and participation: Product configurators, subscriptions, memberships, bookings and event history.
- Data and identity: custom Customer fields, CRM or loyalty IDs, external inventory references and marketplace records.
- Content and code: CMS collections, dynamic pages, custom databases, Velo-like logic and private integrations.
These subjects require qualification; their labels alone do not determine Custom Migration.
| Custom Migration trigger | Wix-specific implication |
|---|---|
| App-owned product, customer, order, or content records | Standard migration may not include the app’s data or behavior. |
| Custom fields or external identifiers whose required handling exceeds supported mapping or transformation | The values may need bespoke interpretation, a non-standard destination, or external-system continuity that Standard Add-ons cannot provide. |
| Velo/API or source-code-dependent behavior | The requirement may need custom logic review or target-side implementation planning. |
| Complex CMS collections or external databases | Native CMS collections and external relationships do not inherit support from CMS Page migration. Wix Blog Posts are not target migration output in the current path. |
| Product configurators, forms, memberships, bookings, or pricing-plan behavior | The selling model may belong to Wix apps, target setup, or custom handling. |
| Non-standard checkout, shipping, tax, fulfillment, or payment logic | Live behavior may need Wix setup, service-plugin planning, or accepted redesign. |
For Custom Migration review, provide:
- Representative records and source evidence, such as relevant screenshots or exports.
- The intended Wix representation and business outcome.
- The rules that will establish acceptance.
Concrete examples make unsupported extraction, relationships or bespoke logic reviewable before work is promised.
Custom Migration can use Self-Execute or Expert Handle for its agreed Migration Actions.
Selecting CSV, XLS or XML as the Source Platform requires Custom Migration; the standard included file workflow covers Products only. Other required data types must be agreed explicitly. This differs from a supported platform’s File Upload connection method, and a Product export alone does not establish the complete Wix scope.
Custom Migration does not automatically include Wix app implementation, Velo development, CMS or dynamic-page construction, payment and shipping setup, theme or page design, or external integration deployment unless those responsibilities are expressly included.
Define What Demo Can and Cannot Prove
Use ordinary and difficult examples to define the required result, then separate their proof paths:
- Demo Migration: inspect only a limited supported standard sample available on the active path.
- Excluded from Demo: Add-ons and Customization; Reviews and Coupons are also unavailable.
- Enhanced or tailored data: validate through the agreed paid scope.
- Live site and apps: assign Wix storefront, extension and operational checks to their implementation owners.
The Demo boundary helps diagnose an approach; it does not establish every site, app or custom outcome.
| Sample area | Decision it should support |
|---|---|
| Simple product | Whether the limited supported sample retains baseline catalog meaning in the actual Wix generation. |
| Option/variant product | Whether supported sample choices retain variant SKUs, prices, weights, media and inventory meaning; prove live selling separately. |
| Collection/category sample | Whether supported sample grouping is usable, and which pages, menus or redirects need separate implementation. |
| Customer with orders | Whether buyer identity and historical order context remain useful. |
| Guest buyer or duplicate profile | Whether identity assumptions need cleanup or acceptance rules. |
| Refunded or discounted order | Whether historical order exceptions remain readable. |
| CMS Page or media-heavy supported content | Whether migrated content remains usable and whether separate Wix Blog rebuild or redirect decisions are clear. |
| App/custom/external record | Identify standard supported extraction and placement where available. Add-on or tailored output requires paid proof; app behavior and site setup need separate checks or exclusion. |
If the limited standard result loses required record meaning, correct the affected scope or configuration before broader execution. Add-ons and tailored handling require agreed paid proof.
Wix Blog continuity, catalog-generation-specific behavior, live apps and Velo implementation remain separate evidence needs; a larger data run does not resolve unsupported structure by itself.
Separate Entity Points From Complexity
Entity Points plan eligible capacity, separately from site complexity:
- Supported Products, Customers and Orders count when they first migrate successfully within the same purchased migration and fixed Source-to-Target path; previously counted records remain counted once.
- Wix Blog Posts are outside supported Target output and are not planned as Wix-target point consumption.
- CMS, Member, app, Velo and Blog-continuity work needs separate scope assessment.
A small project can require Custom Migration when its required handling exceeds supported records or Add-ons. A larger catalog can remain Standard Migration or Managed Migration when its data is supported and responsibilities are clear. Record count does not assign scope or execution ownership.
| Scope signal | What it helps estimate | What it does not prove |
|---|---|---|
| Product count | Catalog volume and possible Entity Points usage. | Whether options, choices, variants, images, collections, and inventory are usable in Wix. |
| Customer count | Buyer-record volume. | Whether contacts, members, subscribers, app participants, and external IDs remain meaningful. |
| Order count | Historical order volume. | Whether payment, refund, fulfillment, discount, and external-reference context is readable. |
| Wix Blog continuity | Content volume, priority posts, URLs, and replacement destinations. | Blog Posts are not supported Wix target migration output; this row informs rebuild and redirect planning rather than Entity Points usage. |
Entity Points should support planning, not replace service-path evaluation. The chosen approach still depends on supported behavior, target setup, custom requirements, execution responsibility, and validation evidence.
Choose Later Actions and Their Evidence
After a paid result, choose later work according to whether the saved configuration remains suitable, supported settings must change or prior output should be replaced. Migration Actions describe those choices.
Define the source-record window separately; reusing configuration does not automatically limit processing to newly added records.
| Current action | When it fits Wix | Required revalidation |
|---|---|---|
| Continue the Migration with Last Saved Configuration | The earlier paid configuration remains suitable for the intended activity; confirm the eligible source-record window separately. | Check newly processed or reprocessed Products, Customers and Orders, regression samples and the separate Blog continuity plan. |
| Continue the Migration with a New Configuration | Supported mapping, filtering, data type selection, or configuration must change after an earlier paid result. | Recheck affected Products, options, variants, collections, Customers, Orders, content, and URL outputs. |
| Perform a New Migration | The intended migrated result should be replaced on the same actual Source and Target Stores within the fixed purchased path. A different path or actual Store requires a separate purchased Migration Service. | Validate the refreshed target result across Wix Stores, content, URLs, and accepted custom or app boundaries. |
Migration Actions process agreed data scope. They do not replace separately assigned Wix site, app, code, payment, fulfillment or integration work. Plan timing and revalidation around those responsibilities.
The first paid run uses Perform a New Migration. Either continuation action requires an earlier paid migration; Demo alone does not establish a paid configuration.
These actions keep the purchased Source-to-Target path and actual Store identities fixed. A different Source Platform, Target Platform, actual Source Store or actual Target Store requires a separate purchased Migration Service.
Confirm which source records the selected activity will read, including newly added records versus changes to existing records, and how it relates to earlier processing state.
A new-record-only window excludes edits to existing records; the window and earlier-state treatment do not follow from an action name alone.
When configuration changes, review the combined earlier and later output and preserve protected Target work under the agreed treatment.
Resolve Gaps Before Broader Execution
An approach is incomplete when required handling, ownership or evidence remains unresolved. Use the signals below to decide whether the gap concerns execution, supported data, Custom scope or separately owned Wix implementation.
| Warning signal | Likely response |
|---|---|
| Product options, choices, variants, and inventory cannot be validated confidently. | Rework catalog scope or consider stronger execution/custom review. |
| Source categories are expected to recreate menus, pages, filters, and SEO paths automatically. | Separate collection migration from site structure and redirect planning. |
| Customer records include members, contacts, subscribers, loyalty, bookings, or app participation. | Classify identity types and review supported versus custom paths. |
| Historical orders are expected to configure live Wix checkout. | Separate migrated history from payment, shipping, tax, and order-setting setup. |
| CMS Pages, Wix Blog content, dynamic pages, or custom data collections are central to launch. | Plan supported content migration separately from Wix Blog rebuild, redirects, CMS setup, or Custom Migration review. |
| App-owned fields, Velo/API logic, or external IDs are business-critical. | Do not rely on generic migration scope; evaluate Add-ons or Custom Migration as appropriate. |
| The merchant cannot define who will validate Wix setup and migration output. | Managed Migration may cover expert actions; the merchant must still assign coordination, setup owners and acceptance criteria. |
Record who resolves each signal, the evidence required and whether it blocks the agreed broader run. A different service name does not resolve missing scope or acceptance responsibilities.
Record the Agreed Wix Approach
Use the Migration Service overview to navigate available services after defining Wix data scope and execution needs. Standard Migration supports customer execution; Managed Migration includes agreed expert actions. Custom Migration adds accepted tailored scope with Self-Execute or Expert Handle. Site implementation and final verification still need assigned owners.
A ready approach records the following decisions:
- The supported Wix records, actual catalog generation and required relationships.
- Eligible Add-ons and any approved Custom Migration requirements.
- Who executes agreed actions, retains manual access and verifies the final result.
- Which settings, site elements, Blog content, apps or integrations need separate setup or reconstruction.
- Which limited standard findings, agreed paid outputs and implementation evidence must be accepted before broader execution.
If those statements are not clear, the service path should not be treated as finalized. Wix migration quality depends on matching the chosen approach to the actual site-commerce environment the merchant wants to operate after launch.
Conclusion
A ready Wix approach matches supported records, eligible Add-ons, accepted Custom scope, capacity and action planning to the actual catalog and responsible owners. Keep data handling, site implementation and acceptance evidence distinct.
Use eligible Add-ons where sufficient and review genuinely unsupported handling separately. Demo supplies limited standard evidence; enhanced or tailored output needs validation in the agreed paid work. Live selling, site experience and operational behavior require separately owned implementation checks before launch.
Common Questions
When is Standard Migration enough for a Wix migration?
Standard Migration can fit when the required Wix records, relationships and any eligible Add-ons stay within supported capability, and the merchant can prepare, execute and verify the agreed work. Confirm the actual catalog generation and assign site setup, app behavior and content continuity separately. Large volume or structural complexity alone does not determine the service.
When should Managed Migration be considered for Wix?
Consider Managed Migration when Wix scope is supported but expert execution of agreed Migration Actions is needed. The merchant retains manual access and verifies the final result. Sample interpretation, content and Blog planning, launch coordination, site building and Wix app setup remain separately assigned.
How are Add-ons different from Custom Migration for Wix?
Add-ons provide bounded filtering, value expressions and compatible supported field routing. Wix does not support Advanced Database Mapping as Target.
Custom Migration handles extraction, app relationships, source-code-dependent behavior or bespoke logic beyond supported capability. An external ID alone is not a custom requirement if an eligible compatible supported field is sufficient.
What should Demo Migration prove for Wix before Full Migration?
Demo examines a limited sample of standard Wix records available in the active path, such as Products, variants, Customers, Orders or supported CMS Pages. Add-ons and Customization are unavailable, and Reviews and Coupons are excluded.
Validate enhanced or tailored output through paid activity. Wix Blog continuity needs separate content/rebuild/redirect proof, and live apps, members or Velo behavior need their own checks.
Which migration action should be used for Wix follow-up work?
After an earlier paid result, select the action by configuration and intended output:
- Continue the Migration with Last Saved Configuration: the saved setup remains suitable for the chosen source-record window.
- Continue the Migration with a New Configuration: supported filters, mappings, data-type selections or other configuration must change.
- Perform a New Migration: the intended migrated result should be replaced within the same fixed path and actual Source and Target Stores.
Reading only newly added records is a separate qualified choice. A different platform path or actual Store requires a separate purchased Migration Service. Recheck affected earlier and later output.
Should a Wix modifier create an independently stocked variant?
A modifier collects customization without generating a separate variant. A choice with its own SKU, price or inventory needs a supported selling representation appropriate to the actual catalog generation. Decide that meaning first; copying a modifier label into a variant can create the wrong stock model.
Does Wix Catalog V3 guarantee that every source field can migrate?
No. Catalog generation and Product lineage explain the native representation; the active Next-Cart path still determines supported Data Types, fields and relationships. Confirm the actual Target generation and required output. A public API or V1-to-V3 reference guide does not establish migration coverage.
Does Wix Source API or File Upload eligibility apply to Wix as Target?
No. Source and Target support are directional, and the exact Wix API and Wix File Upload Source setups are assessed separately. Wix does not support Advanced Database Mapping as Target, regardless of the Source setup. Native API availability does not remove the Target gate.
Can Wix Blog Posts be included in this target migration?
Wix Blog Posts are not supported migrated output in the current Wix target path. Plan content continuity through separate rebuilding, replacement destinations and redirects as needed.
Do not count those posts as Wix-target Entity Points consumption or treat native Wix Blog capability as proof of migration support.