Se X-Cart viene scelta come piattaforma di destinazione, la preparazione deve iniziare dalla generazione esatta del sistema di origine e dall’insieme di moduli installati. Gli store X-Cart possono differire in modo sostanziale per versione, edizione, aggiornamenti e generazioni dei moduli. Gli attributi Product possono funzionare come specifiche, valori selezionabili dal cliente o dimensioni delle varianti. Le installazioni più vecchie possono utilizzare Product Variants, mentre ambienti di origine più recenti possono utilizzare Product Variations e strutture di moduli o API differenti. Membership, record multi-vendor, moduli personalizzati e integrazioni esterne possono inoltre cambiare il significato di un record Product, Customer o Order.
L’obiettivo della preparazione è descrivere lo store reale, non uno schema X-Cart generico presunto. Ogni area di preparazione deve identificare un’azione, un responsabile, un’evidenza e una condizione che permetta di considerarla pronta. In questo modo si crea una base controllata per configurare la migrazione.
Stabilire versione X-Cart, edizione, accesso e storia dei moduli
Registrare la versione X-Cart esatta, il contesto dell’edizione o del pacchetto, la cronologia degli aggiornamenti, i moduli attivi, i moduli personalizzati, il tema, la configurazione Storefront o marketplace, la generazione API e l’ambiente di hosting. La storia della versione è particolarmente importante quando il catalogo ha attraversato cambiamenti tra Product Variants e Product Variations, sostituzioni di moduli o migrazioni database personalizzate.
| Azione | Responsabile | Evidenza | Condizione di preparazione |
|---|---|---|---|
| Identificare la versione X-Cart esatta e la cronologia degli aggiornamenti | Responsabile tecnico | Screenshot dell’area amministrativa, informazioni sul pacchetto, note sugli aggiornamenti | La generazione di origine e gli aggiornamenti noti sono registrati. |
| Inventariare moduli attivi e inattivi | Amministratore dello store o sviluppatore | Elenco dei moduli con autore, versione, stato e finalità | Ogni modulo critico per il business ha un responsabile. |
| Identificare l’uso di Product Variants o Product Variations | Responsabili catalogo e tecnici | Stato del modulo, Products rappresentativi, posizioni dati rilevanti | Il modello di variazione attivo è esplicito. |
| Confermare connessione alla sorgente e accesso ai file | Responsabile hosting o tecnico | Stato dell’accesso, note su allowlist o autenticazione | L’installazione di origine prevista è raggiungibile. |
| Registrare tema e livelli di codice personalizzato | Sviluppatore o agenzia | Nome del tema, percorsi dei moduli personalizzati, override, note di implementazione | Presentazione e funzionamento personalizzato sono distinguibili dai record core. |
| Registrare API e sincronizzazioni | Responsabile delle integrazioni | Versione API, responsabile delle credenziali, elenco di webhook o attività pianificate | I sistemi esterni e le relative chiavi record sono noti. |
Preparare Products, classi Product, attributi e varianti
Preparare il catalogo in base al funzionamento commerciale, non soltanto ai nomi dei campi. Identificare classi Product, attributi descrittivi, valori inseriti dal cliente, dimensioni delle varianti, Product Variants legacy, Product Variations attuali, file digitali e restrizioni di membership o vendor. Per ogni struttura, registrare l’identità Product padre o figlia, gli eventuali override di SKU, stock, prezzo, peso o immagine e il modo in cui l’acquirente utilizza la scelta nella vetrina.
| Struttura nel sistema di origine | Azione di preparazione | Evidenza | Condizione di preparazione |
|---|---|---|---|
| Attributo a livello di classe | Registrare classe, gruppo di attributi, tipo, valori ammessi e Products assegnati | Esportazione di classi Product e attributi | Le definizioni condivise possono essere separate dai valori specifici dei Products. |
| Attributo semplice o specifica | Registrare se il valore è descrittivo, utilizzabile come filtro o inserito dal cliente | Products rappresentativi e screenshot della vetrina | Le specifiche non vengono scambiate per varianti acquistabili. |
| Dimensione di variazione selezionabile | Registrare gli attributi usati per costruire le varianti e ogni combinazione attiva | Manifest delle varianti con SKU, stock, prezzo, peso e immagine | Ogni combinazione acquistabile ha un’identità stabile. |
| Modulo legacy Product Variants | Registrare generazione del modulo, stato di aggiornamento e record delle varianti | Evidenza del modulo e ID Product rappresentativi | Strutture legacy e attuali delle varianti non vengono mescolate senza controllo. |
| Product con file o consegna digitale | Registrare riferimenti ai file e regole di accesso | Elenco Product/file e campioni Order | File e relazioni storiche di acquisto sono disponibili. |
| Product limitato per membership o vendor | Registrare la relazione di accesso o proprietà | Matrice membership/vendor | Visibilità o proprietà del Product sono documentate oltre il solo record Product. |
Preparare Categories, navigazione, visibilità per membership e perimetro del catalogo
Separare la struttura dati del catalogo dalla presentazione della navigazione. Registrare gerarchia delle Categories, assegnazioni Product, menu e destinazioni, classi Product, restrizioni di membership e proprietà vendor o seller. La presenza di una Category non dimostra che il menu o il percorso di scoperta verranno ricreati automaticamente nello store di destinazione.
| Area del perimetro catalogo | Responsabile | Evidenza | Condizione di preparazione |
|---|---|---|---|
| Gerarchia delle Categories | Responsabile catalogo | Elenco padre-figlio e assegnazioni Product | Le Categories mantenute hanno finalità e padre chiari. |
| Navigazione e menu | Responsabile della vetrina | Screenshot dei menu ed elenco delle destinazioni | La presentazione del menu è separata dai dati Category. |
| Classi Product | Architetto del catalogo | Mappa classe-Product e classe-attributo | L’ereditarietà degli attributi condivisi è visibile. |
| Restrizioni di membership | Responsabile B2B o account | Matrice membership-Product/Category/prezzo | Gli effetti su accesso e prezzo sono espliciti. |
| Perimetro vendor o seller | Responsabile marketplace | Campioni vendor-Product e vendor-Order | La proprietà del seller non viene appiattita in campi manufacturer o brand. |
Preparare Customers, membership, indirizzi e Orders
I dati Customer X-Cart possono includere utenti, indirizzi, membership, ruoli, campi del profilo, stato account, preferenze marketing, profili vendor e ID esterni. Separare l’identità di accesso dai ruoli Customer, staff, amministratore, vendor o membership.
Per gli Orders, la preparazione deve conservare descrizioni Product al momento dell’Order, SKU, attributi, selezioni delle varianti, prezzi, sconti, imposte, spedizione, etichette di pagamento, stati, note, spedizioni, rimborsi, resi, contesto vendor e riferimenti esterni quando presenti. Registrare quali moduli creano righe Order aggiuntive, sovrapprezzi, record di abbonamento, transazioni di pagamento, dati di evasione degli ordini o dettagli di regolamento marketplace.
| Area record | Azione di preparazione | Evidenza | Condizione di preparazione |
|---|---|---|---|
| Utenti e Customers | Classificare Customer, amministratore, vendor e altri ruoli | Inventario utenti-ruoli | Gli account non vengono unificati soltanto perché condividono una tabella. |
| Membership | Registrare significato corrente e storico delle membership | Elenco membership e campioni Customer | Il funzionamento di catalogo o prezzo dipendente dalla membership ha un responsabile. |
| Indirizzi | Separare indirizzi del profilo da snapshot degli Orders | Campioni indirizzi Customer e Order | Gli indirizzi storici restano interpretabili. |
| Stati Order | Registrare nomi degli stati, significato nel flusso e dipendenze dai moduli | Mappa degli stati e Orders rappresentativi | Lo stato storico è comprensibile senza il vecchio colore o la vecchia icona dell’area amministrativa. |
| Righe Order e totali | Includere valori delle varianti, sconti, imposte, commissioni, spedizione e righe create da moduli | Dettaglio di Orders rappresentativi | La transazione può essere ricostruita dalle evidenze storiche. |
| ID esterni | Registrare chiavi di pagamento, ERP, marketplace, spedizione o contabilità | Registro degli identificatori | I sistemi che continuano a operare possono trovare lo stesso record. |
Evitare di “ripulire” gli Orders storici sostituendo vecchi nomi Product o attributi con i valori correnti del catalogo. Lo snapshot di origine fa parte dell’evidenza storica.
Inventariare moduli, codice personalizzato, tabelle personalizzate e sistemi esterni
I moduli X-Cart possono estendere o sostituire strutture dati core, aggiungere tabelle database, modificare il funzionamento dei modelli, creare risorse API, aggiungere campi o controllare il rendering della vetrina. Le generazioni X-Cart attuali e precedenti utilizzano inoltre percorsi e framework dei moduli differenti. Preparare quindi un registro delle responsabilità, non un semplice elenco dei moduli installati.
| Effetto del modulo | Evidenza da preparare | Condizione di preparazione |
|---|---|---|
| Campo Product o Customer | Chiave del campo, tipo di dati, proprietario dell’entità, ID rappresentativi | Il valore ha un responsabile nella destinazione o un’esclusione deliberata. |
| Estensione di varianti o inventario | Record delle combinazioni, fonte dello stock, chiave SKU esterna | Identità acquistabile e sistema autorevole per lo stock sono espliciti. |
| Record di abbonamento, prenotazione, bundle o servizio | Relazioni con Product padre, Customer, Order e pianificazione | I record specializzati non vengono ridotti a metadati Product. |
| Modulo marketplace | Relazioni vendor, offerta, commissione, pagamento al seller e Order | I record marketplace sono separati dall’identità del catalogo core. |
| Modulo di pagamento o evasione degli ordini | Riferimenti storici a transazioni, spedizioni o stati | La cronologia può essere separata dalla configurazione futura. |
| Codice o tabella personalizzata | Schema, relazioni tra chiavi, flusso attivo, proprietario dei dati | È documentata l’entità aziendale, non soltanto la tabella. |
| PIM, ERP, WMS, CRM o marketplace esterno | Autorità per campo e ID stabili | Il sistema autorevole che continuerà a operare è identificato. |
Classificare i moduli come attivi e necessari, attivi ma sostituibili, solo storici, inattivi con dati mantenuti oppure obsoleti. Anche un modulo inattivo può possedere record ancora necessari per gli Orders storici.
Preparare contenuti, media, URL e risorse della vetrina
I contenuti X-Cart possono includere descrizioni Product e Category, Pages statiche o CMS, Blog Posts quando forniti da un modulo, menu, banner, etichette, traduzioni, template email, blocchi del tema e pagine generate dai moduli. Preparare i contenuti in base al proprietario, invece di trattare tutto il testo visibile come un’unica esportazione CMS.
Registrare le route importanti di Products, Categories, contenuti, membership, vendor e moduli. Includere percorsi canonici, ambito linguistico o della vetrina, importanza in termini di traffico, modulo che genera la route e destinazione prevista. Temi e moduli possono creare route che non corrispondono a normali record di contenuto.
Preparare media e file originali insieme alle loro relazioni database. Registrare archiviazione esterna, dimensioni generate, originali mancanti, percorsi sensibili alle maiuscole/minuscole e file protetti da regole di accesso specifiche dei moduli.
Creare un pacchetto di origine X-Cart ripristinabile
Un pacchetto di origine X-Cart self-hosted dovrebbe includere backup del database, file applicativi e pubblici rilevanti, dettagli dell’ambiente, manifest dei moduli, note su implementazione o aggiornamenti, stato di accesso e un registro delle modifiche strutturali avvenute dopo il momento in cui sono state raccolte le evidenze.
| Componente del pacchetto | Responsabile | Evidenza | Condizione di preparazione |
|---|---|---|---|
| Database | Amministratore database | Dump con timestamp e nota sulla possibilità di ripristino | Tabelle core e dei moduli provengono dallo stesso stato dello store. |
| File applicativi e pubblici | Responsabile tecnico | Archivio dei file o albero sorgente accessibile | Moduli, temi, media e file protetti sono disponibili. |
| Ambiente | Responsabile tecnico | Note su PHP, database, queue, cache, storage e web server | Il funzionamento sensibile alla versione può essere interpretato. |
| Manifest dei moduli | Sviluppatore o amministratore dello store | Elenco moduli attivi/inattivi con versioni | Le entità appartenenti ai moduli possono essere tracciate. |
| Registro delle modifiche | Responsabile del progetto | Modifiche tardive successive alla raccolta delle evidenze | Nuovi Products, moduli o cambiamenti di schema sono visibili. |
Selezionare campioni rappresentativi per i test di migrazione
Preparare un manifest dei campioni che includa ID di origine, record correlati di moduli o sistemi esterni, file media e relazioni attese nel sistema di origine. Il manifest è pronto quando le evidenze selezionate sono complete, tracciabili e assegnate a un revisore.
Includere:
- Products semplici e Products appartenenti a diverse classi Product;
- Products con attributi descrittivi, valori inseriti dal cliente e varianti attive;
- un caso con varianti legacy o con Product Variations migrate se lo store ha attraversato quel cambiamento di modulo;
- Products limitati per membership o posseduti da vendor quando queste funzioni sono utilizzate;
- Customers con membership, più indirizzi, ID esterni o ruoli vendor;
- Orders di clienti non registrati e registrati con varianti, totali insoliti, rimborsi, spedizioni e record creati da moduli;
- esempi importanti di Categories, contenuti, media e route;
- un record di modulo personalizzato attivo e una relazione con un sistema esterno.
Applicare il gate finale di preparazione per X-Cart
| Domanda di preparazione | Risultato richiesto |
|---|---|
| La storia della sorgente è nota? | Versione, contesto dell’edizione, cronologia degli aggiornamenti, generazione dei moduli e ambiente sono registrati. |
| Il significato del catalogo è completo? | Classi Product, attributi, varianti, Categories, membership, vendor e media sono rappresentati. |
| Account e Orders sono interpretabili? | Ruoli, membership, indirizzi, snapshot Order, stati e riferimenti esterni hanno responsabili. |
| Moduli e dati personalizzati sono classificati? | I record attivi e storici appartenenti ai moduli hanno una destinazione o decisione definita. |
| Contenuti e route sono inventariati? | Percorsi pubblici, route dei moduli, media e risorse di presentazione sono documentati. |
| Il pacchetto di origine è ripristinabile? | Database e file corrispondono allo stesso stato dello store. |
| Il manifest dei campioni è rappresentativo? | Sono inclusi casi core, complessi, legacy, appartenenti a moduli e collegati a sistemi esterni. |
Le incognite critiche devono restare decisioni aperte con un responsabile. Non finalizzare la preparazione se il modello delle varianti, il proprietario di un modulo, la relazione vendor o un identificatore esterno rimangono non classificati.
Conclusione
La preparazione di una migrazione verso X-Cart dipende dalla storia del sistema di origine. Versione, generazione dei moduli, classi Product, attributi, varianti, membership, vendor, estensioni degli Orders, moduli personalizzati e sistemi esterni determinano quali record esistono e come sono collegati.
Un pacchetto di origine ripristinabile e un manifest di evidenze rappresentative permettono di configurare la migrazione in base allo store effettivo.
Domande frequenti
Perché è necessario registrare versione X-Cart e generazione dei moduli?
Strutture e implementazioni dei moduli X-Cart sono cambiate tra le diverse generazioni. Lo stesso concetto visibile nella vetrina può essere archiviato attraverso moduli, entità o API differenti, quindi versione e insieme di moduli effettivamente utilizzati determinano quali evidenze siano autorevoli.
Gli attributi X-Cart e le Product Variations sono la stessa cosa?
No. Gli attributi possono descrivere i Products, raccogliere valori inseriti dal cliente o partecipare a varianti acquistabili. Soltanto le relazioni che definiscono SKU, disponibilità, prezzo, peso o immagine separati devono essere trattate come identità di variante.
Cosa deve essere preparato per le membership X-Cart?
Registrare definizioni delle membership, assegnazioni Customer, restrizioni Product o Category, effetti sui prezzi, regole degli account e Orders rappresentativi. L’etichetta della membership da sola non preserva il suo significato commerciale o di accesso.
I moduli X-Cart inattivi possono essere ignorati?
Non automaticamente. Un modulo inattivo può ancora possedere record Order storici, campi Customer o identificatori esterni. Registrare se i suoi dati sono ancora necessari prima di classificarlo come obsoleto.
Cosa deve contenere il manifest dei campioni X-Cart?
Includere Products semplici e basati su classi, attributi e varianti, membership o vendor dove utilizzati, Orders complessi, route importanti, record appartenenti a moduli e relazioni con sistemi esterni. Usare ID di origine esatti e relative evidenze.
Perché sono necessari sia il backup del database sia quello dei file?
Il database contiene record core e dei moduli, mentre i file possono contenere moduli, temi, media, asset scaricabili, configurazione e codice personalizzato. Un pacchetto di origine completo richiede entrambi provenienti dallo stesso stato dello store.