When evaluating Wix as a prospective Target Platform, the migration approach should match the required Next-Cart Migration Service, supported Add-ons where applicable, responsibility level, scope, and validation burden.
The right Wix migration approach depends on what the merchant expects the future Wix site to operate, not only on how many records need to move. A small product catalog can require deeper planning if it depends on product options, variant-specific inventory, CMS data, memberships, custom forms, external systems, Velo/API logic, or app-owned records. A larger catalog can still follow a straightforward path when the data is supported, the structure is clear, and the merchant can validate the target result with confidence.
For Wix, separate supported record migration from site implementation. Products, Customers, Orders, CMS Pages, images and metadata require qualification in the active path. Wix Blog Posts are not supported target migration output in the current Wix path, so Blog continuity needs a separate content, rebuild or redirect plan. Payments, shipping, taxes, domains, design, apps, member access, CMS permissions, Velo code and integrations need their own setup and live checks unless explicitly agreed.
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.
What Migration Approach Means for Wix
A Wix migration approach defines scope, execution responsibility, support level, special handling, and validation depth. It should answer which records are expected to migrate, which Wix settings must be configured separately, which special requirements need Add-ons, and which unsupported or custom requirements require Custom Migration review.
The approach should be chosen from evidence, not from platform assumptions. Wix is hosted and user-friendly, but that does not make every migration simple. A content-heavy site, variant-rich store, member-based business, custom-coded workflow, or app-driven catalog may require more careful service planning than a conventional product/customer/order transfer.
Confirm the actual Wix Stores catalog generation and Product lineage. Catalog V1 and V3 use different structures; the presence of a V3 API does not prove support for every field or path. In V3, options generate purchasable variants with their own selling identity, while modifiers collect customization without creating variants. A name to engrave is therefore different from a size with its own SKU and inventory. Classify the intended result, then confirm the supported target representation before choosing execution responsibility.
| Workstream | Wix example | Service-path implication |
|---|---|---|
| Supported migrated data | Products, 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. |
This distinction prevents two common errors. The first is under-scoping Wix because it is a hosted platform. The second is over-escalating every Wix site-builder or app requirement into Custom Migration when the real need is target setup or a bounded Data Filter, Advanced Data Mapping, or Data Transformation control.
When Standard Migration May Be Enough
Standard Migration may be suitable when the merchant needs supported Wix data migration with ordinary structure and can manage the preparation, execution, and validation responsibilities. It works best when products are straightforward, collections are not heavily dependent on custom navigation logic, customers and orders are standard, content is limited or supported, and Wix site setup can be handled by the merchant or the site team.
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. |
| Collections are straightforward product groupings. | Product discovery does not depend on complex category-to-page reconstruction. |
| Inventory is product-level or clear variant-level stock. | The merchant can validate stock meaning without external-system complexity. |
| 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. |
Standard Migration becomes weaker when the merchant cannot provide clear samples, does not know which Wix features will own post-launch behavior, or expects custom source functionality to transfer automatically.
When Managed Migration May Be Safer
Managed Migration may be safer when Wix scope is supported but the merchant needs expert execution of agreed Migration Actions. Product, variant, Customer, Order, URL and supported-content review can involve several teams; their interpretation and approval remain customer-side responsibilities. Expert execution does not automatically include launch coordination, Wix site building or final validation.
Managed Migration is especially useful when the project needs included expert-led execution while the merchant retains responsibility for final verification and Wix setup decisions. It can reduce operational pressure, but it does not turn unsupported records into supported records and does not replace the need to configure Wix itself.
| 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 cannot confidently manage every migration step and review task alone. |
| Demo Migration must drive decisions | Samples need coordinated interpretation before Full Migration. |
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.
When Add-ons Are the Right Fit
Add-ons are useful when the merchant needs bounded changes within supported migration behavior. They can filter records through field-based conditions for each data type, transform field values through expressions, or remap supported standard source fields to compatible supported target fields while keeping the values unchanged. They should not be used as a substitute for unsupported data migration or custom business-logic recreation.
For Wix, Add-ons are most useful when the merchant has clear, supported requirements such as excluding records that meet defined conditions, transforming supported values through expressions, or changing a supported field destination.
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.
When several Standard Add-ons are selected, processing follows Data Filter, Data Transformation, Advanced Data Mapping, then Advanced Database Mapping. Filtering selects records; transformation changes supported values; mapping routes the source value, or an already transformed value, without changing it during mapping. Combining supported Add-ons does not by itself require Custom Migration. Tax is excluded from both mapping Add-ons.
| 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. |
The best Add-on request is specific. A vague request such as “make Wix match the old store” is not enough. A useful request states the data type condition, transformation expression, or source and destination fields, together with how the result will be validated in Wix.
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.
Wix custom requirements often appear when the source store has behavior that is not stored as ordinary commerce data. Examples include product configurators, subscription or membership logic, booking or event history, custom customer fields, CRM or loyalty IDs, external inventory references, marketplace records, CMS collections, dynamic pages, custom database structures, Velo-like code, or private integrations.
| 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. |
Custom Migration should be scoped through representative examples. The merchant should provide sample records, source screenshots or exports where appropriate, target expectations, and validation rules. Without examples, custom review becomes too abstract to protect the Wix outcome.
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.
What Demo Migration Should Decide
Demo Migration can examine a limited representative sample available in the active supported path and reveal gaps in the proposed Wix approach. Add-ons and Customization are unavailable in Demo, and Reviews and Coupons are excluded. Use the contexts below to identify standard sample checks and requirements needing separate proof. Validate enhanced or tailored output through the agreed paid scope, and assign storefront, extension and live-operation checks to target implementation.
Use ordinary and difficult project examples to define the required Wix result. The limited Demo can inspect only supported standard samples available in the active path; it diagnoses the approach rather than proving every site, app or custom requirement.
| Sample area | Decision it should support |
|---|---|
| Simple product | Whether baseline Wix catalog transfer is clean. |
| Option/variant product | Whether choices, variant SKUs, prices, weights, images, and inventory behave as expected. |
| Collection/category sample | Whether source discovery meaning can become Wix collections, pages, menus, or redirects. |
| 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.
Entity Points and Wix Scope Planning
Entity Points plan eligible Wix record capacity rather than site complexity. Supported Products, Customers and Orders consume points 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 not supported target migration output and are not planned as Wix-target point consumption. CMS, member, app, Velo and Blog-continuity complexity is assessed separately.
For Wix, Entity Points should be considered alongside data meaning. A small Wix migration may require Custom Migration if it includes app-owned data, CMS collections, custom fields that cannot be handled through supported mapping, external identifiers, or Velo/API-dependent behavior. A larger migration may remain suitable for Standard Migration or Managed Migration if supported records are clear and the merchant can validate the result.
| 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.
Migration Actions and Wix Launch Timing
After a paid migration has produced an earlier result, continued Source Store activity may call for further work while the Wix site is prepared. Choose the action according to whether the recorded configuration remains valid, supported settings must change, or the earlier target result should be replaced. Select the source-record window separately: reusing a configuration does not automatically restrict processing to newly added records.
| Current action | When it fits Wix | Required revalidation |
|---|---|---|
| Continue the Migration with Last Saved Configuration | New eligible records were added and the approved filters, mapping, data type selection, and configuration remain suitable. | Check newly migrated Products, Customers, and Orders plus Wix Stores regression samples and the separate Wix 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 Wix target site or intended migrated result changed enough that the prior output should be replaced, while the purchased Source Platform-to-Target Platform path remains unchanged. A different path requires a separate purchased Migration Service. | Validate the refreshed target result across Wix Stores, content, URLs, and accepted custom or app boundaries. |
Migration Actions do not replace Wix site configuration, app setup, Velo development, CMS collection construction, dynamic-page implementation, live payment and shipping setup, or integration deployment. They should be selected with a defined launch-timing and revalidation plan.
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.
Choose the source-data window separately from the action. “Migrate only newly added entities” selects records added after the last successful run, not edits to existing records. “Continue the previous migration” applies to the appropriate previous migration state. Neither option is implied by an action name. When configuration changes, check the combined earlier and later output; a new action does not automatically erase protected target data.
Signals That the Chosen Wix Approach Is Too Light
The chosen approach is too light when it treats Wix as a simple import destination while ignoring site-commerce complexity. The warning signs usually appear in sample review, not in record counts.
| 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. |
These signals should be addressed before Full Migration because they usually become harder to resolve when launch deadlines are close.
Choosing the Practical Wix Path
The practical Wix path starts with supported data meaning and actual catalog generation. Standard Migration fits customer execution; Managed Migration includes expert execution of agreed supported actions. Add-ons handle bounded filtering, expressions and compatible field routing. Custom Migration handles requirements exceeding those capabilities, with Self-Execute or Expert Handle explicit. Assign site implementation, Wix Blog continuity and final verification separately.
A ready approach can be summarized with four statements:
- which Wix records should migrate;
- which Wix settings and site elements must be configured or rebuilt separately;
- which Add-ons or Custom Migration requirements are in scope;
- which Demo Migration samples must pass before Full Migration.
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
Selecting the right Wix migration approach requires more than estimating record volume. The approach must account for Wix Stores catalog structure, options, choices, variants, inventory, customers, contacts, members, orders, CMS Pages, Wix Blog continuity, URLs, apps, Velo/API logic, external systems, target-side setup, Entity Points, Migration Actions, and validation responsibility.
The right path separates supported Wix records from site setup, uses eligible Add-ons where sufficient and reviews true custom requirements separately. Demo supplies limited standard evidence; paid activity proves enhanced or tailored output. 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 may be enough when the merchant needs supported Wix records with ordinary structure, can manage Wix setup directly, and can validate products, collections, customers, orders, content, and URLs without extensive coordination or custom handling.
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 a paid result exists, use Continue the Migration with Last Saved Configuration when the recorded setup remains correct for the intended source-record window. Reading only newly added records is a separate choice. Use Continue the Migration with a New Configuration when supported filters, mappings, data type selections, or configuration changed. Use Perform a New Migration when the intended Wix result or target-site setup has materially changed while the purchased migration path remains fixed. If the Source Platform-to-Target Platform path must change, a separate purchased Migration Service is required.
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.