After a test or broader migration run into Wix, compare the agreed output with evidence from the actual destination. Record its catalog generation, apps, identity model and content owners: a correct record in one context may remain unusable in another.
Record counts establish presence, not whether Customers, staff or connected systems can use the result. Wix validation must follow the agreed data and its required consumers through the site and operational workflows.
Keep the evidence layers distinct:
- Catalog choices must retain their agreed SKU, price, stock and media meaning.
- Discovery needs both correct grouping and working site navigation.
- Historical Orders need readable purchase context; live checkout needs separate proof.
- Contacts, Customers and Members need their own identity and access checks.
- Content, routes, apps and code need evidence from their actual consumers.
Record the site’s actual catalog version and installed apps before judging Products and customizations. A site uses Catalog V1 or V3; do not assume that a current API example matches the destination. Native catalog, CMS, membership and app features do not establish migration coverage. Keep the accepted data output and separately agreed implementation attached to their owners.
Define Evidence and Acceptance
Use the agreed acceptance criteria, not an assumption that every Source behavior must be cloned. Document migrated data, target setup, bounded adjustments, separate handling and approved exclusions.
A proven transformation, rebuild, archive or exclusion can Pass. Watch is a remaining nonblocking issue. A launch-critical outcome that is unusable or materially unproven is Block, even when it has an owner and plan.
| Validation layer | What to prove | Why it matters for Wix |
|---|---|---|
| Record presence | Products, collections, customers, orders, CMS Pages, media, and other supported migrated records appear in the expected Wix areas. | Presence confirms transfer but not usability; Blog Posts are not counted as migrated output for Wix. |
| Business meaning | Products, choices, variants, Orders, Contacts, Members, content and URLs meet the agreed meaning, including documented transformations or exclusions. | Wix may organize the same business idea differently from the old store. |
| Storefront usability | Customers can find products, select options, see correct media, understand prices, and proceed through the intended purchase path. | Wix is a site-builder commerce platform, so visual and navigation context affects migration quality. |
| Administrative readability | Staff can review product details, customer context, order history, fulfillment information, payment labels, and exception cases. | Migrated history must remain useful for customer support and operations. |
| Launch readiness | Required payment, shipping, tax, domain, redirect, app, content and integration outcomes are demonstrated; only nonblocking issues remain assigned. | Migrated records do not automatically complete future Wix operations. |
Assign findings to the work that can resolve them:
- Migration-data correction.
- Wix configuration or site implementation.
- Bounded data-handling adjustment.
- Separate data handling or external work.
- An approved out-of-scope decision.
Handling path identifies responsibility; it does not determine Pass, Watch or Block.
Check the site consumers as well as the record:
- A collection gallery can resolve the wrong Product group.
- Member access can resolve the wrong Contact.
- A CMS-driven page, automation or Velo function can use an obsolete field or ID.
Correct Product and Order records alone do not approve these journeys.
Test Representative Wix Relationships
Use the prepared Wix sample packet to test the site’s material relationships and exceptions. Simple Products and ordinary paid Orders alone cannot expose complex choices, location stock, identity, content or app dependencies.
Exercise enhanced or separately implemented output in a context that supports it. The examples below guide coverage; they do not establish transfer eligibility.
For each relevant sample group, record the expected and observed outcome:
| Sample group | What to include | Pass condition |
|---|---|---|
| Simple products | Standard products with title, SKU, price, image, description, collection, SEO value, and inventory. | The item appears in Wix with clear storefront and admin meaning. |
| Complex products | Products with options, choices, variants, different SKUs, different prices, different stock, multiple media, personalization, or product-specific rules. | Agreed choices, variant identity, price, stock and media work for Customers and staff. |
| Collections and discovery | Products tied to old categories, filters, menus, landing pages, or merchandising groups. | Wix collections and site navigation expectations are separated and validated. |
| Orders | Paid, refunded, canceled, discounted, taxed, shipped, guest, and multi-item orders. | Order history is readable and customer/order relationships are understandable. |
| Customer identity | Customers, contacts, members, guest buyers, subscribers, loyalty records, booking participants, and app participants where relevant. | Each identity type is classified correctly and not collapsed into a misleading record. |
| Content and SEO | CMS Pages, source Blog continuity cases, media-heavy pages, internal links, high-value URLs, metadata, and redirect samples. | Required content and traffic paths work as agreed; separately rebuilt Blog outcomes have their own proof and are not migrated output. |
| Custom behavior | Apps, Velo/API logic, service plugins, external catalog data, custom fields, and third-party systems. | The agreed ordinary data, bounded adjustment, separate handling, Wix setup, external implementation or exclusion outcome is evidenced. |
A sample Pass approves only the structures and scenarios actually tested. Broader completeness and untested exceptions need further evidence; a clean sample cannot establish that the entire Wix Store is ready.
Where the site has cross-application relationships, include a representative case:
- A Customer who is also a site Member.
- A Product displayed through custom CMS content.
- An Order consumed by an automation or fulfiller.
These expose ownership and reference problems beyond an isolated record.
Validate Catalog Choices and Discovery
Use the site’s actual catalog model. Legacy catalog collections and V3 categories/customizations require their own checks; a grouping record does not prove site navigation.
Options describe selectable properties and choices provide values. Under V3, their combinations define variants; modifiers collect input without variants or independently managed pricing or inventory. Prove the selected combination’s applicable price, SKU, weight, stock and media.
| Catalog area | What to validate | Wix-specific failure signal |
|---|---|---|
| Product identity | Product name, SKU, slug, status, product page visibility, duplicate handling, and product references. | Products exist but staff cannot identify them or customers cannot reach the expected page. |
| Product content | Descriptions, media, gallery order, product ribbons, labels, SEO fields, and rich content where supported. | Text or images transfer but do not support the Wix product-page experience. |
| Options and choices | Size, color, material, style, bundle-like choices, personalization, and other customer selections. | The selectable choice appears but loses order-detail, price, SKU, image, or stock meaning. |
| Variants | Variant-level SKU, price, stock, weight, image, and availability. | Parent product looks correct while variant-specific selling data is wrong or missing. |
| Collections | Grouping, merchandising, product assignment, and discovery role. | Old category logic is imported but does not support actual Wix browsing or navigation. |
| Inventory | Variant-aware stock, tracked/untracked status, stock messages, and availability. | Stock is correct only at product level or does not match the sellable choice. |
Include ordinary Products and relevant exceptions:
- Variant-heavy and stock-sensitive items.
- Media-heavy Products.
- High-traffic and collection-dependent Products.
Require only patterns the actual scope uses, then review their intended destination behavior.
Test free personalization and other non-stock input through the cart and Order line. Check required input, allowed values, associated images and the agreed price effect.
A native modifier cannot supply independently managed pricing or inventory. A charged extra needs a compatible option or other qualified implementation; visual resemblance to a variant does not prove its meaning.
Trace each Source choice to its actual Wix structure and cart or Order-line output. A V1 choice without managed variants does not become stock-bearing merely because a V3 example uses options.
Under V3, test modifier input separately from variant identity. Include both sellable and unavailable combinations under the configured locations and stock authority.
Prove Location Stock and Availability
Reconcile stock at the destination’s actual selling level. For Catalog V3, this means the variant/location record; the default-location Product summary cannot prove all location quantities or availability.
Parent-Product, warehouse, channel, marketplace, app or custom-field stock in the Source needs an explicit mapping to the accepted Wix model. Do not require native IDs to match literally across systems.
The validator should check:
- Confirm the intended Product or variant stock owner for the actual catalog generation.
- Compare relevant variant/location quantities, quantity versus in-stock tracking, preorder settings and stock messages.
- Reconcile included, excluded or consolidated warehouse/channel stock to its reference timestamp.
- Test out-of-stock behavior, Product visibility and the expected sellable or unavailable combination.
Opening stock and ongoing authority need separate proof. Record pending obligations and the intended Wix, ERP/WMS or other stock owner. Test the required update and availability behavior after configuration; a copied quantity does not approve an external sync process.
Separate Order History From Live Checkout
Historical Orders should explain past purchases and their payment, refund, invoice and fulfillment context. They do not prove that future checkout, payment providers, shipping rates, taxes, notifications or Order settings work.
| Order area | Historical validation | Live-readiness validation |
|---|---|---|
| Order identity | Order number, date, status, source reference, customer link, guest order behavior. | Future orders are created through the configured Wix purchase path. |
| Line items | Products, variants, choices, quantities, prices, discounts, taxes, totals, and notes. | New orders capture product and option choices correctly. |
| Payments | Historical payment labels, transaction references, refunds, and payment state where available. | Wix payment providers and payment flow are configured and tested. |
| Fulfillment | Shipping method labels, addresses, delivery context, fulfillment status, tracking, and notes. | Shipping, pickup, delivery, fulfillment, and notifications work after setup. |
| Discounts and taxes | Historical discount values, coupon labels, tax totals, and tax meaning. | Future tax and discount behavior is configured and tested in Wix. |
Record two independent results:
- Historical acceptance: purchased items and past actions remain readable and traceable.
- Live readiness: required new Order, payment and fulfillment behavior is demonstrated after setup.
An agreed archive can Pass its history contract. It does not approve launch-critical checkout, and importing history must not trigger unintended payment, stock, email, automation or fulfillment events.
Include paid, unpaid, refunded, canceled, partially fulfilled, digital, and guest examples where they exist.
The evidence should preserve what happened at purchase time and who owns the next operational action, without using current Product settings or checkout rules to recalculate historical meaning.
Prove Customer, Contact and Member Meaning
Classify Source identity before judging the Wix result:
- Customers, accounts and guest buyers.
- Contacts, subscribers, form submitters and CRM identities.
- Members, loyalty users, booking participants, wholesale users and other app identities.
One person can occupy several roles without one record owning all permissions or history.
| Identity area | What to validate | Pass condition |
|---|---|---|
| Customer records | Names, emails, phone numbers, billing/shipping addresses, and order relationships. | Staff can connect customers to migrated orders and support history. |
| Guest buyers | Orders tied to buyers without full account behavior. | Guest history remains readable without implying a full member account. |
| Contacts and CRM context | Contact details, subscriber meaning, form context, tags, notes, or marketing status where supported. | Contact meaning is not confused with commerce order history. |
| Members | Site membership, login expectations, access rules, paid plans, or gated content where relevant. | Agreed member login, access and plan outcomes are demonstrated in their qualified scope; Customer migration alone is not proof. |
| App-specific identity | Loyalty, bookings, subscriptions, forums, courses, or other app-owned participation. | The agreed ordinary data, target setup, separate handling, third-party work or exclusion outcome is verified for the app identity. |
Readable buyer and Order history can satisfy an agreed commerce-history result. Required membership access, loyalty, subscriptions or CRM automations need their own proof through the responsible app or replacement.
An agreed historical archive remains valid when its meaning and traceability are demonstrated; do not present it as a live entitlement or workflow.
Test duplicate emails and overlapping Contact, Customer, Member, subscriber and app records deliberately. Prove each consumer resolves the intended person.
Check login, Order visibility, consent, permissions, addresses and external CRM keys under their actual owners; a shared email does not justify flattening them into a generic profile.
Verify the Member ID and linked Contact ID separately. Their relationship does not imply equal identifiers.
Use an authorized Member to prove account and Order visibility, then another identity to test denied access where required. A lookup is insufficient if the consuming app resolves the wrong person.
Validate Content, Blog Continuity and SEO
Validate supported CMS Pages separately from Wix Blog continuity. Blog Posts are not supported migrated output to Wix in the approved workflow; separately rebuilt posts need their own content and route evidence.
Site and traffic checks below apply to the agreed scope. Product transfer alone does not establish site readiness.
| Site area | What to validate | Why it matters |
|---|---|---|
| CMS Pages | Page content, internal links, images, layout dependencies, and publish status. | Content pages may support trust, policies, buying guidance, or SEO. |
| Wix Blog continuity | Separately rebuilt Source titles, slugs, bodies, images, categories/tags, internal links and priority routes meet the agreed outcome; exclusions are recorded. | Blog value is preserved without representing Blog Posts as migrated output. |
| Media | Product images, page images, gallery assets, filenames, alt context, and placement. | Image availability does not prove image placement or page readiness. |
| URLs and redirects | Priority product, collection, CMS Page, Blog Post, and landing-page URLs. | Required old traffic paths reach their agreed destinations; accepted exclusions and any nonblocking deviations are recorded. |
| SEO fields | Page titles, meta descriptions, visible headings, index-sensitive content, and internal links. | Wix launch can lose SEO value if only products are checked. |
| Domain and multilingual context | Domain assignment, published URL behavior, language paths, and redirect logic. | Site launch and traffic continuity depend on more than content migration. |
Keep implementation ownership explicit:
- Migrated supported content needs data acceptance.
- Rebuilt layouts, page redesign and menus need their own implementation proof.
- Domains, publishing, device layout and analytics remain separate launch duties unless included.
A content Pass does not establish those outcomes.
Test dynamic pages and CMS-linked content through their actual items, references, media, permissions and route patterns. Check internal links, canonical destinations and member restrictions where required.
For later writes, distinguish full-item replacement from a supported partial patch. Verify unrelated required fields survive and read the current resulting state; relevant CMS reads can lag writes.
Test external assets against their agreed ownership and continuity. Deliberately retained assets can Pass when availability is proven; accidental dependence on a retiring Source is unresolved.
Prove App, Code and Integration Outcomes
Classify each dependency by required outcome: migrated data, configured behavior, rebuilt implementation, retained archive or approved exclusion.
Wix apps, CMS, Velo/API code and service plugins have different contracts. Native extension capability does not establish a supported migration path or working behavior.
| Dependency type | Validation question | Likely handling path |
|---|---|---|
| Wix apps | Does the target app need data, setup, or separate migration handling? | Wix setup, app import, third-party work, or separate data-handling review. |
| Velo/API logic | Is behavior code-driven rather than data-driven? | Rebuild, external implementation, or separate data-handling review. |
| CMS collections | Are records content, dynamic-page data, product-like data, or operational data? | Standard scope, bounded data-handling adjustments, separate data handling, or target setup depending on behavior. |
| Service plugins | Does checkout, shipping, tax, payment, or fulfillment depend on custom logic? | Wix configuration, service-plugin implementation, or separate data-handling review. |
| External systems | Do ERP, CRM, PIM, WMS, accounting, or marketplace records need continuity? | External implementation, separate data-handling review, or accepted exclusion. |
For each business-critical dependency, require demonstrated agreed output. A realistic handling path and owner are necessary, but do not close missing proof.
For an agreed archive, verify retained meaning and traceability. Required live behavior needs the actual app, replacement or external consumer to work.
For required live dependencies, verify:
- The authoritative Wix or external record and its Product, Customer, Member or Order identity mapping.
- A real read or event path that returns the intended state.
- A failure or denied path with the expected containment.
Code that runs without errors can still use the wrong record. Use the integration ownership model to assign each consumer’s proof.
Reconcile Broader and Later Results
Use scope reconciliation after broader execution. Compare agreed record classes and relationships, then investigate rare Products, older Customers, guest Orders, refunds, inactive supported content, priority routes and each custom-data outcome.
Representative tests establish selected structural evidence, not total completeness. Blog continuity remains a separately evidenced workstream.
Wix revalidation should expand according to the configuration and relationships changed by the later action.
| Later action | Required Wix revalidation |
|---|---|
| Continue with the accepted configuration | Confirm touched Products, Customers, Orders, variants, categories or catalog collections, member relationships, routes and external IDs still meet the accepted rules. Unchanged configuration does not select a new-record-only window. Blog stays outside the migrated-output delta. |
| Continue after revising configuration | Recheck every changed filter, mapping, data type selection, Product-option or modifier decision, CRM relationship, content rule, and custom-data outcome, then repeat affected storefront and dashboard scenarios. |
| Create a new migration result | Establish a fresh evidence baseline for the distinct result and repeat affected representative/broader checks. Do not inherit prior approval or assume a new run changes the actual Stores or purchased path. |
Revalidation follows the records and rules actually touched:
- Name new records and any earlier records updated or processed again. Unchanged configuration does not establish a newly-added-only window; a genuinely new-record-only window excludes edits to existing records.
- Compare combined earlier/later output and protect accepted target-side changes where required.
- Recheck dependent variant identity and stock, modifier input, grouping, Contact/Member links, historical Orders and custom consumers.
Keep the actual Source/Target Stores and purchased path fixed. Run completion does not inherit a prior Pass.
Record Pass, Watch or Block
Wix launch approval should classify evidence as Pass, Watch, or Block. The state must be attached to a named Product, variant, modifier, collection, Customer, member, Order, content path, app record, Velo relationship, or defined output.
| Decision state | Required evidence | Launch meaning |
|---|---|---|
| Pass | The expected catalog, historical, CRM, content, or integration behavior is reproducible and no material uncertainty remains. | The reviewed area supports launch. |
| Watch | The migrated result is usable, but a documented nonblocking layout, merchandising, member-area, automation, checkout-configuration, or integration task remains. | Launch may proceed only with an owner, deadline, and follow-up proof. |
| Block | An agreed launch-critical Product, stock, identity, Order, route, app or external-system outcome is unusable, misleading or materially unproven. | Launch approval is withheld until correction or a formally accepted scope decision. |
Apply outcome validation to defined filters, CMS mappings, member relationships and configuration. Separately agreed data handling needs evidence for its actual records, fields, transformations, external IDs and consumers.
This can include unsupported app data under an approved separate scope; the label does not establish feasibility. Data acceptance does not include Wix design, apps, code, automations, payment, shipping, tax or fulfillment implementation unless expressly agreed.
Record expected behavior, observed result, decision state, owner, handling path and retest proof. Pass means the agreed result is demonstrated; Watch means only a nonblocking issue remains; Block means critical usability, meaning or evidence is missing.
An approved transformation, rebuild, archive or exclusion can Pass. An owner, deadline or monitoring plan cannot clear an unproven launch requirement.
Conclusion
Wix migration validation connects records to their agreed meaning and consumers. Catalog generation, stock locations, identity roles and separate content/app ownership determine which evidence is valid. Blog continuity retains its separate rebuild scope.
Use the report to distinguish corrections, bounded adjustments, separate data work, Wix setup and approved exclusions. Then apply the evidence to go-live acceptance.
Record acceptance and authorization to operate the live site are separate decisions; neither follows automatically from a completed run.
Common Questions
What should Representative Testing prove for Wix?
Test the material patterns in scope: option- and modifier-heavy Products, variants, stock, catalog groupings, Customer/Contact/Member relationships, exceptional Orders, CMS Pages and priority URLs.
Where present, include a Blog continuity case and an app, Velo or external-system relationship. Prove the agreed separate Blog outcome rather than counting Blog Posts as migrated output. A representative Pass covers only the selected structures and evidence.
Is Product-count matching enough to validate a Wix migration?
No. Counts cannot prove option versus modifier behavior, variant-level price and stock, collection discovery, Customer/member meaning, historical Order readability, content routes, or app ownership.
Should historical Wix Orders and live checkout be validated separately?
Yes. Historical Orders prove purchased items, totals, discounts, taxes, shipping, payment references, refunds, and fulfillment context. Live payment, shipping, tax, checkout, notification, and fulfiller behavior requires separate Wix configuration evidence.
How should Wix Customers, contacts, and members be validated?
Confirm each identity’s role, distinct member and contact IDs, duplicate handling, addresses and linked Order or CRM context. Test the configured login and permission path with authorized accounts.
Membership, subscriptions, consent and app participation retain separate owners; matching emails do not prove equivalent IDs, access or password continuity.
When is a Wix finding a Block?
Use Block when an agreed launch-critical outcome is unusable, misleading or materially unproven. This includes purchasing, Customer/Member or Order meaning, priority routes and required bounded adjustments, separate data handling, apps, Velo or integration output.
Assignment or a deadline does not supply missing evidence. A proven agreed transformation, archive, rebuild or exclusion can Pass; only a remaining nonblocking issue belongs in Watch.
What must be revalidated after a later Wix migration action?
Revalidate touched Products, Customers, Orders, variants, catalog groupings, Contact/Member links, supported content, app records and external IDs, including earlier records updated or processed again. Compare combined output and protect agreed target-side changes.
Configuration and record window are independent: unchanged rules do not imply newly-added-only processing, and a new-record-only window excludes edits to existing records. Keep the actual Stores and purchased path fixed.
Blog remains outside the migrated-output delta. Retest its separate continuity outcome when content or route decisions change.
Can one Wix option-and-variant test approve both Catalog V1 and V3?
No. Test the catalog generation actually in use. In V3, option combinations define variants; modifiers collect input without variants, independently managed prices or inventory. Source choices and paid personalization may need a different qualified representation.
Prove the agreed SKU, price, stock and cart or Order-line input. An example from another version does not approve this site.