Se PrestaShop viene scelta come piattaforma di destinazione, la preparazione deve documentare sia i record commerciali sia il contesto del negozio in cui tali record operano. I Products possono dipendere da combinazioni, attributi, caratteristiche, campi di personalizzazione, fornitori, produttori, Categories, immagini, scorte, gruppi di clienti, lingue, valute e assegnazioni multistore. Anche Customers e Orders possono variare in base a negozio, gruppo, corriere, modulo, valuta, imposta e stato storico.
Ogni attività di preparazione dovrebbe identificare il responsabile, l’elemento di prova e la condizione che definisce la preparazione completata. Il pacchetto deve separare i record di origine dalla configurazione della destinazione: Orders storici, combinazioni dei Products, gruppi di clienti, assegnazioni ai negozi, URL e dati gestiti dai moduli fanno parte della preparazione alla migrazione, mentre il funzionamento attivo di corrieri, pagamenti, imposte, tema, email e checkout rimane un’attività di implementazione sulla piattaforma di destinazione.
Mettere in sicurezza Back Office, hosting, database, file e backup
Verificare l’accesso al Back Office di PrestaShop, all’hosting, al database, al filesystem, alle directory delle immagini, ai file scaricabili, ai cron job, alle impostazioni Webservice, alla gestione dei moduli e ai servizi collegati. Registrare la versione di PrestaShop, l’ambiente PHP e database, il prefisso del database, il tema attivo, le lingue, le valute, i negozi, i moduli, gli override e il codice personalizzato.
| Attività di preparazione | Responsabile | Evidenza | Condizione di preparazione completata |
|---|---|---|---|
| Verificare l’accesso amministrativo | Amministratore PrestaShop | Account funzionante e riepilogo delle autorizzazioni | Products, combinazioni, Customers, Orders, negozi, moduli e configurazione possono essere ispezionati. |
| Creare backup ripristinabili | Responsabile dell’infrastruttura | Dump del database, archivio di filesystem/immagini, archivio dei file scaricabili e responsabile del ripristino | Il negozio di origine può essere ripristinato senza dipendere dall’ambiente live. |
| Documentare l’ambiente tecnico | Responsabile tecnico | Inventario di PrestaShop, PHP, database, tema, moduli, override e distribuzione | Dati e personalizzazioni dipendenti dalla versione sono documentati. |
| Acquisire gli accessi Webservice e delle integrazioni | Responsabili delle integrazioni | Chiavi Webservice, risorse consentite, endpoint esterni e mappe degli identificativi | I sistemi che continueranno a operare e le interfacce disponibili sulla sorgente sono noti. |
| Conservare gli identificativi di origine | Responsabile dei dati | ID di negozi, Products, combinazioni, Customers, Orders, indirizzi, Categories, moduli e sistemi esterni | Le relazioni tra tabelle e tra sistemi possono essere riconciliate. |
Non eliminare moduli inattivi, override o vecchi campi finché non ne è stata verificata la proprietà dei dati. Un componente inattivo può comunque possedere record storici relativi a Products, Customers o Orders.
Definire l’ambito di multistore, gruppi di negozi, lingue e valute
Il multistore di PrestaShop può applicare dati e impostazioni al contesto di tutti i negozi, di un gruppo di negozi o di un singolo negozio. I negozi possono condividere Customers o Orders in base alla configurazione del gruppo, mentre Products, Categories, prezzi, lingue, corrieri, moduli e URL possono variare a seconda del contesto.
| Area dell’ambito | Evidenza da preparare | Condizione di preparazione completata |
|---|---|---|
| Struttura dei negozi | ID dei gruppi di negozi, ID dei negozi, nomi, stato, negozio predefinito, domini e URI fisico | Ogni contesto del sito pubblico è elencato una sola volta. |
| Impostazioni dei dati condivisi | Condivisione di Customers, Orders e quantità, oltre alle regole a livello di gruppo | Le identità condivise sono distinte dai record duplicati. |
| Assegnazioni di Products e negozi | Disponibilità di Products e Categories, stato, prezzo, testi e immagini specifici per negozio | La presenza di un Product non viene dedotta dal solo negozio predefinito. |
| Lingue e valute | Assegnazioni ai negozi, traduzioni, lingua predefinita, valuta, contesto del tasso di cambio e fallback | I record localizzati rimangono collegati al negozio previsto. |
| Contesto degli URL | Dominio, sottodominio o percorso, dominio SSL, URI fisico, URI virtuale e URL principale | Ogni negozio pubblico dispone di un’identità di percorso completa. |
Registrare quali negozi devono rimanere separati, quali saranno consolidati e quali identificativi storici dei negozi devono rimanere associati a Customers o Orders. Questa decisione deve esistere prima di normalizzare Products o Customers duplicati.
Preparare Products, combinazioni, attributi e caratteristiche
PrestaShop distingue i Products dalle combinazioni. Attributi e valori degli attributi generano le combinazioni, mentre le caratteristiche descrivono proprietà che non creano una variante. I record a livello di combinazione possono contenere riferimenti, riferimenti del fornitore, codici a barre, impatto sul prezzo, impatto sul peso, quantità, quantità minima, date di disponibilità, immagini e stato della combinazione predefinita.
| Schema del catalogo | Evidenza da preparare | Condizione di preparazione completata |
|---|---|---|
| Product semplice | ID Product, riferimento, tipo, prezzo, gruppo fiscale, stock, Category, produttore, fornitore, immagini e assegnazioni ai negozi | Il Product può essere interpretato senza dati di combinazione nascosti. |
| Product con combinazioni | ID Product, ID delle combinazioni, valori degli attributi, riferimenti, prezzi, pesi, stock, immagini e combinazione predefinita | Ogni combinazione vendibile è tracciabile in modo indipendente. |
| Caratteristica del Product | Caratteristica, valore, lingua, assegnazione al Product, uso nei filtri o nel confronto | Le informazioni descrittive sono separate dalle opzioni acquistabili. |
| Pacchetto o Product virtuale | Relazioni con componenti/file, quantità, regole di accesso ed esempi di Orders | Il funzionamento dei Products non semplici dispone di evidenza completa dalla sorgente. |
| Relazione fornitore/produttore | ID, riferimenti, collegamenti ai Products, contesto di approvvigionamento e chiavi esterne | Proprietà del brand e dell’approvvigionamento rimangono distinte. |
| Product multistore | Assegnazioni ai negozi, valori specifici per negozio, Categories, prezzi e stato | Il contesto del negozio viene mantenuto invece di essere appiattito. |
Includere casi inattivi, solo online, non disponibili, fuori produzione, esauriti, in preordine, con quantità minima e con disponibilità limitata nel tempo. Questi stati richiedono una decisione esplicita sulla destinazione, non una normalizzazione automatica.
Preparare personalizzazioni, prezzi specifici, stock e gruppi di clienti
I campi di personalizzazione possono raccogliere testo o file inseriti dall’acquirente e rimanere associati a un Product e successivamente a una riga di Order. I prezzi specifici possono dipendere da Product, combinazione, negozio, valuta, paese, gruppo di clienti, Customer, quantità e intervallo di date. Lo stock può appartenere a un Product o a una combinazione e può essere condiviso tra più negozi.
| Struttura commerciale | Evidenza | Condizione di preparazione completata |
|---|---|---|
| Campo di personalizzazione | ID del campo, Product, tipo, stato obbligatorio, etichetta, posizione del file caricato ed esempio di riga Order | I dati inseriti dall’acquirente rimangono distinti dagli attributi riutilizzabili del Product. |
| Prezzo specifico | Product/combinazione, negozio, valuta, paese, gruppo, Customer, quantità, data, tipo di riduzione e priorità | Ogni prezzo condizionale dispone del contesto completo. |
| Gruppo di clienti | ID del gruppo, membri, uso come gruppo predefinito, visualizzazione del prezzo, riduzione, accesso alle Categories e assegnazione al negozio | Il significato del gruppo è documentato oltre il suo nome. |
| Stock | ID Product/combinazione, contesto della quantità per negozio o condivisa, stato riservato se disponibile e sistema autorevole esterno | Sono noti l’unità vendibile e il contesto di negozio di ogni quantità. |
| Regola del carrello | Codice, condizioni, azioni, restrizioni, date, utilizzo e riferimenti a Orders storici | L’evidenza storica degli sconti è separata dalla configurazione delle promozioni future. |
Prezzi e sconti degli Orders storici devono rimanere fotografie del momento in cui l’ordine è stato effettuato. Non devono essere ricostruiti a partire dai prezzi specifici, dai gruppi o dalle regole del carrello attuali.
Preparare Categories, CMS Pages, URL descrittivi e percorsi di scoperta
Le Categories di PrestaShop possono avere una gerarchia padre-figlio, assegnazioni ai negozi, nomi e descrizioni localizzati, immagini, metadati, URL descrittivi, accesso per gruppo e appartenenza dei Products. CMS Pages e Categories possono ospitare contenuti legali, di servizio ed editoriali. I moduli di navigazione e le strutture del tema possono creare ulteriori percorsi attraverso cui i clienti raggiungono i contenuti.
| Area del sito pubblico | Evidenza da preparare | Condizione di preparazione completata |
|---|---|---|
| Gerarchia delle Categories | ID Category, elementi padre, assegnazioni ai negozi, gruppi di accesso, appartenenza dei Products e traduzioni | Tassonomia e ambito di accesso sono completi. |
| URL di Products e Categories | URL descrittivo, negozio, lingua, intento canonico, metadati e priorità | I percorsi di valore elevato hanno decisioni esplicite sulla destinazione. |
| Contenuto CMS | ID di CMS Page/Category, lingua, assegnazione al negozio, stato, percorso e relazione con il menu | I contenuti CMS rimangono separati dalla presentazione del tema. |
| Navigazione | Modulo di menu, collegamenti, gerarchia, contesto di negozio/lingua e oggetto di destinazione | I percorsi dei clienti non vengono dedotti dalle sole Categories. |
| Collegamenti interni e redirect | Pagina di origine, oggetto collegato, vecchio percorso e intento della destinazione | I collegamenti possono essere riscritti e i percorsi prioritari mantenuti. |
Raccogliere gli URL prioritari da strumenti di analisi, dati di ricerca, backlink, campagne, email ai Customers e navigazione interna. Una sitemap da sola non mostra tutti i percorsi che hanno valore commerciale.
Preparare Customers, indirizzi, Orders e documenti storici
La preparazione dei Customers deve comprendere identità dell’account, gruppo predefinito e gruppi aggiuntivi, contesto del negozio, lingua, indirizzi, consenso, informazioni aziendali o fiscali, ID esterni e dipendenze di autenticazione. La preparazione degli Orders deve conservare il contesto del Customer o dell’ospite, carrello, valuta, negozio, corriere, modulo di pagamento, indirizzi, righe Product e combinazione, personalizzazioni, totali, stati, fatture, documenti di consegna, messaggi, rimborsi e riferimenti esterni.
| Area dei record | Evidenza | Condizione di preparazione completata |
|---|---|---|
| Account Customer | ID Customer, email, negozio, gruppo predefinito/gruppi aggiuntivi, lingua, stato, indirizzi, consenso e ID esterno | Gli account duplicati e condivisi vengono risolti deliberatamente. |
| Autenticazione | Schema delle password, SSO/social login, percorso di reimpostazione e responsabile delle comunicazioni sull’account | L’accesso agli account è pianificato senza presumere la portabilità delle credenziali. |
| Righe Order | Riferimenti a Product/combinazione, etichette storiche, personalizzazioni, quantità, prezzo, imposta e sconto | Gli articoli acquistati rimangono comprensibili indipendentemente dai dati correnti del catalogo. |
| Totali e stato dell’Order | Valuta, subtotale, spedizione, sconti, imposte, totale finale, stato attuale e cronologia | Il significato commerciale storico può essere riconciliato. |
| Documenti e record post-vendita | Fattura, documento di consegna, nota di credito, reso, messaggio, pagamento, corriere e riferimenti di tracciamento | L’evidenza necessaria per assistenza e finanza è recuperabile. |
| ID esterni | Chiavi ERP, marketplace, contabilità, pagamento ed evasione degli ordini | La provenienza tra sistemi rimane tracciabile. |
Selezionare come casi rappresentativi Orders di ospiti e utenti registrati, multi-gruppo e multistore, con combinazioni, personalizzazioni, sconti, rimborsi, resi e spedizioni parziali.
Inventariare moduli, override, temi e tabelle personalizzate
Creare un registro di proprietà per moduli, override, temi, controller personalizzati, tabelle personalizzate, modifiche dirette al database, integrazioni Webservice, flussi dati, marketplace, ricerca, programmi fedeltà, pagamenti, spedizioni, abbonamenti e collegamenti ERP/PIM/WMS/CRM.
| Dipendenza | Evidenza da preparare | Condizione di preparazione completata |
|---|---|---|
| Modulo | Nome, versione, stato, scopo, responsabile della configurazione, tabelle/campi, hook e record interessati | I dati gestiti dal modulo hanno una destinazione o un proprietario mantenuto. |
| Override o codice personalizzato | Override di classe/controller, funzionamento modificato, impatto sul database e sviluppatore responsabile | La logica di business è documentata separatamente dalla vecchia implementazione. |
| Tema | Versione del tema, template, posizioni dei moduli, contenuto incorporato, script personalizzati e dipendenze di percorso | La presentazione è separata dai contenuti e dai record trasferibili. |
| Tabella o colonna personalizzata | Schema, chiavi, record core referenziati e processo che li utilizza | I record personalizzati possono essere interpretati invece di essere copiati senza contesto. |
| Sistema esterno | Endpoint, elementi autorevoli, direzione della sincronizzazione, ID e responsabile del cutover | Si evitano sistemi autorevoli in conflitto tra loro. |
| Dati generati | Cache, indici, log, sessioni, esportazioni temporanee e tabelle abbandonate | I dati non autorevoli vengono esclusi deliberatamente. |
Se la stessa funzionalità esiste in più negozi, registrare se i dati del modulo sottostante sono condivisi, duplicati o specifici del contesto.
Selezionare campioni rappresentativi per i test di migrazione
Scegliere record di origine che espongano la reale complessità del negozio. Registrare ID, contesto del negozio, lingua, URL, riferimenti alle combinazioni, gruppi di clienti, dipendenze dai moduli e il motivo per cui ogni campione è stato selezionato.
| Campione | Evidenza da preparare | Scopo della preparazione |
|---|---|---|
| Product semplice | Prezzo, imposta, stock, Category, produttore/fornitore, immagini, negozio e Order | Definisce la baseline di un Product ordinario. |
| Product con molte combinazioni | Attributi, combinazioni, riferimenti, stock, immagini, impatti su prezzo/peso e combinazione predefinita | Rappresenta la struttura delle varianti vendibili. |
| Product con caratteristiche/personalizzazioni | Caratteristiche, campi/file con valori inseriti dal Customer e righe Order corrispondenti | Separa i dati descrittivi dai valori inseriti dall’acquirente. |
| Caso multistore | Product, Category, Customer o prezzo con contesto tutti i negozi/gruppo/negozio | Rappresenta proprietà condivise e specifiche del negozio. |
| Caso gruppo di clienti | Customer, gruppi, prezzo specifico, accesso alle Categories e Order pertinente | Rappresenta il commercio segmentato. |
| Order complesso | Combinazione, personalizzazione, sconto, imposta, corriere, pagamento, fattura, reso e ID esterni | Rappresenta l’evidenza storica delle transazioni. |
| Record gestito da un modulo | Elemento core, tabelle/campi del modulo, hook e chiave esterna | Espone l’ambito non core prima dell’esecuzione. |
Il pacchetto di campioni PrestaShop è pronto quando ogni record selezionato dispone di una scheda con il risultato atteso dalla sorgente, l’ambito di negozio e lingua, i file correlati e un revisore nominato.
Completare il controllo finale di preparazione per PrestaShop
| Area di preparazione | Condizione di preparazione completata |
|---|---|
| Accesso e recupero | Back Office, hosting, database, file, immagini, download, credenziali, backup e responsabilità del ripristino sono confermati. |
| Multistore | Negozi, gruppi, domini, impostazioni dei dati condivisi, lingue, valute e valori specifici per negozio sono documentati. |
| Catalogo | Products, combinazioni, attributi, caratteristiche, personalizzazioni, Categories, fornitori, produttori, stock, prezzi e identificativi sono tracciabili. |
| Customers e Orders | Account, gruppi, indirizzi, carrelli, Orders, righe, totali, stati, documenti, messaggi, resi e ID esterni dispongono di evidenza. |
| Contenuti e URL | Contenuto CMS, navigazione, URL descrittivi, metadati, collegamenti interni e decisioni sui redirect sono documentati. |
| Dipendenze | Moduli, override, temi, tabelle personalizzate, integrazioni Webservice e sistemi esterni hanno responsabili nominati. |
| Campioni | I record rappresentativi coprono ogni schema materiale relativo a Product, negozio, Customer, Order, contenuto e modulo. |
L’ambito PrestaShop è pronto quando ogni record rilevante può essere ricondotto al proprio contesto di negozio, al proprietario sulla sorgente, ai record correlati, all’evidenza disponibile e alla destinazione prevista o al sistema che continuerà a possederlo.
Conclusione
Preparare PrestaShop richiede evidenze coordinate su Products, combinazioni, attributi, caratteristiche, personalizzazioni, ambito multistore, gruppi di clienti, Customers, Orders, contenuti CMS, URL descrittivi, moduli, override e sistemi esterni. La checklist dovrebbe rendere esplicite queste relazioni prima dell’esecuzione, invece di fare affidamento sulle esportazioni del solo negozio predefinito.
Un pacchetto di preparazione completo conserva evidenze di origine recuperabili, risolve la distinzione tra record condivisi e specifici del negozio, separa il commercio storico dalla configurazione attiva e assegna un responsabile a ogni dipendenza di modulo o personalizzazione.
Domande frequenti
Cosa bisogna preparare per prima cosa prima di una migrazione verso PrestaShop?
Verificare l’accesso a Back Office, hosting, database, filesystem, immagini e moduli; creare backup ripristinabili; quindi documentare la versione di PrestaShop e la struttura multistore. La preparazione del catalogo non dovrebbe iniziare finché la sorgente non può essere ispezionata e ripristinata in modo affidabile.
Perché Products e combinazioni devono essere preparati separatamente?
Un Product contiene le informazioni condivise del catalogo, mentre le combinazioni possono possedere riferimenti, codici a barre, impatti su prezzo e peso, stock, immagini, quantità minime e valori delle opzioni. Ogni combinazione effettivamente vendibile deve poter essere tracciata in modo indipendente.
In cosa differiscono le caratteristiche di PrestaShop dagli attributi?
Gli attributi creano combinazioni di Product che i clienti possono selezionare. Le caratteristiche descrivono proprietà che rimangono stabili tra le combinazioni. Confondere i due concetti può creare false varianti o rimuovere informazioni necessarie per filtri e confronti.
Perché il contesto multistore è essenziale?
Products, Categories, Customers, prezzi, lingue, moduli e URL possono essere condivisi o personalizzati per tutti i negozi, per un gruppo di negozi o per un singolo negozio. Lo stesso ID di origine può quindi avere un significato commerciale diverso a seconda del contesto.
Quali Orders di PrestaShop dovrebbero essere scelti come campioni rappresentativi?
Includere Customers ospiti e registrati, combinazioni, testo o file di personalizzazione, prezzi per gruppi di clienti, sconti, più imposte, fatture, resi, note di credito, riferimenti di pagamento e corriere e ID di sistemi esterni.
Cosa deve contenere il registro di moduli e override di PrestaShop?
Registrare ogni modulo, override, tabella personalizzata, dipendenza del tema, integrazione Webservice e connettore esterno che crea o utilizza dati di business. Ogni elemento necessita di un responsabile, dei record interessati, delle evidenze e di una decisione sulla destinazione o sul sistema che continuerà a gestirlo.