La preparazione dei dati storici degli ordini è un passaggio decisivo nella migrazione a Shopware. Questa guida spiega come valutare quali ordini passati importare e illustra le buone pratiche, come includere i dati degli ultimi due o tre anni per garantire la continuità dei rapporti con i clienti attivi e il valore analitico. solution25 mostra come una selezione e una preparazione accurate dei dati sostengano la coerenza operativa e la business intelligence dopo la migrazione, anche per i merchant in Italia.
Kostenlose 15-minütige Erstberatung direkt mit unseren Experten.
Nell’e-commerce di oggi, veloce e competitivo, i dati sono molto più di semplici informazioni: sono la base per business intelligence, esperienze utente personalizzate, assistenza clienti, conformità fiscale e continuità operativa. Quando un’azienda passa da una piattaforma e-commerce a un’altra, che sia da Shopware 5 a Shopware 6, da Magento a Shopware, da WooCommerce a una soluzione personalizzata o da un vecchio sistema ERP, la preparazione dei dati storici degli ordini diventa un passaggio decisivo.
Gli ordini storici contengono una grande quantità di informazioni transazionali: chi ha acquistato cosa e quando, a quale prezzo, da quale regione, con quale categoria fiscale e con quali sconti o promozioni. Questi dati sono strettamente collegati all’anagrafica clienti, alla gestione del magazzino, alle dichiarazioni fiscali, ai rimborsi, alla documentazione di spedizione e alle analisi delle prestazioni. Perdere o rappresentare in modo errato queste informazioni durante la migrazione può causare problemi legali, clienti insoddisfatti, report errati o persino errori contabili.
In parole semplici: lo storico degli ordini non è solo “dati vecchi”, è una parte essenziale del DNA della Sua azienda.
Purtroppo i dati storici sono spesso disordinati, incoerenti e distribuiti su fonti diverse, come vecchi database, esportazioni CSV o interfacce ERP. Preparare questi dati per la migrazione richiede una pianificazione accurata, una pulizia strutturata, la mappatura sullo schema della nuova piattaforma e la validazione, senza dimenticare la conformità alla protezione dei dati e un’eventuale ristrutturazione per rappresentare il modello d’ordine multi-entità di Shopware 6.
Questa guida La accompagna nel processo in modo strutturato e pratico. Che esegua la migrazione internamente o con un’agenzia esterna, questi passaggi Le assicurano di non spostare semplicemente dati, ma di migrare record utilizzabili, affidabili e conformi alle norme.
Al termine di questa guida saprà:
Tratteremo inoltre gli errori più comuni, i consigli per gestire relazioni con i clienti, rimborsi e ordini ospite, e gli strumenti e gli script che possono automatizzare parti del flusso di lavoro.
Questa documentazione presuppone la disponibilità di risorse tecniche (sviluppatori, amministratori di database o partner di migrazione), ma contiene anche indicazioni di contesto per project manager, responsabili e-commerce e ruoli di data governance, così che possano seguire il processo.
Iniziamo capendo perché gli ordini storici sono importanti sia a livello operativo sia strategico.
Prima consulenza gratuita di 15 minuti direttamente con i nostri esperti.
Quando pianificano una migrazione o un cambio di piattaforma, molte aziende valutano di non trasferire i vecchi ordini per risparmiare tempo o semplificare. Questo però può creare lacune significative nell’operatività, nell’assistenza clienti e nella continuità aziendale a lungo termine. Gli ordini storici non sono solo un registro delle attività passate: sono la base di processi finanziari, legali, analitici e orientati al cliente.
Ecco i motivi principali per cui gli ordini storici devono essere conservati e importati correttamente:
Nella maggior parte dei paesi, governi e autorità fiscali richiedono di conservare i dati delle transazioni per diversi anni (in genere da 5 a 10 anni, a seconda della giurisdizione; in Italia le scritture contabili vanno conservate di norma per 10 anni). Questi dati possono essere controllati in caso di:
La mancanza di registrazioni corrette e tempestive può comportare sanzioni o problemi legali. I soli PDF o le esportazioni in fogli di calcolo spesso non bastano: per le verifiche automatizzate servono dati integrati e interrogabili.
I team di supporto e vendita hanno bisogno di accedere rapidamente allo storico dei clienti in caso di:
Senza gli ordini storici nel nuovo sistema, i collaboratori devono passare da un sistema all’altro o chiedere all’IT l’accesso ai dati legacy: il servizio diventa più difficile per collaboratori e clienti.
Immagini di dover dire a un cliente fedele: “Purtroppo non abbiamo più accesso ai Suoi ordini precedenti.” Un danno evitabile alla fiducia nel brand.
Gli ordini storici sono la base delle analisi moderne, in particolare per capire:
Se mancano gli ordini storici, si creano lacune nella segmentazione e nella personalizzazione in strumenti come Google Analytics, Metabase o dashboard BI. Ne risentono i programmi di fidelizzazione, le raccomandazioni intelligenti e la marketing automation.
Se offre punti fedeltà, sconti o livelli esclusivi basati sugli ordini precedenti, il trasferimento degli acquisti storici è indispensabile. Dovrà:
Dati mancanti possono irritare i clienti abituali e ridurre il valore del Suo programma.
Per capire quali prodotti vendono bene nel tempo servono i dati storici di vendita. Questi supportano:
Inoltre i dati di vendita sono spesso legati a valutazioni delle performance degli SKU o a contratti con i fornitori: perdere questo storico può rendere più difficili trattative e riordini futuri.
I dati storici degli ordini confluiscono spesso nei seguenti sistemi:
Senza il trasferimento dello storico, questi sistemi possono smettere di funzionare, diventare incoerenti o mostrare dati incompleti, con correzioni lunghe o sincronizzazioni parziali come conseguenza.
Prima di iniziare il lavoro tecnico, come esportazione dei dati, scrittura di script o formattazione dei file, deve definire con chiarezza il perimetro degli ordini storici da migrare. Questa fase è decisiva per preservare la qualità dei dati, ridurre gli errori ed evitare lavoro inutile dovuto all’importazione di record irrilevanti o incoerenti.
Non tutti i dati storici hanno lo stesso valore. Migrare ogni singola transazione degli ultimi 10 anni sembra scrupoloso, ma spesso porta a database gonfiati, tempi di importazione più lunghi e processi successivi più complessi. D’altra parte, una migrazione troppo ridotta può causare la perdita del contesto di business, analisi difettose o lacune di conformità.
Nel preparare il dataset tenga conto dei seguenti filtri:
Quanto indietro deve arrivare lo storico?
Best practice: importare almeno gli ultimi 2-3 anni per coprire i rapporti attivi con i clienti e le analisi di base. I dati più vecchi possono essere archiviati o mantenuti in sola lettura.
Da considerare:
Quali ordini includere?
Suggerimento: si concentri sugli ordini con dati di pagamento e consegna validi. Gli ordini annullati o non riusciti andrebbero archiviati, a meno che non siano rilevanti per analisi o rilevamento frodi.
Shopware 6 richiede per ogni ordine una voce order_customer valida. Se il Suo vecchio sistema mescola clienti ospiti e registrati, deve uniformare questa struttura dati prima dell’importazione.
Raccomandazione: migrare entrambi i tipi, ma distinguerli tramite gruppi di clienti o metadati.
Le differenze regionali in materia di imposte, spedizione e metodi di pagamento richiedono spesso una segmentazione per semplificare gli script di trasformazione.
Esempio: se avvia il Suo shop Shopware 6 inizialmente solo in Italia, può escludere gli ordini più vecchi provenienti da Stati Uniti o Regno Unito.
source_system, imported_at o import_batch_id per la tracciabilità successiva.Questo approccio strutturato facilita rollback, ricerca degli errori e isolamento dei record problematici durante i test.
Prima di iniziare il lavoro tecnico, come esportazione dei dati, scrittura di script o formattazione dei file, deve definire con chiarezza il perimetro degli ordini storici da migrare. Questa fase è decisiva per preservare la qualità dei dati, ridurre gli errori ed evitare lavoro inutile dovuto all’importazione di record irrilevanti o incoerenti.
Non tutti i dati storici hanno lo stesso valore. Migrare ogni singola transazione degli ultimi 10 anni sembra scrupoloso, ma spesso porta a database gonfiati, tempi di importazione più lunghi e processi successivi più complessi. D’altra parte, una migrazione troppo ridotta può causare la perdita del contesto di business, analisi difettose o lacune di conformità.
Nel preparare il dataset tenga conto dei seguenti filtri:
| Dimensione | Domande / opzioni | Note / suggerimenti |
|---|---|---|
| Periodo |
Ultimi 6 mesi 1 anno 3 anni Tutti i dati disponibili |
Consigliati almeno 2-3 anni. Archiviare i dati più vecchi o mantenerli in sola lettura. Rispettare gli obblighi di conservazione previsti dalla legge. Bilanciare volume dei dati e prestazioni del sistema. |
| Tipi di ordine |
Ordini completati Transazioni annullate o non riuscite Ordini rimborsati Carrelli abbandonati o preordini |
Concentrarsi su dati di pagamento e consegna validi. Archiviare gli ordini annullati, salvo se rilevanti per l’analisi. |
| Tipi di cliente |
Ordini ospite Clienti registrati Possibile distorsione dovuta a ordini anonimi |
Shopware 6 richiede una voce order_customer valida.Serve una struttura dati uniforme prima dell’importazione. Raccomandazione: migrare entrambi i tipi, ma distinguerli. |
| Filtri geografici |
Ordini nazionali Ordini internazionali B2B o B2C Ordini multilingua / multivaluta |
Considerare le differenze di imposte, spedizione e pagamento. La segmentazione semplifica gli script. Esempio: all’inizio focus sull’Italia. |
source_system, imported_at o import_batch_id per la tracciabilità successiva.Questo approccio strutturato facilita rollback, ricerca degli errori e isolamento dei record problematici durante i test.
s_order, s_order_details, s_user e s_order_documents.SELECT o.id, o.ordernumber, o.invoice_amount, u.email, d.articleID, d.quantity
FROM s_order o
JOIN s_order_details d ON o.id = d.orderID
JOIN s_user u ON o.userID = u.id;
sales_order, sales_order_item, customer_entity e altre.wp_posts, wp_postmeta e wp_woocommerce_order_items.| Tipo | Descrizione |
|---|---|
| Testate degli ordini | ID ordine, stato, totali, valuta, data, canale di vendita |
| Righe | ID prodotto/SKU, quantità, prezzo unitario, aliquota IVA, sconto |
| Clienti | Nome, e-mail, gruppo clienti, indirizzo di fatturazione/consegna |
| Spedizione | Metodo, numero di tracking, corriere, data di consegna |
| Transazioni | Metodo di pagamento, ID transazione, stato, importo rimborsato |
| Fatture | Numero fattura, data fattura, riferimento PDF (se presente) |
Facoltativi, ma utili:
Dopo l’esportazione dei dati grezzi, il passo successivo è la pulizia e la validazione, prima di mappare i dati sullo schema di Shopware 6. Ne parliamo nella prossima sezione.
L’esportazione dei dati storici degli ordini è solo l’inizio: ciò che ha ora tra le mani è spesso disordinato, incompleto o strutturato in modo incoerente. Pulire e validare questi dati è decisivo per evitare errori di importazione, prevenire perdite di dati e garantire nel tempo l’accuratezza dei report nel nuovo sistema Shopware 6.
Se i dati non sono puliti correttamente, rischia:
La maggior parte delle esportazioni, soprattutto da sistemi datati o personalizzati, contiene problemi come:
order_id + datum + email.order_items e orders. Tutti gli ordini “orfani” devono essere contrassegnati.anonymous@example.com per gli ospiti).| Strumento | Caso d’uso |
|---|---|
| Excel / LibreOffice | Individuazione visiva di duplicati, valori null, formattazione |
| Python (Pandas) | Automazione di trasformazioni e validazioni |
| Script PHP o Node.js | Elaborazione di grandi dataset JSON/CSV |
| Strumenti di test per le API Shopware | Verifica dell’accettazione dell’importazione (Postman, cURL) |
| OpenRefine | Pulizia approfondita dei dati e clustering di testo |
Conservi sempre:
Questo garantisce tracciabilità, possibilità di rollback e risoluzione dei problemi se dopo il deployment emergono criticità.
Una volta puliti e validati, i dati storici degli ordini devono essere strutturati in modo da corrispondere allo schema della piattaforma di destinazione, in questo caso Shopware 6. A differenza dei sistemi legacy, che spesso si basano su tabelle monolitiche, Shopware 6 utilizza per gli ordini un’architettura modulare basata su entità. Questa modularità offre grande flessibilità e scalabilità, ma significa anche che i file di importazione devono rispettare regole relazionali rigorose e la separazione delle entità.
| Entità | Scopo |
|---|---|
| order | Ordine principale con totali, stato e metadati |
| order_line_item | Singoli prodotti o righe personalizzate |
| order_customer | Istantanea del cliente al momento dell’ordine |
| order_transaction | Informazioni di pagamento (metodo, stato, ID transazione) |
| order_delivery | Dettagli di spedizione, tracking e metodo di spedizione |
| order_address | Indirizzi di fatturazione e consegna dell’ordine |
order_id o order_number coerenti.order_line_item.csv potrebbe contenere:
| order_id | product_id | label | quantity | total_price |
|---|---|---|---|---|
| abc123 | prod567 | Blue T-Shirt | 2 | 39,98 |
order_customer.csv potrebbe contenere:
| order_id | first_name | last_name | customer_number | |
|---|---|---|---|---|
| abc123 | john@example.com | John | Doe | CUST-001 |
Se usa la Sync API o la Admin API, il payload di ogni ordine dovrebbe essere strutturato all’incirca così (semplificato):
{
"order": {
"orderNumber": "10001",
"salesChannelId": "...",
"currencyId": "...",
"orderCustomer": { ... },
"transactions": [ ... ],
"deliveries": [ ... ],
"lineItems": [ ... ],
"addresses": [ ... ]
}
}
Strutturando correttamente i dati in entità singole e relazionali, crea la base per un’importazione senza intoppi in Shopware 6. Tutte le relazioni restano intatte e reporting e processi di assistenza clienti funzionano come previsto.
Nomi dei campi e tipi di dati possono variare da un sistema all’altro. Crei una tabella di mappatura come questa:
| Campo precedente (Magento) | Nuovo campo (Shopware) | Note di trasformazione |
|---|---|---|
| customer_email | order_customer.email | Convertire in minuscolo |
| status | order.state_id | Usare gli UUID di stato di Shopware |
| shipping_address | order_address | Appiattire la struttura se annidata |
La semplice migrazione dei dati grezzi degli ordini spesso non basta a preservare interamente il valore operativo che la Sua azienda ha costruito nel tempo. Gli ordini non esistono isolati: sono inseriti in processi aziendali più ampi, strategie di marketing e customer journey. Per massimizzare l’utilità dei dati storici degli ordini, conviene arricchirli con informazioni di contesto che supportino decisioni più intelligenti e una continuità operativa senza intoppi dopo la migrazione.
utm_source, utm_medium, utm_campaign). Potrà così analizzare l’efficacia storica del marketing anche dopo la migrazione.Integrando questi livelli di contesto nella migrazione dei dati storici degli ordini, si assicura che Shopware 6 non si limiti a memorizzare i Suoi dati, ma fornisca anche la business intelligence e gli insight operativi necessari per un successo duraturo dopo la migrazione.
La migrazione dei dati storici degli ordini non riguarda solo gli ordini: è altrettanto importante gestire correttamente i dati dei clienti. Shopware 6 impone una relazione rigorosa tra ordini e clienti: ogni ordine deve essere collegato a un’entità order_customer valida. Questo pone sfide particolari quando bisogna considerare sia account cliente registrati sia ordini ospite.
Decida se:
Questo può richiedere endpoint API o livelli di dati separati. Alcuni shop importano gli ordini senza questi dati per semplicità; altri li considerano critici.
order_customer, anche negli ordini ospite.Questi clienti servono solo come riferimento per l’ordine.
order_customer validi. Collegamenti ai clienti mancanti o errati causano errori di importazione.Una gestione accurata di account cliente e ordini ospite garantisce che i Suoi ordini storici in Shopware 6 restino ricercabili, collegati e utilizzabili, sia nel backend sia nello storefront. Così si preservano sia i processi operativi sia l’esperienza dei clienti.
L’importazione dei dati storici degli ordini è un’operazione complessa con molte dipendenze e relazioni. Importare l’intero dataset in un colpo solo è rischioso e può causare errori difficili da diagnosticare, corruzione dei dati o instabilità del sistema.
Per ridurre questi rischi è indispensabile una fase rigorosa di test e validazione. Questa sezione La guida tra le buone pratiche per test incrementali e la verifica dei dati d’ordine importati in Shopware 6.
Gestisca gli errori uno per uno e corregga i dati o la logica di importazione.
Avvii l’importazione completa solo quando le importazioni di prova sono prive di errori e la qualità dei dati è confermata. Così garantisce un’importazione finale senza intoppi e con disagi minimi.
I dati storici degli ordini contengono informazioni sensibili come:
Si assicuri di garantire:
Strumenti consigliati:
Esempio: uno script Python per convertire gli ordini WooCommerce nel formato Shopware.
Domanda: Cosa succede se non importo gli ordini?
Risposta: Perde lo storico dei clienti, la profondità dei report e rischia problemi legali con la documentazione fiscale.
Domanda: Posso importare ordini senza prodotti?
Risposta: No. Shopware richiede riferimenti di prodotto validi (SKU, ID o UUID).
Domanda: E se alcuni campi mancano o sono sconosciuti?
Risposta: Usi valori segnaposto o dati predefiniti, ma senza compromettere l’integrità referenziale.
Preparare i dati storici degli ordini non è un semplice copia-incolla. Richiede:
Ma ne vale la pena: lo storico degli ordini è un asset prezioso per business intelligence, assistenza clienti e conformità legale.
Si prenda il tempo per una preparazione accurata, così da avviare la migrazione alla nuova piattaforma con fiducia e chiarezza. Se gestisce un e-commerce in Italia e pianifica il passaggio a Shopware 6, solution25 La supporta volentieri in ogni fase.