Quando Wix viene valutato come piattaforma di destinazione, i principali rischi nascono dal tentativo di rappresentare nello stesso ambiente dati e comportamenti che nello store di origine possono appartenere a database, tema, script di checkout, estensioni Product o applicazioni diverse. Wix combina commerce, creazione del sito, dati CMS, funzionalità di relazione con i Customers, Members, applicazioni e comportamento programmabile all’interno di una piattaforma gestita, ma questi domini non diventano automaticamente un unico tipo di dato Wix Stores.
L’architettura attuale del catalogo Wix introduce inoltre un confine importante: Catalog V3 utilizza varianti universali, separa opzioni e modifiers e gestisce l’inventario per variante e location. Gli Orders appartengono a un dominio eCommerce più ampio che comprende separatamente fatturazione, transazioni, invoices, evasione e impostazioni. Collections CMS e campi di riferimento possono sostenere applicazioni personalizzate del sito, ma non sostituiscono automaticamente entità Product, Customer, Order o possedute dalle app.
Ogni catena di rischio deve quindi rendere espliciti il presupposto di partenza, il vincolo di Wix, la conseguenza sulla migrazione, l’impatto operativo, la direzione di mitigazione e il segnale di controllo.
Confini tra sito hosted, commerce, CMS e applicazioni
Wix non espone un database target generico in cui copiare qualsiasi tabella di origine. I dati devono appartenere a Wix Stores, eCommerce Orders, Contacts, Members, collezioni CMS, un’applicazione Wix, codice Velo, un service plugin o un sistema esterno. Design del sito e comportamento delle pagine dinamiche rappresentano ulteriori livelli distinti.
| Presupposto di origine | Vincolo Wix | Conseguenza sulla migrazione | Impatto operativo | Indicazione di mitigazione | Segnale di controllo |
|---|---|---|---|---|---|
| Le tabelle di origine possono essere riprodotte direttamente. | Wix usa risorse business definite, schemi CMS, applicazioni e API. | Record personalizzati vengono appiattiti in campi o inseriti nel dominio sbagliato. | Il personale perde stato dei flussi, contesto di reportistica o collegamenti esterni. | Classificare ogni entità non standard per proprietario e ciclo di vita prima della mappatura. | Ogni record richiesto ha un solo proprietario Wix o esterno supportato. |
| Tema e dati del page builder migrano insieme ai record. | Pagine, sezioni, pagine dinamiche, template e presentazione mobile di Wix sono implementazione della destinazione. | I contenuti esistono senza layout o interazioni che li rendevano utilizzabili. | Percorsi importanti risultano incompleti anche quando i dati commerce sono presenti. | Separare contenuti e riferimenti durevoli dall’implementazione della presentazione. | Ogni pagina chiave ha proprietario chiaro per contenuto, percorso e comportamento. |
| Gli script checkout sono normali campi Order. | Il comportamento del checkout attivo dipende da impostazioni Wix, estensioni, service plugin, app e percorsi di codice supportati. | Fee, regole di approvazione, input personalizzati o comportamento dei provider scompaiono. | I nuovi Orders non possono seguire le regole operative richieste. | Rappresentare separatamente i dati storici e assegnare il comportamento futuro a un proprietario che continuerà a gestirlo. | La regola business richiesta ha un proprietario di implementazione Wix o esterno esplicito. |
| I record delle app fanno parte del core Wix Stores. | Bookings, Events, Restaurants, Pricing Plans, loyalty, subscriptions e altre app possiedono entità separate. | Record specializzati vengono appiattiti in Contacts, Products o note Order. | Pianificazioni, diritti, saldi o cronologia dei partecipanti diventano inutilizzabili. | Preservare i riferimenti ai record padre e spostare il record specializzato nel suo dominio reale. | L’applicazione che continuerà a operare riconosce Contact, Product e transazione previsti. |
Questo confine è alla radice di molti rischi Wix e va risolto prima che i singoli campi vengano trattati come ambito della migrazione.
Rischio di lineage tra Catalog V1, Catalog V3 e Products
Catalog V3 di Wix non è semplicemente un nuovo nome per un endpoint. Utilizza varianti universali: ogni Product ha almeno una variante, anche senza opzioni. Le opzioni creano varianti e incidono sull’inventario. I modifiers raccolgono informazioni aggiuntive senza creare varianti. Gli Inventory Items vengono gestiti separatamente e possono rappresentare una variante in una location.
Store di origine e integrazioni Wix meno recenti possono riflettere ancora presupposti di Catalog V1. Il rischio aumenta quando record legacy o di origine vengono rappresentati senza definire quale generazione di catalogo e quale granularità Product userà lo store di destinazione.
| Presupposto | Vincolo del catalogo | Conseguenza sulla migrazione | Impatto operativo | Direzione di mitigazione | Segnale di controllo |
|---|---|---|---|---|---|
| Un Product senza opzioni non ha variante. | Catalog V3 usa una variante universale predefinita. | ID a livello Product e stock vengono rappresentati in modo incoerente con sistemi basati sulle varianti. | Aggiornamenti di inventario e integrazioni non trovano l’unità vendibile corretta. | Definire un’identità variante nella destinazione per ogni Product, inclusi i Products semplici. | Ogni Product ha una variante vendibile stabile riconosciuta dalle integrazioni. |
| I record Catalog V1 e V3 sono intercambiabili. | V3 modifica confini tra Product, variante, customization, inventario e servizi collegati. | ID o relazioni vengono riutilizzati sotto il modello sbagliato. | La sincronizzazione del catalogo crea duplicati o perde modifiche alle varianti. | Registrare lineage del catalogo di origine e mappa delle entità V3 di destinazione. | Ogni Product e variante di origine viene risolto una sola volta nel catalogo target. |
| La creazione Product genera automaticamente tutte le relazioni di inventario. | Product e Inventory Item possono essere creati con operazioni separate. | Products esistono senza i record di inventario previsti. | Gli articoli appaiono vendibili ma non seguono la logica di stock per location prevista. | Trattare identità Product/variante e Inventory Items come record collegati ma distinti. | Ogni variante tracciata ha la relazione inventario-location prevista. |
| I dati Product di app legacy sono normali dati Catalog. | Le app possono estendere o referenziare Products tramite entità proprie. | Il comportamento posseduto dall’app viene copiato in campi Product privi di significato operativo. | Il personale vede valori che nessun flusso Wix mantiene. | Tenere distinte entità applicative e Products del catalogo preservando le chiavi. | L’applicazione riesce a risolvere il Product o la variante estesa. |
I proprietari coinvolti sono i team catalogo, integrazione e tutti i sistemi che utilizzano ID Product o variante. La mitigazione richiede una mappa di lineage, non una conversione generica dei campi.
Rischio tra opzioni, modifiers, varianti e personalizzazione
Le Customizations di Catalog V3 distinguono opzioni e modifiers. Le opzioni generano combinazioni con SKU, prezzi e inventario diversi. I modifiers raccolgono testo o selezioni senza modificare l’identità della variante o dello stock. I cataloghi di origine inseriscono spesso taglia, colore, incisione, confezione, upgrade di servizio, garanzie e specifiche nella stessa tabella delle opzioni.
| Modello di origine | Vincolo Wix | Conseguenza sulla migrazione | Impatto operativo | Indicazione di mitigazione | Segnale di controllo |
|---|---|---|---|---|---|
| Taglia o colore vengono trattati come metadati descrittivi. | Le scelte vendibili dovrebbero formare varianti quando possiedono SKU, prezzo o stock. | Il Product mostra il valore ma non può gestire la combinazione acquistata. | Inventario ed evasione usano l’articolo sbagliato. | Preservare la relazione opzione-scelta-variante. | L’opzione selezionata risolve la variante e l’Inventory Item previsti. |
| Incisione o testo libero diventano un’opzione. | Le opzioni creano varianti; i modifiers raccolgono input senza cambiare inventario. | Il catalogo genera combinazioni inutili per ogni percorso di personalizzazione. | Amministrazione Product e stock diventano ingestibili. | Usare un proprietario di tipo modifier per input che non cambia inventario. | L’input Customer appare sulla transazione senza creare una variante. |
| Gli extra a pagamento diventano automaticamente varianti. | Alcuni extra cambiano il prezzo ma non l’identità di inventario e possono appartenere ad app o modifiers. | Variants artificiali frammentano reportistica e disponibilità. | Il personale non distingue il Product base da un servizio opzionale. | Stabilire se l’extra appartiene a modifier, app, bundle o flusso esterno. | I dettagli dell’Order mostrano l’extra mentre l’inventario base resta coerente. |
| I componenti di bundle sono memorizzati come testo Product. | Stock ed evasione dei componenti richiedono una relazione separata. | L’offerta è visibile ma la disponibilità dei componenti non è calcolabile. | Si verificano overselling ed errori di prelievo. | Assegnare la logica dei componenti a un’app compatibile o a un sistema esterno. | Il sistema responsabile dello stock identifica ogni componente. |
| Le specifiche diventano dimensioni variante. | Info Sections, brand, Categories e altri campi catalogo possono descrivere Products senza generare combinazioni. | Il numero di varianti cresce e i clienti incontrano scelte irrilevanti. | La manutenzione del catalogo diventa complessa e soggetta a errori. | Tenere le informazioni non selezionabili fuori dalle dimensioni delle opzioni. | Le specifiche restano riutilizzabili o descrittive senza modificare l’identità variante. |
Il rischio è sotto controllo quando ogni input del cliente ha un effetto chiaro sull’identità vendibile, sull’inventario, sul prezzo, sull’evasione o sul contesto storico dell’Order.
Rischio dell’inventario per variante e location
Gli Inventory Items Wix possono tracciare lo stock di una specifica variante in una specifica location. Le locations possono rappresentare store, magazzini o centri di evasione. Questo crea un modello di rischio più granulare rispetto a una singola quantità Product.
| Presupposto | Vincolo di inventario | Conseguenza sulla migrazione | Impatto operativo | Direzione di mitigazione | Segnale di controllo |
|---|---|---|---|---|---|
| Una quantità di origine può essere copiata sul Product. | L’inventario appartiene a relazioni variante-location. | Il conteggio viene scollegato dall’unità vendibile e dalla location di evasione. | I Customers vedono disponibilità inesatta e il personale evade dal pool di stock sbagliato. | Mappare ogni proprietario dello stock di origine a variante e location di destinazione. | Totali per location e variante corrispondono al modello operativo dichiarato. |
| Tutti i Products devono avere stock tracciato. | Servizi, prodotti digitali, articoli illimitati e disponibilità controllata esternamente possono seguire regole diverse. | Offerte senza stock diventano indisponibili o compaiono quantità fuorvianti. | Vendite valide vengono bloccate o Products non supportati restano esposti. | Classificare separatamente casi tracked, unlimited, preorder e stock esterno. | Ogni classe di inventario produce il comportamento di vendita previsto. |
| La creazione Product dimostra che l’inventario è completo. | Gli Inventory Items possono richiedere creazione e titolarità separate. | Products esistono con record di stock mancanti. | Il personale presume che lo stock sia migrato perché il catalogo è visibile. | Includere le relazioni Inventory Item nel modello del catalogo. | Ogni variante tracciata ha un Inventory Item identificabile nella location prevista. |
| Uno snapshot è sufficiente per un catalogo gestito da ERP. | I sistemi esterni continuano a pubblicare stock dopo la migrazione. | I conteggi iniziali sono corretti ma gli aggiornamenti successivi falliscono o si collegano male. | L’inventario dei canali diverge rapidamente. | Preservare chiavi Product, variante, location e sistema esterno. | Un aggiornamento continuativo raggiunge il record variante-location previsto. |
| Gli Orders storici dovrebbero riapplicare le variazioni di stock. | Transazioni storiche e inventario iniziale hanno responsabilità separate. | La quantità viene decrementata una seconda volta. | Lo store parte con disponibilità errata. | Stabilire l’inventario iniziale indipendentemente dalla cronologia Order importata. | Gli Orders storici non modificano la posizione di stock iniziale approvata. |
Il rischio di inventario incide rapidamente sui ricavi, ma il controllo strutturale resta chiaro: Wix e ogni sistema esterno responsabile dello stock devono usare la stessa identità di variante e location.
Contacts, Members, Customers e partecipanti alle app
Wix Contacts può rappresentare persone che interagiscono con il sito, mentre Members aggiunge relazioni di account e accesso. Commerce Customers, utenti che inviano form, subscribers, clienti Bookings, partecipanti Events, titolari di Pricing Plans, partecipanti loyalty e profili applicativi possono sovrapporsi senza essere la stessa entità.
| Presupposto di origine | Vincolo Wix | Conseguenza sulla migrazione | Impatto operativo | Indicazione di mitigazione | Segnale di controllo |
|---|---|---|---|---|---|
| Ogni Customer dovrebbe diventare Member. | Identità Contact e accesso Member sono relazioni separate. | Gli acquirenti guest ricevono aspettative di login non supportate o l’accesso riservato dei Members viene perso. | Supporto account e contenuti protetti diventano incoerenti. | Preservare separatamente cronologia dell’acquirente e diritti Member. | Solo gli utenti previsti ricevono accesso Member e gli Orders restano collegati al Contact corretto. |
| La sola email dimostra una singola persona. | Duplicati di origine, email condivise, indirizzi cambiati e ID esterni possono rappresentare storie diverse. | Contacts vengono uniti erroneamente o una persona diventa più record. | Marketing, supporto e cronologia Orders diventano inaffidabili. | Usare ID di origine, collegamenti agli Orders, email, telefono e chiavi esterne in una gerarchia di identità documentata. | Persone di alto valore e casi ambigui vengono risolti nel Contact corretto. |
| Il consenso subscriber è un normale dato Contact. | Il permesso di comunicazione ha finalità e provenienza separate dall’identità. | Contacts importati possono essere trattati come contattabili a fini marketing senza una relazione valida. | Compliance e targeting si indeboliscono. | Preservare soltanto informazioni di preferenza supportate e con significato chiaro. | I flussi marketing distinguono identità e permesso di comunicazione. |
| I partecipanti alle app appartengono ai custom fields del Contact. | Bookings, Events, Pricing Plans, loyalty e altre app possiedono record specializzati. | Pianificazione, diritti, avanzamento o saldo vengono appiattiti. | Il Customer service non riesce a comprendere la relazione attiva. | Mantenere il collegamento Contact e migrare o archiviare l’entità specializzata sotto il proprietario reale. | L’app che continua a operare riconosce Contact e record di partecipazione previsti. |
| Gli ID CRM esterni possono essere sostituiti. | Sistemi CRM e supporto possono considerare la chiave esistente come autoritativa. | Gli aggiornamenti creano Contacts duplicati o si collegano al record sbagliato. | Segmentazione e cronologia del supporto si frammentano. | Preservare identificatori esterni durevoli alla granularità Contact o organizzazione usata dal CRM. | Una ricerca CRM restituisce il Contact Wix previsto. |
Il controllo consiste in un modello di identità a livelli: relazioni Contact, Member, Customer, partecipante e account esterno restano collegate senza essere appiattite.
Orders, billing, transazioni, evasione e impostazioni
Gli eCommerce Orders Wix gestiscono il ciclo successivo all’acquisto e collegano articoli acquistati, dettagli di pagamento, informazioni di spedizione e stato di evasione. Wix separa inoltre Order Billing, Order Transactions, Invoices, Payment Requests, Fulfillments e Order Settings. La migrazione storica deve preservare evidenze in queste aree senza assegnare autorità operativa corrente ai vecchi record.
| Catena di rischio | Conseguenza sulla migrazione | Impatto operativo | Direzione di mitigazione | Segnale di controllo |
|---|---|---|---|---|
| Un solo stato di origine viene copiato come stato completo dell’Order. | Significato di pagamento, evasione, annullamento, invoice e rimborso viene compresso. | Il personale non riesce a capire se denaro o merci sono ancora dovuti. | Preservare uno stato storico leggibile attraverso le relazioni Order pertinenti. | Gli Orders complessi sono comprensibili senza accedere al sistema di origine. |
| Le righe Order si collegano solo ai Products padre. | La variante acquistata, il modifier o la configurazione posseduta dall’app vengono persi. | Supporto ed evasione non riescono a identificare cosa è stato acquistato. | Preservare snapshot delle righe e riferimenti affidabili a Product/variante/customization. | La riga mostra identità vendibile e input dell’acquirente previsti. |
| I dati di pagamento storici vengono trattati come autorità attiva. | Dettagli pagamento e Transactions documentano il passato; provider e impostazioni correnti sono separati. | Il team si aspetta che vecchie credenziali o token elaborino nuovo commerce. | Conservare riferimenti di transazione sicuri e configurare separatamente il comportamento di pagamento corrente. | I pagamenti storici sono tracciabili senza esporre o riutilizzare impropriamente credenziali. |
| Le etichette di spedizione ricreano l’evasione corrente. | Fulfillments, impostazioni delivery, corrieri e locations hanno titolarità corrente separata. | I nuovi Orders seguono percorsi incompleti. | Preservare le evidenze storiche di spedizione e definire separatamente l’evasione attiva. | Responsabilità di evasione storiche e attive sono distinguibili. |
| Gli Orders importati attivano aggiornamenti di inventario correnti. | Cronologia Order e Inventory Items iniziali hanno finalità diverse. | Lo stock viene decrementato di nuovo o sincronizzato in modo errato. | Isolare l’importazione della cronologia Order dall’autorità sullo stock iniziale. | L’inventario resta stabile dopo l’introduzione dei record storici. |
I proprietari coinvolti sono Customer service, finance, operations e team integrazioni. La direzione di mitigazione consiste nel preservare le evidenze storiche mantenendo autoritative le impostazioni Wix correnti.
Rischio di collezioni CMS, pagine dinamiche e campi di riferimento
Le collezioni Wix CMS possono memorizzare data items strutturati e campi di riferimento. Possono alimentare pagine dinamiche, directory, risorse, contenuti vetrina online personalizzati e flussi applicativi e possono anche collegarsi a database esterni. Questa flessibilità crea il rischio che tabelle personalizzate di origine vengano spostate nel CMS senza preservare schema, riferimenti, permessi, codice o comportamento delle pagine.
| Presupposto di origine | Vincolo CMS | Conseguenza sulla migrazione | Impatto operativo | Direzione di mitigazione | Segnale di controllo |
|---|---|---|---|---|---|
| Una tabella di origine può diventare automaticamente una singola collezione CMS. | Campi della collezione, schema degli item, permessi, riferimenti, indici e pagine/codice che la utilizzano sono elementi distinti. | Le righe vengono trasferite ma relazioni e modalità di modifica scompaiono. | Le pagine dinamiche mostrano dati incompleti o non risolvono i record collegati. | Definire schema collezione, campi di riferimento, permessi e consumer come un unico modello. | Gli item rappresentativi risolvono ogni riferimento e relazione di pagina richiesta. |
| ID numerici di origine possono essere copiati come riferimenti. | I riferimenti CMS devono puntare alle identità dei data item di destinazione. | I vecchi ID diventano semplici valori senza significato. | Record collegati e pagine dinamiche si disconnettono. | Tradurre le relazioni di origine in campi di riferimento della destinazione. | Ogni relazione padre-figlio o molti-a-molti viene risolta in Wix CMS. |
| Aggiornare un item preserva i valori non specificati. | Alcune operazioni di update sostituiscono il contenuto dell’item quando alcuni campi sono omessi. | Una sincronizzazione parziale elimina dati involontariamente. | Sistemi esterni cancellano campi che non possiedono. | Definire titolarità dei campi e comportamento di update sicuro per le integrazioni continuative. | Gli aggiornamenti modificano solo i campi posseduti dal sistema che pubblica. |
| I dati CMS riflettono immediatamente ogni scrittura ovunque. | In flussi pertinenti, il recupero dei dati può essere eventualmente consistente. | Automazioni o letture front-end agiscono su stato non ancora aggiornato. | Compaiono azioni duplicate o incoerenze temporanee. | Progettare integrazioni che tollerino la propagazione e usino una gestione autoritativa di eventi/stato. | I flussi sensibili al tempo non dipendono da presupposti di lettura immediata dopo la scrittura. |
| CMS può sostituire domini Product, Order o applicativi. | CMS è storage flessibile ma non riproduce il comportamento di Wix Stores o delle app. | Record commerce o partecipanti vengono duplicati in un modello ombra non gestito. | Il personale mantiene fonti di verità in conflitto. | Usare CMS solo quando è il proprietario reale nella destinazione, non come tabella generica di overflow. | Ogni entità ha un solo system of record dichiarato. |
Il rischio CMS è sotto controllo quando schema, riferimenti, permessi, routes e codice che utilizzano i dati vengono trattati come un’unica catena di dipendenze.
Rischio per pagine, URL, contenuti multilingua e SEO
La struttura Wix può includere pagine statiche, pagine dinamiche, route Product e Category, Blog Posts, menu, media, form, versioni multilingua, domini, metadati SEO e redirect. I percorsi e le strutture dei page builder dello store di origine non si trasferiscono necessariamente in modo diretto.
| Dipendenza di origine | Vincolo Wix | Conseguenza sulla migrazione | Impatto operativo | Indicazione di mitigazione | Segnale di controllo |
|---|---|---|---|---|---|
| I record Product o Category ricreano la navigazione. | Categories, menu, pagine e route dinamiche Wix sono correlati ma distinti. | I record catalogo esistono senza il percorso di navigazione previsto. | I clienti non riescono a trovare Products ad alto valore. | Assegnare titolarità di navigazione e landing indipendentemente dall’appartenenza Category. | I percorsi prioritari del cliente raggiungono la destinazione Product o Category prevista. |
| Gli URL di origine possono restare invariati automaticamente. | Le route dipendono da strutture Wix di pagina, catalogo, multilingua e dominio. | Percorsi ad alto valore cambiano senza continuità. | Traffico da ricerca, backlink e bookmark falliscono. | Definire destinazioni canoniche e relazioni di redirect per URL prioritari. | I vecchi percorsi prioritari risolvono risorse di destinazione utilizzabili. |
| I dati del page builder sono contenuti portabili. | Sezioni Wix, componenti, pagine dinamiche, app e codice definiscono la presentazione. | Il testo si trasferisce ma form, query, interazioni e relazioni di layout scompaiono. | Percorsi di contenuto e conversione diventano incompleti. | Separare contenuti e media durevoli da presentazione e comportamento della destinazione. | Ogni pagina chiave ha proprietario funzionante per contenuto, route e interazione. |
| La lingua è un singolo campo sul record di origine. | I contenuti multilingua possono richiedere coordinamento tra route, pagine, item CMS, menu e valori catalogo. | Le traduzioni esistono ma non sono collegate all’esperienza linguistica prevista. | Gli utenti vedono contenuti nella lingua sbagliata o duplicati. | Preservare identità della versione linguistica e contesto delle route tra i proprietari pertinenti. | Percorsi linguistici e contenuti associati sono coerenti per i journey prioritari. |
| Il trasferimento dei media preserva i riferimenti incorporati. | Contenuti, media Product, item CMS e applicazioni possono referenziare gli asset in modi diversi. | I file esistono ma pagine o Products puntano ai vecchi percorsi. | Immagini o download non funzionanti riducono la fiducia. | Trasferire relazioni di attachment e link incorporati insieme al record proprietario. | Route rappresentative mostrano gli asset previsti senza dipendenze dal dominio di origine. |
Il segnale di controllo è la continuità del percorso di acquisto e di fruizione dei contenuti, non un conteggio uguale di pagine o file media.
App, Velo, service plugin e sistemi esterni
Codice Velo, applicazioni Wix, service plugin, webhook e sistemi esterni possono calcolare prezzi, validare input, interrogare collezioni CMS, gestire iscrizioni, sincronizzare Products, pubblicare inventario o modificare l’evasione. I loro record e la loro logica non fanno automaticamente parte del core Wix Stores.
| Presupposto sulla dipendenza | Vincolo Wix | Conseguenza sulla migrazione | Impatto operativo | Direzione di mitigazione | Segnale di controllo |
|---|---|---|---|---|---|
| App simili hanno record compatibili. | Ogni app definisce entità, permessi, identificatori e ciclo di vita propri. | I dati vengono spostati in campi generici senza un proprietario applicativo funzionante. | Saldi, pianificazioni, iscrizioni o cronologia scompaiono. | Mappare l’entità reale di origine nell’app Wix o nel proprietario esterno previsto. | L’applicazione che continua a operare riconosce il Contact, Product o Order padre. |
| Il codice Velo può essere copiato come dato. | Il codice dipende da API Wix, schemi CMS, eventi, permessi e secrets. | Gli script arrivano senza dipendenze valide o titolarità nella destinazione. | Regole business falliscono silenziosamente o generano dati incoerenti. | Ricreare solo il comportamento necessario rispetto allo schema target e alle API supportate. | Il comportamento ha un proprietario definito e nessuna dipendenza di origine non spiegata. |
| Gli ID esterni possono essere rigenerati. | ERP, CRM, PIM, WMS, marketplace e sistemi contabili possono usare chiavi stabili. | La sincronizzazione si collega a duplicati o record sbagliati. | Operazioni stock, Customer e Order divergono. | Preservare gli identificatori alla stessa granularità di entità usata dal sistema autoritativo. | Una ricerca round-trip esterna risolve un solo record Wix previsto. |
| Un custom field riproduce un’automazione. | I campi memorizzano valori; automazioni e service plugin eseguono comportamento. | Il dato sopravvive senza la regola che lo utilizza. | Il personale vede valori obsoleti o fuorvianti. | Assegnare separatamente titolarità del valore e del comportamento. | Il processo continuativo aggiorna e interpreta correttamente il campo. |
| La disponibilità di un’API garantisce equivalenza del modello. | Le API espongono risorse definite e comportamento di consistenza, non semantica arbitraria del sistema di origine. | L’ambito viene definito sulla connettività anziché sulla compatibilità tra proprietari. | Relazioni mancanti emergono dopo l’implementazione. | Valutare compatibilità di entità e ciclo di vita prima di fare affidamento sull’API. | Ogni integrazione continuativa ha una mappa definita tra entità di origine e destinazione. |
Questo dominio coinvolge sviluppatori, amministratori applicativi e responsabili business. La mitigazione strutturale è una mappa delle dipendenze applicative con ID padre stabili e titolarità esplicita del comportamento.
Matrice di titolarità del rischio e dei controlli
| Dominio di rischio | Proprietario principale | Impatto business se non controllato | Direzione di mitigazione | Segnale di controllo |
|---|---|---|---|---|
| Lineage del catalogo | Responsabile catalogo e integrazioni | Products e varianti duplicati o identificati male | Definire lineage V1/V3 e identità universale delle varianti. | Ogni elemento vendibile di origine viene risolto una sola volta in Catalog V3. |
| Opzioni e modifiers | Responsabile catalogo ed evasione | Variants false o personalizzazioni perse | Classificare le scelte in base all’effetto su identità, inventario e dati Order. | Le selezioni dell’acquirente producono la variante o il modifier previsto. |
| Inventario | Responsabile operations di inventario | Overselling e incoerenza tra locations | Proteggere granularità variante-location e autorità esterna sullo stock. | Conteggi iniziali e continuativi raggiungono l’Inventory Item previsto. |
| Contacts e Members | Responsabile Customer operations | Fusioni errate, errori di accesso e cronologia app interrotta | Preservare relazioni a livelli tra identità, accesso, consenso e applicazioni. | Identità di alto valore e casi ambigui vengono risolti correttamente. |
| Orders | Customer service e finance | Cronologia illeggibile o presupposti operativi non sicuri | Preservare snapshot storici e relative evidenze di transazione/evasione. | Gli Orders complessi possono essere spiegati dall’inizio alla fine. |
| CMS e sito | Responsabile sito e contenuti | Pagine dinamiche, route e riferimenti non funzionanti | Definire insieme schema, campi di riferimento, pagine, permessi e URL. | I journey statici e dinamici prioritari funzionano correttamente. |
| Applicazioni e Velo | Responsabile applicazioni o engineering | Comportamenti persi e integrazioni interrotte | Ricostruire il comportamento rispetto alle entità target e agli ID stabili. | I flussi continuativi riconoscono e aggiornano i record previsti. |
La matrice assegna chiaramente i controlli, così implementazione e verifiche possono seguire le relazioni dichiarate senza inventare nuova titolarità durante l’esecuzione.
Conclusione
I vincoli della migrazione verso Wix derivano dall’interazione tra una piattaforma site-builder gestita, Catalog V3, varianti universali, Inventory Items per variante e location, Contacts, Members, Orders, collezioni CMS, applicazioni, Velo e sistemi esterni. I rischi più seri emergono quando questi domini vengono trattati come un unico database o quando presupposti di Catalog V1 e Catalog V3 vengono mescolati.
Una migrazione controllata protegge il lineage dei Products, distingue opzioni e modifiers, assegna l’inventario a variante e location corrette, separa l’identità Contact dalle relazioni Member e app, preserva gli Orders storici senza assegnare loro autorità attiva e tratta CMS, sito e comportamento applicativo come domini di titolarità espliciti. Questi controlli trasformano avvertenze generiche in catene causa-impatto specifiche di Wix.
Domande frequenti
Perché Catalog V1 rispetto a Catalog V3 rappresenta un rischio di migrazione?
Catalog V3 utilizza varianti universali e separa in modo più esplicito Products, Customizations, Inventory Items, locations e altri servizi di catalogo. Riutilizzare presupposti o identificatori V1 senza una mappa di lineage può generare Products duplicati, inventario mancante o integrazioni interrotte.
Qual è il rischio nel trattare i modifiers Wix come opzioni Product?
Le opzioni creano varianti e influenzano SKU, prezzo e identità di inventario. I modifiers raccolgono informazioni aggiuntive senza generare varianti. Confonderli può creare combinazioni di inventario artificiali o perdere la reale identità della variante acquistata.
Perché un Product Wix può esistere senza un comportamento di inventario completo?
Le relazioni tra Product e Inventory Item possono essere create separatamente e lo stock tracciato è specifico per variante e location. La presenza visibile del Product non dimostra che ogni variante tracciata abbia l’Inventory Item e l’assegnazione location previsti.
Contacts, Members e Customers Wix sono la stessa entità?
No. Un Contact fornisce identità e contesto CRM, un Member aggiunge relazioni di account o accesso, il commerce crea contesto Customer e Order e le app Wix possono possedere record separati di partecipazione o diritto. Queste relazioni devono restare collegate senza essere appiattite.
Gli Orders storici dimostrano che checkout ed evasione Wix attivi sono pronti?
No. Gli Orders storici preservano articoli acquistati, dettagli di pagamento, informazioni di spedizione e stato di evasione. Provider attivi, Order settings, aggiornamenti inventario, notifiche, regole delivery e servizi di evasione restano configurazione corrente.
Quando i dati personalizzati di origine dovrebbero usare Wix CMS invece di un’app Wix o un sistema esterno?
Usare CMS quando la collezione è il vero proprietario dei dati strutturati del sito e sono definiti schema, riferimenti, permessi, pagine e comportamento di aggiornamento. Record specializzati relativi a commerce, membership, pianificazione o transazioni devono restare nell’app o nel sistema esterno che ne possiede il ciclo di vita.