Before migrating to Wix, establish what must move, who owns it and what the destination needs to do. A Product record, a Member account and a working app each require different evidence; their presence in one site does not make them one transferable package.
Separate actual Source evidence from Wix Target prerequisites. For a Wix Source, record its real Stores, Contacts, Members, CMS and app structures. For another Source, use that platform’s own records, extraction limits and recovery evidence before choosing a Wix representation.
Build the checklist around four fields:
- Action: what must be preserved or decided.
- Owner: who can supply or approve it.
- Evidence: the original record, relationship or sample.
- Ready condition: what must be settled before execution.
Use the agreed migration scope to distinguish data handling from site implementation.
Define the Wix Site and Record Owners
Record the intended Wix site, plan, installed apps, required permissions and actual Stores catalog generation. A site uses Catalog V1 or V3; prepare the model that the selected workflow can actually handle.
The Wix constraints and risks explain why native features and API access do not establish migration coverage. Keep Source inspection evidence separate from destination configuration.
| Preparation area | Decision to record | Owner | Ready evidence |
|---|---|---|---|
| Wix Stores | Whether Products, checkout, Orders, inventory, and fulfillment are central to the destination | Commerce owner | Store operating summary |
| Wix site structure | Which pages, menus, dynamic pages, member areas, and regional routes are required | Site owner | Page and navigation map |
| Wix Contacts and Members | Which identities are Contacts, Customers, Members, subscribers, or app participants | Customer owner | Identity classification matrix |
| Wix CMS | Which custom collections, references, permissions, and dynamic pages remain necessary | Content/data owner | Collection and relationship inventory |
| Wix apps | Which records belong to Wix Blog, Bookings, Pricing Plans, Reviews, Events, or other applications | Application owners | App-by-app dependency register, with Blog Posts assigned to a separate rebuild rather than supported migrated output to Wix in the approved workflow |
| External systems | Which ERP, PIM, WMS, CRM, marketplace, tax, shipping, or analytics systems remain authoritative | Technical owner | System-of-record map |
The ownership map is ready when each required record family has a qualified Wix or external destination, an accountable owner and a feasible handling path. Mark site configuration separately from migrated data.
Secure Source Evidence and Recovery
Collect:
- administrator access to the Source Platform and the Wix site;
- required Wix Stores, Contacts, Members, CMS, application, domain, and SEO permissions, with Blog permissions for separately scoped rebuilding where relevant;
- dated exports or backups for Products, Customers, Orders, content, media, categories, URLs, reviews, and custom data;
- application exports and API documentation where available;
- external identifiers used by ERP, CRM, warehouse, marketplace, or fulfillment systems;
- a source-change owner for Products, Customers, Orders, content, and inventory during the migration window.
| Evidence item | Why it matters | Ready condition |
|---|---|---|
| Access record | Confirms the required source and Wix areas can be inspected | Permissions are available to the responsible owners |
| Dated source archive | Preserves a recoverable reference state | Files open, dates and scope are recorded, and required records/files have a verified recovery path or a readiness hold |
| Media archive | Protects Product, page, Blog Post, and CMS media | Files and source relationships can be identified |
| App inventory | Exposes records outside ordinary catalog and content exports | Every active app has an owner and evidence source |
| External-ID register | Protects synchronization and reconciliation | Each key is assigned to the correct entity level |
| Change log | Records source updates after the reference archive | Product, Order, Customer, content, and inventory changes have accountable owners |
If a Source app cannot provide an export, record the missing scope, alternative evidence, owner and readiness decision. Required evidence gaps need resolution, an approved exclusion or a hold.
Protect dated archives and credentials. Record the covered records and fields, Source environment, retrieval location and recovery owner; verify what can actually be recovered. An export that opens is useful evidence, but it does not prove full site restoration.
Before cleanup, preserve original keys for:
- Products, variants, choices and customizations.
- Contacts, Members and Orders.
- Collections, routes and external systems.
Keep original values and approved transformations traceable.
Prepare Product Choices, Variants and Media
For Catalog V3, prepare three distinct structures:
- Variants: every Product has at least one, including a default variant when no options exist.
- Options: choice combinations define sellable variants. Record actual definitions, reusable customization IDs and Product assignments.
- Modifiers: collect buyer input without creating variants or independently managed pricing or inventory.
A free gift message differs from a priced engraving choice. Qualify a compatible option, app or other agreed representation for a charged extra; do not assume a modifier can carry its price. When using the V3 API, supply the intended variants explicitly rather than assuming option definitions generate them.
Include:
- simple Products with one default variant;
- Products with several option combinations;
- variant-specific SKU, barcode, price, cost, weight, media, and stock;
- modifiers such as gift messages, personalization, or additional selections;
- digital Products and variant-level digital files where relevant;
- Products with brands, ribbons, info sections, Categories, and reusable customizations;
- bundles, subscriptions, bookings, or app-owned Product behavior;
- ERP, PIM, marketplace, supplier, and fulfillment identifiers.
| Source behavior | Preparation decision | Required evidence | Ready condition |
|---|---|---|---|
| Choice creates a sellable combination | Define option choices and variant ownership | Parent/child IDs, SKU, price, weight, media, and stock | Every combination has one intended Wix variant |
| Choice collects buyer information | Distinguish free modifier input from priced options or other qualified app handling | Input type, allowed values, price effect, and Order-line example | Input retains its Order-line meaning; any price effect has a compatible representation without inventing stock |
| Product has structured descriptive data | Define Product field, info section, brand, Category, CMS, or app owner | Field schema and continuing consumer | Each field has a named Wix or external owner, compatible representation and defined continuing consumer |
| Product behavior is app-owned | Identify the continuing app or replacement | Related Product records and configuration evidence | Required app data, selected handling path and implementation prerequisites are recorded |
| Product uses external master data | Define the system of record and key | ERP/PIM IDs and lookup examples | Each identifier remains attached to the correct variant or Product |
Prepare the selected path's Product-type and field coverage independently of the catalog model.
Wix’s native Product CSV import does not import digital Products; preserve required digital files and access relationships with another qualified owner or an approved exclusion. That native CSV boundary is not a universal limitation of every migration path.
The catalog area is ready when every major Product pattern has a defined Product–variant–option–modifier structure appropriate to the actual site version, with original prices, visibility, media, files, and application ownership documented.
Prepare Location Stock and Availability
For Catalog V3, prepare inventory by variant and location, using the actual quantity or in-stock tracking method and applicable preorder settings. The Product’s read-only inventory summary covers the default location, not the complete stock matrix.
A compatible operation may create Product and inventory data together. Product creation alone still does not prove that all required variant/location inventory records exist.
Prepare:
- the list of warehouses, stores, fulfillment centers, and virtual inventory locations;
- the default Wix inventory location;
- Product and variant identifiers used by each stock source;
- quantity, in-stock, unlimited, preorder, and unavailable examples;
- source-to-Wix location assignments;
- the future inventory system of record;
- opening quantities and the timestamp or source snapshot they represent.
| Inventory case | Owner | Evidence | Ready condition |
|---|---|---|---|
| Single-location stock | Inventory owner | Variant quantity report | Each quantity maps to one Wix variant at the default location |
| Multi-location stock | Operations owner | Variant-location matrix | Every source location has an intended Wix or external destination |
| ERP- or WMS-owned stock | Integration owner | System key and synchronization example | Wix opening values and future authority are documented |
| Preorder Product | Merchandising owner | Variant-location preorder rules | Preorder capacity and availability ownership are clear |
| In-stock tracking without quantity | Catalog owner | Representative Products and source status values | Availability states are not mistaken for numeric quantities |
Keep stock decisions separate:
- Consolidate location quantities only when the destination intentionally uses one stock pool.
- Preserve tracking and preorder meaning; never turn an in-stock flag into a guessed quantity.
- Record opening quantities, timestamps, pending obligations and future ERP/WMS authority independently.
Map Source sellable identities and locations to their intended Wix records. Cross-system identity needs a reliable mapping, not literally equal native IDs.
Prepare Identity, Consent and Access
Keep identity roles distinct:
- Contacts: CRM identity, labels, subscription status and extended fields.
- Members: member IDs, account status, profile visibility and Members Area relationships.
- Customers and app participants: commerce history and any separately owned application context.
A link between these records does not make their IDs or permissions interchangeable.
Prepare:
- registered buyers, guest buyers, subscribers, Contacts, Members, and app participants;
- duplicate email and phone examples;
- Contact labels, custom fields, subscription status, and consent evidence;
- Member status, privacy, profile, badge, and custom-field requirements;
- addresses and historical Order relationships;
- loyalty, booking, pricing-plan, community, or CRM ownership;
- external Contact, Customer, and Member identifiers.
| Identity type | Preparation owner | Required evidence | Ready condition |
|---|---|---|---|
| Buyer or guest | Customer operations | Customer and Order examples | Historical commerce context is connected to the intended Contact or Customer record |
| Contact | CRM owner | Labels, fields, subscription status, and consent source | Contact meaning is documented independently of membership |
| Site Member | Member-area owner | Member ID, Contact ID, status, profile, and access expectations | Member and Contact identities are not treated as interchangeable IDs |
| App participant | Application owner | Booking, plan, loyalty, review, or community records | The application relationship has a continuing owner |
| External CRM record | Integration owner | CRM ID and matching rule | The durable key is attached to the correct Wix identity |
Prepare authentication independently of identity:
- Qualify the exact Source-to-Wix Member access path, including verification and account status.
- Define supported password-setting, reset or activation handling, first-login expectations and Customer communications.
- Assign SSO and app-access dependencies to responsible owners.
A Contact/Member link does not transfer Source credentials or specialized plan, booking, loyalty or community rights.
Preserve Historical Order Meaning
Select historical Orders that reveal the purchased configuration and its accounting context. Use the cases below to expose item identity, adjustments, payment and fulfillment relationships.
Include:
- ordinary, canceled, refunded, and partially fulfilled Orders;
- Orders with variant Products and modifiers;
- guest and registered-Customer Orders;
- multiple shipments or fulfillment records;
- Orders from Wix-relevant applications or external channels;
- marketplace, accounting, ERP, WMS, CRM, or support references.
| Historical area | Evidence | Ready condition |
|---|---|---|
| Purchased items | Product, variant, modifier, quantity, and price examples | The purchased configuration can be explained from the source packet |
| Customer context | Guest/registered identity and addresses | The intended Contact, Customer, or Member relationship is documented |
| Payment and refund context | Method, transaction, refund, and total examples | Historical references are separated from current Wix payment setup |
| Fulfillment context | Shipping, tracking, status, and line-allocation examples | Past fulfillment can be understood without configuring live shipping |
| External lineage | Order IDs from connected systems | Reconciliation keys are retained at the correct Order level |
Preserve what happened at purchase time:
- Purchased variants, modifiers and line text.
- Prices, discounts, taxes and addresses.
- Dates, statuses and transaction references.
Prepare current checkout, payment, fulfillment, notifications and inventory updates separately. Define how historical imports avoid new payments, stock changes, fulfillment, email, automations and app/webhook events. Retained history does not authorize a new operational action.
Prepare CMS, Blog Continuity and Routes
Prepare the actual CMS contract:
- Field types, original item IDs, references and multireference targets.
- Permissions, indexes, dynamic-page routes and consuming pages or code.
- Source environment, including sandbox/live context where used.
- External database ownership and connections.
App collections follow their app-managed field and permission contracts. Some are read-only; others allow specific writes. Neither behaves as an unrestricted custom collection.
Plan Blog continuity separately. Wix has native Blog functionality, but Blog Posts are not supported migrated output to Wix in the approved workflow.
Preserve Source posts, author/date context, media, language relationships, metadata, internal links and routes for a separately scoped rebuild. Assign content and SEO owners and record the expected outcome or an approved exclusion. A migrated CMS Page does not replace Wix Blog data.
Collect:
- CMS collection schemas, fields, references, permissions, and indexes;
- representative data items and parent-child references;
- dynamic pages and the collection fields used in their routes;
- CMS Pages, Source Blog Posts for separately scoped Wix rebuilding, Product and Category content, and application-owned content;
- image, video, file, and alt-text inventories;
- high-value URLs, metadata, internal links, menus, redirects, and domain plans;
- external database ownership and connection dependencies.
| Content area | Owner | Required evidence | Ready condition |
|---|---|---|---|
| CMS collection | Data/content owner | Schema, fields, references, permissions, and sample items | Every collection has a business purpose and route or consumer |
| Wix app collection | Application owner | App name, source records, and read/write expectations | App-owned data is not treated as an ordinary custom collection |
| CMS Page or Blog Post | Editorial owner | Content, author/date context, media, metadata, and source URL | Each record has an intended Wix content owner and route; Blog Posts require a separate rebuild and are not a supported migrated output in the approved workflow |
| Dynamic page | Site owner | Collection, slug field, reference fields, and page mapping | The page can be reconstructed from documented relationships |
| Priority URL | SEO owner | Source path, destination, redirect, and retirement decision | Every high-value path has an approved outcome |
Use a URL and redirect ledger before retiring Source paths. Record:
- Original paths, language and domain context.
- Dynamic-page reference keys and intended destinations.
- Redirect constraints, approved exclusions and accountable owners.
Qualify unsupported Source patterns before execution. Copied content does not establish the resulting route or app-page behavior.
Assign App, Code and Integration Dependencies
Create a dependency register for every Wix app, source app, API, webhook, automation, Velo function, service plugin, external database, and connected business platform.
For each dependency, record:
- business purpose;
- Products, variants, Contacts, Members, Orders, CMS items, or content affected;
- authoritative system and external IDs;
- export or API availability;
- configuration and credentials owner;
- continuing destination, replacement, or retirement decision;
- source evidence needed before the destination workflow is configured.
Group priority dependencies by their business role:
- Operations: ERP, PIM, WMS, CRM, tax, shipping and marketplaces.
- Customer services: loyalty, subscriptions, bookings, events, pricing plans and memberships.
- Discovery and engagement: reviews, search, analytics and marketing.
For each retained custom field or app record, identify its parent entity, field/type contract, durable key, continuing consumer and evidence for the selected path. Keep inactive records when they explain required history.
Assign configuration and event-containment duties for live workflows. An agreed archive needs recoverable historical meaning; it does not require a live app rebuild unless that behavior is part of scope. Record Blog under its separate rebuild plan.
Choose Representative Migration Samples
| Sample | Preparation purpose |
|---|---|
| Simple Product | Establish the ordinary Product and default-variant pattern |
| Product with several options and variants | Expose option, SKU, media, price, and variant ownership |
| Product with modifiers | Expose buyer-input and Order-line relationships |
| Multi-location inventory item | Expose variant-location ownership and stock authority |
| Contact linked to a Member | Expose distinct Contact and Member IDs and profile context |
| Complex historical Order | Expose variants, modifiers, payment, refund, fulfillment, and external IDs |
| CMS collection with references | Expose schema, parent-child links, permissions, and dynamic pages |
| Priority content route | Expose CMS, media, URL and redirect ownership, plus separately rebuilt Blog continuity; Blog Posts are not a supported migrated output to Wix in the approved workflow |
| App-owned or external record | Expose the continuing application and stable parent identifiers |
For each sample, record:
- Source evidence: ID, relevant URL, original values, related files and business reason.
- Expected Wix result: catalog generation, owner, representation, external keys and approved exclusions.
- Review: responsible reviewer and the relationship to prove.
Include actual location stock alongside default-location summaries, linked Contact/Member identities and reference-dependent CMS routes where used. Blog samples describe separately rebuilt content and routes, not migrated Blog output.
Define acceptance criteria before testing; use a proof context that can exercise the selected output.
Complete the Wix Readiness Gate
| Readiness question | Required evidence | Ready condition |
|---|---|---|
| Are access and source archives recoverable? | Access record and dated exports/backups | Required records can be inspected independently of the live source |
| Is the Wix operating model defined? | Site, Stores, Contacts, Members, CMS, and app ownership map | Every required record family has an owner, qualified handling path and resolved prerequisites |
| Are Product and inventory structures prepared? | Product/variant/modifier and variant-location matrices | Every major sellable pattern has a defined representation |
| Are identity relationships prepared? | Contact/Member/Customer classification and matching rules | IDs, consent, access, and app relationships are documented |
| Are Orders and content evidence complete? | Historical Order packet and content/URL ledger | Transactions and routes can be explained from source evidence |
| Is Blog continuity separately scoped? | Source post/media/language/route inventory, rebuild owner and scope decision | Blog Posts are not supported migrated output to Wix in the approved workflow; required continuity has a separate rebuild plan or approved exclusion, with evidence and route owners |
| Are apps and external systems inventoried? | Dependency register | Every critical dependency has a qualified continuation, rebuild, archive or approved exclusion; required prerequisites are resolved |
| Are representative migration samples selected? | Sample ledger | Catalog, inventory, identity, Order, CMS, and integration complexity is covered |
| Are unresolved items controlled? | Decision log | Required gaps are resolved, excluded with approval, or held; remaining non-blocking work has an owner and due date |
Complete readiness only when required evidence is recoverable, selected handling is feasible and critical site/app prerequisites are resolved. This applies to the separately scoped Blog rebuild as well as migrated data.
Resolve a required gap, exclude it with approval or hold execution. An owner and due date control remaining nonblocking work; they do not close a critical unknown. Preparation establishes a workable plan and test criteria, not proof of an outcome that has not yet been produced.
Conclusion
A useful Wix preparation package connects actual Source evidence to a qualified destination model. Keep record handling, account access, site configuration and separate Blog continuity under explicit ownership.
Carry the agreed scope, original samples and expected relationships into Wix Validation Priorities. Representative testing can then expose structural mistakes before broader execution, while separately implemented site and Blog work retains its own evidence.
Common Questions
What should be prepared first for a Wix migration?
Start with the Wix ownership map and actual Stores catalog version. Define which records belong to Stores, Contacts, Members, CMS, Blog, other Wix apps, and external systems, then confirm destination prerequisites and source evidence coverage before preparing detailed inputs.
Assign Blog continuity to separately scoped rebuilding; the approved workflow does not deliver migrated Blog Posts to Wix.
Why must Wix Product options and modifiers be prepared separately?
For Catalog V3, options define sellable variants; modifiers collect input without variants, independently managed pricing or inventory. Prepare choice definitions, customization IDs, Product assignments and intended variants separately.
A free engraving instruction differs from a priced engraving choice, which needs a compatible option or another qualified representation. Keep buyer-entered values in their intended cart and historical Order-line context; do not create false stock-bearing SKUs.
How should multi-location inventory be prepared?
For a Catalog V3 destination, prepare a variant-location matrix showing source quantities or in-stock meaning, tracking methods, preorder rules, location IDs, timestamps, pending obligations, and future authority. A default-location Product summary is not the full matrix. Do not reduce stock to one parent-Product quantity unless consolidation is intentional.
Are Wix Contacts and Members the same record?
No. Members are typically linked to Contacts, but the Member ID and Contact ID are distinct and the records serve different account, profile, privacy, and CRM purposes.
What should be prepared for Wix CMS collections?
Document each collection’s purpose, schema and field types, item IDs, references or multireferences, permissions, indexes, samples, dynamic-page consumers, source environment, and external database owner. For app collections, prepare the actual app-managed field and read/write contract rather than assuming an unrestricted custom collection.
When is Wix preparation complete?
It is complete when access, the actual catalog version, Products, inventory, Contacts, Members, Orders, content, CMS relationships, routes, apps, external systems, and samples have accountable owners and recoverable evidence. Required gaps must be resolved, excluded with approval, or held before execution.
Required Blog continuity also needs Source evidence and a separate rebuild or approved exclusion decision; Blog Posts are not supported migrated output to Wix in the approved workflow.
Can every Wix site use the Catalog V3 preparation model?
No. A site uses Catalog V1 or V3, not both at once. Confirm the actual site version and selected workflow, then prepare the matching Product, variant, and inventory structure. V3 relationships in this checklist apply to a V3 destination rather than proving that every existing Wix Store uses that model.
Does a Product inventory summary cover every location?
No. In Catalog V3, the Product summary reflects the default location. Prepare the actual variant-location inventory records, tracking methods, preorder rules, timestamps, and stock owner for all relevant locations; the summary cannot establish the complete stock matrix.
Can the native Product CSV import digital Products?
No. Wix native Product CSV import does not import digital Products. Preserve required digital files and access relationships, then record a qualified path and owner or an approved exclusion. This native CSV limit does not establish the capability of every migration workflow.
How should Blog Posts be prepared when migrating to Wix?
Blog Posts are not a supported migrated output to Wix in the approved workflow. Wix has native Blog functionality and APIs, but those capabilities do not establish migration support.
Preserve priority Source posts, author and publication context, media, language relationships, metadata, internal links and routes for a separately scoped rebuild and continuity plan. Assign content and SEO owners and record the expected rebuilt outcome or an approved exclusion. A migrated Product or CMS Page is not a substitute for Wix Blog data; later validation must assess the separately rebuilt content and routes.