Wix brings a hosted website and commerce environment together. When evaluating it as the prospective Target Platform, plan how store records, site presentation and business apps will work together after migration.
Supported data transfer is one part of the work. Site design, live checkout, payments, shipping, domains, navigation and app workflows need their own Wix setup or implementation. The selected migration path and agreed scope determine what moves; native Wix features alone do not establish that coverage.
Understand Wix’s Hosted Site and Store Layers
Wix combines site building and commerce on hosted infrastructure. Products, catalog discovery, checkout, contacts, members, content, URLs and apps therefore need to form one usable site experience. Server operations sit with the platform; the merchant still owns the selected design, configuration and connected workflows.
Keep similarly named structures distinct:
- Catalog groupings: categories or older catalog collections organize Products under the actual site’s catalog model.
- CMS collections: site data can include custom collections and app-managed collections that expose business-app records.
Confirm the catalog generation before interpreting fields or integrations. A shared label does not establish a shared structure.
Evaluate both the supported records and the future site that consumes them. Blog Posts are not a supported migrated output to Wix in the approved workflow, so valuable source Blog content needs a separate rebuild or continuity plan. Native Wix Blog functionality does not remove that boundary.
| Wix layer | Migration significance |
|---|---|
| Hosted site foundation | Server, hosting, editor, and core site experience are managed by Wix, so source-code or server-level behavior must be translated into Wix-supported setup or custom implementation. |
| Wix Stores catalog | Products, categories or catalog collections, options, choices, variants, media, inventory, and product visibility need Wix-specific interpretation. |
| Site-builder experience | Pages, menus, sections, product pages, category or catalog-grouping pages, mobile presentation, and site design are implementation concerns, not direct data transfer assumptions. |
| Business and commerce apps | Bookings, events, restaurants, forms, pricing plans, loyalty, marketing, and other apps may own records outside ordinary store migration scope. |
| Developer and integration layer | Wix APIs, CMS data, external databases, custom code, service plugins, and connected systems may introduce fields that need alignment, integrations that need reconnection, or behavior that requires separate implementation review. |
| Site URLs and domains | Published URLs, primary domains, secondary URLs, multilingual versions, redirects, and SEO-sensitive paths need launch planning beyond record import. |
Measure the result by whether people can use and maintain the intended Wix site, alongside the completeness of the agreed records.
Translate Source Expectations
Source behavior can live in code, database tables, plugins, modules or files. In Wix, the equivalent catalog rules, checkout, templates, accounts, content, SEO and integrations need compatible platform configuration, store records, apps, CMS data or separately implemented behavior.
Translate the business purpose before choosing a target structure. Illustrative examples include:
- A source category: its purpose may involve a Wix catalog grouping, menu, gallery, filter, page or redirect decision. These are different responsibilities, not interchangeable records.
- A source account: distinguish customer history, contact or CRM use, site membership, subscriber status, consent and app-owned identity.
- A source checkout rule: assess compatible Wix setup, a service plugin, an app, separate implementation or an agreed exclusion.
| Source-store assumption | Wix planning interpretation | Early review focus |
|---|---|---|
| Products move as simple catalog records. | Wix products may depend on categories or catalog collections, options, choices, variants, media, inventory, visibility, and page display. | Product samples should include simple items, option-heavy items, inventory-sensitive items, and image-rich products. |
| Categories map directly to navigation. | Wix discovery can involve catalog groupings, pages, menus, filters, product galleries, and SEO landing paths. | Separate catalog grouping from storefront navigation and high-value URLs. |
| Historical orders prove checkout readiness. | Order history is different from live payment, shipping, tax, fulfillment, and checkout setup. | Validate historical order readability and test live Wix setup separately. |
| Customers are one record type. | Customers may intersect with contacts, members, CRM records, subscribers, app records, and consent. | Classify the future use of buyer identity before migration scope is accepted. |
| Design moves with store data. | Wix presentation depends on target-site implementation inside Wix. | Treat design parity, page layout, and mobile display as site implementation work. |
| Custom code transfers directly. | Wix is hosted, so custom behavior must be represented through supported Wix capabilities, apps, APIs, CMS data, or custom implementation. | Identify scripts, custom fields, external IDs, product configurators, and checkout logic early. |
Give each requirement a supported data representation, a Wix setup owner or a separately agreed implementation. This scope distinction prevents record transfer from becoming a promise to reproduce every source behavior.
Review Commerce in Its Site Context
Review commerce through the tasks operators and shoppers need: choosing a product, finding it, checking out, interpreting an old Order and using the correct customer identity. Fulfillment context and connected workflows need their own evidence.
Each commerce area asks a different question:
- Products: do options and variants retain their required price, SKU, weight, stock and media meaning?
- Discovery: do catalog groupings support the intended navigation under the actual site model?
- Orders: can staff interpret history independently of future checkout setup?
- Customer identity: which records serve buyer lookup, member access, CRM, consent or an app?
| Commerce area | Wix migration question | Planning implication |
|---|---|---|
| Products | Do product names, descriptions, prices, SKUs, media, visibility, options, choices, variants, and inventory make sense in Wix? | Representative test samples must include products that expose option and variant behavior. |
| Catalog grouping and discovery | Do categories or catalog collections support the intended product grouping, navigation, filters, landing paths, and customer browsing experience? | Category migration should not be approved until discovery paths are reviewed. |
| Cart and checkout | Which behavior is migrated history, and which behavior must be configured in Wix? | Payment, shipping, tax, pickup, delivery, discount, and checkout settings need target-side validation. |
| Orders | Are historical orders readable with line items, totals, shipping, payment context, fulfillment status, and customer links where supported? | Order migration should support lookup and service continuity without being confused with live checkout setup. |
| Customers, contacts, and members | Which source records should become commerce customers, CRM contacts, site members, subscribers, or app-related records? | Buyer identity should be classified before scope is accepted. |
| Apps and integrations | Which business workflows depend on apps, external systems, custom fields, or Wix development capabilities? | Unsupported or app-owned data needs explicit scope and ownership review; target configuration or rebuilding may be required separately. |
Preserve the required business meaning in an agreed Wix representation. Native feature availability and a successful sample do not establish that every field or relationship is included in the migration.
Separate Content Continuity From Site Design
A content-led store may depend on much more than Product pages. Landing and policy pages, Blog content, media, galleries, forms, menus and internal links can sustain discovery and conversion. Plan that site experience alongside the catalog.
Separate the content outcome from its delivery path:
- CMS Pages: transfer only where the selected workflow and agreed scope support them.
- Blog Posts: plan reconstruction or continuity separately; public Wix Blog APIs do not establish approved migration output to Wix.
- Site implementation: page layout, sections, animations, forms, widgets, embedded scripts and design need a compatible Wix build.
Use the URL and redirect plan to protect important landing paths and internal links alongside content.
| Site area | Wix migration concern | Practical decision |
|---|---|---|
| CMS Pages | Informational, policy, landing, and service pages may carry SEO and conversion value. | Decide which pages migrate, which are rebuilt in Wix, and which are retired. |
| Wix Blog continuity | Source Blog content may include authorship, dates, tags, categories, media, internal links, and metadata, but Blog Posts are not a supported migrated output for Wix. | Define the rebuild, content-continuity, and redirect plan separately from migration output. |
| Media | Product images, page images, galleries, downloadable files, videos, and alt text may live in different source structures. | Validate media in both catalog and page contexts. |
| Site design | Layout, templates, mobile presentation, menus, and page sections are Wix implementation concerns. | Define design expectations as target setup, not automatic data migration. |
| URLs and SEO | Product slugs, page slugs, redirects, metadata, internal links, multilingual URLs, and domains affect launch continuity. | Inventory high-value URLs before migration and revalidate before launch. |
Commerce records can be correct while the website remains unfinished. Define both data acceptance and site-readiness evidence in Wix validation priorities.
Identify App, CMS and Integration Owners
Identify dependencies by the job they perform. Illustrative groups include:
- Business apps: bookings, event registrations, restaurant orders, membership plans, forms and loyalty.
- Content and data: custom CMS collections, CRM fields, marketing tags and external database connections.
- Live behavior: custom Product displays and checkout-adjacent integrations.
A dependency can own required meaning outside ordinary store records.
Keep data handling and live implementation separate:
- Confirm eligible records and compatible fields before promising transfer. App-owned data, custom fields, external IDs and bespoke transformations need review against the actual path.
- Assign reconstruction, integration reconnection and workflow changes to the implementation owner.
- Assign platform settings and third-party app configuration to the appropriate setup owner.
The metadata and extension model explains why a stored value does not establish its working consumer.
| Dependency type | Wix planning treatment |
|---|---|
| Wix app records | Confirm whether records are supported, rebuilt in the target app, handled separately, or excluded. |
| CMS collections | Determine whether the data is commerce content, site content, custom data, or app-owned structure. |
| Velo/API behavior | Review whether custom logic affects catalog, checkout, pages, members, CRM, or integrations. |
| External databases and systems | Identify external IDs, sync direction, ownership, and post-migration reconnection requirements. |
| Service plugins | Distinguish live checkout, payment, shipping, tax, fulfillment, and custom flow requirements from migrated history. |
An API or app can provide an implementation route without making its records eligible for ordinary migration. Confirm both the data path and the component that will use the result.
Separate Data Transfer From Implementation
Separate migrated records, Wix configuration, site implementation and custom or integration work. Use Wix preparation to turn those responsibilities into source evidence and Target prerequisites.
| Workstream | Examples | How to handle it |
|---|---|---|
| Migrated records | Products, categories or catalog collections, customers, orders, Coupons, CMS Pages, images, URLs, and fields confirmed within the selected workflow and agreed scope. | Define supported scope and validate representative samples without treating Blog Posts as migrated output. |
| Wix configuration | Payments, shipping, tax, checkout settings, notifications, fulfillment, apps, domains, and site permissions. | Prepare and test directly in Wix. |
| Site implementation | Layout, menus, page design, product-page presentation, content sections, mobile display, and brand experience. | Treat as target build work, not data migration. |
| Custom or integration work | Velo logic, app-owned data, external IDs, custom fields, API workflows, and unsupported source structures. | Review field alignment, integration ownership, separate implementation work, and any accepted exclusions. |
Custom-coded, WooCommerce/WordPress, Shopify-app and content-heavy Sources can place important behavior outside standard store records. Discover the actual ownership before promising a common transfer path.
Choose the Next Planning Step
Evaluate whether the intended business can use Wix-supported Products, pages, content, media, checkout, customer management and apps with sustainable ownership. Hosted infrastructure changes technical responsibility; it does not settle every fit question.
Investigate custom-code parity, Product configurators, unusual checkout, advanced B2B, external systems and custom content architecture before commitment. Source samples and representative evidence may lead to field alignment, Wix setup, separate implementation or an agreed simplification; complexity alone does not reject the platform.
Use three questions to choose the next planning task:
| Decision question | Why it matters |
|---|---|
| Can the core business operate inside Wix-supported commerce and site structures? | This confirms whether Wix is a suitable target operating environment. |
| Which source behaviors should be migrated, rebuilt, configured, or excluded? | This prevents unsupported expectations from being treated as migration defects. |
| What must be proven before launch? | This turns the platform decision into a validation plan. |
Start with Wix fit profiles to judge the intended operating model. Where an essential requirement remains uncertain, review Wix constraints and risks before committing. Carry the agreed responsibilities into preparation and validation.
Conclusion
A Wix migration joins supported commerce data with a hosted site, content, URLs and app-owned behavior. Keep the selected catalog model and the owners of configuration, design and integrations visible throughout planning.
The result needs more than correct record counts: shoppers must find and buy Products, staff must understand useful customer and Order history, important content and URLs must remain usable, and required apps or custom work must support the agreed operation.
Common Questions
Is Wix a hosted or self-hosted Target Platform?
Wix is hosted. The merchant does not manage the server or source-code environment in the same way as a self-hosted open-source platform. Migration planning should therefore separate supported data transfer from Wix setup, apps, site implementation, and custom development choices.
Is Wix the same as a standard store platform?
Wix includes store features within a broader website-building environment. Product data, site pages, media, menus, checkout settings, apps, CMS data and URLs can all affect launch readiness, so record transfer and site implementation need separate planning.
Can product variants migrate cleanly to Wix?
Transfer depends on the selected migration workflow and agreed scope, as well as whether the source product structure can be represented through the target site’s options, choices, variants, SKUs, inventory, and pricing behavior.
Complex configurators, add-ons, bundles, or custom product logic need separate review.
Will the source store design migrate directly into Wix?
Source design assets can support a Wix-side build, but layouts, menus, mobile presentation and content sections do not transfer automatically with store records. Agree the compatible Wix implementation separately from data and asset migration.
What should be checked before committing to Wix migration?
Check product complexity, catalog grouping and navigation expectations, customer/contact/member meaning, historical order needs, checkout configuration, CMS Pages, source Blog continuity, high-value URLs, apps, custom fields, and external-system dependencies.