La validazione di una migrazione verso Wix deve dimostrare che il sito migrato può funzionare come ambiente commerciale Wix, non soltanto che i record compaiano in un pannello di amministrazione. Wix combina la presentazione realizzata con il site builder, i dati di catalogo di Wix Stores, collezioni, varianti, inventario, ordini, pagamenti, contatti, membri, collezioni CMS, Blog Posts, contenuti multimediali, app, logica Velo/API, service plugin, URL, domini e impostazioni necessarie alla messa online. Il confronto dei conteggi può confermare la presenza dei record, ma non dimostra che lo store sia effettivamente utilizzabile da clienti, personale, motori di ricerca o flussi di lavoro collegati.
Un processo di validazione efficace verifica il significato operativo su più livelli. I Products devono essere visibili e acquistabili. Opzioni e varianti devono mantenere, dove supportato, il significato delle scelte, degli SKU, delle quantità disponibili e dei prezzi. Le collezioni devono sostenere la scoperta dei prodotti senza essere confuse con l’intera navigazione del sito. Gli ordini storici devono restare leggibili senza essere scambiati per la configurazione futura dei pagamenti o del checkout. Contatti, Customers e membri devono essere verificati come contesti di identità distinti. Contenuti del sito, URL, media, campi SEO, app e logica personalizzata devono essere controllati come aree specifiche del lancio su Wix, non trattati come normali record di catalogo.
Cosa deve dimostrare la validazione su Wix
Una migrazione verso Wix dovrebbe essere approvata solo quando il risultato nella piattaforma di destinazione è comprensibile nella vetrina online, nell’amministrazione, nei contenuti e nella verifica operativa. Questo non significa che ogni comportamento della piattaforma di origine debba essere riprodotto in modo identico. Significa che il perimetro di migrazione concordato, la configurazione lato Wix, gli adeguamenti di migrazione approvati, le esigenze di gestione non standard e le esclusioni accettate devono essere sufficientemente chiari da sostenere una decisione di messa online.
| Livello di validazione | Cosa dimostrare | Perché è importante per Wix |
|---|---|---|
| Presenza dei record | Products, collezioni, Customers, Orders, CMS Pages, Blog Posts, media e altri record supportati compaiono nelle aree Wix previste. | La presenza conferma il trasferimento, non l’effettiva utilizzabilità. |
| Significato operativo | Products, scelte, varianti, Orders, contatti, membri, contenuti e URL continuano a rappresentare il significato previsto nella piattaforma di origine. | Wix può organizzare la stessa esigenza commerciale in modo diverso rispetto allo store precedente. |
| Utilizzabilità della vetrina online | I clienti possono trovare i prodotti, selezionare le opzioni, vedere i media corretti, comprendere i prezzi e seguire il percorso di acquisto previsto. | Wix è una piattaforma commerciale basata anche sulla costruzione del sito, quindi contesto visivo e navigazione incidono sulla qualità della migrazione. |
| Leggibilità amministrativa | Il personale può verificare dettagli dei Products, contesto dei Customers, storico Orders, informazioni sull’evasione degli ordini, etichette di pagamento e casi eccezionali. | Lo storico migrato deve restare utile per assistenza clienti e attività operative. |
| Preparazione alla messa online | Pagamenti, spedizioni, imposte, dominio, redirect, app, contenuti e integrazioni sono configurati separatamente o assegnati a un responsabile. | I record migrati non completano automaticamente le future operazioni su Wix. |
Ogni risultato della validazione deve essere classificato in base al percorso di gestione appropriato. Alcuni problemi richiedono correzioni della migrazione. Altri riguardano la configurazione di Wix. Altri ancora richiedono adeguamenti di migrazione approvati, una valutazione per una gestione non standard oppure rientrano fuori dal perimetro concordato e devono essere documentati prima della messa online.
La verifica deve collegare Wix Stores al resto del sito Wix. I record Products e Orders possono essere corretti mentre gallerie di collezioni, accesso dei membri, pagine alimentate dal CMS, automazioni o logica Velo puntano ancora a un’identità o a un campo diverso. L’approvazione della messa online deve quindi seguire l’intero percorso del cliente e il flusso operativo, non soltanto il pannello del commercio elettronico.
Validare il test rappresentativo con campioni Wix realmente rappresentativi
La validazione del test di migrazione rappresentativo deve utilizzare record capaci di far emergere i rischi specifici di Wix. Un campione composto soltanto da Products semplici, Customers ordinari e Orders pagati senza eccezioni può superare i controlli anche se lo store reale contiene opzioni complesse, inventario a livello di variante, dipendenze dai contenuti, collezioni CMS, record dei membri, dati posseduti da app, comportamenti di checkout personalizzati o URL ad alto valore.
Un set di campioni utile dovrebbe includere:
| Gruppo di campioni | Cosa includere | Condizione di superamento |
|---|---|---|
| Products semplici | Products standard con titolo, SKU, prezzo, immagine, descrizione, collezione, valore SEO e inventario. | Il Product compare in Wix con un significato chiaro sia nella vetrina online sia nell’amministrazione. |
| Products complessi | Products con opzioni, scelte, varianti, SKU diversi, prezzi diversi, quantità disponibili diverse, più media, personalizzazione o regole specifiche del Product. | Il funzionamento di varianti e opzioni è sufficientemente chiaro per clienti e personale. |
| Collezioni e scoperta | Products collegati a vecchie Categories, filtri, menu, landing page o gruppi di merchandising. | Il ruolo delle collezioni Wix e le aspettative di navigazione del sito sono distinti e verificati. |
| Orders | Orders pagati, rimborsati, annullati, scontati, tassati, spediti, guest e con più articoli. | Lo storico Orders è leggibile e le relazioni tra Customer e Order sono comprensibili. |
| Identità del Customer | Customers, contatti, membri, guest buyer, iscritti, record loyalty, partecipanti a prenotazioni e partecipanti ad app, quando rilevanti. | Ogni tipo di identità è classificato correttamente e non viene appiattito in un record fuorviante. |
| Contenuti e SEO | CMS Pages, Blog Posts, pagine ricche di media, link interni, URL ad alto valore, metadati e campioni di redirect. | I percorsi importanti per contenuti e traffico dispongono di un piano Wix confermato. |
| Funzionalità personalizzate | App, logica Velo/API, service plugin, dati di catalogo esterni, custom fields e sistemi di terze parti. | Il requisito è assegnato al perimetro standard, a un adeguamento approvato della migrazione, a una gestione non standard, alla configurazione Wix, a un’implementazione esterna o a un’esclusione. |
Il test rappresentativo deve aiutare a decidere se l’approccio scelto per Wix è sufficientemente sicuro da proseguire. Se il campione non include le strutture Wix a rischio più elevato, un risultato positivo ha valore limitato anche quando i record selezionati sembrano corretti.
Il campione dovrebbe includere almeno una relazione che attraversa più applicazioni Wix, per esempio un Customer che è anche membro del sito, un Product visualizzato tramite contenuti CMS personalizzati oppure un Order utilizzato da un’automazione o da un soggetto responsabile dell’evasione. Questi casi fanno emergere problemi di titolarità dei dati che normali Products e Orders pagati non riescono a mostrare.
Validare Products, collezioni, opzioni e varianti in Wix
La validazione dei Products deve partire dal significato del catalogo. Wix Stores organizza i Products in un catalogo e usa le collezioni per raggrupparli. Le opzioni descrivono proprietà selezionabili, le scelte sono i valori disponibili sotto ogni opzione e le varianti rappresentano combinazioni di opzioni e scelte. Poiché le varianti possono contenere valori come prezzo, SKU, peso e inventario, il controllo non deve fermarsi al Product principale.
| Area del catalogo | Cosa validare | Segnale di errore specifico di Wix |
|---|---|---|
| Identità del Product | Nome, SKU, slug, stato, visibilità della pagina Product, gestione dei duplicati e riferimenti. | I Products esistono ma il personale non riesce a identificarli o i clienti non raggiungono la pagina prevista. |
| Contenuto del Product | Descrizioni, media, ordine della galleria, ribbons, etichette, campi SEO e contenuti avanzati dove supportati. | Testo o immagini vengono trasferiti ma non sostengono correttamente l’esperienza della pagina Product Wix. |
| Opzioni e scelte | Taglia, colore, materiale, stile, scelte simili a bundle, personalizzazione e altre selezioni del cliente. | La scelta compare ma perde il significato relativo a dettaglio dell’Order, prezzo, SKU, immagine o inventario. |
| Varianti | SKU, prezzo, inventario, peso, immagine e disponibilità a livello di variante. | Il Product principale sembra corretto, ma i dati specifici della variante sono errati o mancanti. |
| Collezioni | Raggruppamento, merchandising, assegnazione dei Products e ruolo nella scoperta. | La vecchia logica delle Categories viene importata ma non sostiene la navigazione o l’esplorazione effettiva in Wix. |
| Inventario | Quantità per variante, stato tracked/untracked, messaggi di disponibilità e stato di vendita. | La quantità è corretta solo a livello di Product o non corrisponde alla scelta effettivamente acquistabile. |
Il set di validazione deve comprendere Products ordinari e casi limite. Una migrazione verso Wix non è pienamente dimostrata finché non sono stati verificati nella piattaforma di destinazione almeno un Product ricco di varianti, uno ricco di media, uno ad alto traffico, uno sensibile alla disponibilità e uno che dipende fortemente dalle collezioni.
I modificatori dei Products richiedono prove separate rispetto alle opzioni e alle varianti che gestiscono inventario. Occorre verificare testo di personalizzazione, scelte senza inventario, immagini, effetti sul prezzo e dati risultanti nelle righe degli Orders, in modo che una scelta visibile al cliente non venga approvata soltanto perché nella vetrina online assomiglia a una variante.
Validare inventario, disponibilità e contesto di vendita
La validazione dell’inventario deve confermare che le quantità appartengano al record effettivamente vendibile. In Wix, l’inventario è legato al significato dell’elemento di catalogo e della variante. Se lo store di origine registra l’inventario per Product principale, magazzino, canale, marketplace, app o custom field, il risultato in Wix può richiedere controlli più approfonditi di un semplice confronto delle quantità.
Occorre verificare:
- se l’inventario è previsto per il Product o per la variante;
- se l’inventario a livello di variante è preservato dove supportato;
- se stato di stock e disponibilità corrispondono alle aspettative per la messa online;
- se le quantità provenienti da magazzini o canali di origine sono state intenzionalmente incluse, escluse o semplificate;
- se i Products esauriti si comportano come previsto in Wix;
- se visibilità del Product e disponibilità sostengono il funzionamento previsto della vetrina online.
Le anomalie dell’inventario devono essere separate dalla configurazione operativa futura. I valori di stock migrati possono sostenere il lancio, ma l’azienda deve comunque confermare le impostazioni Wix per l’inventario, la gestione continuativa delle quantità, le integrazioni e gli eventuali processi esterni di sincronizzazione.
Validare gli Orders storici separatamente dal checkout operativo
Gli Orders Wix gestiscono il ciclo successivo all’acquisto e includono articoli acquistati, dettagli di pagamento, informazioni di spedizione, stato dell’evasione degli ordini, pagamenti e rimborsi, fatture, evasione degli ordini e impostazioni degli Orders. La validazione dello storico deve confermare che gli Orders migrati restino utili al personale. Non deve essere interpretata come prova che checkout Wix, provider di pagamento, tariffe di spedizione, imposte, regole di evasione, notifiche o impostazioni dei nuovi Orders siano pronti.
| Area dell’Order | Validazione dello storico | Validazione della preparazione futura |
|---|---|---|
| Identità dell’Order | Numero, data, stato, riferimento di origine, collegamento al Customer, comportamento degli Orders guest. | I nuovi Orders vengono creati tramite il percorso di acquisto Wix configurato. |
| Righe dell’Order | Products, varianti, scelte, quantità, prezzi, sconti, imposte, totali e note. | I nuovi Orders registrano correttamente Products e scelte. |
| Pagamenti | Etichette di pagamento storiche, riferimenti delle transazioni, rimborsi e stato del pagamento dove disponibili. | I provider di pagamento Wix e il relativo flusso sono configurati e testati. |
| Evasione | Etichette dei metodi di spedizione, indirizzi, contesto di consegna, stato di evasione, tracking e note. | Spedizione, ritiro, consegna, evasione e notifiche funzionano dopo la configurazione. |
| Sconti e imposte | Valori storici degli sconti, etichette coupon, totali fiscali e significato delle imposte. | Il comportamento futuro di imposte e sconti è configurato e testato in Wix. |
La condizione di superamento deve dichiarare entrambi i risultati: gli Orders storici sono leggibili e la creazione dei nuovi Orders Wix è stata testata attraverso la configurazione della piattaforma di destinazione. L’uno non dimostra automaticamente l’altro.
Quando presenti, includere esempi pagati, non pagati, rimborsati, annullati, parzialmente evasi, digitali e guest. Le prove devono mantenere ciò che è realmente accaduto al momento dell’acquisto e chiarire chi è responsabile della successiva azione operativa, senza ricalcolare lo storico usando le impostazioni correnti dei Products o le regole di checkout attuali.
Validare Customers, contatti, membri e significato CRM
La validazione delle identità in Wix richiede particolare attenzione perché lo store di origine può distinguere Customers, account, iscritti, contatti, membri, utenti loyalty, partecipanti a prenotazioni, utenti che inviano form, utenti wholesale e identità possedute da specifiche app. Wix può gestire informazioni relative a Customers, contatti, membri e CRM tramite funzioni o app differenti.
| Area dell’identità | Cosa validare | Condizione di superamento |
|---|---|---|
| Record Customer | Nomi, email, telefoni, indirizzi di fatturazione/spedizione e relazioni con gli Orders. | Il personale può collegare i Customers agli Orders migrati e allo storico di assistenza. |
| Guest buyer | Orders associati ad acquirenti senza un account completo. | Lo storico guest resta leggibile senza suggerire l’esistenza di un account membro completo. |
| Contatti e contesto CRM | Dati di contatto, significato dell’iscrizione, contesto dei form, tag, note o stato marketing dove supportati. | Il significato del contatto non viene confuso con lo storico commerciale degli Orders. |
| Membri | Iscrizione al sito, aspettative di login, regole di accesso, piani a pagamento o contenuti riservati quando rilevanti. | Il comportamento dei membri è configurato o incluso separatamente nel perimetro, non presunto dalla migrazione dei Customers. |
| Identità possedute da app | Loyalty, prenotazioni, abbonamenti, forum, corsi o altre partecipazioni gestite da app. | I record sono assegnati al perimetro standard, alla configurazione Wix, a una gestione non standard, al lavoro di terze parti o a un’esclusione. |
L’obiettivo è mantenere una continuità pratica dell’identità. Se il personale riesce a trovare il corretto acquirente e comprenderne il contesto storico, la migrazione di base dei Customers può essere utilizzabile. Se invece lo store di origine dipende da accesso membri, dati loyalty, abbonamenti o automazioni CRM, queste aspettative richiedono una verifica separata.
È utile testare intenzionalmente le collisioni di identità. La stessa email può comparire tra contatti, Customers, membri, iscritti o record di app, ma la destinazione deve mantenere accesso, visibilità degli Orders, consensi, permessi, indirizzi e chiavi CRM esterne secondo il rispettivo proprietario, senza appiattire ogni persona in un unico profilo generico.
Validare CMS Pages, Blog Posts, media, URL e continuità SEO
Wix è una piattaforma commerciale basata sulla costruzione del sito, quindi la validazione deve includere contenuti e continuità del traffico quando rientrano nel perimetro. La sola migrazione dei Products non dimostra che il sito Wix sia pronto. CMS Pages importanti, Blog Posts, librerie multimediali, pagine dinamiche, link interni, menu, redirect, page title, meta description, aspettative canoniche, alt text e domini possono incidere sulla qualità della messa online.
| Area del sito | Cosa validare | Perché è importante |
|---|---|---|
| CMS Pages | Contenuto, link interni, immagini, dipendenze dal layout e stato di pubblicazione. | Le pagine possono sostenere fiducia, policy, guida all’acquisto o SEO. |
| Blog Posts | Titoli, slug, contenuti, immagini, Categories/tag dove supportati e link interni. | I contenuti del blog possono generare traffico organico e aiutare i clienti a comprendere l’offerta. |
| Media | Immagini Products, immagini delle pagine, asset delle gallerie, nomi file, contesto alt e posizionamento. | La disponibilità del file non dimostra il corretto posizionamento dell’immagine o la prontezza della pagina. |
| URL e redirect | URL prioritari di Products, collezioni, CMS Pages, Blog Posts e landing page. | I vecchi percorsi di traffico devono avere una gestione Wix accettata. |
| Campi SEO | Page title, meta description, heading visibili, contenuti sensibili all’indicizzazione e link interni. | Il lancio su Wix può perdere valore SEO se vengono controllati soltanto i Products. |
| Dominio e contesto multilingue | Assegnazione del dominio, comportamento degli URL pubblicati, percorsi linguistici e logica dei redirect. | Messa online e continuità del traffico dipendono da elementi ulteriori rispetto alla migrazione dei contenuti. |
La validazione deve mantenere chiaro il confine tra attività. Migrare i contenuti supportati è una cosa. Ricostruire layout, ridisegnare pagine, configurare menu, impostare domini, pubblicare il sito, rifinire la resa mobile e gestire strumenti di analisi possono essere attività Wix o lavori esterni alla migrazione.
Le pagine dinamiche e i contenuti collegati al CMS devono essere testati insieme agli elementi delle collezioni, ai media, ai permessi e ai pattern di percorso da cui dipendono. Un testo migrato non è una prova sufficiente se il relativo riferimento all’insieme di dati, il link interno, la destinazione canonica o la restrizione per i membri non funziona più nel sito Wix.
Validare app, logica Velo/API, service plugin e sistemi esterni
Wix può essere esteso con app, sviluppo Velo/API, collezioni CMS, cataloghi personalizzati, estensioni per checkout e spedizioni, servizi di pagamento esterni, form, prenotazioni, membri, abbonamenti, loyalty e integrazioni di terze parti. Anche lo store di origine può contenere record appartenenti ad app, plugin o moduli che non hanno una destinazione Wix standard. La validazione deve distinguere ciò che viene migrato, ciò che va configurato, ciò che va ricostruito e ciò che viene escluso.
| Tipo di dipendenza | Domanda di validazione | Percorso di gestione probabile |
|---|---|---|
| App Wix | L’app di destinazione richiede dati, configurazione o una gestione di migrazione separata? | Configurazione Wix, importazione dell’app, lavoro di terze parti o valutazione per gestione non standard. |
| Logica Velo/API | Il funzionamento dipende dal codice anziché dai dati? | Ricostruzione, implementazione esterna o valutazione per gestione non standard. |
| Collezioni CMS | I record sono contenuti, dati di pagine dinamiche, dati simili a Products oppure dati operativi? | Perimetro standard, adeguamento approvato della migrazione, gestione non standard o configurazione Wix, secondo il funzionamento richiesto. |
| Service plugin | Checkout, spedizione, imposte, pagamento o evasione dipendono da logica personalizzata? | Configurazione Wix, implementazione del service plugin o valutazione per gestione non standard. |
| Sistemi esterni | ERP, CRM, PIM, WMS, contabilità o marketplace richiedono continuità dei record? | Implementazione esterna, valutazione per gestione non standard o esclusione accettata. |
La condizione di superamento non è che “tutte le app funzionino”. È necessario che ogni dipendenza critica per il business sia identificata e assegnata a un percorso di gestione realistico.
Per ogni dipendenza critica, occorre dimostrare quale record Wix o esterno sia l’autorità e quale identificatore lo colleghi a Products, Customers, membri o Orders. Il test dovrebbe includere un percorso reale di lettura o evento e anche un caso di errore: il fatto che il codice venga eseguito senza errori non dimostra che recuperi il record corretto o includa tutto lo stato richiesto.
Validare risultati rappresentativi, più ampi e successivi su Wix
Il test rappresentativo su Wix deve far emergere le questioni di titolarità specifiche della piattaforma usando Products, opzioni, modificatori, varianti, collezioni, stati di inventario, Customers, contatti, membri, Orders eccezionali, CMS Pages, Blog Posts, URL prioritari, record appartenenti ad app e relazioni Velo o con sistemi esterni. L’esecuzione di migrazione più ampia deve poi dimostrare che l’interpretazione accettata rimane completa anche per Products rari, Customers meno recenti, Orders guest, rimborsi, contenuti inattivi, percorsi ad alto valore e ogni risultato di dati personalizzati concordato.
La rivalidazione su Wix deve ampliarsi in funzione della configurazione e delle relazioni modificate dall’azione successiva.
| Azione successiva | Rivalidazione Wix richiesta |
|---|---|
| proseguire con la configurazione accettata | Confermare che Products, Customers, Orders, Blog Posts, varianti, collezioni, relazioni dei membri, percorsi e identificatori esterni successivi continuino a seguire la configurazione approvata. |
| proseguire con una configurazione rivista | Ricontrollare ogni filtro, mappatura, selezione dei tipi di dati, decisione su opzioni o modificatori dei Products, relazione CRM, regola dei contenuti e risultato dei dati personalizzati modificato, quindi ripetere gli scenari interessati nella vetrina online e nel pannello di amministrazione. |
| produrre un nuovo risultato di migrazione distinto | Stabilire una nuova base di evidenza e ripetere il test rappresentativo e le decisioni rilevanti dell’esecuzione più ampia per il nuovo risultato, senza ereditare l’approvazione dallo stato Wix precedente. |
Decidere la preparazione al lancio di Wix con Pass, Watch o Block
L’approvazione della messa online su Wix dovrebbe classificare le evidenze come Pass, Watch o Block. Lo stato deve essere associato a un Product, variante, modificatore, collezione, Customer, membro, Order, percorso di contenuto, record di app, relazione Velo o risultato concordato specifico.
| Stato decisionale | Evidenza richiesta | Significato per la messa online |
|---|---|---|
| Pass | Il funzionamento atteso di catalogo, storico, CRM, contenuti o integrazioni è riproducibile e non rimangono punti rilevanti non chiariti. | L’area esaminata può sostenere la messa online. |
| Watch | Il risultato migrato è utilizzabile, ma resta un’attività non bloccante documentata relativa a layout, merchandising, area membri, automazioni, configurazione del checkout o integrazioni. | La messa online può procedere solo con un responsabile, una scadenza e una successiva verifica. |
| Block | Un Product rilevante non è acquistabile, il significato di variante o inventario è errato, il contesto di Customer/membro o Order è fuorviante, un percorso prioritario non funziona oppure una relazione critica con app o sistema esterno non è utilizzabile. | L’approvazione della messa online viene sospesa finché non viene apportata una correzione o accettata formalmente una decisione sul perimetro. |
Per Wix, confrontare i risultati concordati con i filtri Products approvati, i mappatura delle collezioni CMS, le relazioni dei membri e il risultato delimitato della configurazione. Le attività di migrazione non standard concordate devono essere verificate rispetto ai record delle collezioni CMS accettati, ai dati di app non supportati, alle relazioni Velo/API, ai campi dei service plugin, agli identificatori esterni o alle trasformazioni su misura. La validazione conferma il risultato concordato; non implica l’implementazione di design Wix, app, codice, automazioni, pagamenti, spedizioni, imposte o evasione degli ordini salvo inclusione esplicita.
Il report di validazione deve registrare comportamento atteso, risultato osservato, stato decisionale, responsabile, percorso di gestione e prova del nuovo test. In questo modo gli output della migrazione restano distinti dalla configurazione Wix e i difetti irrisolti relativi a dati e relazioni non possono essere nascosti in una checklist generica di lancio.
Conclusione
La validazione di Wix deve dimostrare che il risultato migrato è utilizzabile come ambiente integrato di sito e commercio Wix. Products, collezioni, opzioni, varianti, inventario, Orders, Customers, contatti, membri, CMS Pages, Blog Posts, media, URL, redirect, app, logica Velo/API, service plugin e sistemi esterni richiedono tutti un livello di verifica adeguato.
Un processo solido distingue la presenza dei record dal loro significato operativo, la leggibilità degli Orders storici dalla configurazione del checkout futuro, i dati Customer dal comportamento di membri e accessi e i contenuti migrati dalla configurazione necessaria alla messa online su Wix. Il risultato dovrebbe essere un report chiaro che identifichi ciò che ha superato i controlli, ciò che richiede correzioni, ciò che rientra negli adeguamenti di migrazione approvati, ciò che richiede una valutazione per gestione non standard, ciò che deve essere configurato in Wix e ciò che è intenzionalmente escluso dal perimetro.
Domande frequenti
Cosa deve dimostrare il test rappresentativo per Wix?
Deve confermare l’interpretazione dei Products con molte opzioni e modificatori, delle varianti, dell’inventario, delle collezioni, delle relazioni tra Customer, contatto e membro, degli Orders eccezionali, delle CMS Pages, dei Blog Posts, degli URL prioritari e di almeno un record appartenente a un’app, a Velo o a un sistema esterno.
La corrispondenza del numero di Products è sufficiente per validare una migrazione verso Wix?
No. I conteggi non dimostrano il comportamento di opzioni rispetto ai modificatori, prezzo e stock a livello di variante, scoperta tramite collezioni, significato Customer/membro, leggibilità degli Orders storici, percorsi dei contenuti o titolarità dei dati delle app.
Gli Orders storici e il checkout operativo di Wix devono essere validati separatamente?
Sì. Gli Orders storici dimostrano articoli acquistati, totali, sconti, imposte, spedizione, riferimenti di pagamento, rimborsi e contesto dell’evasione. Pagamenti, spedizioni, imposte, checkout, notifiche e funzionamento dei soggetti che evadono gli ordini richiedono prove separate sulla configurazione Wix.
Come devono essere validati Customers, contatti e membri in Wix?
Occorre confermare quale identità rappresenti ogni record, se email o indirizzi duplicati rimangano comprensibili, quali persone possano accedere e se visibilità degli Orders, campi CRM, permessi, abbonamenti o relazioni con app richiedano una gestione separata.
Quando un risultato della validazione Wix deve essere classificato come Block?
Si usa Block quando un Product non può essere acquistato correttamente, il significato di Customer/membro o Order è errato, un percorso prioritario non funziona oppure un output approvato relativo ad adeguamento della migrazione, gestione non standard, app, Velo o integrazione è inutilizzabile.
Cosa va rivalidato dopo una successiva azione di migrazione verso Wix?
Devono essere rivalidati tutti i Products, Customers, Orders, Blog Posts, varianti, collezioni, relazioni dei membri, percorsi dei contenuti, record di app e identificatori esterni interessati. Una configurazione modificata o un nuovo risultato richiedono prove più ampie rispetto a una prosecuzione senza variazioni.