Wix Pre-Migration Preparation Checklist

A Wix site can combine Stores, Contacts, Members, CMS collections, content, and application records. Preparation must establish the actual catalog version and record owner before Product data, account identity, inventory, and site behavior are treated as one migration package.

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. Native Wix Blog functionality does not establish migration coverage: Blog Posts are not a supported migrated output to Wix in the approved workflow. Preserve their Source evidence for a separately scoped rebuild and continuity plan.

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. Record the intended site, plan, installed applications, required permissions, and actual Stores catalog version. Each site uses Catalog V1 or V3 rather than both at once; confirm that the selected workflow matches that site before using the V3 model in this checklist. Collect actual Source Store evidence separately from destination prerequisites and app configuration.

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, 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.

When a source application cannot provide an export, record the affected scope, evidence alternative, owner, and readiness decision. Protect dated archives and credentials and record covered records, fields, source environment, and recovery owner. Freeze original Product, variant, choice, customization, Contact, Member, Order, collection, route, and external keys before approved cleanup; keep original values and transformation decisions traceable.

Prepare Products, Options, Variants, Modifiers, and Media

For a Catalog V3 destination, every Product has at least one variant, including a default variant when no options exist. Options define the dimensions of sellable combinations; modifiers collect additional information without creating variants. Prepare actual choice definitions, reusable customization identities, Product assignments, and intended sellable combinations. The V3 API requires those variants to be supplied explicitly rather than assuming that option definitions automatically 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.

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 Inventory Locations and Availability Rules

For a Catalog V3 site, inventory is tracked at the variant-location level. Each inventory item connects one variant to one inventory location and uses quantity or in-stock tracking, with preorder settings where applicable. A Product's read-only inventory summary reflects the default location and is not complete multi-location stock evidence. Product creation alone also does not prove that inventory items exist; prepare the actual variant/location records and chosen workflow coverage.

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.

Do not sum location-specific stock unless the destination intentionally uses one consolidated stock pool. Preserve the source tracking method and availability/preorder meaning rather than converting an in-stock flag to a guessed quantity. Opening quantities, timestamps, pending obligations, and future ERP/WMS authority need separate evidence. The ready condition is a controlled relationship from source sellable identity and location to the intended inventory item for the actual site version.

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.

Authentication should be prepared separately from identity. Confirm the exact Source-to-Wix Member access path, including verification, account status, supported password-setting, reset or activation handling, first-login expectations, and Customer communications. Name the responsible owner for SSO and app-access dependencies. A Contact or Member ID link does not by itself transfer source credentials or specialized plan, booking, loyalty, or community rights.

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 Orders preserve past commerce, including original purchased variants, modifiers, line text, prices, discounts, taxes, addresses, dates, statuses, and transaction references. Current Wix checkout, payment, fulfillment, notification, and inventory-update settings remain separate preparation. Record how historical imports will avoid new payment, stock, fulfillment, email, automation, or app/webhook actions; retaining a past Order does not authorize a new operational event.

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. Record actual field types, reference or multireference targets, original item IDs, route consumers, and the source environment, including sandbox/live context where used. App collections mirror application-owned records and have their own field and permission contracts; some are read-only, while some allow specific writes. Do not treat an app collection as an unrestricted custom collection.

Blog continuity needs a separate preparation decision. Wix has native Blog functionality, but Blog Posts are not a supported migrated output to Wix in the approved workflow. Where the editorial content must continue, preserve its Source body, author and publication context, media, language relationships, metadata, internal links and routes for a separately scoped rebuild. Assign that outcome and its URL decisions to content and SEO owners; a migrated CMS Page is not a substitute for 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.

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. Preserve original paths, language and domain context, dynamic-page reference keys, intended destinations, approved exclusions, and owners; copied content does not establish the resulting route or app-page behavior.

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, field/type contract, continuing consumer, durable key, and evidence of the selected data path. Keep inactive application records when they explain important history, and name the configuration and event-containment owners for continuing workflows. Record Blog continuity under its separate rebuild scope; native app access does not establish approved migrated Blog output to Wix.

Select Representative Migration Test Samples

For every sample, record the source ID, source URL where relevant, business reason, original values and related files, intended Wix version, owner and representation, approved exclusions, external keys, and responsible reviewer. Include default-location summary versus actual location stock, linked Contact/Member identities, and reference-dependent CMS routes where used. The packet states expected relationships before the representative migration test begins. Mark Blog samples as Source evidence for separately planned rebuilding, with their own content and route expectations, rather than expected migrated Blog output to Wix.

Complete the Wix Readiness Gate

The gate is complete when no critical Product, inventory, Contact, Member, Order, CMS, Blog rebuild, URL, app, or external-system decision depends on an undocumented assumption. Resolve required evidence and site-version or app prerequisites, exclude them with approval, or hold readiness; an owner and due date alone do not close them.

Conclusion

Wix preparation should produce a site-and-commerce evidence package with the actual catalog version recorded and separate owners for Stores, Contacts, Members, CMS, Blog, applications, and external systems. For a V3 destination, connect Products to their real variants and modifiers and inventory to its variant/location records. Preserve distinct identity roles and the actual field and consumer contracts for CMS and app data. Keep Blog continuity in its separate rebuild scope; native Blog functionality and API access do not establish approved migrated Blog output to Wix.

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. Carry the Source sample expectations, agreed migration scope and separately planned Blog outcomes into Wix Validation Priorities.

Common Questions