Se Wix viene scelto come piattaforma di destinazione, la preparazione deve separare record commerce, contenuti del sito, identità Member, dati CRM, collezioni CMS, applicazioni e codice personalizzato prima che inizi qualsiasi esecuzione della migrazione. Wix Stores, Wix Contacts, Wix Members, Wix CMS, Wix Blog e l’ecosistema più ampio di applicazioni Wix possono partecipare allo stesso sito, ma non possiedono gli stessi record.
Un pacchetto di preparazione efficace registra quattro elementi per ogni area principale: azione richiesta, responsabile, evidenza da fornire e condizione che consente di considerare l’area pronta. Questo evita di confondere un record Product con un’implementazione completa della vetrina online, un Contact con un Member o una collezione CMS con dati posseduti da un’app.
Confermare il modello operativo del sito e del commerce Wix
Definire quali prodotti e livelli del sito Wix saranno operativi nello store di destinazione.
| Area di preparazione | Decisione da registrare | Responsabile | Evidenza di prontezza |
|---|---|---|---|
| Wix Stores | Stabilire se Products, checkout, Orders, inventario ed evasione sono centrali nella destinazione | Responsabile commerce | Sintesi del modello operativo dello store |
| Struttura del sito Wix | Definire quali pagine, menu, pagine dinamiche, aree Member e route regionali sono richiesti | Responsabile sito | Mappa di pagine e navigazione |
| Wix Contacts e Members | Stabilire quali identità sono Contacts, Customers, Members, subscribers o partecipanti alle app | Responsabile Customer | Matrice di classificazione delle identità |
| Wix CMS | Definire quali collezioni personalizzate, riferimenti, permessi e pagine dinamiche restano necessari | Responsabile contenuti/dati | Inventario di collezioni e relazioni |
| App Wix | Stabilire quali record appartengono a Wix Blog, Bookings, Pricing Plans, Reviews, Events o altre applicazioni | Responsabili applicativi | Registro delle dipendenze per app |
| Sistemi esterni | Definire quali ERP, PIM, WMS, CRM, marketplace, sistemi fiscali, di spedizione o strumenti di analisi restano autoritativi | Responsabile tecnico | Mappa dei system of record |
Il modello operativo è pronto quando ogni famiglia principale di record ha un solo proprietario Wix o esterno previsto e il team del sito distingue chiaramente ciò che appartiene ai dati di migrazione da ciò che appartiene alla configurazione Wix.
Preparare accessi, archivi di origine e responsabilità sulle modifiche
Raccogliere:
- accesso amministratore alla piattaforma di origine e al sito Wix;
- permessi richiesti per Wix Stores, Contacts, Members, CMS, Blog, applicazioni, domini e SEO;
- export o backup datati di Products, Customers, Orders, contenuti, media, Categories, URL, Reviews e dati personalizzati;
- export delle applicazioni e documentazione API quando disponibili;
- identificatori esterni usati da ERP, CRM, magazzino, marketplace o sistemi di evasione;
- un responsabile delle modifiche di origine per Products, Customers, Orders, contenuti e inventario durante la finestra di migrazione.
| Elemento di evidenza | Perché è importante | Condizione di prontezza |
|---|---|---|
| Registro accessi | Conferma che le aree di origine e Wix necessarie possono essere ispezionate | I responsabili dispongono dei permessi necessari |
| Archivio di origine datato | Conserva uno stato di riferimento recuperabile | I file si aprono correttamente e includono le date di esportazione |
| Archivio media | Protegge media Product, pagine, Blog Posts e CMS | File e relazioni di origine sono identificabili |
| Inventario delle app | Fa emergere record esterni ai normali export di catalogo e contenuti | Ogni app attiva ha un responsabile e una fonte di evidenza |
| Registro degli ID esterni | Protegge sincronizzazione e riconciliazione | Ogni chiave è assegnata al corretto livello di entità |
| Registro modifiche | Registra gli aggiornamenti di origine successivi all’archivio di riferimento | Modifiche a Product, Order, Customer, contenuti e inventario hanno responsabili definiti |
Quando un’applicazione di origine non può fornire un export, registrare la limitazione e il responsabile invece di trattare il dato come inesistente.
Preparare Products, opzioni, varianti, modifiers e media
Wix Catalog V3 rappresenta ogni Product attraverso almeno una variante. Le opzioni Product creano varianti, mentre i modifiers raccolgono informazioni aggiuntive senza creare varianti. Preparare famiglie di Products rappresentative che rendano visibili queste differenze.
Includere:
- Products semplici con una sola variante predefinita;
- Products con diverse combinazioni di opzioni;
- SKU, barcode, prezzo, costo, peso, media e stock specifici per variante;
- modifiers come messaggi regalo, personalizzazioni o selezioni aggiuntive;
- Products digitali e file digitali a livello variante quando rilevanti;
- Products con brand, ribbons, info sections, Categories e customizations riutilizzabili;
- bundle, subscriptions, Bookings o comportamenti Product posseduti da app;
- identificatori ERP, PIM, marketplace, fornitore ed evasione.
| Comportamento di origine | Decisione di preparazione | Evidenza richiesta | Condizione di prontezza |
|---|---|---|---|
| Una scelta crea una combinazione vendibile | Definire scelte di opzione e titolarità della variante | ID padre/figlio, SKU, prezzo, peso, media e stock | Ogni combinazione ha una sola variante Wix prevista |
| Una scelta raccoglie informazioni dell’acquirente | Definire titolarità modifier o app | Tipo di input, valori consentiti, effetto sul prezzo ed esempio di riga Order | Il valore non viene classificato erroneamente come elemento con inventario |
| Il Product contiene dati descrittivi strutturati | Definire proprietario tra campo Product, info section, brand, Category, CMS o app | Schema del campo e consumer che continuerà a usarlo | Ogni campo ha un proprietario Wix o esterno definito |
| Il comportamento del Product appartiene a un’app | Identificare l’app che continuerà a gestirlo o la sostituzione | Record Product collegati ed evidenza di configurazione | I dati app richiesti sono inclusi nel registro dipendenze |
| Il Product usa dati master esterni | Definire system of record e chiave | ID ERP/PIM ed esempi di lookup | Ogni identificatore resta associato al Product o alla variante corretta |
L’area catalogo è pronta quando ogni modello Product importante ha una struttura Product–variante–opzione–modifier definita e le evidenze di origine distinguono i dati Product riutilizzabili da record inseriti dal cliente o posseduti dalle applicazioni.
Preparare locations di inventario e regole di disponibilità
In Wix Catalog V3 l’inventario è tracciato a livello variante-location. Ogni Inventory Item collega una variante a una location di inventario e può usare quantità o tracking dello stato in-stock, con impostazioni di preorder quando applicabili.
Preparare:
- elenco di magazzini, store, centri di evasione e locations virtuali;
- location di inventario Wix predefinita;
- identificatori Product e variante usati da ogni fonte stock;
- esempi di quantità, stato in-stock, disponibilità illimitata, preorder e indisponibilità;
- assegnazioni dalle locations di origine alle locations Wix;
- futuro system of record dell’inventario;
- quantità iniziali e timestamp o snapshot di origine che rappresentano.
| Caso di inventario | Responsabile | Evidenza | Condizione di prontezza |
|---|---|---|---|
| Stock in una sola location | Responsabile inventario | Report quantità per variante | Ogni quantità viene collegata a una variante Wix nella location predefinita |
| Stock multi-location | Responsabile operations | Matrice variante-location | Ogni location di origine ha una destinazione Wix o esterna prevista |
| Stock gestito da ERP o WMS | Responsabile integrazione | Chiave di sistema ed esempio di sincronizzazione | Valori iniziali Wix e autorità futura sono documentati |
| Product in preorder | Responsabile merchandising | Regole preorder variante-location | Capacità di preorder e titolarità della disponibilità sono chiare |
| Tracking in-stock senza quantità | Responsabile catalogo | Products rappresentativi e valori di stato di origine | Gli stati di disponibilità non vengono confusi con quantità numeriche |
Non sommare lo stock specifico per location a meno che il target non debba intenzionalmente usare un unico pool consolidato. La condizione di prontezza è una mappatura controllata tra identità vendibile e location di origine e Inventory Item Wix previsto.
Preparare Contacts, Members, Customers e contesto marketing
Wix Contacts e Wix Members sono collegati ma distinti. I Contacts possono contenere identità, label, stato subscription e campi estesi. I Members dispongono di Member ID, stato account, visibilità profilo e relazioni con Members Area. Commerce Customers e partecipanti alle app possono aggiungere ulteriore contesto.
Preparare:
- acquirenti registrati, guest, subscribers, Contacts, Members e partecipanti alle app;
- esempi di email e telefono duplicati;
- Contact labels, custom fields, stato subscription ed evidenze del consenso;
- requisiti di stato Member, privacy, profilo, badge e custom fields;
- indirizzi e relazioni con Orders storici;
- titolarità di loyalty, Bookings, Pricing Plans, community o CRM;
- identificatori esterni Contact, Customer e Member.
| Tipo di identità | Responsabile preparazione | Evidenza richiesta | Condizione di prontezza |
|---|---|---|---|
| Acquirente o guest | Customer operations | Esempi Customer e Order | Il contesto commerce storico è collegato al Contact o Customer previsto |
| Contact | Responsabile CRM | Labels, campi, stato subscription e fonte del consenso | Il significato del Contact è documentato indipendentemente dalla membership |
| Member del sito | Responsabile Member Area | Member ID, Contact ID, stato, profilo e aspettative di accesso | Identità Member e Contact non vengono trattate come ID intercambiabili |
| Partecipante ad app | Responsabile applicativo | Record Booking, plan, loyalty, Review o community | La relazione applicativa ha un proprietario che continuerà a gestirla |
| Record CRM esterno | Responsabile integrazione | ID CRM e regola di matching | La chiave durevole è associata all’identità Wix corretta |
L’autenticazione va preparata separatamente dall’identità. Se le password di origine non possono essere riutilizzate, registrare responsabile e requisito di comunicazione al Customer senza trattare la portabilità della password come normale dato Customer.
Preparare Orders storici e contesto delle transazioni
Selezionare Orders che rendano visibili identità Product e variante, modifiers, sconti, imposte, billing, shipping, pagamento, transazioni, evasione, rimborsi e riferimenti esterni.
Includere:
- Orders ordinari, annullati, rimborsati e parzialmente evasi;
- Orders con Products in variante e modifiers;
- Orders di guest e Customers registrati;
- più spedizioni o record di evasione;
- Orders provenienti da applicazioni rilevanti per Wix o canali esterni;
- riferimenti marketplace, contabilità, ERP, WMS, CRM o supporto.
| Area storica | Evidenza | Condizione di prontezza |
|---|---|---|
| Articoli acquistati | Esempi di Product, variante, modifier, quantità e prezzo | La configurazione acquistata può essere spiegata usando il pacchetto di origine |
| Contesto Customer | Identità guest/registrata e indirizzi | La relazione Contact, Customer o Member prevista è documentata |
| Contesto pagamenti e rimborsi | Esempi di metodo, transazione, rimborso e totale | I riferimenti storici sono separati dalla configurazione pagamento Wix corrente |
| Contesto evasione | Esempi di spedizione, tracking, stato e allocazione per riga | L’evasione passata può essere compresa senza configurare la spedizione attiva |
| Lineage esterno | ID Order dei sistemi collegati | Le chiavi di riconciliazione sono conservate al corretto livello Order |
Gli Orders storici preservano il commerce passato. Configurazione corrente di checkout Wix, pagamenti, evasione, notifiche e aggiornamenti inventario resta preparazione separata in carico ai responsabili del sito e delle operations.
Preparare collezioni CMS, pagine, Blog Posts, media e URL
Wix CMS può contenere collezioni personalizzate, data items, campi di riferimento, permessi, indici, relazioni con pagine dinamiche e connessioni a database esterni. Le app collezioni Wix possono rispecchiare dati posseduti dalle applicazioni Wix. Preparare questi livelli separatamente.
Raccogliere:
- schemi delle collezioni CMS, campi, riferimenti, permessi e indici;
- data items rappresentativi e riferimenti padre-figlio;
- pagine dinamiche e campi collezione usati nelle route;
- CMS Pages, Wix Blog Posts, contenuti Product e Category e contenuti posseduti dalle applicazioni;
- inventari di immagini, video, file e alt text;
- URL ad alto valore, metadati, link interni, menu, redirect e piani di dominio;
- titolarità dei database esterni e dipendenze di connessione.
| Area contenuti | Responsabile | Evidenza richiesta | Condizione di prontezza |
|---|---|---|---|
| Collection CMS | Responsabile dati/contenuti | Schema, campi, riferimenti, permessi e item campione | Ogni collezione ha una finalità business e una route o un consumer |
| Collection di app Wix | Responsabile applicativo | Nome app, record di origine e aspettative di lettura/scrittura | I dati posseduti dall’app non vengono trattati come normale collezione personalizzata |
| CMS Page o Blog Post | Responsabile editoriale | Contenuto, contesto autore/data, media, metadati e URL di origine | Ogni record ha un proprietario contenuto Wix e una route previsti |
| Pagina dinamica | Responsabile sito | Collection, campo slug, campi di riferimento e mappatura della pagina | La pagina può essere ricostruita dalle relazioni documentate |
| URL prioritario | Responsabile SEO | Percorso di origine, destinazione, redirect e decisione di ritiro | Ogni percorso ad alto valore ha un esito approvato |
I redirect URL Wix hanno vincoli specifici della piattaforma; i pattern di origine non supportati devono essere identificati nel registro delle route prima dell’esecuzione della migrazione, non dopo la dismissione dei percorsi di origine.
Inventariare app, logica Velo, API e sistemi esterni
Creare un registro delle dipendenze per ogni app Wix, app di origine, API, webhook, automazione, funzione Velo, service plugin, database esterno e piattaforma business collegata.
Per ciascuna dipendenza, registrare:
- finalità business;
- Products, varianti, Contacts, Members, Orders, item CMS o contenuti interessati;
- sistema autoritativo e ID esterni;
- disponibilità di export o API;
- responsabile di configurazione e credenziali;
- decisione su continuazione nella destinazione, sostituzione o ritiro;
- evidenza di origine necessaria prima di configurare il flusso di destinazione.
Tra le dipendenze prioritarie rientrano ERP, PIM, WMS, CRM, sistemi fiscali, spedizione, marketplace, loyalty, subscriptions, Bookings, Events, Pricing Plans, iscrizioni, Reviews, ricerca, strumenti di analisi e piattaforme marketing.
Il registro è pronto quando ogni custom field attivo o record applicativo ha un responsabile, un’entità padre, un consumer che continuerà a utilizzarlo e una chiave durevole.
Selezionare campioni rappresentativi per i test di migrazione
| Campione | Finalità della preparazione |
|---|---|
| Product semplice | Stabilire il modello ordinario Product e variante predefinita |
| Product con diverse opzioni e varianti | Rendere visibili titolarità di opzioni, SKU, media, prezzi e varianti |
| Product con modifiers | Rendere visibili relazioni tra input dell’acquirente e riga Order |
| Inventory Item multi-location | Rendere visibili titolarità variante-location e autorità sullo stock |
| Contact collegato a un Member | Rendere visibili ID Contact e Member distinti e contesto del profilo |
| Order storico complesso | Rendere visibili varianti, modifiers, pagamento, rimborso, evasione e ID esterni |
| Collection CMS con riferimenti | Rendere visibili schema, collegamenti padre-figlio, permessi e pagine dinamiche |
| Route di contenuto prioritaria | Rendere visibili titolarità di CMS, Blog, media, URL e redirect |
| Record posseduto da app o sistema esterno | Rendere visibili applicazione che continuerà a gestirlo e identificatori padre stabili |
Per ogni campione registrare ID di origine, URL di origine quando rilevante, motivo business, proprietario Wix previsto, esclusioni note, chiavi esterne e revisore responsabile.
Completare il gate di preparazione di Wix
| Domanda di prontezza | Evidenza richiesta | Condizione di prontezza |
|---|---|---|
| Accessi e archivi di origine sono recuperabili? | Registro accessi ed export/backup datati | I record richiesti possono essere ispezionati indipendentemente dal sistema di origine attivo |
| Il modello operativo Wix è definito? | Mappa di titolarità per sito, Stores, Contacts, Members, CMS e app | Ogni famiglia principale di record ha un solo proprietario previsto |
| Strutture Product e inventario sono preparate? | Matrici Product/variante/modifier e variante-location | Ogni modello vendibile importante ha una rappresentazione definita |
| Le relazioni di identità sono preparate? | Classificazione Contact/Member/Customer e regole di matching | ID, consenso, accesso e relazioni applicative sono documentati |
| Evidenze Orders e contenuti sono complete? | Pacchetto Orders storici e registro contenuti/URL | Transazioni e route sono spiegabili dai dati di origine |
| App e sistemi esterni sono inventariati? | Registro dipendenze | Ogni dipendenza critica ha un proprietario che continuerà a gestirla |
| Sono stati selezionati campioni rappresentativi? | Registro campioni | Complessità di catalogo, inventario, identità, Orders, CMS e integrazioni è coperta |
| Gli elementi irrisolti sono sotto controllo? | Registro decisioni | Ogni elemento aperto ha un responsabile e una scadenza |
Il gate è completo quando nessuna decisione critica su Product, inventario, Contact, Member, Order, CMS, URL, app o sistema esterno dipende da un presupposto non documentato.
Conclusione
La preparazione per Wix deve produrre un pacchetto di evidenze per sito e commerce che separi Wix Stores, Contacts, Members, CMS, Blog, applicazioni e sistemi esterni. I Products devono essere collegati alle reali varianti e ai modifiers, l’inventario deve essere assegnato per variante e location, i record di identità devono mantenere ruoli distinti e dati CMS o app devono avere proprietari definiti.
Quando queste decisioni vengono documentate prima del test di migrazione rappresentativo, i campioni possono mettere alla prova l’architettura Wix prevista senza trasformare design del sito, accesso account o configurazione attiva in presupposti sui dati di migrazione.
Domande frequenti
Cosa va preparato per primo per una migrazione verso Wix?
Partire dalla mappa di titolarità Wix. Definire quali record appartengono a Wix Stores, Contacts, Members, CMS, Blog, altre app Wix e sistemi esterni prima di preparare export dettagliati.
Perché opzioni Product e modifiers Wix vanno preparati separatamente?
Le opzioni creano varianti, mentre i modifiers raccolgono informazioni aggiuntive senza creare varianti. Combinarli può generare SKU artificiali o eliminare dalle righe Order storiche i valori inseriti dall’acquirente.
Come va preparato l’inventario multi-location?
Preparare una matrice variante-location con quantità di origine, metodi di tracking, regole di preorder, ID delle locations e futuro system of record. Non ridurre i dati a una sola quantità del Product padre a meno che il consolidamento sia intenzionale.
Wix Contacts e Members sono lo stesso record?
No. I Members sono normalmente collegati ai Contacts, ma Member ID e Contact ID sono distinti e i record svolgono funzioni diverse per account, profilo, privacy e CRM.
Cosa va preparato per le collezioni Wix CMS?
Documentare finalità, schema, campi, riferimenti, permessi, indici, item rappresentativi, pagine dinamiche, connessioni a database esterni e proprietario che continuerà a gestire ogni collezione.
Quando la preparazione di Wix può considerarsi completa?
È completa quando accessi, Products, locations di inventario, Contacts, Members, Orders, contenuti, collezioni CMS, route, app, sistemi esterni, campioni ed elementi irrisolti dispongono tutti di responsabili definiti ed evidenze recuperabili.