Wix migration risk begins when records appear complete but the site, apps or connected systems cannot use them correctly. A source database, theme, checkout script or app record does not become equivalent Wix Stores data merely because a connection succeeds.
Confirm the actual catalog generation. Catalog V1 and V3 are not backwards compatible; V3 makes variant, customization and location-inventory relationships explicit. Orders, Contacts, Members, CMS collections and apps still have separate responsibilities. A successful connection establishes access, not model compatibility or a complete business operation.
For each essential requirement, identify the wrong assumption, its business consequence, the accountable owner and evidence that the agreed outcome works. Native Wix features do not establish migration coverage; qualify the selected path and separate implementation scope.
Separate Site, Commerce and App Ownership
Choose the Wix business resource, CMS model or external system that actually owns the required record. Code, service plugins and site design may consume that data without becoming its storage destination.
Illustrative example: copying an appointment into Contact fields may preserve its text while losing the scheduling workflow. The app and business owners need a supported record treatment and a working consumer before that outcome can be accepted.
| Source assumption | Wix constraint | Migration consequence | Operational impact | Mitigation cue | Control signal |
|---|---|---|---|---|---|
| Source tables can be reproduced directly. | Wix uses defined business resources, CMS schemas, applications, and APIs. | Custom records are flattened into fields or placed in the wrong domain. | Staff lose workflow state, reporting context, or external links. | Classify every nonstandard entity by owner and lifecycle before mapping. | Each required record has one supported Wix or external owner. |
| Theme and page-builder data migrate with records. | Wix site pages, sections, dynamic pages, templates, and mobile presentation are target implementation. | Content exists without the layout or interactions that made it usable. | Important journeys appear incomplete even when commerce data is present. | Separate durable content and references from presentation implementation. | Each required page has accountable owners and demonstrated content, route and behavior outcomes. |
| Checkout scripts are ordinary Order fields. | Live checkout behavior depends on Wix settings, extensions, service plugins, apps, and supported code paths. | Fees, approval rules, custom inputs, or provider behavior disappear. | New Orders cannot follow required business rules. | Represent historical data separately and assign future behavior to a continuing owner. | The required rule has an accountable Wix or external owner and demonstrated behavior in its agreed implementation. |
| App records are part of Wix Stores core. | Bookings, Events, Restaurants, Pricing Plans, loyalty, subscriptions, and other apps own separate entities. | Specialized records are flattened into Contacts, Products, or Order notes. | Schedules, entitlements, balances, or participant history become unusable. | Preserve parent references and move the specialized record to its actual domain. | The continuing application recognizes the intended Contact, Product, and transaction. |
Resolve the owner and required consumer before mapping fields. Otherwise, a complete import can leave the business without the workflow those fields were meant to support.
Confirm Catalog Generation and Product Lineage
First identify the actual destination catalog generation. The following universal-variant and location-inventory relationships describe Catalog V3; a V1 site needs its own compatible mapping and event consumers. A future platform transition is not evidence that a selected destination already uses V3.
Catalog V3 separates responsibilities that a source model may combine:
- Every Product has at least one variant, including Products without options.
- Options create variants; modifiers collect input without independently managed price or stock.
- Inventory Items represent stock or availability for the relevant variant and location.
Product and inventory handling can be combined by a compatible operation or handled separately. Confirm the actual relationships rather than assuming record creation completed them.
A legacy Product-level identifier may not identify the V3 variant used for selling or stock. If a continuing connector targets the wrong level, visible Products can coexist with missed updates or duplicates. Catalog and integration owners need a lineage map from each source sellable item to its agreed Wix representation.
| Assumption | Catalog constraint | Migration consequence | Operational impact | Mitigation direction | Control signal |
|---|---|---|---|---|---|
| A Product without options has no variant. | Catalog V3 uses a default universal variant. | Product-level identifiers and stock are mapped inconsistently with variant-based systems. | Inventory and integration updates cannot locate the intended sellable unit. | Define one target variant identity for every Product, including simple Products. | Every Product has a stable sellable variant recognized by integrations. |
| Catalog V1 and V3 records are interchangeable. | V3 changes Product, variant, customization, inventory, and related service boundaries. | IDs or relationships are reused under the wrong model. | Catalog synchronization creates duplicates or misses variant changes. | Record source lineage, the actual destination catalog generation, and its compatible entity map. | Each source Product and variant resolves once in the target catalog. |
| Product creation automatically creates all inventory relationships. | Product and Inventory Item creation can be separate operations. | Products exist without the intended tracked inventory records. | Items appear sellable but do not follow location-aware stock behavior. | Treat Product/variant identity and Inventory Items as connected but separate records. | Every tracked variant has the intended location inventory relationship. |
| Legacy app Product data is native Catalog data. | Apps can extend or reference Products through their own entities. | App-owned behavior is copied as unexplained Product fields. | Staff see values that no Wix workflow maintains. | Keep application entities and catalog Products distinct while preserving keys. | The application can resolve the Product or variant it extends. |
Bind the lineage map to source evidence and the actual destination generation. Carry it into Wix preparation, then prove that continuing systems resolve the intended Product or variant.
Distinguish Options, Modifiers and Paid Extras
Classify source inputs by what they change:
- Selling identity: size or color may require a separately managed SKU, price or stock position.
- Free personalization: engraving text or an instruction may need capture without a new stock-bearing choice.
- Paid or dependent extras: packaging, service upgrades or warranties need a compatible pricing and fulfillment approach; specifications may be descriptive rather than selectable.
Native guidance lists 6 options per Product, 100 choices per option and 1,000 variants per Product. Its 50,000-Product guidance concerns Dashboard or CSV creation. Recheck the actual catalog/editor limits; these figures do not establish migration coverage, API request capacity or model compatibility.
| Source pattern | Wix constraint | Migration consequence | Operational impact | Mitigation cue | Control signal |
|---|---|---|---|---|---|
| Size or color is treated as descriptive metadata. | Sellable choices should form variants when they own SKU, price, or stock. | The Product displays the value but cannot manage the purchased combination. | Inventory and fulfillment use the wrong item. | Preserve the option-choice-variant relationship. | The selected option resolves to the intended variant and Inventory Item. |
| Free personalization becomes an inventory-bearing option. | Native modifiers capture input without varied pricing or independent inventory. | Unnecessary variants proliferate for input that does not need distinct selling identity. | Product administration and stock become unmanageable. | Use modifiers where separate pricing and inventory are unnecessary; qualify paid personalization separately. | Customer input appears on the transaction without creating a variant. |
| Paid extras become variants automatically. | Some extras change price without owning stock; native modifiers do not provide that varied pricing. | Unnecessary variant relationships can fragment reporting or stock authority. | Staff cannot distinguish the base Product from an optional service. | Choose compatible option/variant pricing, a qualified app or bundle, or an external workflow; do not assign a separate price to a native modifier. | Order details show the extra while base inventory remains coherent. |
| Bundle components are stored as Product text. | Component stock and fulfillment require a separate relationship. | The offer is visible but component availability cannot be calculated. | Overselling and picking errors occur. | Assign component logic to a compatible app or external system. | The system responsible for stock can identify every component. |
| Specifications become variant dimensions. | Info Sections, brands, Categories, and other catalog fields can describe Products without creating combinations. | Variant count expands and shoppers encounter irrelevant choices. | Catalog maintenance becomes complex and error-prone. | Keep nonselectable information outside option dimensions. | Specifications remain reusable or descriptive without changing variant identity. |
Continuing V3 synchronization has two related risks:
- Updating an array of options, modifiers or variants can replace the whole array. Sending one changed choice can remove other choices; option and variant updates must stay aligned.
- A stale Product revision can conflict with the current record. Preserve existing variant identities where the intended operation updates them.
Catalog and integration owners need one coherent update contract. This array rule does not mean that every omitted top-level Product field is replaced.
The risk is controlled when every shopper input has a clear effect on sellable identity, inventory, price, fulfillment, or historical Order context.
Protect Variant and Location Stock
For a V3 destination, connect stock to the correct variant and location. A quantity copied at the wrong level can appear plausible while availability or fulfillment uses a different stock pool.
The inventory and integration owners must qualify the site’s generation, location model and authoritative stock source. A V1 integration or another Wix application needs its own compatible representation.
| Assumption | Inventory constraint | Migration consequence | Operational impact | Mitigation direction | Control signal |
|---|---|---|---|---|---|
| One source quantity can be copied to the Product. | Inventory belongs to variant-location relationships. | The count is detached from the sellable unit and fulfillment location. | Customers see inaccurate availability and staff fulfill from the wrong stock pool. | Map each source stock owner to a target variant and location. | Location totals and variant totals match the declared operating model. |
| All Products should have tracked stock. | Services, digital goods, unlimited items, and externally controlled availability may use different rules. | Non-stock offers become unavailable or misleading quantities appear. | Valid sales are blocked or unsupported Products remain exposed. | Classify tracked, unlimited, preorder, and external-stock cases separately. | Each inventory class produces the intended selling behavior. |
| Product creation proves inventory completeness. | Inventory Items may need separate creation and ownership. | Products exist with missing stock records. | Staff assume stock was migrated because the catalog is visible. | Include Inventory Item relationships in the catalog model. | Every tracked variant has an identifiable Inventory Item at the intended location. |
| A snapshot is sufficient for an ERP-managed catalog. | External systems continue publishing stock after migration. | Opening counts are correct but later updates fail or attach incorrectly. | Channel inventory drifts rapidly. | Preserve Product, variant, location, and external-system keys. | A continuing update reaches the intended variant-location record. |
| Historical Orders should replay stock changes. | Historical transactions and opening inventory have separate responsibilities. | Quantity is decremented a second time. | The Store starts with incorrect available stock. | Establish opening inventory independently from imported Order history. | Historical Orders do not change the approved opening stock position. |
Use stable cross-system mappings for variants and locations. External systems do not need identical native IDs, but their opening and continuing updates must reach the intended Wix stock record.
Keep Contact, Member and App Identity Distinct
A Contact, Member and app participant can describe overlapping relationships without being interchangeable. A buyer, form submitter or subscriber may need CRM identity; a booking, event, pricing plan or loyalty relationship may need its own live records.
Collapsing those layers can mislink history or grant the wrong access. Customer operations and app owners must define intended identity, permissions, consent meaning and continuing participation separately.
| Source assumption | Wix constraint | Migration consequence | Operational impact | Mitigation cue | Control signal |
|---|---|---|---|---|---|
| Every Customer should become a Member. | Contact identity and Member access are separate relationships. | Guest buyers gain unsupported login expectations or member-only access is lost. | Account support and protected content become inconsistent. | Preserve buyer history and Member entitlement separately. | Only intended users receive Member access, and Orders remain linked to the correct Contact. |
| Email alone proves one person. | Source duplicates, shared emails, changed addresses, and external IDs can represent distinct histories. | Contacts merge incorrectly or one person becomes several records. | Marketing, support, and Order history become unreliable. | Use source IDs, Order links, email, phone, and external keys in a documented identity hierarchy. | High-value and ambiguous people resolve to the intended Contact. |
| Subscriber consent is ordinary Contact data. | Communication permission has purpose and provenance separate from identity. | Imported Contacts may be treated as marketable without a valid relationship. | Compliance and targeting are weakened. | Preserve only supported preference information with clear meaning. | Marketing workflows distinguish identity from communication permission. |
| App participants belong in Contact custom fields. | Bookings, Events, Pricing Plans, loyalty, and other apps own specialized records. | Schedule, entitlement, progress, or balance data is flattened. | Customer service cannot understand the active relationship. | Keep the Contact link and migrate or archive the specialized entity under its actual owner. | Required live participation is recognized by the app; an agreed archive retains traceability under its separate continuity contract. |
| External CRM IDs can be replaced. | CRM and support systems may treat the existing key as authoritative. | Updates create duplicate Contacts or attach to the wrong record. | Segmentation and support history split. | Preserve durable external identifiers at the Contact or organization grain used by the CRM. | A CRM lookup returns the intended Wix Contact. |
Keep buyer history, CRM identity, Member access, app participation and external-account links connected at their intended levels. A permission or marketing preference needs its own retained meaning, not an inference from Contact presence.
Keep Order History Separate From Live Operations
Order history records what was bought, paid and fulfilled. If one source status replaces all of that meaning, service and finance teams can lose the distinction between a completed sale, an outstanding payment and an unresolved shipment.
Treat Orders, billing, transactions, invoices, payment requests, fulfillments and current settings as related but separate domains. Preserve the agreed historical evidence without letting an import replay live payment, inventory or fulfillment effects.
| Risk chain | Migration consequence | Operational impact | Mitigation direction | Control signal |
|---|---|---|---|---|
| One source status is copied as the complete Order state. | Payment, fulfillment, cancellation, invoice, and refund meaning are compressed. | Staff cannot tell whether money or goods are still outstanding. | Preserve readable historical state across the relevant Order relationships. | Complex Orders can be understood without source-system access. |
| Order lines link only to parent Products. | The purchased variant, modifier, or app-owned configuration is lost. | Support and fulfillment cannot identify what was bought. | Preserve line snapshots and reliable Product/variant/customization references. | The line item shows the intended sellable identity and buyer input. |
| Historical payment data is treated as live authority. | Payment details and Transactions document the past; current providers and settings are separate. | Teams expect old credentials or tokens to process new commerce. | Retain safe transaction references and configure current payment behavior independently. | Historical payments are traceable without exposing or misusing credentials. |
| Shipping labels recreate current fulfillment. | Fulfillments, delivery settings, carriers, and locations have separate current ownership. | New Orders follow incomplete routes. | Preserve historical shipment evidence and define live fulfillment separately. | Historical and active fulfillment responsibilities are distinguishable. |
| Imported Orders trigger current inventory updates. | Order history and opening Inventory Items have different purposes. | Stock is decremented again or synchronized incorrectly. | Keep historical Order import isolated from opening-stock authority. | Inventory remains stable after historical records are introduced. |
Customer service, finance, operations and integration teams should agree which historical evidence must remain readable and which settings govern new activity. A valid archive can support agreed history; it cannot establish a required live process.
Protect CMS References and Shared Fields
CMS items can support structured content, directories, resources, dynamic pages and custom application workflows, including connections to external data. Moving rows without their schema, references, permissions and consumers can leave pages unable to resolve the intended records.
The content/data owner and technical owner need one model for storage and use. A native collection is not proof that custom source tables are supported migration output.
| Source assumption | CMS constraint | Migration consequence | Operational impact | Mitigation direction | Control signal |
|---|---|---|---|---|---|
| A source table can become one CMS collection automatically. | Collection fields, item schemas, permissions, references, indexes, and consuming pages or code are separate. | Rows transfer while required relationships or management behavior disappear. | Dynamic pages show incomplete data or fail to resolve linked records. | Define collection schema, reference fields, permissions, and consumers as one model. | Representative items resolve every required reference and page relationship. |
| Numeric source IDs can be copied as references. | CMS references must point to destination data-item identities. | Old IDs become meaningless literal values. | Related records and dynamic pages disconnect. | Translate source relationships to destination reference fields. | Each parent-child or many-to-many relationship resolves in Wix CMS. |
| Updating an item preserves unspecified values. | The Data API’s full-item update replaces content; a supported partial patch has different semantics. | Partial synchronization deletes data unexpectedly. | External systems erase fields they do not own. | Define field ownership and safe update behavior for continuing integrations. | Updates change only fields owned by the publishing system. |
| CMS data immediately reflects every write everywhere. | Data retrieval can be eventually consistent in relevant workflows. | Automations or front-end reads act on stale state. | Duplicate actions or temporary inconsistency appears. | Design integrations to tolerate propagation and use authoritative event/state handling. | Time-sensitive workflows do not rely on immediate read-after-write assumptions. |
| CMS can replace Product, Order, or app domains. | CMS is flexible storage but does not reproduce Wix Stores or application behavior. | Core commerce or participant records are duplicated into an unmanaged shadow model. | Staff maintain conflicting sources of truth. | Use CMS only when it is the actual target owner, not as a generic overflow table. | Each entity has one declared system of record. |
Define the actual write contract:
- Full-item replacement: omitted values can be lost; preserve fields maintained by other owners.
- Supported partial patch: only the intended fields change under that operation’s contract.
- Read-after-write: relevant CMS reads can lag behind a successful write; use an appropriate fresh-state check rather than issuing a duplicate action from stale evidence.
Agree field ownership, permissions and update behavior before synchronization resumes.
CMS risk is controlled when the schema, references, permissions, routes, and code that consume the data are treated as one dependency chain.
Plan Separate Blog Continuity
For migrations into Wix, Blog Posts are not a supported migrated output. Public Wix Blog APIs describe Wix platform capabilities, but they do not establish migration support and must not be used to infer that Blog Posts can be migrated to Wix.
Give the content owner a separate Blog continuity record:
- Which source content, authorship, dates, categories or tags, media, links and embedded commerce references must remain useful.
- Which material will be rebuilt or otherwise preserved, which routes need redirects and what can be retired.
Product connectivity does not change the approved Blog migration boundary.
Preserve Routes, Content and Language Context
Routes connect content with the people who use it. Static and dynamic pages, catalog routes, Blog content, menus, media, forms, languages, domains, metadata and redirects can have different owners.
If a Product arrives but its priority menu or old landing path does not reach it, record presence has not preserved discovery. Assign the site and SEO owners an agreed destination and a working route; design reconstruction and Blog continuity remain separate work.
| Source dependency | Wix constraint | Migration consequence | Operational impact | Mitigation cue | Control signal |
|---|---|---|---|---|---|
| Product or Category records recreate navigation. | Wix Categories, menus, pages, and dynamic routes are related but separate. | Catalog records exist without the intended browse path. | Shoppers cannot find high-value Products. | Assign navigation and landing ownership independently from Category membership. | Priority buyer paths reach the intended Product or Category destination. |
| Source URLs can remain unchanged automatically. | Routes depend on Wix page, catalog, multilingual, and domain structures. | High-value paths change without continuity. | Search traffic, backlinks, and bookmarks fail. | Define canonical destinations and redirect relationships for priority URLs. | Priority old paths resolve to usable target resources. |
| Page-builder data is portable content. | Wix sections, components, dynamic pages, apps, and code define presentation. | Text transfers but forms, queries, interactions, and layout relationships disappear. | Content and conversion journeys become incomplete. | Separate durable content and media from target presentation and behavior. | Each required page has accountable owners and working content, routes and interactions. |
| Language is one field on the source record. | Multilingual content can require coordinated routes, pages, CMS items, menus, and catalog values. | Translations exist but are not connected to the intended language experience. | Users see wrong-language or duplicate content. | Preserve translation identity and route context across the relevant owners. | Language paths and associated content are coherent for priority journeys. |
| Media transfer preserves embedded references. | Content, Product media, CMS items, and applications can reference assets differently. | Files exist while pages or Products point to old paths. | Broken images and downloads undermine trust. | Translate attachment and embedded-link relationships with the owning record. | Representative routes render intended assets without unintended reliance on a retiring Source; deliberately retained external assets need confirmed continuity. |
Use the URL and redirect plan to preserve relevant destinations, not only URL counts. Required buyer and content journeys need working evidence.
Rebuild App and Integration Contracts
Apps, Velo, service plugins, webhooks and external systems can own different jobs:
- Selling and access rules, such as pricing, input checks and membership behavior.
- Data queries and synchronization for CMS, Products or inventory.
- Fulfillment and other continuing operational actions.
A copied field cannot execute the missing rule. Developers, app administrators and business owners must agree both record ownership and the component that consumes the result.
| Dependency assumption | Wix constraint | Migration consequence | Operational impact | Mitigation direction | Control signal |
|---|---|---|---|---|---|
| Similar apps have compatible records. | Each app defines its own entities, permissions, identifiers, and lifecycle. | Data is moved into generic fields without a working application owner. | Balances, schedules, memberships, or history disappear. | Map the actual source entity to the intended Wix app or external owner. | The continuing application recognizes its parent Contact, Product, or Order. |
| Velo code can be copied as data. | Code depends on Wix APIs, CMS schemas, events, permissions, and secrets. | Scripts arrive without valid dependencies or target ownership. | Business rules fail silently or produce inconsistent data. | Recreate only the necessary behavior against the target schema and supported APIs. | The behavior has a named owner, demonstrated required outputs and no unexplained Source dependency. |
| External IDs can be regenerated. | ERP, CRM, PIM, WMS, marketplace, and accounting systems may use stable keys. | Synchronization attaches to duplicates or wrong records. | Stock, Customer, and Order operations diverge. | Preserve identifiers at the same entity grain used by the authoritative system. | A round-trip external lookup resolves to one intended Wix record. |
| A custom field reproduces an automation. | Fields store values; automations and service plugins execute behavior. | Data survives without the rule that consumes it. | Staff see stale or misleading values. | Assign value ownership and behavior ownership separately. | The continuing process updates and interprets the field correctly. |
| API availability guarantees model equivalence. | APIs expose defined resources and consistency behavior, not arbitrary source semantics. | Scope is based on connectivity rather than compatible ownership. | Missing relationships surface after implementation. | Evaluate entity and lifecycle compatibility before relying on the API. | Every required continuing integration has a defined record map and demonstrated intended output. |
Keep stable parent IDs and explicit behavior ownership in the application dependency map. The metadata and extension model helps distinguish a preserved value from the workflow expected to use it.
Assign Risk Owners and Evidence
| Risk domain | Primary owner | Business impact if uncontrolled | Mitigation direction | Control signal |
|---|---|---|---|---|
| Catalog lineage | Catalog and integration owner | Duplicate or misidentified Products and variants | Define source lineage, destination generation, and compatible sellable identity. | Each source sellable item resolves once in the selected destination catalog. |
| Options and modifiers | Catalog and fulfillment owner | False variants or lost personalization | Classify choices by effect on identity, inventory, and Order data. | Buyer selections produce the intended variant or modifier record. |
| Inventory | Inventory operations owner | Overselling and location mismatch | Protect variant-location grain and external stock authority. | Opening and continuing counts reach the intended Inventory Item. |
| Contacts and Members | Customer operations owner | False merges, access errors, and broken app history | Preserve layered identity, access, consent, and application relationships. | High-value and ambiguous identities resolve correctly. |
| Orders | Customer service and finance | Unreadable history or unsafe operational assumptions | Preserve historical snapshots and related transaction/fulfillment evidence. | Complex old Orders can be explained end to end. |
| CMS and site | Site and content owner | Broken dynamic pages, routes, and references | Define schema, reference fields, pages, permissions, and URLs together. | Priority dynamic and static journeys resolve correctly. |
| Applications and Velo | Application or engineering owner | Lost behavior and broken integrations | Rebuild behavior against target entities and stable IDs. | Continuing workflows recognize and update the intended records. |
Use the matrix to assign the risks already developed above. Carry required outcomes and accepted scope decisions into Wix validation; named owners or completed processing alone do not establish control.
Conclusion
Wix risk comes from incompatible assumptions about catalog generation, selling identity, stock, people, history and continuing site or app behavior. V3 adds universal-variant and variant-location responsibilities; it does not make other domains equivalent or prove migration coverage.
Control the agreed operation: preserve lineage, choose the right option or modifier meaning, map stock authority, keep identity layers distinct and retain readable history. Treat CMS, Blog continuity, site routes and live app behavior as explicit responsibilities with demonstrated outcomes.
Common Questions
Why is Catalog V1 versus Catalog V3 a migration risk?
V1 and V3 are not backwards compatible, and sites can still use either generation. V3 introduces distinct variant, customization, and inventory relationships. Preserve source lineage and qualify the actual destination version, identifiers, and event consumers rather than treating V3 as a universal destination.
What is the risk of treating Wix modifiers as Product options?
In V3, options create variants with distinct selling identity; modifiers collect input without independently managed pricing or stock. Turning free, non-stock personalization into inventory-bearing choices can create unnecessary combinations. Treating a priced or stocked choice as a modifier can lose its selling meaning. Classify the input before choosing its representation.
Why can a Wix Product exist without complete inventory behavior?
For a V3 catalog, Product creation and Inventory Item relationships can be separate, and tracked stock belongs to a variant and location. A visible Product does not prove inventory completeness.
A V1 destination requires qualification against its own compatible resources.
Are Wix Contacts, Members, and Customers the same entity?
No. A Contact provides identity and CRM context, a Member adds account or access relationships, commerce creates Customer and Order context, and Wix apps can own separate participant or entitlement records. They should remain connected without being collapsed.
Can historical Orders prove that current Wix checkout and fulfillment are ready?
No. Historical Orders preserve purchased items, payment details, shipping information, and fulfillment state. Active providers, Order settings, inventory updates, notifications, delivery rules, and fulfillment services remain current configuration.
When should source custom data use Wix CMS rather than a Wix app or external system?
Use CMS when it is the agreed owner of structured site data and its schema, references, permissions, pages and update behavior are defined. Required live commerce, membership, scheduling or transactional behavior needs a component that owns its lifecycle.
An agreed archive can preserve historical traceability in a suitable representation; it does not recreate a required live app process. Qualify the selected data path separately from native CMS capability.
Does Wix Blog migration follow the same model as Product catalog migration?
No. For migrations into Wix, Blog Posts are not a supported migrated output. Preserve Wix Blog continuity through a separate content rebuild or continuity plan, including authorship, dates, media, URLs, categories or tags, internal links, and redirects where relevant.
Do not infer Blog migration support from Wix Product migration or public Wix Blog APIs.
Must every Wix destination use Catalog V3?
No. Sites can still use V1 or V3, and the versions are not backwards compatible. Determine the selected destination’s actual generation and qualify its identifiers, inventory model, APIs, and event consumers. An announced transition does not establish the current site’s version.
Can a partial Wix CMS update erase fields that an integration does not own?
Yes, if it uses a full-item replacement operation with an incomplete object. Omitted fields can be lost. Use the ownership model appropriate to the actual operation, distinguish full replacement from supported partial patching, and preserve fields maintained by other consumers.