Se Gambio viene scelto come piattaforma di destinazione, la preparazione deve innanzitutto identificare quale generazione della struttura di catalogo, quale ambiente di hosting, quali moduli e quali personalizzazioni utilizza realmente lo store di origine. Le attuali Product Options e Product Variants possono convivere, negli store attivi da molti anni, con precedenti attributi o proprietà degli articoli. I Products possono inoltre dipendere da visibilità per gruppo Customer, prezzi di gruppo, prezzi graduati, Categories, contenuti, moduli, sistemi esterni e campi multilingua.
Ogni attività di preparazione deve indicare un responsabile, un’evidenza e una condizione di prontezza. Il pacchetto deve distinguere le evidenze dell’origine dall’implementazione sulla destinazione: relazioni Product/variante, Orders storici, record Content Manager, URL, identificativi esterni e dati gestiti da moduli fanno parte della preparazione alla migrazione; il funzionamento attivo di pagamenti, spedizioni, imposte, email, tema e processo di acquisto resta invece configurazione lato destinazione.
Confermare ambiente Gambio, accessi e percorso di ripristino
Registrare se lo store di origine utilizza Gambio Cloud o un’installazione self-hosted. Confermare l’accesso all’area amministrativa e, dove applicabile, a hosting, database, filesystem, immagini Product, file scaricabili, Content Manager, moduli, processi pianificati e sistemi collegati. Registrare la versione Gambio, l’ambiente PHP/database per gli store self-hosted, il tema, le lingue, le valute, i moduli attivi, i GXModules, il codice personalizzato e le integrazioni.
| Attività di preparazione | Responsabile | Evidenza | Condizione di prontezza |
|---|---|---|---|
| Confermare l’accesso amministrativo | Amministratore Gambio | Account funzionante e riepilogo del ruolo | Products, opzioni, varianti, Customers, Orders, contenuti e moduli possono essere esaminati. |
| Confermare l’accesso all’ambiente | Responsabile infrastruttura | Riepilogo dell’accesso Cloud oppure a hosting/database/filesystem | Le evidenze disponibili nell’origine sono note per l’ambiente operativo. |
| Creare backup ripristinabili | Responsabile infrastruttura | Backup di database, file, immagini, download e configurazione con responsabile del ripristino | Lo store di origine può essere ripristinato senza dipendere dal sistema live. |
| Registrare versioni e personalizzazioni | Responsabile tecnico | Inventario di Gambio, PHP/database se rilevante, tema, moduli, GXModules e codice personalizzato | Strutture dipendenti dalla versione e modifiche sono documentate. |
| Mappare i sistemi esterni | Responsabili delle integrazioni | Endpoint e ID di ERP/PIM/WMS/CRM/marketplace/contabilità/pagamenti/evasione | Autorità dati che continueranno a operare e chiavi di sincronizzazione sono note. |
Conservare gli identificativi di Products, varianti correnti, attributi/proprietà legacy, Categories, gruppi Customer, Customers, Orders, contenuti, moduli e sistemi esterni. La mappa degli identificativi è essenziale quando la stessa scelta visibile può essere memorizzata attraverso generazioni Gambio differenti.
Classificare Products, tipi Product e relazioni con le Categories
Preparare i Products in base al funzionamento commerciale, non al numero di righe. Registrare numero articolo, identificativi modello o barcode, tipo Product, prezzo, classe fiscale, stock, dimensioni, Manufacturer, Categories, immagini, file scaricabili, stato di consegna, regole di quantità, descrizioni multilingua, metadati e visibilità.
| Modello Product | Evidenze da preparare | Condizione di prontezza |
|---|---|---|
| Product fisico standard | ID Product, numero articolo/modello, prezzo, imposta, stock, peso, Category, Manufacturer e immagini | Un solo record identifica chiaramente l’articolo venduto ed evaso. |
| Product scaricabile | File, collegamento Product, relazione di accesso, limiti o scadenza se utilizzati e campione di Order completato | Il file e l’evidenza storica dell’acquisto sono recuperabili. |
| Servizio o Product senza spedizione | Tipo Product, prezzo, imposta, disponibilità ed esempio di Order | Non vengono inventati dati di stock fisico o spedizione. |
| Product in più Categories | Assegnazioni Product-Category e principali percorsi pubblici | Non vengono creati Products duplicati soltanto per riprodurre i percorsi di scoperta. |
| Product limitato a gruppi Customer | Visibilità per gruppo, ID Product, relazioni di prezzo e Customers rappresentativi | Accesso e ambito commerciale sono documentati oltre allo stato del Product. |
| Product ricco di media | Immagini principali/aggiuntive, media specifici di variante, ordine e percorso di archiviazione | Ogni risorsa ha un proprietario Product o variante noto. |
Registrare casi inattivi, nascosti, fuori produzione, non disponibili, in back-order, con quantità minima e con quantità graduata. Questi stati richiedono un trattamento esplicito sulla destinazione.
Separare Product Options e varianti correnti dalle strutture legacy
La documentazione corrente di Gambio distingue opzioni, Product Options e Product Variants. Le Product Variants rappresentano combinazioni concrete e possono sovrascrivere identificativi, stock, prezzo, peso o relazioni con immagini del Product padre. Gli store più vecchi possono utilizzare attributi o proprietà degli articoli per scelte simili attraverso tabelle e regole differenti.
| Struttura nell’origine | Evidenze da preparare | Condizione di prontezza |
|---|---|---|
| Opzione corrente | ID opzione, valori, traduzioni, ordine e assegnazioni Product | Le definizioni riutilizzabili delle scelte sono documentate. |
| Product Option | Product, valori collegati, riferimenti immagini, obbligatorietà e scopo di visualizzazione | I valori selezionabili a livello Product sono tracciabili. |
| Product Variant | ID variante, combinazione di opzioni, modello/EAN/GTIN, prezzo, stock, peso, elenco immagini e collegamento Product | Ogni combinazione vendibile ha un’identità completa. |
| Attributo articolo legacy | Gruppo/valore attributo, collegamento Product, effetto su prezzo/peso, comportamento stock ed esempi di righe Order | Il funzionamento legacy non viene rinominato come variante corrente senza evidenza. |
| Proprietà articolo legacy | Gruppi proprietà, valori, combinazioni, stock, collegamento Product e contesto della versione di origine | Proprietà della combinazione e provenienza sono esplicite. |
| Personalizzazione dell’acquirente | Proprietario GX-Customizer o modulo, definizione del campo, valore inserito e riferimento alla riga Order | L’input occasionale del Customer resta distinto dai dati di variante riutilizzabili. |
Creare un registro delle scelte con una riga per ogni famiglia di opzioni importante. Indicare se il valore modifica identità vendibile, prezzo, stock, peso, media, evasione, filtro oppure soltanto la descrizione Product.
Preparare gruppi Customer, prezzi, regole di quantità e stock
I gruppi Customer di Gambio possono influire sull’accesso a Products e Categories, sulla visibilità dei contenuti, sui prezzi Product, sui prezzi graduati, sul trattamento fiscale, sugli sconti e su altre regole commerciali. Lo stock può appartenere a un Product o a una Product Variant, mentre sistemi esterni possono continuare a esserne l’autorità.
| Area commerciale | Evidenza | Responsabile | Condizione di prontezza |
|---|---|---|---|
| Gruppo Customer | ID gruppo, nome, membri, assegnazioni di visibilità, campi prezzo, comportamento sconti o imposte | Responsabile commerciale | Il significato del gruppo è documentato oltre all’etichetta. |
| Prezzo specifico per gruppo | Product/variante, gruppo, valuta, importo e comportamento di fallback | Responsabile dei prezzi | Ogni prezzo è collegato al Product e al gruppo previsti. |
| Prezzo graduato | Product/variante, gruppo, soglie di quantità, prezzo e contesto temporale | Responsabile dei prezzi | Soglie e ambito commerciale sono completi. |
| Regola di quantità | Quantità minima, incremento di acquisto, unità di confezionamento e proprietario Product/variante | Responsabile catalogo | I vincoli di quantità non sono nascosti nelle note. |
| Stock | ID Product/variante, quantità, modalità di gestione stock, stato back-order e autorità esterna | Responsabile inventario | È nota la quantità autorevole per l’unità vendibile. |
| Promozione o coupon | Codice/regola, valore, condizioni, date, utilizzo e riferimenti agli Orders storici | Responsabile marketing | L’evidenza storica dello sconto resta separata dalla configurazione attiva sulla destinazione. |
Prezzi e sconti degli Orders storici devono restare snapshot. Non devono essere ricalcolati in base alle impostazioni correnti dei gruppi Customer.
Preparare Customers, indirizzi, Orders e storico dell’assistenza
La preparazione dei Customers deve includere identità, appartenenza ai gruppi Customer, indirizzi, informazioni aziendali o fiscali, stato dell’account, evidenze di consenso, Reviews, note quando rilevanti, ID esterni e dipendenze di autenticazione. La preparazione degli Orders deve mantenere righe Product o variante, valori selezionati, indirizzi, quantità, prezzi, imposte, sconti, etichette di pagamento e spedizione, stati, commenti, fatture, consegne, rimborsi, recessi e riferimenti esterni.
| Area del record | Evidenza | Responsabile | Condizione di prontezza |
|---|---|---|---|
| Identità Customer | ID Customer, email, gruppo, stato, indirizzi, lingua, campi azienda/fiscali e ID esterno | Responsabile dati Customer | Account duplicati e assegnazioni gruppo sono risolti deliberatamente. |
| Autenticazione | Schema password, social login/SSO, MFA, percorso di reset e responsabile della comunicazione | Responsabile sicurezza | L’accesso account è pianificato senza presumere la portabilità delle password. |
| Righe Order | ID Product/variante, nomi snapshot, valori opzione, quantità, prezzo, imposta e sconto | Responsabile dati Order | Gli articoli acquistati restano comprensibili indipendentemente dai dati correnti di catalogo. |
| Stato e commenti Order | Storico stati, timestamp, commenti pubblici/interni e team responsabile | Responsabile operations | Il significato storico del processo è documentato. |
| Documenti e record post-vendita | Fattura, documento di consegna, rimborso, recesso, tracking e riferimenti di pagamento | Responsabili finanza/assistenza | Le evidenze storiche per assistenza e riconciliazione sono recuperabili. |
| ID esterni | Chiavi ERP, marketplace, contabilità, pagamento ed evasione | Responsabili integrazioni | La provenienza cross-system resta tracciabile. |
Includere account di clienti non registrati o con restrizioni, gruppi dealer, più indirizzi, Orders con opzioni correnti e legacy, casi di prezzi graduati, rimborsi, recessi e Orders evasi da sistemi esterni.
Preparare Categories, record Content Manager, pagine legali e URL
I contenuti Gambio possono risiedere nelle descrizioni Product o Category, nei tab Product, nelle voci del Content Manager, nelle pagine legali, in banner, aree teaser, menu, temi, file di lingua o moduli. L’accesso per gruppo Customer può essere applicato anche a Products, Categories e contenuti.
| Area della vetrina | Evidenze da preparare | Condizione di prontezza |
|---|---|---|
| Gerarchia Category | ID Category, parent, assegnazioni Product, visibilità per gruppo, traduzioni, immagini e metadati | Gerarchia del catalogo e ambito di accesso sono completi. |
| Record Content Manager | ID contenuto, tipo, lingua, stato, accesso per gruppo, percorso, posizionamento menu/footer e media | Il contenuto CMS resta separato dalla presentazione del tema. |
| Tab Product o campo aggiuntivo | ID Product, definizione campo/tab, lingua, posizione di visualizzazione e tema/modulo che lo utilizza | Il contenuto appartenente al Product non viene convertito in una Page generica. |
| URL prioritario | Proprietario Product/Category/contenuto, lingua, percorso di origine, metadati e destinazione prevista | Ogni percorso di alto valore ha una decisione di mantenimento, modifica, unione, ritiro o redirect. |
| Link interno | Contenuto di origine, oggetto collegato, vecchio percorso e destinazione prevista | I link possono essere riscritti senza perdere il record di riferimento. |
| Contenuto tema o StyleEdit | Tema, blocco, posizionamento, contenuto di origine e responsabile | Le dipendenze di presentazione restano separate dai contenuti trasferibili. |
Includere pagine legali e policy come record di contenuto, assegnando però la revisione legale corrente al responsabile aziendale appropriato. La preparazione della migrazione deve conservare identità e posizionamento del contenuto, non certificarne l’aggiornamento legale.
Inventariare moduli, GXModules, tabelle personalizzate e integrazioni
Creare un registro di proprietà per moduli, GXModules, componenti di pagamento e spedizione, connettori marketplace, flussi Product, ricerca, loyalty, Reviews, personalizzazione, integrazioni ERP/PIM/WMS/CRM, tabelle personalizzate, campi modificati e cambiamenti diretti al database.
| Dipendenza | Evidenze da preparare | Condizione di prontezza |
|---|---|---|
| Modulo o GXModule | Nome, versione, stato, scopo, responsabile configurazione, tabelle/campi e record interessati | I dati appartenenti al modulo hanno una destinazione o un responsabile mantenuto. |
| Campo/tabella personalizzata | Schema, relazioni tra chiavi, scopo aziendale e codice che utilizza il dato | I record personalizzati possono essere interpretati invece di essere copiati alla cieca. |
| Personalizzazione del tema | Versione tema, impostazioni StyleEdit, override, script e contenuti/percorsi interessati | La presentazione è separata dai record trasferibili. |
| Sistema esterno | Endpoint, entità autorevoli, direzione di sincronizzazione, ID e responsabile del passaggio operativo | Si evitano sistemi di riferimento concorrenti. |
| API o flusso dati | Risorse, responsabile delle credenziali, identificativi nei dati trasmessi, direzione di aggiornamento e responsabile degli errori | Le evidenze dell’integrazione sono complete senza esporre segreti nella documentazione. |
| Dati generati | Cache, log, sessioni, indici di ricerca, export temporanei e tabelle abbandonate | I dati non autorevoli vengono esclusi deliberatamente. |
I moduli inattivi devono restare nel registro quando i loro campi o record storici sono ancora presenti in Products, Customers, Orders o contenuti.
Selezionare campioni rappresentativi per il test di migrazione
Scegliere campioni che espongano la reale generazione Gambio e il modello operativo dello store. Registrare ID di origine, numeri articolo, URL, provenienza delle opzioni, gruppi Customer, dipendenze da moduli, chiavi esterne e motivo della selezione di ciascun campione.
| Campione | Evidenze da preparare | Scopo della preparazione |
|---|---|---|
| Product standard | Prezzo, imposta, stock, Category, Manufacturer, media, visibilità per gruppo e Order | Definisce il riferimento ordinario per i Products. |
| Famiglia di Product Variants correnti | Product, opzioni, varianti, identificativi, stock, prezzo, peso, immagini e Orders | Rappresenta l’attuale modello delle combinazioni. |
| Product con attributi/proprietà legacy | Versione di origine, gruppi/valori, combinazioni, comportamento prezzo/stock e righe Order | Espone la struttura legacy prima della mappatura. |
| Caso di gruppo Customer | Customer, gruppo, Product/contenuto con restrizioni, prezzo e Order rilevante | Rappresenta il commercio segmentato. |
| Order complesso | Variante o scelta legacy, sconto, imposta, pagamento, spedizione, fattura, rimborso/recesso e ID esterni | Rappresenta l’evidenza commerciale storica. |
| Caso contenuto/percorso | Voce Content Manager o contenuto Product/Category, lingua, accesso per gruppo, URL e link | Rappresenta proprietà dei contenuti e SEO. |
| Record gestito da modulo | Entità core, tabella/campo del modulo, responsabile configurazione e chiave di integrazione | Espone l’ambito non core prima dell’esecuzione. |
Il pacchetto di campioni Gambio è pronto quando ogni record selezionato dispone di una scheda delle aspettative di origine, del contesto opzione/variante, dei file correlati e di un revisore nominato.
Completare il controllo finale di preparazione per Gambio
| Area di preparazione | Condizione di prontezza |
|---|---|
| Accesso e ripristino | Area amministrativa, Cloud oppure accesso a hosting/database/file, immagini, download, backup e responsabilità del ripristino sono confermati. |
| Catalogo | Products, varianti correnti, attributi/proprietà legacy, Categories, Manufacturers, media, prezzi, stock e identificativi sono tracciabili. |
| Customers e Orders | Account, gruppi, indirizzi, Orders, righe, totali, stati, documenti, record post-vendita e ID esterni dispongono di evidenze. |
| Contenuti e URL | Record Content Manager, pagine legali, contenuti Product/Category, temi, percorsi prioritari, link e decisioni di redirect sono documentati. |
| Dipendenze | Moduli, GXModules, campi/tabelle personalizzati, API, flussi dati e sistemi esterni hanno responsabili nominati. |
| Campioni | I record rappresentativi coprono ogni modello rilevante corrente, legacy, per gruppi Customer, Order, contenuto e modulo. |
L’ambito Gambio è pronto quando ogni record rilevante può essere ricondotto alla propria generazione di origine, al responsabile, ai record correlati, all’evidenza e alla destinazione prevista o al sistema che continuerà a gestirlo.
Conclusione
La preparazione di una migrazione verso Gambio richiede evidenze coordinate sull’ambiente operativo, Products, opzioni e varianti correnti, attributi o proprietà legacy, gruppi Customer, prezzi, stock, Customers, Orders, record Content Manager, URL, moduli e sistemi esterni. La checklist deve rendere esplicite provenienza e proprietà prima dell’esecuzione.
Un pacchetto di preparazione completo conserva evidenze dell’origine ripristinabili, distingue le strutture di catalogo correnti da quelle legacy, separa transazioni storiche e configurazione attiva e assegna a ogni dipendenza di contenuto o modulo un responsabile definito.
Domande frequenti
Cosa deve essere preparato per primo in una migrazione verso Gambio?
Confermare se lo store è Cloud o self-hosted, garantire gli accessi amministrativi e infrastrutturali disponibili, creare backup ripristinabili e registrare versione Gambio, tema, moduli e personalizzazioni.
Perché varianti correnti e attributi o proprietà legacy devono essere separati?
Perché possono produrre scelte simili nella vetrina attraverso record e regole differenti. Le Product Variants correnti possono possedere identificativi, stock, prezzo, peso e immagini, mentre attributi o proprietà più vecchi possono memorizzare tali relazioni diversamente.
Come devono essere preparati i gruppi Customer?
Documentare appartenenza al gruppo insieme a visibilità di Products, Categories e contenuti, prezzi di gruppo, prezzi graduati, sconti e comportamento fiscale. Conservare soltanto il nome del gruppo non ne mantiene il significato commerciale.
Quali Orders Gambio devono essere scelti come campioni rappresentativi?
Includere varianti correnti, scelte basate su attributi/proprietà legacy, prezzi per gruppi Customer, account non registrati o dealer, sconti, imposte, fatture, consegne, rimborsi o recessi e riferimenti di integrazione esterni.
Come devono essere separati Content Manager e contenuti del tema?
Le voci del Content Manager e i contenuti Product/Category devono mantenere identità del record, lingua, accesso, percorso e link. StyleEdit, blocchi del tema e override dei template appartengono alla presentazione e richiedono una responsabilità separata.
Cosa deve essere incluso nel registro dei moduli Gambio?
Registrare ogni modulo, GXModule, tabella o campo personalizzato, flusso dati, connessione API e integrazione esterna che crea o utilizza dati aziendali. Ogni voce deve avere un responsabile, record interessati, evidenze e una decisione sulla destinazione o sul sistema che continuerà a gestirla.