A Wix migration can show the expected Product totals while priced choices, variant stock, Member access or notifications still fail. Prevention begins with the system that owns each record and the evidence that its required consumer works.
Wix migrations can fail when Wix Stores, the CMS, Site Members, apps, multilingual content, Velo logic, and automations are treated as one interchangeable data layer. These systems can display related information while retaining different ownership, permissions, and workflow behavior.
For each pitfall, connect the wrong assumption to its consequence, prevention owner and evidence of the agreed result. Assignment alone is insufficient: a required journey must work before it can Pass.
Pitfall 1: Counting Records as Site Readiness
What goes wrong
The team plans only Product, Customer and Order transfer, then reviews presence in the dashboard. That leaves the surrounding site and its required behaviors untested.
The resulting gaps appear in customer journeys:
- Key Products cannot be found or selected correctly.
- Important content and old URLs no longer lead to the intended page.
- Checkout remains unusable despite readable catalog records.
Early warning signs
| Warning sign | Why it matters |
|---|---|
| The migration scope only lists products, customers, and orders. | Wix site structure, content, URLs, apps, and configuration may be missing from launch planning. |
| Product review happens only inside the dashboard. | Storefront display and shopper discovery may still fail. |
| Site design, menus, domains, and redirects are deferred until the end. | Customer journeys depend on more than migrated records. |
| Apps, forms, members, CMS collections, or Velo logic are not inventoried. | Business-critical behavior may sit outside core Wix Stores records. |
Prevention
Plan three connected outcomes:
- Commerce: catalog records, Product pages, catalog grouping, Customer/Member meaning and historical Orders.
- Site continuity: CMS Pages, media, navigation, URLs, redirects and domains.
- Separate implementation: apps, configuration and Blog rebuilding. Blog Posts are not supported migrated output to Wix in the approved workflow.
Use the agreed migration scope to separate transferred records from merchant, Wix configuration, developer, app-provider and external-system duties. A setup gap and a record-transfer defect need different correction owners.
Recommendation example
Illustrative Shopify-to-Wix sample set:
- A simple Product, a variant-heavy Product and an important collection.
- A high-traffic Product page, CMS Page and priority redirect.
- A guest Order, repeat Customer and relevant Member relationship.
- A Blog rebuild/continuity case where Blog content is required.
Review the connected journey under its actual owners; the sample does not establish automatic transfer coverage.
Pass condition
The agreed priority selling, content, identity, history and operating journeys work. Approved transformations, rebuilds, archives or exclusions can Pass when their outcomes are evidenced.
Assign only remaining nonblocking issues to record correction, Wix configuration, custom implementation, external work or manual reconstruction. An assigned launch-critical gap remains unproven.
Pitfall 2: Flattening Choices and Stock Identity
What goes wrong
A flattened catalog can preserve Product counts while losing the purchasable combination. Choices then resolve the wrong SKU, price, stock, image or weight, or lose personalization and Order-line meaning.
Source patterns that expose this mistake include:
- Options, configurable Products and custom options.
- Bundles, extras and personalization.
- Product builders and app-managed choices.
Native Wix options and variants still need a qualified interpretation of that Source behavior.
Early warning signs
| Warning sign | Why it matters |
|---|---|
| Product options are not separated from variants. | Choice display may work while SKU, price, stock, or order detail becomes wrong. |
| Variant-specific inventory is not sampled. | Stock may appear correct only at parent-product level. |
| Product media is validated only by file count. | Images may not appear in the right product or choice context. |
| Bundle, customization, or paid-option behavior is described as ordinary product data. | The requirement may need custom implementation, app setup, Velo/API work, or manual rebuild. |
Prevention
Build samples around distinct catalog cases:
- Simple and variant-heavy Products.
- Different variant prices, SKUs and stock.
- Media-heavy Products and important catalog groupings.
- Products governed by apps or custom logic.
Confirm the actual catalog generation and editor before applying the Wix constraints. In Catalog V3, every Product has at least one variant; option combinations define sellable variants. Native modifiers collect input without separately managed stock, pricing or variation weight.
A free engraving instruction and a priced engraving choice need different treatment. Qualify a compatible option or other implementation for the charged choice; matching storefront controls do not establish equivalent behavior.
Classify difficult behavior before accepting scope. Compatible explicit fields may fit supported mapping; app logic, configurators, bespoke transformations and external catalog behavior need qualified Wix, custom or external handling, or approved exclusion.
For later catalog work:
- Name touched records and rules, including earlier records processed again.
- Separate configuration from the record window. Unchanged rules do not imply new-only processing; a new-record-only window excludes edits to existing records.
- Compare combined output and protect accepted target changes. Keep the actual Stores and agreed migration path fixed.
Recommendation example
Illustrative example: a Product has color/size variants with different SKUs, images and stock. Verify each agreed variant’s price and Order-line meaning, then test both sellable and unavailable combinations.
Catalog V3 Product query/search responses omit variant data. Verify the complete family through the selected integration’s variant evidence. Location stock needs its actual variant/location mapping; a default-location summary cannot prove the full matrix. Cross-system IDs need reliable correspondence, not literal equality.
Pass condition
Sampled Products meet their agreed visibility, discovery, selection, cart and historical Order-line outcomes. Required SKU, price, media and stock relationships work in the actual catalog model; unavailable combinations remain unavailable as intended.
Pitfall 3: Mistaking Catalog Groups for Navigation
What goes wrong
Old categories, collections, menus, filters, landing pages and merchandising groups are treated as one object. Catalog groupings may arrive while menu logic, campaign destinations and SEO landing pages are lost.
Catalog groups do not recreate discovery. Pages, menus, dynamic sections, galleries, internal links, search, redirects and page design still determine whether Customers reach the intended Product.
Early warning signs
| Warning sign | Why it matters |
|---|---|
| Category migration is treated as navigation migration. | Customers may not reach the right products after launch. |
| Old landing pages are not included in URL review. | High-value traffic paths may be lost. |
| Product groups are validated without checking menus or links. | Wix collections may exist but remain disconnected from the customer journey. |
| Filter or merchandising rules are assumed to carry over. | Source behavior may require Wix setup, app logic, or manual page work. |
Prevention
Map the actual catalog generation: legacy Stores collections and V3 categories need deliberate correspondence. Neither is a custom CMS collection.
Use URL and redirect planning to check the independent discovery layers:
- Product grouping and gallery display.
- Menus, internal links and search.
- Landing pages, redirects and high-traffic routes.
Give each old category or collection role an intended outcome: Product group, menu entry, landing page, redirect, content page, dynamic CMS page or deliberate retirement.
Recommendation example
Illustrative example: “Summer Essentials” served four purposes:
- Product grouping.
- A homepage campaign link.
- An SEO landing page.
- An email campaign destination.
Wix may need a catalog group, landing page, menu placement and redirect, with post-launch analytics ownership. One imported label cannot prove all four purposes.
Pass condition
Required discovery paths work through the agreed catalog groups, pages and navigation. Redirects and intentional retirements are verified against the approved route decisions. Assigning an unfinished critical route to Wix setup is not a Pass.
Pitfall 4: Collapsing Customer and Member Identity
What goes wrong
An imported Contact is treated as the whole person’s commerce and access model. Customer, subscriber, guest, loyalty, booking, paid-plan and other app roles can then lose membership, marketing or account meaning.
This can create support and customer-experience problems after launch. Staff may see a record but not understand whether it represents a buyer, site member, contact, subscriber, or app participant.
Early warning signs
| Warning sign | Why it matters |
|---|---|
| Customer count is used as proof of identity continuity. | Counts do not confirm account, member, order, or CRM relationships. |
| Guest buyers are not sampled. | Guest order history may behave differently from registered-customer history. |
| Members and contacts are treated as the same thing. | Access rules and CRM context may require different Wix handling. |
| Loyalty, subscriptions, bookings, or paid plans are assumed to migrate automatically. | App-owned data may need separately qualified handling, setup and consumer proof. |
Prevention
Classify identity before mapping:
- Commerce: Customers, guest buyers and wholesale records.
- CRM: Contacts, subscribers, form participants and external CRM identifiers.
- Membership and apps: Members, paid-plan members, booking participants and loyalty users.
Assign each role to supported mapping, Wix configuration, app import, custom/external work, manual reconstruction or approved exclusion. A shared email does not establish identical IDs, access or consent.
Test relevant exceptions:
- Repeat and guest buyers.
- Multiple addresses and linked Orders.
- Members with required access.
- App-specific identity relationships.
Verify Member and linked Contact IDs separately. Test authorized access and required denial with different identities; successful lookup alone does not prove correct permissions.
Recommendation example
Illustrative example: Customers, newsletter subscribers, wholesale buyers, paid Members and loyalty users share one Source. Give each role its own Wix expectation and sample; do not approve all of them from a single Customer count.
Pass condition
Customer, Contact, Member and Order-history relationships meet their agreed scope. Required app identity, access and CRM outcomes are demonstrated through their actual owners. An agreed archive or exclusion needs its own evidence; a separate review assignment does not close missing required behavior.
Pitfall 5: Approving Checkout From Order History
What goes wrong
Past Orders can preserve purchased items, payment labels, shipping, refunds, discounts, taxes, fulfillment, notes and Customer links. Those records do not configure future checkout fields, payment providers, shipping rules, discounts, notifications or Order settings.
The result is a launch risk: staff can read old orders, but the target store may not be able to process new orders correctly.
Early warning signs
| Warning sign | Why it matters |
|---|---|
| Historical order samples are treated as checkout testing. | Past order data does not prove future Wix purchase flow. |
| Payment labels are mistaken for payment-provider configuration. | Payment setup must be configured and tested in Wix. |
| Shipping and tax values are reviewed only in old orders. | Future calculation behavior may still be incomplete. |
| Custom checkout rules are not identified. | Source-specific fees, validation, or shipping logic may require apps, service plugins, Velo/API work, or custom implementation. |
Prevention
Record separate acceptance results:
- History: Order identity, lines, totals, discounts, taxes, shipping, payment labels, refunds, fulfillment, notes and Customer relationships.
- Live commerce: the configured purchase, payment, shipping, tax, discount, fulfillment and notification behavior.
A historical Pass cannot approve untested checkout.
Assign Source checkout rules to Wix configuration, apps, service-plugin/custom implementation or approved exclusion.
The native Developer Preview Order-import API illustrates a different contract from a new purchase: history is retained without stock adjustment, buyer notification or new Contact/subscription creation, while a separate import event is emitted. Preview behavior may change; this example does not establish which path a migration uses.
Qualify the actual path and its external consumers so imported history cannot trigger duplicate fulfillment or billing.
Recommendation example
A merchant has old orders with local-delivery fees calculated from custom delivery zones. Those historical order amounts may migrate as readable past data. Future Wix checkout still needs shipping or delivery setup that reproduces or replaces the old business rule.
Pass condition
Historical Orders are readable and traceable under the agreed history contract. Required future payment, shipping, tax, discount, fulfillment and communication behavior has independent test evidence. Keep the two decisions separate: an agreed archive can Pass while unproven launch-critical checkout remains Block.
Pitfall 6: Leaving Content and Blog Continuity Behind
What goes wrong
Product transfer can leave the site context incomplete:
- Content: CMS Pages, Blog continuity, dynamic pages, media, Product images and catalog/landing pages.
- Discovery and SEO: menus, internal links, redirects, titles, meta descriptions, alt text and canonical expectations.
- Implementation: domains, language paths and device layout.
Each required outcome needs an explicit owner and evidence.
Blog Posts are outside approved migrated output to Wix. Preserve editorial content, media, language relationships and routes for a separately scoped Blog rebuild; neither a Product nor a CMS Page becomes Wix Blog data.
For content-led selling, buying guides, campaign pages and organic-search traffic, these gaps can remove the route from useful content to a purchase.
Early warning signs
| Warning sign | Why it matters |
|---|---|
| SEO is reviewed only at product level. | Page, blog, collection, redirect, and internal-link risks may remain. |
| Media transfer is treated as page readiness. | Image files may exist without correct placement, alt context, or layout. |
| Redirects and domain steps are deferred until launch day. | Search traffic, bookmarks, analytics, and campaign links can break. |
| Blog Posts or CMS Pages are not sampled. | Content loss may appear only after launch. Supported content and separately rebuilt Blog continuity therefore need their actual owners’ review. |
Prevention
Build the content/SEO review around:
- Priority Product, catalog, CMS, separately rebuilt Blog and media-heavy pages.
- Internal links, menus, high-value URLs and redirects.
- Titles, descriptions, alt context and canonical expectations.
- Domain and device-presentation responsibilities.
Keep three work scopes distinct:
- Supported transferred content.
- Blog rebuilding, including author/publication context, media, internal links and routes.
- Page/layout reconstruction, device refinement, menu strategy, redesign and domains.
Assign implementation separately from record acceptance.
Recommendation example
Illustrative example: a Store relies on buyer guides, Blog tutorials and well-performing category pages. Review supported content, separately rebuilt posts, priority routes, internal links, redirects, media and the agreed device layout before launch. A complete Product list cannot demonstrate those outcomes.
Pass condition
Required Products, supported pages, separately rebuilt Blog content, media, menus, redirects, metadata and internal links meet their agreed outcomes. Blog acceptance proves rebuilding, not migrated Blog output.
Design, layout, domain, analytics and SEO work retains its own owners. Launch-critical outcomes need proof; only genuinely nonblocking work can remain assigned.
Pitfall 7: Using CMS as the Operational Catalog
What goes wrong
CMS views expose related app data, so the team assumes Products, inventory, Orders and Members can be imported, edited or permissioned like ordinary custom records.
The consequences can differ:
- Duplicate data develops conflicting authority.
- Read-only app records reject the assumed updates.
- Dynamic pages or forms reference the wrong collection.
Wix Stores and other apps own their app collections. Custom CMS collections can support separate content models, but they do not automatically become the operational Wix Stores catalog.
Early warning signs
| Warning sign | Why it matters |
|---|---|
| A custom collection is proposed as the destination for imported Store Products. | Product display may be rebuilt without Wix Stores commerce behavior. |
| Wix app collections are treated as editable custom tables. | App-owned records may be read-only or governed by fixed permissions. |
| Dynamic pages show Product-like content from a custom collection. | The page can look correct while cart, inventory, and Order relationships remain absent. |
| Forms or Velo code write directly to a collection without an ownership decision. | Data may bypass the app that should govern it. |
Prevention
Choose the collection owner before mapping:
- Wix Stores governs its operational catalog and app collection contract.
- Custom CMS data needs deliberate fields, permissions, dynamic pages and integration logic.
- A duplicate Product representation needs a business purpose and synchronization owner.
Apply the field and reference distinction to its consumers. For later CMS writes, distinguish full-item replacement from a supported patch, preserve unrelated required fields and verify current state when reads lag writes.
| Collection type | Appropriate use | Main control |
|---|---|---|
| Wix Stores app collection | Display or reference app-owned commerce data. | Manage operational data through Wix Stores. |
| Custom CMS collection | Structured content, directories, resources, or custom workflows. | Define fields, permissions, dynamic pages and ownership; prove required references and consumers. |
| Member-private collection | Member-specific records or submissions. | Preserve role and item-level rules; prove authorized access and required denial. |
| External-system mirror | Reporting or integration use. | Define synchronization, identifier mappings and conflict handling; verify the agreed consumer outcome. |
Recommendation example
Illustrative example: a custom comparison guide references Products. If both data paths are qualified, keep operational Products in Wix Stores and guide records in an appropriate custom collection. Map stable identities or references between them; do not reconstruct the commerce catalog inside the guide because both render on dynamic pages.
Pass condition
Each collection has an owner, purpose, permission model and update path, with evidence that its required consumers use the intended records. Operational Products remain governed by Wix Stores. Custom content meets its agreed live or archive contract without being mistaken for a replacement commerce engine.
Pitfall 8: Detaching Translations From Records and Routes
What goes wrong
Translated text is detached from its primary record, SEO fields or localized route. Product and Category translations can then disagree with checkout, CMS content or redirect destinations, sending a reader into the wrong language journey.
A redirect ledger needs language and destination context when Source paths or Wix URL structures differ. One undifferentiated list cannot establish the right language outcome.
Early warning signs
| Warning sign | Why it matters |
|---|---|
| Translations are stored without a primary-record relationship. | Updates can create inconsistent or orphaned language versions. |
| Product and Category translations are reviewed separately from checkout and email text. | The shopping journey can switch languages unexpectedly. |
| Redirects are prepared without a language column or destination review. | Visitors may land on the default-language page or a broken path. |
| CMS dynamic-page URLs are expected to translate exactly like ordinary Pages. | URL behavior can differ by content type. |
Prevention
Prepare linked language evidence:
- Product/Category primary records and translated text.
- CMS fields, separately rebuilt Blog content and menus.
- Checkout, email and other operational text.
- SEO fields and language-appropriate old/new routes.
Define primary language, translation owners, fallback and supported URL behavior. Blog language relationships remain in the separate rebuild scope; native multilingual features do not establish transfer coverage. Review each redirect in its actual language context.
| Multilingual layer | Prevention decision |
|---|---|
| Product and Category text | Preserve the relationship to the primary commerce record. |
| CMS and Blog content | Map translated fields and the pages that render them; handle Blog content through the separate rebuild and continuity workstream. |
| URLs and redirects | Assign old and new paths by language and destination relevance. |
| Checkout and communications | Configure translated labels, emails, and operational messages. |
Recommendation example
Illustrative example: English and French Product pages used different legacy paths. Map both to the intended Wix Product and language relationship, then verify:
- Language-appropriate redirects and navigation.
- French Product text and checkout labels.
- French email content where required.
Shared primary identity does not require copying Source numeric IDs.
Pass condition
Representative language journeys remain coherent from landing page through Product discovery and checkout. Translations stay attached to the correct records, and priority legacy URLs resolve to relevant destinations in the intended language.
Pitfall 9: Treating App Behavior as Record Data
What goes wrong
A field import is treated as implementation of an app or connected workflow. The omitted behavior can sit in:
- CMS/custom catalogs, Velo/API code or service plugins.
- Checkout rules, fees, shipping rates or external payment services.
- ERP, CRM, PIM, WMS, accounting or marketplace relationships.
Basic record checks cannot prove these business-critical consumers.
Wix extensibility does not make behavior transferable as ordinary data. Qualify app setup, CMS permissions, code, automations, external integrations, manual rebuilding or deliberate exclusion according to the required outcome.
Early warning signs
| Warning sign | Why it matters |
|---|---|
| App-owned records are not listed separately. | Important data may not belong to core Wix Stores migration scope. |
| Velo/API behavior is described without examples. | Code-driven behavior cannot be validated as ordinary records. |
| Service-plugin behavior is assumed from historical data. | Checkout, shipping, payment, and fulfillment logic may need implementation. |
| External systems are tested only after launch. | Operational workflows may fail after traffic moves to Wix. |
Prevention
Use an integration dependency register for apps, custom fields, CMS collections, scripts, service plugins and external systems. Record:
- Owner and business purpose.
- Actual Source sample and qualified Wix outcome.
- Handling path, durable identity mapping and acceptance evidence.
Compatible fields and references may fit supported mapping. That does not recreate an app’s lifecycle, a Velo function or an external sync.
For required live behavior, name the responsible implementation and test its consumer. For an agreed archive, preserve meaning and traceability. Resolve or explicitly exclude required gaps; an unexplained identifier is not a working relationship.
Recommendation example
Illustrative example: a Source uses a configurator, loyalty app and ERP sync. Product records alone do not restore configuration behavior, loyalty balances or synchronization. Qualify the separate app, Velo/API, external implementation, manual reconstruction or approved exclusion outcome, then test what was agreed.
Pass condition
Each required app, Velo/API, CMS, external-system and custom-data dependency meets its evidenced live, rebuild, archive or approved exclusion outcome. Keep that acceptance distinct from core Wix Stores record presence.
Pitfall 10: Expecting Records to Restore Automations
What goes wrong
Records arrive, and the team assumes automations arrive with them. Products, Contacts, Members, Orders, forms and CMS data do not define the required trigger, conditions, actions or timing.
App installation and Velo/webhook dependencies also affect the available workflow. Validate actual retained definitions and behavior rather than inferring them from imported history.
Failures may be invisible on the storefront:
- Customers receive no confirmation.
- Staff tasks or lead routing never happen.
- External systems receive no expected event.
Early warning signs
| Warning sign | Why it matters |
|---|---|
| The source has abandoned-cart, Order, form, membership, or lead workflows with no target inventory. | Important triggers and actions may be missing. |
| Notifications are inferred from historical emails or Order notes. | Past output does not reveal the complete workflow definition. |
| Apps are installed after automation planning. | Available triggers and actions may change with the app set. |
| Webhooks or Velo actions have no owner or run-log review. | External processes can fail without visible storefront errors. |
Prevention
For each retained critical automation, record:
- Trigger, conditions, actions and timing.
- Audience, app dependencies and required data fields.
- External endpoint and accountable owner where applicable.
Retain only workflows that serve the agreed business purpose. After configuration, use controlled representative events in the qualified test context to prove routing, completed actions and intended external payloads. Check a nonmatching or failure path as well as success.
| Workflow type | Required control |
|---|---|
| Order or cart automation | Confirm Wix Stores trigger, Customer data, message, timing, and exception handling. |
| Form or lead automation | Confirm form source, field mapping, assignment, and follow-up action. |
| Member automation | Confirm role, access event, notification, and membership state. |
| Webhook or Velo workflow | Confirm endpoint, payload, authentication, error handling, and run log. |
Recommendation example
Illustrative example: a high-value Order must notify staff and reach an ERP. Treat these as two outputs. Use a representative test Order to verify the internal notification and the external payload, including the intended threshold and failure handling.
Pass condition
Every retained critical automation has a configured trigger, correct conditions, completed actions and an accountable owner, supported by representative success and exception evidence. Approved retirements or exclusions have explicit decisions. Migrated records alone do not prove a workflow exists.
Set Cross-Pitfall Priorities and Owners
Resolve catalog generation and record ownership before relying on discovery, identity or history. Custom CMS, translated content and separate Blog rebuilding then need their actual references, permissions, media and routes. Apps and automations must consume those intended records under separately proven contracts.
| Control area | Prevention priority | Evidence of control | Responsible owner |
|---|---|---|---|
| Wix Stores catalog | Preserve agreed Product, option/modifier, variant, media, location-stock and Category or legacy grouping relationships. | Representative Products remain selectable, purchasable, and operationally understandable. | Catalog and Wix Stores configuration owners |
| Site discovery | Connect Categories, menus, Pages, Blog Posts, CMS content, and dynamic pages intentionally. Blog Posts belong to a separate rebuild/continuity workstream, not approved migrated Blog output to Wix. | Customers can move from content and navigation to the intended Products. | Site, content, Blog-rebuild and SEO owners |
| Identity | Separate Customers, contacts, Site Members, and app participants by use. | Each identity type retains the account, access, or communication context it needs. | Customer operations, identity and application owners |
| Collections | Distinguish Wix app collections from custom CMS collections and permissions. | Required collection references, access and consumers work under the declared owner and update path. | CMS/application and permissions owners |
| Multilingual structure | Preserve translated content, SEO fields, URLs, and redirects as related language journeys. | Priority journeys remain coherent in each supported language. | Localization, content and SEO owners |
| Custom behavior | Inventory apps, Velo, service plugins, external systems, and custom fields. | Each agreed live, rebuild, archive or exclusion outcome is evidenced; critical unknowns remain open. | Application, development and integration owners |
| Automations | Rebuild triggers, conditions, actions, and integrations separately from records. | Representative events execute the intended internal and external workflow. | Operations and automation owners |
Use the Wix preparation checklist to resolve evidence, feasibility and required setup prerequisites before execution. Assign correction, Wix setup, Blog/content rebuilding and app/external work to their actual owners.
Judge produced outcomes separately: a proven agreed result is Pass; a residual nonblocking issue is Watch with ownership and follow-up proof; a critical unusable or materially unproven journey is Block. A deadline does not supply missing evidence.
Conclusion
Wix migration prevention follows the record’s actual owner and consumer. A populated dashboard cannot prove catalog choice, access, route or workflow meaning when those relationships are missing.
Keep supported transfer, Blog rebuilding, site configuration and app/automation work distinguishable. Required Product, identity, history, content and language outcomes need demonstrated evidence; unresolved critical work cannot be cleared by assigning an owner.
Carry the agreed outcomes and evidence into Wix Validation Priorities for record, separate Blog and rebuilt-workflow acceptance.
Common Questions
Why is Wix more than a generic hosted Store destination?
Wix combines Wix Stores with Pages, Blog content, CMS collections, Site Members, apps, multilingual features, Velo code, and automations. Those layers can reference the same Customer or Product while retaining different ownership and permissions.
What is the main Product-structure pitfall in Wix Stores?
Source options and variants may not translate cleanly into Wix Product, option, choice, variant, media, price, and inventory relationships. Review complex Products by purchasable behavior rather than Product count.
Are Wix CMS collections the same as Wix Stores collections?
No. Wix app collections expose app-owned data and are governed by the corresponding app. Custom CMS collections have their own fields, permissions, and dynamic-page uses; they do not automatically become an operational Store catalog.
How should Customers, contacts, and Site Members be separated?
Classify commerce history, marketing, site login, restricted content, loyalty, booking and other app relationships separately. Preserve distinct Member/Contact IDs, matching rules and each required consumer’s access or communication meaning.
A required meaning without an owner is unresolved; do not discard it. Qualify handling, demonstrate an agreed archive or exclusion, or hold the affected outcome. Customer migration alone does not establish password or app-entitlement continuity.
What makes multilingual Wix migration risky?
Translations, Product text, CMS content, SEO fields, checkout language, and redirects must stay connected to the correct primary records and language-specific paths. A single generic redirect or translation list is insufficient.
Will Wix automations resume when records are migrated?
Imported records do not restore the Source workflow definitions. Confirm retained triggers, conditions, actions, timing, app dependencies and any Velo/webhook behavior, then use representative events to prove the intended outcomes.
Wix may supply app-specific automations; inspect them rather than assuming they match the old workflow. Approved retirements need explicit decisions instead of unnecessary rebuilding.
Can a Wix modifier reproduce a choice that needs separate stock, price, or shipping weight?
No. In the documented native model, modifiers collect customization without separately managed stock, pricing or variation weight. Options provide the appropriate variant structure for commercial differences.
Confirm the actual catalog/editor and qualified representation for a charged, weighted or stocked choice. Similar Product-page controls do not establish equivalent meaning.
Does a Wix Catalog V3 Product query prove that all variants were captured?
No. Product query and search results do not include the variants.
Review the complete family and its inventory relationships separately through the selected integration’s evidence. Matching parent Product counts cannot prove that every sellable combination, identifier, or balance is present.
Does importing a Wix Order reproduce the native effects of a new purchase?
No. The documented Developer Preview Order-import API retains supplied history without native purchase effects such as stock adjustment, buyer notification or new Contact/subscription creation. It emits a separate import event; preview behavior may change.
Qualify the actual migration path and its consumers. This native example does not prove workflow coverage, and history must not trigger duplicate fulfillment or billing.
Does native Wix Blog functionality establish Blog migration support?
No. Wix has native Blog capabilities, but a destination feature does not establish the output supported by a migration workflow. Blog Posts are not a supported migrated output to Wix in the approved workflow.
Preserve priority posts, media, editorial context, language relationships and routes through a separately scoped rebuild and continuity workstream, then review that outcome under its content and SEO owners.