La migrazione dei dati verso PrestaShop consiste nel tradurre il significato della sorgente in un modello di catalogo che distingue variazioni acquistabili, caratteristiche descrittive, personalizzazioni inserite dal Customer, ambito dei singoli negozi e funzionamento gestito dai moduli. Record familiari come Products, Categories, Customers, Orders, Coupons, CMS Pages, immagini e URL assumono un significato diverso quando entrano nelle relazioni PrestaShop tra combinazioni, caratteristiche, Customer Group, multistore, lingue e moduli.
La distinzione centrale è che una piattaforma di origine può usare un unico livello generico di “opzioni” o campi personalizzati per svolgere funzioni differenti. In PrestaShop, un valore potrebbe dover diventare un attributo usato da una combinazione, una caratteristica condivisa dall’intero Product, un campo di personalizzazione compilato dal Customer, un’associazione Product, un’assegnazione Category, una relazione con un Customer Group, un valore specifico per un negozio oppure un record gestito da un modulo. Eseguire la mappatura soltanto in base al nome del campo, invece che al significato operativo, può produrre un catalogo tecnicamente popolato ma incoerente dal punto di vista commerciale.
Il significato del catalogo PrestaShop parte dalla struttura dei Products
I Products PrestaShop possono essere Products standard, Products con combinazioni, pack oppure Products virtuali. Il record Product contiene inoltre associazioni con Categories, contesto di brand e fornitori, immagini, allegati, Products correlati, caratteristiche, campi di personalizzazione, prezzi, stock, lingue e ambito del negozio. Queste relazioni determinano come il Product viene selezionato, visualizzato, governato e venduto.
| Significato nella sorgente | Domanda per la destinazione PrestaShop | Conseguenza sulla relazione |
|---|---|---|
| Un singolo articolo vendibile senza versioni selezionabili | Resta un Product standard? | Identità Product, riferimento, prezzo, stock, immagine, tasse, Category e URL restano a livello Product. |
| Taglia, colore, capacità, finitura o altra versione acquistabile | Gli attributi devono creare combinazioni? | L’identità della combinazione può gestire riferimento, impatto sul prezzo, quantità, immagine e valori selezionati. |
| Specifica stabile come materiale o paese di origine | Deve diventare una caratteristica? | Il valore descrive il Product nel suo complesso invece di creare una versione acquistabile diversa. |
| Testo inserito dal Customer o file caricato per una personalizzazione | Deve diventare un campo di personalizzazione o un’altra struttura nella destinazione? | Il valore inserito dal Customer resta distinto dagli attributi e dalle caratteristiche descrittive. |
| Gruppo di Products esistenti venduti insieme | È un pack, un’associazione, una Category o un’altra relazione commerciale? | La destinazione deve preservare l’identità dei Products e l’intento del raggruppamento senza duplicazioni. |
| Scelta o record generato da un modulo | Quale modulo o processo di destinazione ne è responsabile? | I campi core del Product non devono assorbire accidentalmente il funzionamento attivo di un’estensione. |
La rappresentazione corretta nella destinazione dipende da ciò che il valore fa. Un valore “Colore” può creare una combinazione, descrivere una caratteristica del Product, supportare una Category o un’esperienza di filtro oppure esistere soltanto come risultato di un modulo. L’etichetta, da sola, non è sufficiente.
Combinazioni, attributi, caratteristiche e personalizzazioni non sono intercambiabili
Le combinazioni PrestaShop rappresentano versioni acquistabili di un Product. Sono create a partire dai valori degli attributi e possono avere un proprio riferimento, impatto sul prezzo, quantità, associazione con immagini, impatto sul peso, disponibilità e altri dati specifici della variazione. Le caratteristiche descrivono proprietà condivise dal Product e non modificano la versione acquistata dal Customer. I campi di personalizzazione raccolgono testo o file forniti dal Customer.
Questa separazione deve restare visibile nel modello migrato:
| Struttura PrestaShop | Significato commerciale | Errore comune tra sorgente e destinazione |
|---|---|---|
| Gruppo di attributi e valore | Dimensione selezionabile come taglia o colore | Trasformare specifiche descrittive in scelte che il Customer deve selezionare. |
| Combinazione | Combinazione valida e acquistabile di attributi | Appiattire vere varianti in un solo Product e perdere SKU, prezzo, immagine o stock del record figlio. |
| Caratteristica e valore della caratteristica | Proprietà stabile del Product | Trasformare specifiche utili a filtro o confronto in testo libero. |
| Campo di personalizzazione | Testo o file inserito dal Customer | Trattare la personalizzazione come valore fisso di un attributo o come nota dell’Order. |
| Pack | Relazione Product che raggruppa Products esistenti | Duplicare i dati dei componenti o confondere un bundle con una variazione. |
| Product virtuale | Product non fisico con un significato specifico per la consegna | Preservare un riferimento a un file senza le relazioni con Product e accesso. |
Una piattaforma di origine può memorizzare le varianti figlie come Products separati. PrestaShop può rappresentarle come combinazioni sotto un unico Product principale quando sono effettivamente versioni dello stesso articolo. Al contrario, Products indipendenti non devono essere compressi in combinazioni se hanno identità distinte per merchandising, contenuto, ciclo di vita o reportistica.
Anche la generazione delle combinazioni dipende dal vocabolario degli attributi. Valori incoerenti nella sorgente come “Large”, “L” e “large” devono essere esaminati prima di diventare valori di attributo separati nella destinazione. La normalizzazione, tuttavia, non deve unire valori che hanno SKU, prezzi, stock o significato per il Customer differenti.
Categories, brand, fornitori e associazioni determinano la scoperta dei Products
Le Categories PrestaShop formano percorsi gerarchici del catalogo e possono includere descrizioni, immagini, metadati, URL semplificati, associazioni Product e contesto del negozio. Un Product può essere associato a più Categories, mentre una Category può essere definita come Category principale. Brand, fornitori, Products correlati, accessori e pack creano ulteriori relazioni per scoperta o gestione operativa.
Le piattaforme di origine spesso mescolano questi ruoli. Una raccolta può essere una vera famiglia Product, una campagna stagionale, un archivio del brand, il risultato di un filtro, una scorciatoia di navigazione oppure una pagina di destinazione SEO. Riprodurre ogni raggruppamento della sorgente come Category PrestaShop può preservare disordine e duplicare lo stesso intento.
| Struttura nella sorgente | Possibile significato in PrestaShop | Segnale decisionale |
|---|---|---|
| Famiglia gerarchica permanente | Albero delle Categories | Customers e personale usano la gerarchia come percorso stabile del catalogo. |
| Raggruppamento per brand o produttore | Relazione con il brand, Category, caratteristica o pagina di contenuto | La destinazione segue le esigenze di navigazione, fiducia, reportistica e governance dei Products. |
| Riferimento al fornitore | Relazione con il fornitore o chiave esterna per l’approvvigionamento | Il valore supporta sourcing o amministrazione più che il branding del sito pubblico. |
| Raccolta stagionale o di campagna | Category temporanea, regola di merchandising o pagina di destinazione di contenuto | La struttura può non meritare un posto permanente nella gerarchia del catalogo. |
| Products correlati o accessori | Associazione Product | La relazione supporta il cross-selling senza modificare l’identità Product. |
| Bundle di Products esistenti | Pack o altra struttura bundle definita | I componenti restano identificabili e il bundle non diventa una falsa variazione. |
La relazione tra Category principale e URL semplificato merita particolare attenzione perché il contesto Category può influenzare il modo in cui i percorsi Product vengono generati e interpretati. Un Product può essere assegnato alle Categories corrette ma ricevere comunque un percorso principale non previsto se la relazione principale non è definita.
Identità del Customer e trattamento tramite Customer Group devono restare distinti
Un record Customer in PrestaShop contiene identità, informazioni di contatto, indirizzi, stato dell’account, contesto linguistico e relazioni con gli Orders. I Customer Group possono influenzare il modo in cui il negozio tratta l’acquirente tramite sconti, visualizzazione dei prezzi, visibilità o altri comportamenti configurati. Il gruppo, quindi, non è una semplice etichetta.
| Modello Customer nella sorgente | Domanda sul modello di destinazione | Risultato della relazione |
|---|---|---|
| Account retail ordinario | Quali identità, indirizzi, lingua e collegamenti agli Orders restano autorevoli? | Lo storico del Customer rimane collegato all’account corretto. |
| Acquirente wholesale o professionale | Quale gruppo, prezzo, trattamento fiscale, visibilità o relazione con un account esterno ne definisce il trattamento? | L’identità dell’acquirente resta distinta dalle regole commerciali. |
| Segmento fidelizzazione o membership | Il valore è un gruppo core, un record di modulo, un segmento CRM o un’etichetta storica? | La destinazione conserva soltanto la relazione che continuerà a essere utilizzata. |
| Acquirente guest | L’Order deve conservare l’identità senza creare un account ordinario? | Lo storico dell’Order resta interpretabile senza una falsa continuità dell’account. |
| Customers duplicati | Quale record possiede email, indirizzi, Orders e identificativi esterni? | Le decisioni di consolidamento non interrompono le relazioni con gli Orders. |
Un Customer Group nella sorgente può aver influenzato prezzi, trattamento fiscale, accesso al catalogo, approvazione o comunicazioni al di fuori del core del negozio. Migrare soltanto il nome del gruppo non preserva questi risultati. Il modello di destinazione deve indicare quali funzioni appartengono alla configurazione PrestaShop, quali a un modulo e quali restano di competenza di un CRM o ERP esterno.
Il multistore aggiunge responsabilità specifiche per negozio ai record condivisi
Il multistore PrestaShop consente a un unico back office di gestire più negozi o gruppi di negozi. Per la migrazione, ciò significa che Products, Categories, Customers, contenuti, lingue, valute, URL e funzionamento dei moduli possono essere condivisi, ereditati oppure specifici per negozio. Il semplice conteggio dei record non dimostra che questa responsabilità sia stata preservata.
| Area multistore | Decisione di responsabilità |
|---|---|
| Products e combinazioni | Quali negozi ricevono Product, variazione, visibilità, prezzo e contesto della quantità? |
| Categories | Quale albero radice e quale associazione al negozio governano il posizionamento nella navigazione? |
| Customers e gruppi | Quali identità e trattamenti commerciali sono condivisi e quali specifici per negozio? |
| Lingue e campi localizzati | Quali nomi, descrizioni, slug e metadati tradotti appartengono a ciascuna lingua e negozio? |
| CMS Pages e contenuti | Quale sito pubblico, lingua, percorso di navigazione o dominio è responsabile del contenuto? |
| URL e domini | Quale negozio sostituisce ciascun percorso importante della sorgente? |
| Moduli | Quali record o impostazioni dei moduli si applicano globalmente, per gruppo di negozi o per singolo negozio? |
Appiattire le assegnazioni nel negozio predefinito può far sembrare completi i dati condivisi eliminando però confini tra brand, regioni, lingue o B2B/B2C. L’errore opposto, cioè duplicare ogni record condiviso per ciascun negozio, crea divergenze inutili e rende più difficile la futura governance del catalogo.
Gli Orders preservano le evidenze della transazione, non la configurazione futura del negozio
Gli Orders PrestaShop collegano Customers o identità guest a snapshot dei Products, combinazioni, quantità, prezzi, sconti, tasse, spedizione, etichette di pagamento, indirizzi, messaggi, cronologia degli stati e riferimenti dei moduli. Gli Orders storici devono restare comprensibili anche quando il flusso della sorgente non ha un equivalente esatto in PrestaShop.
| Relazione dell’Order | Significato nel record di destinazione |
|---|---|
| Riga Product e combinazione | Nome acquistato, riferimento, attributi selezionati, quantità e prezzo al momento della vendita. |
| Identità Customer o guest | Contesto dell’acquirente e relazione con i dati storici dell’account. |
| Indirizzi | Snapshot di fatturazione e consegna utilizzati per la transazione. |
| Sconti e voucher | Effetto storico sull’Order, non ricreazione automatica delle future regole promozionali. |
| Etichette di pagamento e corriere | Evidenza della transazione originale, non prova che i moduli corrispondenti siano attivi nella destinazione. |
| Stato e messaggi | Flusso storico e contesto di assistenza che possono richiedere una mappatura semantica. |
| Riferimento di modulo o sistema esterno | Chiave tra sistemi o contesto gestito da un’estensione con uno scopo definito nella destinazione. |
Un modulo di pagamento, un corriere, una regola fiscale, un modello email o una personalizzazione del checkout riguarda la configurazione attiva della destinazione. Le etichette storiche possono essere preservate senza fingere che il futuro flusso operativo sia già stato implementato. Questa separazione mantiene gli Orders utili per assistenza e finanza evitando di confondere lo storico delle transazioni con la configurazione operativa.
Moduli, override, temi e dati personalizzati richiedono una responsabilità esplicita
L’ecosistema di moduli e override di PrestaShop può estendere Products, combinazioni, Customers, Orders, checkout, promozioni, Reviews, fidelizzazione, flussi dati per marketplace, SEO, spedizione, pagamenti, strumenti di analisi e amministrazione. Un valore mostrato nel back office o nel sito pubblico può quindi provenire da una tabella core, da una tabella di un modulo, da un override, dalla logica del tema o da un sistema esterno.
| Tipo di dipendenza | Interpretazione nel modello dati |
|---|---|
| Entità gestita da un modulo | Identificare il Product, Customer, Order, elemento di contenuto o record esterno padre e il modulo di destinazione che continuerà a utilizzarla. |
| Campo personalizzato su un record core | Usare un campo nativo o un campo di estensione governato soltanto quando è noto il responsabile nella destinazione. |
| Override o codice personalizzato | Stabilire se modifica memorizzazione, calcolo, validazione o presentazione, invece di presumere che sia un dato trasferibile. |
| Campo del tema | Separare il contenuto durevole dal layout o markup specifico del tema della sorgente. |
| Identificativo esterno | Preservare chiavi ERP, CRM, PIM, contabilità, marketplace o evasione degli ordini in una relazione di integrazione governata. |
| Risultato memorizzato in cache o derivato | Ricrearlo dai dati autorevoli della destinazione invece di copiare residui tecnici obsoleti. |
I residui dei moduli non devono essere copiati soltanto perché esistono. Allo stesso tempo, un campo gestito da un modulo che controlla identità Product, diritti del Customer, interpretazione degli Orders o continuità delle integrazioni non può essere liquidato come metadato facoltativo. Il modello di destinazione deve identificare chi continuerà a utilizzare quel dato.
Contenuti, lingue e URL portano con sé il contesto del negozio
I campi di Products, Categories, CMS Pages e altri contenuti PrestaShop possono essere localizzati. Nomi, descrizioni, slug, metadati e didascalie delle immagini possono variare per lingua e negozio. Una piattaforma di origine può invece utilizzare negozi separati, record duplicati, plugin di traduzione o URL specifici per lingua.
Il modello di destinazione deve distinguere l’identità condivisa dall’espressione localizzata. Un solo Product può mantenere riferimento e struttura relazionale comuni mentre nome, descrizione, slug e metadati variano per lingua. Un record tradotto nella sorgente non deve diventare un Product duplicato a meno che non rappresenti davvero un articolo commerciale distinto.
Anche gli URL richiedono un proprietario dell’oggetto. Un percorso della sorgente può identificare un Product, una Category, una pagina del brand, una CMS Page, un percorso linguistico o il dominio di un negozio. Il percorso di destinazione deve risolvere verso l’oggetto PrestaShop e il contesto di negozio che sostituiscono quell’intento. Le sole stringhe degli URL semplificati, senza il record corretto e le relazioni con lingua e negozio, non sono sufficienti.
La responsabilità nella destinazione va definita prima della mappatura dei campi
Un modello di destinazione PrestaShop completo assegna ogni valore importante della sorgente a uno di questi risultati:
- un Product, una combinazione, un attributo, una caratteristica, una personalizzazione, una Category, un Customer, un Order, un contenuto o una relazione con il negozio nativi;
- un modulo governato o un campo personalizzato con un responsabile che continuerà a utilizzarlo nella destinazione;
- una relazione con un sistema esterno il cui identificativo stabile deve restare tracciabile;
- una configurazione o presentazione della destinazione da ricostruire invece che migrare come dati;
- residui legacy da archiviare o escludere.
| Area decisionale | Domanda chiave sulla responsabilità |
|---|---|
| Variazione Product | Quale Product e quale combinazione di attributi gestiscono SKU, prezzo, quantità, immagine e identità acquistabile? |
| Informazioni Product | Quali valori sono caratteristiche, descrizioni, allegati o contenuti localizzati invece che combinazioni? |
| Scoperta nel catalogo | Quali Categories, brand, fornitori, associazioni e URL preservano l’intento del Customer? |
| Trattamento del Customer | Quale gruppo o relazione esterna governa prezzo, visibilità, tasse o diritto di accesso? |
| Multistore | Quale negozio o gruppo di negozi è responsabile di ciascuna assegnazione e valore localizzato? |
| Dati di moduli o personalizzati | Quale modulo di destinazione, team o sistema esterno continuerà a utilizzare il record? |
Questa prospettiva sulla responsabilità impedisce a PrestaShop di diventare un contenitore di etichette copiate dalla sorgente. Il catalogo migrato può invece funzionare come un insieme coerente di relazioni tra Products, Customers, Orders, contenuti, negozi e moduli.
Conclusione
Le differenze del modello dati di PrestaShop si concentrano sulla separazione tra Products e combinazioni, attributi e caratteristiche, contenuto fisso e personalizzazione del Customer, identità Customer e trattamento tramite gruppi, record condivisi e responsabilità multistore, Orders storici e configurazione futura, record core ed estensioni gestite da moduli.
Una migrazione affidabile preserva queste distinzioni prima di mappare i campi. Il risultato non è semplicemente un database popolato, ma un catalogo e una struttura degli account nella destinazione in cui i record mantengono un significato commerciale chiaro tra negozi, lingue, moduli e sistemi connessi.
Domande frequenti
Perché le combinazioni PrestaShop sono diverse dalle normali opzioni Product?
Le combinazioni sono versioni acquistabili di un Product create a partire da valori di attributo. Possono gestire riferimento, impatto sul prezzo, quantità, immagine, peso e disponibilità a livello della variazione. Una caratteristica descrittiva o una personalizzazione inserita dal Customer ha invece un ruolo diverso.
Le caratteristiche PrestaShop sono uguali agli attributi?
No. Gli attributi creano dimensioni selezionabili per le combinazioni, mentre le caratteristiche descrivono proprietà stabili del Product. Confonderli può trasformare specifiche in scelte non necessarie oppure appiattire vere variazioni in testo descrittivo.
Come vanno interpretate le varianti della sorgente memorizzate come Products separati?
Occorre stabilire se sono davvero versioni di un solo Product oppure articoli commerciali indipendenti. Identità condivisa, contenuto comune, differenze selezionabili, proprietà dello SKU, stock, prezzi e ciclo di vita aiutano a determinare se le combinazioni sono appropriate.
Perché i Customer Group richiedono più di una semplice mappatura delle etichette?
Un Customer Group può essere collegato a sconti, visualizzazione dei prezzi, visibilità, trattamento fiscale o funzionamento dei moduli. La relazione tra Customer e gruppo va preservata insieme a una definizione chiara del trattamento commerciale che continuerà nella destinazione.
In che modo il multistore cambia la mappatura dei dati?
Il multistore aggiunge responsabilità di negozio e gruppo di negozi a Products, Categories, Customers, contenuti, lingue, URL e moduli. I record condivisi devono restare condivisi quando appropriato, mentre le assegnazioni specifiche per negozio non devono essere appiattite nel negozio predefinito.
Come devono essere gestiti i dati appartenenti ai moduli?
Ogni record del modulo va ricondotto all’oggetto padre, al suo significato operativo e al soggetto che continuerà a utilizzarlo nella destinazione. Occorre preservare entità durevoli e chiavi di integrazione, ricostruire il funzionamento attivo nell’ambiente di destinazione ed escludere residui in cache, derivati o obsoleti che non hanno più uno scopo.