L’approccio corretto per una migrazione verso Wix dipende da ciò che l’azienda si aspetta di poter gestire nel futuro sito Wix, non soltanto dal numero di record da trasferire. Un catalogo Product piccolo può richiedere una pianificazione più profonda se dipende da opzioni Product, inventario specifico per variante, dati CMS, iscrizioni, form personalizzati, sistemi esterni, logica Velo/API o record posseduti da app. Un catalogo più grande può invece seguire un percorso relativamente semplice quando i dati sono supportati, la struttura è chiara e l’azienda è in grado di validare con sicurezza il risultato nella destinazione.
Per Wix, la scelta del percorso di servizio deve separare i record migrati dalla configurazione Wix e dall’implementazione del sito. Products, Customers, Orders, CMS Pages, Blog Posts, media e metadati supportati possono rientrare nell’ambito di migrazione. Impostazioni checkout, provider di pagamento, spedizione, imposte, collegamento del dominio, design del sito, configurazione delle app, accesso Member, permessi CMS, codice personalizzato e integrazioni esterne possono richiedere lavoro lato destinazione, Add-ons, Custom Service o implementazione manuale. L’approccio migliore è il percorso meno complesso che riesce comunque a proteggere il risultato operativo previsto in Wix.
All’interno dei servizi di migrazione Next-Cart, le evidenze relative a Wix devono distinguere record supportati, responsabilità di esecuzione, Add-ons con ambito delimitato, dati posseduti da Velo o applicazioni e implementazione lato Wix.
Cosa significa scegliere un approccio di migrazione per Wix
Un approccio di migrazione Wix definisce ambito, responsabilità di esecuzione, livello di supporto, gestione speciale e profondità della validazione. Deve chiarire quali record si prevede di migrare, quali impostazioni Wix vanno configurate separatamente, quali requisiti particolari richiedono Add-ons e quali esigenze non supportate o personalizzate richiedono revisione tramite Custom Service.
L’approccio deve essere scelto a partire dalle evidenze, non da presupposti sulla piattaforma. Wix è hosted e relativamente semplice da usare, ma questo non rende automaticamente semplice ogni migrazione. Un sito ricco di contenuti, uno store con molte varianti, un’attività basata su Members, un flusso sviluppato su misura o un catalogo guidato da app può richiedere una pianificazione del servizio più accurata di un convenzionale trasferimento Product/Customer/Order.
| Area di lavoro | Esempio Wix | Implicazione per il percorso di servizio |
|---|---|---|
| Dati migrati supportati | Products, collezioni, Customers, Orders, CMS Pages, Blog Posts, immagini e metadati supportati. | Può rientrare in Standard Service o Managed Service in base a complessità e necessità di supporto all’esecuzione. |
| Adeguamenti supportati dei dati | Applicazione di condizioni specifiche per tipo di dati, trasformazione dei valori dei campi tramite espressioni o scelta di destinazioni diverse per campi di origine supportati. | Può rientrare in Data Filter, Advanced Data Mapping o Data Transformation quando le esigenze restano entro il comportamento supportato. |
| Dati personalizzati o non supportati | Record posseduti da app, custom fields che richiedono interpretazione non standard oltre la mappatura supportata, ID esterni, logica Velo/API, collezioni CMS complesse o trasformazioni su misura. | Richiede revisione tramite Custom Service. |
| Configurazione della destinazione Wix | Pagamenti, checkout, spedizione, imposte, pickup, delivery, sconti, configurazione app, dominio, design del sito e impostazioni Member. | Deve essere configurata e testata in Wix, non presunta dal risultato della migrazione. |
Questa distinzione evita due errori comuni. Il primo è sottostimare la migrazione verso Wix perché la piattaforma è hosted. Il secondo è trasformare ogni requisito legato al site builder o alle app in Custom Service quando l’esigenza reale è configurazione lato target o un controllo delimitato tramite Data Filter, Advanced Data Mapping o Data Transformation.
Quando Standard Service può essere sufficiente
Standard Service può essere adatto quando l’azienda deve migrare dati Wix supportati con struttura ordinaria ed è in grado di gestire preparazione, esecuzione e validazione. Funziona meglio quando i Products sono relativamente semplici, le collezioni non dipendono fortemente da logiche di navigazione personalizzate, Customers e Orders sono standard, i contenuti sono limitati o supportati e la configurazione del sito Wix può essere gestita dall’azienda o dal team del sito.
Standard Service può comunque produrre un risultato Wix solido quando le aspettative sono realistiche. L’azienda deve comprendere che la migrazione può trasferire record supportati, mentre design del sito, comportamento del checkout attivo, domini, configurazione pagamenti, regole di spedizione, configurazione fiscale, accesso Member e configurazione delle app devono essere gestiti in Wix.
| Segnale favorevole a Standard Service | Motivo specifico per Wix |
|---|---|
| I Products hanno opzioni semplici o strutture variante chiare. | I record catalogo supportati possono essere verificati senza trasformazioni su misura. |
| Le collezioni sono raggruppamenti Product semplici. | La scoperta dei Products non dipende da una ricostruzione complessa tra Categories e pagine. |
| L’inventario è a livello Product oppure ha stock a livello variante ben definito. | L’azienda può validare il significato dello stock senza complessità dovuta a sistemi esterni. |
| Customers e Orders servono soprattutto per consultazione e cronologia del servizio. | I record storici non richiedono comportamenti avanzati di account, Members, loyalty o app. |
| CMS Pages e Blog Posts sono limitati o facili da verificare. | La migrazione dei contenuti non domina il rischio di lancio. |
| Design del sito e configurazione checkout vengono gestiti direttamente in Wix. | L’ambito della migrazione resta distinto dall’implementazione della destinazione. |
Standard Service diventa meno adatto quando l’azienda non riesce a fornire campioni chiari, non sa quali funzionalità Wix possiederanno il comportamento dopo il lancio o si aspetta che funzionalità personalizzate del sistema di origine vengano trasferite automaticamente.
Quando Managed Service può essere più sicuro
Managed Service può essere più sicuro quando i dati sono in gran parte supportati ma il percorso di esecuzione richiede maggiore coordinamento. Una migrazione Wix può includere molti punti di verifica: campioni catalogo, comportamento delle varianti, inventario, Customers, Orders, contenuti, URL, redirect, dipendenze dalle app, configurazione della destinazione e tempistiche di lancio. Anche senza trasformazioni personalizzate, l’azienda può avere bisogno di supporto per coordinare le fasi della migrazione e interpretare i risultati.
Managed Service è particolarmente utile quando l’azienda desidera un supporto all’esecuzione guidato da Next-Cart mantenendo la responsabilità della verifica finale e delle decisioni sulla configurazione Wix. Può ridurre la pressione operativa, ma non trasforma record non supportati in record supportati e non elimina la necessità di configurare Wix.
| Compatibilità con Managed Service | Scenario Wix |
|---|---|
| Ambito supportato con molte aree da verificare | Products, collezioni, Customers, Orders, CMS Pages, Blog Posts, URL e immagini richiedono tutti revisione strutturata. |
| Tempistiche di lancio sensibili | Lo store di origine rimane attivo mentre viene preparato il sito Wix. |
| Contenuti e SEO sono importanti | URL, redirect, landing page, Blog Posts, CMS Pages e link interni richiedono sequenziamento accurato. |
| Capacità interna limitata | L’azienda non riesce a gestire con sicurezza ogni fase di migrazione e verifica in autonomia. |
| Demo Migration deve guidare le decisioni | I campioni richiedono interpretazione coordinata prima della Full Migration. |
Managed Service va scelto per ottenere maggiore coordinamento e sicurezza nell’esecuzione. Quando il requisito sottostante riguarda record posseduti da app, custom fields non gestibili con mappatura supportata, logica Velo/API, identificatori esterni o comportamento di origine non supportato, può essere comunque necessario Custom Service.
Quando gli Add-ons sono la scelta corretta
Gli Add-ons sono utili quando l’azienda necessita di modifiche delimitate all’interno di un comportamento di migrazione supportato. Possono filtrare record attraverso condizioni basate sui campi per ciascun tipo di dati, trasformare valori dei campi tramite espressioni oppure rimappare campi standard di origine supportati verso campi target supportati compatibili mantenendo invariati i valori. Non devono essere usati come sostituto della migrazione di dati non supportati o della ricostruzione di logica business personalizzata.
Per Wix, gli Add-ons sono più utili quando l’azienda ha esigenze chiare e supportate, come escludere record che soddisfano determinate condizioni, trasformare valori supportati con espressioni o cambiare la destinazione di un campo supportato.
| Esigenza Add-on | Esempio Wix | Verifica del confine |
|---|---|---|
| Data Filter | Applicare condizioni supportate sui campi di Product, Order, Customer, Blog Post o contenuti affinché migrino soltanto i record corrispondenti. | Il filtraggio non deve rimuovere record necessari per supporto, SEO o validazione del lancio. |
| Data Transformation | Applicare espressioni per trasformare valori di campi supportati destinati a Wix durante la migrazione. | Espressione e output devono restare delimitati e supportati. |
| Advanced Data Mapping | Rimappare campi standard di origine supportati verso differenti campi Wix supportati per Product, Customer, Order, contenuti o metadati mantenendo invariati i valori. | La mappatura non può creare comportamenti Wix non supportati o logica personalizzata delle app. |
| Esigenza Tailored o Custom Add-on | Una funzione Standard Add-on richiede modifica specifica del progetto oppure è necessaria una funzionalità Add-on su misura. | Questo lavoro viene valutato e quotato tramite Custom Service invece di essere trattato come ambito Standard Add-on. |
La migliore richiesta Add-on è specifica. Una richiesta vaga come “fare in modo che Wix corrisponda al vecchio store” non è sufficiente. Una richiesta utile indica la condizione sul tipo di dati, l’espressione di trasformazione oppure i campi di origine e destinazione, insieme al modo in cui il risultato verrà validato in Wix.
Quando considerare Custom Service
Custom Service va considerato quando il requisito della migrazione Wix supera il comportamento supportato. Il fattore decisivo non è soltanto la dimensione dello store. Conta la necessità di valutazione personalizzata, record non supportati, dati posseduti da app, custom fields che richiedono interpretazione non standard oltre la mappatura supportata, identificatori esterni, trasformazioni su misura, gestione di una Custom Platform, logica Velo/API o adeguamenti personalizzati della logica di migrazione.
I requisiti personalizzati per Wix emergono spesso quando lo store di origine ha comportamenti che non sono memorizzati come normali dati commerce. Esempi: configuratori Product, logica subscription o membership, cronologia Bookings o Events, custom fields Customer, ID CRM o loyalty, riferimenti inventario esterni, record marketplace, collezioni CMS, pagine dinamiche, strutture database personalizzate, codice simile a Velo o integrazioni private.
| Fattore che può richiedere Custom Service | Implicazione specifica per Wix |
|---|---|
| Record Product, Customer, Order o contenuto posseduti da app | La migrazione standard può non includere dati o comportamento dell’app. |
| Custom fields o identificatori esterni la cui gestione richiesta supera mappatura o trasformazione supportati | I valori possono richiedere interpretazione su misura, una destinazione non standard o continuità con sistemi esterni che gli Standard Add-ons non possono fornire. |
| Comportamento dipendente da Velo/API o codice sorgente | Il requisito può richiedere revisione della logica personalizzata o pianificazione dell’implementazione lato target. |
| Collections CMS complesse o database esterni | Le relazioni tra contenuti e dati possono non rientrare nella normale migrazione di CMS Pages o Blog Posts. |
| Configuratori Product, form, iscrizioni, Bookings o comportamento Pricing Plans | Il modello di vendita può appartenere a app Wix, configurazione della destinazione o gestione personalizzata. |
| Logica non standard di checkout, spedizione, imposte, evasione o pagamento | Il comportamento attivo può richiedere configurazione Wix, pianificazione di service plugin o una riprogettazione accettata. |
Custom Service deve essere definito attraverso esempi rappresentativi. L’azienda dovrebbe fornire record campione, screenshot o export di origine quando opportuno, risultato atteso sul target e regole di validazione. Senza esempi, la revisione personalizzata diventa troppo astratta per proteggere il risultato Wix.
Custom Service non include automaticamente implementazione di app Wix, sviluppo Velo, costruzione CMS o di pagine dinamiche, configurazione pagamenti e spedizioni, design del tema o delle pagine o deployment di integrazioni esterne, a meno che tali responsabilità non siano espressamente incluse.
Cosa deve decidere la Demo Migration
La Demo Migration deve verificare se l’approccio selezionato riesce a preservare il significato specifico di Wix. Non va considerata soltanto un’anteprima dei conteggi dei record. Per Wix, la Demo Migration deve chiarire se Products, collezioni, varianti, inventario, Customers, Orders, contenuti, URL e requisiti di gestione speciale stanno seguendo il percorso corretto.
Un campione efficace per la Demo Migration Wix dovrebbe includere esempi ordinari e difficili. L’obiettivo è dimostrare l’adeguatezza dell’approccio, non approvare soltanto i record più semplici.
| Area campione | Decisione che deve supportare |
|---|---|
| Product semplice | Stabilire se il trasferimento catalogo Wix di base è corretto. |
| Product con opzioni/varianti | Verificare se scelte, SKU variante, prezzi, pesi, immagini e inventario funzionano come previsto. |
| Esempio collezione/Category | Verificare se il significato di scoperta di origine può diventare collezioni Wix, pagine, menu o redirect. |
| Customer con Orders | Verificare se identità dell’acquirente e contesto storico degli Orders restano utili. |
| Acquirente guest o profilo duplicato | Stabilire se le regole di identità richiedono pulizia o criteri di accettazione. |
| Order rimborsato o scontato | Verificare se le eccezioni nella cronologia Orders restano leggibili. |
| CMS Page, Blog Post o contenuto ricco di media | Chiarire decisioni su migrazione contenuto, ricostruzione o redirect. |
| Record app/custom/esterno | Stabilire se il requisito appartiene ad Add-ons, Custom Service, configurazione della destinazione o esclusione. |
Se la Demo Migration mostra che record Wix importanti perdono significato, l’approccio deve essere corretto prima della Full Migration. Non è appropriato continuare con un percorso debole aspettandosi che il volume completo dei dati risolva problemi strutturali.
Entity Points e pianificazione dell’ambito Wix
Gli Entity Points aiutano a stimare il volume di migrazione eleggibile, ma non misurano da soli la complessità Wix. Per Wix, record Product, Customer, Order e Blog Posts eleggibili possono consumare Entity Points la prima volta che migrano, mentre i record già conteggiati sullo stesso percorso restano conteggiati una sola volta; complessità CMS, Member, app e Velo viene valutata separatamente.
Per Wix, gli Entity Points vanno considerati insieme al significato dei dati. Una migrazione Wix piccola può richiedere Custom Service se comprende dati posseduti da app, collezioni CMS, custom fields non gestibili tramite mappatura supportata, identificatori esterni o comportamenti dipendenti da Velo/API. Una migrazione più ampia può restare adatta a Standard Service o Managed Service se i record supportati sono chiari e l’azienda può validare il risultato.
| Segnale di ambito | Cosa aiuta a stimare | Cosa non dimostra |
|---|---|---|
| Conteggio Product | Volume catalogo e possibile uso di Entity Points. | Se opzioni, scelte, varianti, immagini, collezioni e inventario sono utilizzabili in Wix. |
| Conteggio Customer | Volume dei record acquirente. | Se Contacts, Members, subscribers, partecipanti alle app e ID esterni restano significativi. |
| Conteggio Order | Volume della cronologia Orders. | Se contesto di pagamento, rimborso, evasione, sconto e riferimenti esterni è leggibile. |
| Conteggio Blog Posts | Volume contenuti quando rilevante. | Se CMS Pages, URL, redirect, media e struttura del sito sono pronti per il lancio. |
Gli Entity Points devono supportare la pianificazione, non sostituire la valutazione del percorso di servizio. L’approccio scelto dipende comunque da comportamento supportato, configurazione della destinazione, requisiti personalizzati, responsabilità di esecuzione ed evidenze di validazione.
Additional Migration Options e tempistiche di lancio Wix
Le Additional Migration Options diventano rilevanti quando l’ambiente di origine continua a cambiare durante la preparazione del sito Wix. L’azione corretta dipende dal fatto che siano comparsi solo nuovi record, debba cambiare la configurazione supportata o sia stato ridefinito il risultato atteso sul target.
| Azione corrente | Quando è adatta a Wix | Riconvalida richiesta |
|---|---|---|
| Continue the Migration with the Last Used Configuration | Sono stati aggiunti nuovi record eleggibili e filtri, mappatura, selezione tipo di dati e configurazione già approvati restano adeguati. | Verificare i nuovi Products, Customers, Orders e Blog Posts migrati più campioni di regressione Wix Stores. |
| Continue the Migration with a New Configuration | Mapping, filtraggio, selezione tipo di dati o configurazione supportata sono cambiati dopo la Demo Migration. | Rivedere Products, opzioni, varianti, collezioni, Customers, Orders, contenuti e output URL interessati. |
| Perform a New Migration | Il sito target Wix o il risultato migrato previsto è cambiato abbastanza da richiedere la sostituzione dell’output precedente, mentre il percorso piattaforma di origine → piattaforma di destinazione acquistato resta invariato. Un percorso diverso richiede un servizio di migrazione acquistato separatamente. | Validare il risultato target aggiornato tra Wix Stores, contenuti, URL e confini custom/app accettati. |
Le Additional Migration Options non sostituiscono configurazione del sito Wix, configurazione delle app, sviluppo Velo, costruzione delle collezioni CMS, implementazione delle pagine dinamiche, configurazione live di pagamenti e spedizione o deployment delle integrazioni. Devono essere selezionate insieme a un piano definito di tempistiche del lancio e riconvalida.
Segnali che l’approccio Wix scelto è troppo leggero
L’approccio scelto è troppo leggero quando tratta Wix come una semplice destinazione di importazione ignorando la complessità site-commerce. I segnali di allarme emergono normalmente durante la revisione dei campioni, non dai conteggi dei record.
| Segnale di allarme | Risposta probabile |
|---|---|
| Opzioni Product, scelte, varianti e inventario non possono essere validati con sicurezza. | Rivedere l’ambito catalogo o considerare un supporto all’esecuzione/revisione custom più forte. |
| Si presume che Categories di origine ricreino automaticamente menu, pagine, filtri e percorsi SEO. | Separare migrazione delle collezioni dalla struttura del sito e pianificazione dei redirect. |
| I record Customer includono Members, Contacts, subscribers, loyalty, Bookings o partecipazione ad app. | Classificare i tipi di identità e verificare percorsi supportati rispetto a quelli custom. |
| Si presume che gli Orders storici configurino il checkout Wix attivo. | Separare la cronologia migrata da configurazione di pagamenti, spedizione, imposte e Order settings. |
| CMS Pages, Blog Posts, pagine dinamiche o collezioni di dati personalizzati sono centrali al lancio. | Pianificare migrazione contenuti, ricostruzione, redirect, configurazione CMS o revisione Custom Service. |
| Campi posseduti da app, logica Velo/API o ID esterni sono critici per il business. | Non fare affidamento su un ambito generico; valutare Add-ons o Custom Service in base alla necessità. |
| L’azienda non sa definire chi validerà configurazione Wix e output della migrazione. | Managed Service può aiutare il coordinamento, ma devono comunque essere definiti criteri di accettazione. |
Questi segnali vanno affrontati prima della Full Migration perché diventano normalmente più difficili da risolvere quando le scadenze di lancio sono vicine.
Scegliere il percorso pratico per Wix
Il percorso pratico per Wix è il servizio meno complesso che riesce comunque a proteggere il futuro risultato site-commerce. Standard Service può essere sufficiente per dati supportati e lineari quando l’azienda sa gestire configurazione della destinazione e validazione. Managed Service è più sicuro quando i dati sono supportati ma coordinamento dell’esecuzione e revisione sono importanti. Gli Add-ons aiutano con filtraggio di record supportati, trasformazione dei valori dei campi o rimappatura dei campi. Custom Service è necessario quando esigenze personalizzate, non supportate, possedute da app, legate a sistemi esterni o trasformazioni su misura influenzano il risultato della migrazione.
Un approccio pronto può essere riassunto con quattro affermazioni:
- quali record Wix devono migrare;
- quali impostazioni Wix ed elementi del sito devono essere configurati o ricostruiti separatamente;
- quali requisiti Add-on o Custom Service rientrano nell’ambito;
- quali campioni della Demo Migration devono superare la verifica prima della Full Migration.
Se queste affermazioni non sono chiare, il percorso di servizio non dovrebbe essere considerato definitivo. La qualità della migrazione Wix dipende dall’allineamento tra approccio scelto ed effettivo ambiente site-commerce che l’azienda vuole gestire dopo il lancio.
Conclusione
Scegliere il giusto approccio di migrazione verso Wix richiede più della stima del volume dei record. L’approccio deve considerare struttura catalogo Wix Stores, opzioni, scelte, varianti, inventario, Customers, Contacts, Members, Orders, CMS Pages, Blog Posts, URL, app, logica Velo/API, sistemi esterni, configurazione lato target, Entity Points, Additional Migration Options e responsabilità di validazione.
Il percorso corretto non è sempre il più complesso. È quello che separa l’ambito di migrazione supportato dalla configurazione Wix, identifica quando gli Add-ons sono sufficienti, inoltra i veri requisiti custom a Custom Service e usa la Demo Migration per dimostrare che il risultato in Wix sosterrà vendite reali, esperienza del sito e revisione operativa.
Domande frequenti
Quando Standard Service è sufficiente per una migrazione verso Wix?
Standard Service può essere sufficiente quando l’azienda necessita di record Wix supportati con struttura ordinaria, può gestire direttamente la configurazione Wix e sa validare Products, collezioni, Customers, Orders, contenuti e URL senza ampio coordinamento o gestione personalizzata.
Quando conviene considerare Managed Service per Wix?
Managed Service è utile quando la migrazione resta entro le funzionalità supportate ma l’azienda necessita di maggiore supporto all’esecuzione, coordinamento, revisione dei campioni, pianificazione della finestra di lancio o aiuto nella gestione delle fasi prima della Full Migration.
In cosa differiscono gli Add-ons da Custom Service per Wix?
Gli Add-ons supportano filtraggio delimitato dei record, trasformazione dei valori dei campi o rimappatura dei campi all’interno del comportamento di migrazione supportato. Custom Service riguarda dati app non supportati, custom fields che richiedono interpretazione non standard oltre la mappatura supportata, identificatori esterni, logica Velo/API, trasformazioni su misura, gestione Custom Platform o adeguamenti personalizzati della logica di migrazione.
Cosa deve dimostrare la Demo Migration per Wix prima della Full Migration?
La Demo Migration deve dimostrare che i record Wix rappresentativi funzionano come previsto: Products, varianti, collezioni, inventario, Customers, Orders, CMS Pages, Blog Posts, URL e qualsiasi campione app/custom che influenza il percorso di servizio scelto.
Quale azione di migrazione va usata per attività successive su Wix?
Usare Continue the Migration with the Last Used Configuration quando devono essere aggiunti soltanto nuovi record eleggibili con la configurazione approvata. Usare Continue the Migration with a New Configuration quando sono cambiati filtri, mappatura, selezioni tipo di dati o configurazione supportati. Usare Perform a New Migration quando il risultato Wix previsto o la configurazione del sito target sono cambiati in modo sostanziale mentre il percorso di migrazione acquistato resta fisso. Se deve cambiare il percorso piattaforma di origine → piattaforma di destinazione, è necessario acquistare un servizio di migrazione separato.