Wix preparation should separate commerce records, site content, member identity, CRM data, CMS collections, applications, and custom code before any migration run begins. Wix Stores, Wix Contacts, Wix Members, Wix CMS, Wix Blog, and the broader Wix application ecosystem can all participate in one site, but they do not own the same records.
A useful preparation package records four things for every major area: the required action, the accountable owner, the evidence to provide, and the ready condition. This prevents a Product record from being mistaken for a complete storefront implementation, a Contact from being treated as a Member, or a CMS collection from being assumed to represent app-owned data.
Confirm the Wix Site and Commerce Operating Model
Define which Wix products and site layers will operate in the Target Store.
| 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 |
| External systems | Which ERP, PIM, WMS, CRM, marketplace, tax, shipping, or analytics systems remain authoritative | Technical owner | System-of-record map |
The operating model is ready when every major record family has one intended Wix or external owner and the site team understands which requirements belong to migration data versus Wix site configuration.
Prepare Access, Source Archives, and Change Ownership
Collect:
- administrator access to the Source Platform and the Wix site;
- required Wix Stores, Contacts, Members, CMS, Blog, application, domain, and SEO permissions;
- 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 correctly and include export dates |
| 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 |
When a source application cannot provide an export, record the limitation and responsible owner rather than treating the data as absent.
Prepare Products, Options, Variants, Modifiers, and Media
Wix Catalog V3 represents every Product through at least one variant. Product options create variants, while modifiers collect additional information without creating variants. Prepare representative Product families that expose these differences.
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 | Define modifier or app ownership | Input type, allowed values, price effect, and Order-line example | The value is not misclassified as inventory-bearing |
| 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 |
| Product behavior is app-owned | Identify the continuing app or replacement | Related Product records and configuration evidence | Required app data is included in the dependency register |
| 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 |
The catalog area is ready when every major Product pattern has a defined Product–variant–option–modifier structure and the source evidence distinguishes reusable Product data from buyer-entered or application-owned records.
Prepare Inventory Locations and Availability Rules
Wix Catalog V3 inventory is tracked at the variant-location level. Each inventory item connects one variant to one inventory location and can use quantity or in-stock tracking, with preorder settings where applicable.
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 |
Do not sum location-specific stock unless the destination intentionally uses one consolidated stock pool. The ready condition is a controlled mapping from source sellable identity and location to the intended Wix inventory item.
Prepare Contacts, Members, Customers, and Marketing Context
Wix Contacts and Wix Members are connected but distinct. Contacts can hold identity, labels, subscription status, and extended fields. Members have member IDs, account status, profile visibility, and Members Area relationships. Commerce Customers and app participants can add further context.
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 |
Authentication should be prepared separately from identity. If source passwords cannot be reused, record the accountable owner and Customer communication requirement without treating password portability as ordinary Customer data.
Prepare Historical Orders and Transaction Context
Select Orders that expose Product and variant identity, modifiers, discounts, taxes, billing, shipping, payment, transactions, fulfillment, refunds, and external references.
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 |
Historical Orders preserve past commerce. Current Wix checkout, payment, fulfillment, notification, and inventory-update settings remain separate preparation owned by the responsible site and operations teams.
Prepare CMS Collections, Pages, Blog Posts, Media, and URLs
Wix CMS can contain custom collections, data items, reference fields, permissions, indexes, dynamic-page relationships, and external database connections. Wix app collections can mirror data owned by Wix applications. Prepare these layers separately.
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, Wix Blog Posts, 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 |
| 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 |
Wix URL redirects have platform-specific constraints, so unsupported source patterns should be identified in the route ledger before the migration run rather than discovered after source paths have been retired.
Inventory Apps, Velo Logic, APIs, and External Systems
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.
Priority dependencies include ERP, PIM, WMS, CRM, tax, shipping, marketplace, loyalty, subscriptions, bookings, events, pricing plans, memberships, reviews, search, analytics, and marketing platforms.
The register is ready when each active custom field or application record has a named owner, parent entity, continuing consumer, and durable key.
Select Representative Migration Test 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, Blog, media, URL, and redirect ownership |
| App-owned or external record | Expose the continuing application and stable parent identifiers |
For every sample, record the source ID, source URL where relevant, business reason, intended Wix owner, known exclusions, external keys, and responsible reviewer.
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 major record family has one intended owner |
| 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 |
| Are apps and external systems inventoried? | Dependency register | Every critical dependency has a continuing owner |
| Are representative migration samples selected? | Sample ledger | Catalog, inventory, identity, Order, CMS, and integration complexity is covered |
| Are unresolved items controlled? | Decision log | Every open item has an owner and due date |
The gate is complete when no critical Product, inventory, Contact, Member, Order, CMS, URL, app, or external-system decision depends on an undocumented assumption.
Conclusion
Wix preparation should produce a site-and-commerce evidence package that separates Wix Stores, Contacts, Members, CMS, Blog, applications, and external systems. Products must be connected to their real variants and modifiers, inventory must be assigned by variant and location, identity records must retain their distinct roles, and CMS or app data must have named owners.
When those decisions are documented before the representative migration test, the sample set can expose the intended Wix architecture without turning site design, account access, or live configuration into migration-data assumptions.
Common Questions
What should be prepared first for a Wix migration?
Start with the Wix ownership map. Define which records belong to Wix Stores, Contacts, Members, CMS, Blog, other Wix apps, and external systems before preparing detailed exports.
Why must Wix Product options and modifiers be prepared separately?
Options create variants, while modifiers collect additional information without creating variants. Combining them can produce false SKUs or remove buyer-entered values from historical Order lines.
How should multi-location inventory be prepared?
Prepare a variant-location matrix showing source quantities, tracking methods, preorder rules, location IDs, and the future system of record. Do not reduce the data 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, fields, references, permissions, indexes, representative items, dynamic pages, external database connections, and continuing owner.
When is Wix preparation complete?
It is complete when access, Products, inventory locations, Contacts, Members, Orders, content, CMS collections, routes, apps, external systems, samples, and unresolved decisions all have accountable owners and recoverable evidence.