Wix combines website creation, commerce, CRM, CMS, marketing, and application data inside one site. That breadth makes migration meaning more important than field similarity. A source Product can become a Wix Stores Product with options, choices, variants, media, Categories, brand relationships, and inventory. A person may exist as a Contact, a site Member, a Customer connected to Orders, or a participant in another Wix business application. A source CMS record may belong in a Wix CMS collection, while a Product, Blog Post, booking, event, or app record belongs to a different Wix data owner.
Wix also has an active catalog-version boundary. A Wix site can use Catalog V1 or Catalog V3, but not both at the same time. Catalog V3 introduces universal variants, reusable Customizations, separate Inventory Items by variant and location, hierarchical Categories, brands, reusable information sections, and other catalog entities. That means the destination site’s catalog version is part of the data model, not a minor technical detail.
The core translation task is to preserve the parent-child and cross-system relationships behind the data. Product identity must remain connected to the correct variant, Category, inventory record, location, media, and external key. Contact identity must remain separate from Member access and marketing consent. Orders should preserve transaction evidence without becoming future checkout configuration. CMS collections and app data need explicit owners rather than being flattened into generic page content.
The Wix Catalog Version Is a Data-Ownership Boundary
Catalog V1 and Catalog V3 do not expose exactly the same record structure. A site uses one catalog version at a time, so data translation must follow the version active on the destination site. Catalog V3 is designed around more explicit services for Products, variants, Inventory Items, locations, Categories, brands, ribbons, information sections, and reusable Customizations.
Catalog V3 also uses universal variants: every Product has at least one variant, including a default variant for Products without visible options. In that model, price, SKU, inventory, and other sellable details can be understood at variant level even when the shopper sees a simple Product.
| Source-store assumption | Wix catalog meaning | Translation consequence |
|---|---|---|
| A Product with no options has no variant | Catalog V3 still represents a default variant | Product and sellable identity remain related even when no choice is visible. |
| Every option is descriptive Product data | Options create variants; modifiers collect customization without creating variants | Separate stock-bearing choices from buyer input and optional customization. |
| One inventory quantity belongs to the Product | Catalog V3 Inventory Items relate a variant to a location | Preserve both sellable variant and location context behind each quantity. |
| A collection equals a Category tree | Wix catalog version and Category model determine Product organization | Map source hierarchy to the destination Category relationships supported by the site. |
| Wix Store data and Wix CMS data are interchangeable | Wix Stores catalog entities and Wix CMS collection items have different owners | Use CMS only for records that genuinely belong to CMS collections or external data structures. |
A migration should therefore avoid assuming that a field map created for one Wix catalog version applies unchanged to another. External integrations also need the correct entity IDs and catalog grain. An ERP that recognizes variants cannot be connected reliably through only a parent Product ID when Catalog V3 inventory is managed per variant and location.
Products, Universal Variants, Options, Choices, and Modifiers
A Wix Product is the parent catalog record. In Catalog V3, every Product has at least one variant. Products with options can generate variants from combinations of option choices. Each variant can carry distinct SKU, price, media, and inventory meaning. Customizations distinguish options that create variants from modifiers that collect additional buyer input without changing variant or inventory identity.
This distinction is central when migrating configurable Products. A source size or color that changes SKU or stock is usually option-and-variant data. An engraving field, gift note, or optional personalization is modifier-like. A source application may combine both into one configurator, so the migration must separate the resulting sellable identity from the buyer-supplied instructions.
| Source configuration | Wix owner | Meaning that must remain intact |
|---|---|---|
| Simple Product with one SKU | Product plus default variant | Product content at parent level; sellable SKU, price, and inventory identity at variant level. |
| Size/color combinations | Options, choices, and variants | Each purchasable combination remains connected to the correct choices, SKU, price, media, and stock. |
| Engraving text or gift message | Modifier or app-owned customization output | Buyer input remains connected to the purchased line without creating false inventory variants. |
| Optional upgrade | Modifier, separate Product, or variant according to stock and price meaning | The destination owner follows whether the upgrade creates a distinct sellable item. |
| Bundle or kit | Product relationship, app-owned bundle, or external inventory structure | Components, stock authority, price formation, and resulting Order-line data remain explainable. |
| Subscription, booking, event, or service offer | Wix Stores Product or another Wix business application according to behavior | Catalog identity remains separate from recurring billing, scheduling, attendance, or entitlement. |
Catalog V3 Customizations can be reusable across Products. That creates another relationship boundary: the customization definition can be shared, while the Product assignment and resulting variant or modifier behavior remain Product-specific. Deleting or changing a shared definition can affect several Products, so source option templates should be translated as reusable entities only when they truly share the same business meaning.
Product media also needs ownership discipline. Parent Product media can describe the overall offer, while an option choice or variant image can identify a specific combination. Moving all images into one undifferentiated gallery can preserve files but lose the relationship that helps a shopper recognize the selected variant.
Categories, Brands, Info Sections, Ribbons, and Discovery
Wix catalog organization can involve hierarchical Categories, Product assignments, brands, ribbons, reusable information sections, search, site navigation, and page presentation. These records serve different purposes.
Catalog V3 Categories can form parent-child trees and support Product assignment to multiple Categories, with a main Category relationship. Brands represent manufacturer or brand identity. Info Sections provide reusable rich Product information such as specifications, size charts, care instructions, or warranty details. Ribbons provide promotional labels. Site pages and menus determine public navigation and presentation.
| Source concept | Wix destination owner | Translation consequence |
|---|---|---|
| Permanent department hierarchy | Category tree and Product Category relationships | Preserve enduring browsing and classification meaning. |
| Manufacturer or brand | Brand entity and Product association | Keep brand identity separate from Categories and descriptive specifications. |
| Technical specifications | Product fields, Info Sections, CMS data, or external PIM according to reuse and ownership | Do not turn descriptive attributes into variants unless they create sellable combinations. |
| Size chart or care guide shared by Products | Reusable Info Section | Preserve one shared content owner and Product references. |
| Sale, new, or featured badge | Ribbon or merchandising presentation | Keep promotional status separate from permanent Product classification. |
| Seasonal collection | Category, landing page, ribbon, campaign, or curated presentation according to purpose | Preserve the campaign meaning without making it a permanent Product type. |
| Menu item | Site navigation relationship pointing to a Category, Product page, CMS page, or external URL | Navigation does not become the owner of Product classification. |
The same source value may need different owners depending on use. “Organic” could be a searchable specification, a Product badge, a Category, or a certification field from an external PIM. Translation should follow the workflow that consumes the value rather than the label used in the source system.
Variant and Location Relationships Control Inventory Meaning
Catalog V3 Inventory Items represent a specific variant at a specific location. The inventory record can track quantity, availability, preorder behavior, and other stock meaning for that variant-location combination. Every store also has a default location, while additional locations can represent warehouses, branches, or fulfillment points.
A source platform may store one quantity per Product, one quantity per variant, or separate quantities by warehouse and channel. Those models are not equivalent.
| Source inventory pattern | Wix destination relationship |
|---|---|
| One Product quantity with no visible options | Default variant → intended inventory location → Inventory Item. |
| Variant-level stock | Each source sellable combination → Wix variant → Inventory Item by location. |
| Warehouse-specific stock | Source warehouse/branch → Wix location or external warehouse owner → variant-location quantity. |
| Unlimited or made-to-order availability | Variant availability and inventory-tracking meaning, not an arbitrary large quantity. |
| Preorder stock | Variant-location Inventory Item plus preorder rules where the destination supports that behavior. |
| External stock authority | Wix variant/location IDs plus ERP or warehouse key used for ongoing synchronization. |
| Marketplace allocation | Variant → channel/external listing relationship → stock owner rather than duplicate uncontrolled quantities. |
Catalog V3 Product creation and Inventory Item creation are separate operations unless a combined creation flow is used. That separation reinforces the ownership model: a Product can exist without a complete inventory record, and inventory cannot be understood without the variant and location that own it.
When an ERP or warehouse remains authoritative, the opening stock quantity is less durable than the identifiers that keep future updates aligned. A Product-level external ID is not enough if the external system stores each variant-location pair separately.
Contacts, Members, Customers, and Marketing Relationships
Wix CRM Contacts and site Members represent different relationships. A Contact is a person or organization record used across CRM, communications, Orders, and business applications. A Member is a site user with authentication and potentially profile, role, permission, or gated-content relationships. A commerce Customer can be connected to a Contact and Orders without reproducing every source account behavior.
A source Customer account may contain addresses, Order history, passwords, company roles, customer groups, tax exemptions, loyalty points, memberships, subscriptions, consent, and application-specific attributes. Those values should be assigned to the Wix entity or external system that owns their ongoing use.
| Source identity pattern | Wix relationship decision |
|---|---|
| Registered retail buyer | Contact/Customer identity connected to addresses and Orders; Member relationship only when site access is intended. |
| Guest buyer | Order-linked Contact context without inventing a Member account. |
| Newsletter-only subscriber | Contact plus communication consent/subscription relationship, not automatically a Customer or Member. |
| Site community or gated-content user | Member plus Contact relationship and any relevant role, permission, or access owner. |
| B2B company contact | Contact plus company/CRM/external account relationship; not automatically a complete organization hierarchy. |
| Loyalty participant | Contact/Customer plus the Wix or external loyalty ledger that owns points and status. |
| Duplicate source accounts | Consolidated only when email, phone, external IDs, addresses, consent, and Order ownership support one identity. |
Passwords and authentication state should not be treated as ordinary profile fields. Even when a source Customer becomes a Wix Member, login credentials, invitation state, roles, and permissions have separate security and lifecycle meaning.
Marketing consent also remains independent from purchase history. A Contact who bought once is not automatically a subscriber, and a subscriber may never have purchased. Preserving consent requires keeping the communication relationship distinct from the Contact record itself.
Orders Preserve Commerce History and Application Context
Wix eCommerce Orders manage the post-purchase lifecycle. An Order can contain purchased items, payment details, billing and shipping information, discounts, taxes, delivery or pickup data, fulfillment status, refunds, invoices, and external references. Draft Orders, billing records, transactions, invoices, and fulfillments have related but distinct owners.
The Product or variant line in a historical Order is a transaction snapshot. It should preserve what was purchased, including selected options or customizations, even if the current catalog later changes. Current payment, tax, shipping, notification, invoice, and inventory settings remain configuration for future Orders.
| Historical value | Wix Order meaning |
|---|---|
| Source Order number | External reference for Customer service and reconciliation. |
| Product/variant line | Purchased title, variant, SKU, quantity, price, and selected choices. |
| Modifier or personalization output | Buyer-provided or application-generated value connected to the correct Order line. |
| Discount, tax, and delivery charge | Explanation of the historical total, not current rule configuration. |
| Payment and refund data | Financial history linked to the Order and transaction owner. |
| Shipment, delivery, pickup, or service fulfillment | Historical fulfillment state and tracking context. |
| Invoice or accounting reference | Order/invoice relationship plus external accounting identifier. |
| Sales-channel or app reference | Order source and external application ownership. |
Wix Orders can be created by several Wix business solutions and integrations, not only Wix Stores. A migrated source record should therefore preserve which application or channel originated the transaction when that distinction affects reporting, fulfillment, or Customer service.
Historical Orders also should not create artificial current Products. An Order line for a retired Product, one-off service, or app-generated charge can remain understandable as a snapshot without adding a new Product to the active catalog.
Wix CMS Collections, Data Items, References, and External Data
Wix CMS stores data items inside collections. Data items can contain typed fields and references to other items. Wix also supports external database connections that expose outside collections through Wix data interfaces. These capabilities make CMS useful for structured content, directories, custom catalogs, resource libraries, and application data, but CMS does not replace Wix Stores, Contacts, Orders, Blog, Bookings, Events, or other specialized owners.
A source custom table should become a Wix CMS collection only when the business record genuinely belongs to a content or custom-data model. A Product that must participate in Wix Stores checkout, variants, inventory, and Orders should remain a Wix Stores Product. A Blog Post should remain Blog content if publishing behavior matters. A booking should remain connected to the booking system that owns availability and attendance.
| Source record | Wix destination owner |
|---|---|
| Product specification library | Info Sections, Product fields, CMS collection, or external PIM according to reuse and authority. |
| Editorial resource or directory | CMS collection and data items with explicit references and dynamic-page relationships. |
| Blog article | Wix Blog Post with publication, author, Category/tag, media, and URL meaning. |
| Custom Product catalog that is not directly sold | CMS or external database collection; Wix Stores only when commerce behavior is required. |
| Event, booking, course, or membership record | Relevant Wix business application plus Contact/Member and transaction relationships. |
| External database row | External collection relationship with stable IDs and reference fields. |
| Page-builder content | Site page/section presentation connected to CMS or commerce records, not the authoritative data owner. |
CMS reference fields preserve relationships between records, such as a resource linked to an author, Category, Product, or location. Flattening those relationships into copied text removes the ability to update and query the records independently.
Site Pages, URLs, Media, Multilingual Data, and SEO
Wix site content can include pages, dynamic pages, Blog Posts, CMS-driven content, media, menus, Product pages, Category pages, redirects, SEO fields, domains, and multilingual variants. These records determine how catalog and content data are presented and discovered, but they do not replace the underlying Product, CMS item, Contact, or Order.
A source page-builder layout may combine Product references, text, images, forms, and application widgets. The destination model should separate reusable content and business records from the visual section that renders them.
| Source web asset | Wix ownership relationship |
|---|---|
| Product title, description, media, URL, and SEO data | Wix Stores Product and Product-page presentation. |
| Category landing page | Category plus page/navigation relationship and any supporting content. |
| CMS Page or dynamic content page | Site page/dynamic page plus CMS collection and data-item references. |
| Blog Post | Wix Blog record with author, publication, Category/tag, media, and route meaning. |
| Menu item | Navigation relationship pointing to a page, Category, Product, dynamic page, anchor, or external URL. |
| Multilingual content | Language-specific site/content/Product fields and references, not duplicated unrelated records unless intended. |
| Source URL | Destination route plus redirect relationship where the path changes. |
| Theme or Editor component | Presentation configuration that references authoritative content or commerce entities. |
The old URL should point to a known destination record. A redirect is a relationship between routes, not a substitute for defining which Wix Product, Category, page, Blog Post, or dynamic item replaces the source asset. Internal links and media references should also retain their intended destination rather than preserving obsolete source paths.
Apps, Velo, Service Plugins, and External-System Ownership
Wix applications, Velo code, service plugins, automations, webhooks, external databases, and third-party systems can own data that is not native to the Wix Stores catalog. Reviews, subscriptions, loyalty, marketplaces, accounting, fulfillment, advanced search, Product feeds, CRM, and custom configurators may each introduce records and identifiers.
A destination application that performs a similar function is not proof that source application data maps directly. The owning entity, data schema, relationship keys, and lifecycle must be understood.
| Custom or external signal | Destination owner |
|---|---|
| ERP Product or variant ID | Product/variant plus ERP relationship at the catalog grain recognized externally. |
| Warehouse inventory key | Variant-location Inventory Item plus warehouse system. |
| CRM Contact or company ID | Contact plus external CRM/company relationship. |
| Marketplace listing ID | Product/variant/channel relationship, not a generic Product field. |
| Review, loyalty, or subscription record | Wix app or external system plus Product, Contact, Member, or Order references. |
| Custom configurator state | App/Velo/CMS owner plus Product/variant and resulting Order-line output. |
| External database record | External collection plus Wix reference fields and durable outside-system key. |
| Webhook or service-plugin setting | Destination configuration that connects systems, not a Customer or Product record. |
This ownership model avoids preserving unusable custom data. A value is durable only when teams know its parent record, authoritative system, lifecycle, and consumer. Generic custom fields are not a substitute for a defined Product-to-app, Contact-to-CRM, Order-to-marketplace, or CMS-to-external-database relationship.
Representative Wix Translation Chains
Relationship chains make the destination meaning explicit by showing the parent record, the dependent records, and the external owner where applicable. They are especially useful in Wix because commerce, CRM, Members, CMS, and applications can all hold data about the same business event. A complete chain shows which Wix entity is authoritative and which records only reference or present that data.
| Source pattern | Wix destination relationship |
|---|---|
| Apparel Product with size/color stock | Catalog version → Product → options/choices → variants → variant media/SKU → Inventory Items by location. |
| Personalized gift | Product/variant → modifier or app-owned input → Order-line customization → fulfillment reference. |
| Multi-location inventory | Variant → Wix location → Inventory Item → external warehouse key where another system remains authoritative. |
| Customer who also uses gated content | Contact/Customer → Orders and addresses; Member → authentication/role/access; consent remains a separate communication relationship. |
| CMS-driven resource linked to Products | CMS collection → data items/reference fields → Wix Stores Product IDs → dynamic page/navigation. |
| Marketplace sale | Order → source/channel reference → line-item Product/variant snapshot → transaction/fulfillment history → external marketplace ID. |
| SEO-sensitive Category | Category tree/Product membership → site page or Category route → navigation → destination URL → source redirect. |
These chains preserve Wix-specific ownership while recognizing that a source platform may have combined commerce, content, identity, and application data inside one record or table.
Conclusion
Wix data-model translation begins with the destination site’s catalog version and extends across Wix Stores, inventory locations, CRM Contacts, site Members, eCommerce Orders, CMS collections, pages, Blog content, apps, Velo, and external systems. Those record families are connected, but they are not interchangeable.
A strong Wix destination model assigns each source value to the Product, variant, customization, Category, location, Inventory Item, Contact, Member, Order, CMS item, content record, application, or external system that owns its continuing meaning. That structure preserves commerce and content relationships without confusing historical data with future configuration or collapsing specialized application data into generic fields.
Common Questions
Why does the Wix catalog version matter during migration?
A Wix site uses either Catalog V1 or Catalog V3, and the entity relationships differ. Catalog V3 uses universal variants and separate services for inventory by variant and location, Categories, brands, Customizations, information sections, and other catalog records.
Are Wix Product options and modifiers the same?
No. Options and choices create variants that can carry SKU, price, media, and inventory meaning. Modifiers collect personalization or optional input without creating a separate variant or inventory identity.
Can every Wix Contact become a site Member?
No. A Contact is a CRM and business-relationship record. A Member has authentication and potentially profile, role, permission, or gated-access meaning. A buyer can remain a Contact/Customer without receiving a Member account.
Do migrated Wix Orders configure future checkout behavior?
No. Orders preserve purchased items, choices, payment/refund history, addresses, fulfillment, invoices, and external references. Current payment, tax, shipping, notification, and inventory behavior remains separate configuration.
When should source custom data become a Wix CMS collection?
Use CMS when the data belongs to a structured content or custom-record model that benefits from fields, references, queries, and dynamic pages. Products, Orders, Contacts, Blog Posts, bookings, events, and other specialized records should remain with their native Wix owners when that behavior is required.
How should Wix app and external-system data be represented?
Keep the value with its parent Product, variant, Contact, Member, Order, CMS item, or other business record and retain the external identifier used by the owning application. A generic note or unstructured field does not preserve the relationship needed for future synchronization.