Se Shopware viene scelto come piattaforma di destinazione, la preparazione deve definire come i record della piattaforma sorgente si collegano a canali di vendita, Products e varianti, proprietà, campi personalizzati, Customers, Orders, Shopping Experiences, regole, media, URL, estensioni e sistemi esterni. Un’esportazione completa non è sufficiente quando lo stesso Product può comparire in più canali di vendita, le varianti possono ereditare o sovrascrivere valori del Product padre, le proprietà possono servire sia al filtraggio sia alla generazione delle varianti e il funzionamento commerciale dipende da regole assegnate.
Ogni attività di preparazione dovrebbe avere un responsabile, un’evidenza e una condizione di prontezza. Il pacchetto di preparazione deve inoltre distinguere le evidenze della piattaforma sorgente dall’implementazione sulla piattaforma di destinazione. Relazioni Product, contesto storico degli Orders, URL esistenti, identificatori esterni e record posseduti da estensioni appartengono alla preparazione della migrazione; comportamento attivo di pagamenti, spedizione, imposte, processi, tema e canali di vendita restano decisioni di implementazione sulla piattaforma di destinazione.
Mettere in sicurezza accessi Shopware, hosting, database e file
Confermare l’accesso a Shopware Administration, gestione hosting o cloud, database dove disponibile, file applicativi, archiviazione media, attività pianificate, credenziali delle integrazioni e gestione delle estensioni. Registrare versione Shopware, modello di distribuzione, ambiente PHP e database per installazioni self-hosted, canali di vendita attivi, lingue, valute, estensioni, codice personalizzato e sistemi collegati.
| Attività di preparazione | Responsabile | Evidenza | Condizione di prontezza |
|---|---|---|---|
| Confermare l’accesso amministrativo | Amministratore Shopware | Account funzionante e riepilogo dei ruoli | Products, Customers, Orders, regole, canali di vendita, estensioni e contenuti possono essere ispezionati. |
| Creare backup sorgente ripristinabili | Responsabile infrastruttura | Esportazione database, archivio file/media, archivio configurazione e responsabile del ripristino | Il negozio sorgente può essere recuperato indipendentemente dall’ambiente di produzione. |
| Registrare l’ambiente tecnico | Responsabile tecnico | Inventario di Shopware, PHP, database, hosting, deployment e versioni delle estensioni | Record e personalizzazioni dipendenti dalla versione sono documentati. |
| Acquisire codice personalizzato ed estensioni | Responsabile sviluppo | Elenco estensioni, plugin/app personalizzati, file modificati, entità personalizzate e note di distribuzione | Ogni record o comportamento non-core ha un responsabile. |
| Mappare i sistemi esterni | Responsabili integrazioni | Identificatori ERP, PIM, WMS, CRM, marketplace, ricerca, pagamento ed evasione degli ordini | Sistemi autorevoli e chiavi di sincronizzazione continuative sono noti. |
Preservare gli identificatori interni per Products, varianti, Categories, proprietà, canali di vendita, Customers, Orders, media, campi personalizzati e sistemi esterni. Queste chiavi sono necessarie quando i record devono essere riconciliati tra entità Shopware o ricollegati alle integrazioni.
Preparare canali di vendita, domini, lingue e ambito Customer
I canali di vendita Shopware possono rappresentare siti, contesti headless, feed di confronto Product, canali social o altri endpoint rivolti ai Customers. Products, Categories, domini, lingue, valute, metodi di pagamento, metodi di spedizione, temi e relazioni Customer possono dipendere dal canale di vendita scelto.
| Area del canale di vendita | Evidenza da preparare | Condizione di prontezza |
|---|---|---|
| Inventario dei canali | ID canale, tipo, stato, dominio, lingua, valuta, ambito Customer e responsabile | Ogni contesto attivo rivolto ai Customers è elencato una sola volta. |
| Disponibilità Product | ID Product/variante, livello di visibilità, canali assegnati e canali esclusi | L’ambito Product non viene dedotto dalla semplice presenza nel catalogo globale. |
| Contesto dominio e lingua | Dominio, percorso, locale, valuta, intento hreflang e comportamento di fallback | I record localizzati sono collegati al corretto contesto pubblico. |
| Collegamento Customer | Comportamento di registrazione, relazione Customer-canale, casi di email duplicate e policy account | Le identità Customer non vengono unite tra canali senza evidenze. |
| Configurazione specifica del canale | Responsabili di pagamento, spedizione, imposte, tema, analisi e contenuti legali | La configurazione attiva è separata dalle evidenze dei record migrati. |
Documentare se il negozio sorgente presenta più siti, regioni, brand, lingue, percorsi all’ingrosso, marketplace o esperienze headless. Identificare quali contesti devono restare distinti e quali saranno intenzionalmente consolidati. Questa decisione deve esistere prima di normalizzare le evidenze di catalogo e Customer.
Preparare Products, varianti, proprietà e campi personalizzati
I Products Shopware possono utilizzare relazioni tra Product padre e varianti, proprietà, produttori, media, Categories, prezzi avanzati, campi personalizzati, tempi di consegna, quantità di acquisto e visibilità nei canali di vendita. Le proprietà possono sostenere i filtri del sito e fornire anche i valori usati per generare le varianti, ma proprietà descrittive e proprietà che definiscono varianti non coincidono automaticamente.
| Modello di catalogo | Evidenza da preparare | Condizione di prontezza |
|---|---|---|
| Product semplice | ID Product, numero Product, prezzo, stock, imposta, produttore, Category, media e visibilità per canale | Il Product può essere interpretato senza dipendenze nascoste da estensioni. |
| Famiglia di varianti | ID padre, ID varianti, combinazioni di opzioni, valori ereditati e sovrascritti, SKU, stock, prezzo, peso e immagini | Ogni variante vendibile è tracciabile al Product padre e ai valori opzione corretti. |
| Proprietà filtrabile | Gruppo proprietà, valori opzione, assegnazioni Product, uso nel filtro e traduzioni | I dati descrittivi per la scoperta sono distinti dall’identità acquistabile della variante. |
| Campo personalizzato | Set di campi, nome tecnico, tipo, assegnazione entità, valori, traduzioni e processo che lo utilizza | Gli usi per personale, sito, regole e integrazioni sono documentati. |
| Product multicanale | ID Product/variante, canali assegnati, livelli di visibilità, Category principale e percorso SEO specifico per canale | La disponibilità per canale è esplicita e non dedotta. |
| Product ricco di media | Media principale/galleria, immagini specifiche della variante, contesto alt, ordine e archiviazione esterna | Ogni risorsa media ha un proprietario Product o variante noto. |
Registrare separatamente Products inattivi, nascosti, fuori produzione, in back-order, clearance, digitali, simili a bundle o abbonamenti e Products creati da estensioni. Non normalizzare stati Product insoliti in un unico Product attivo ordinario soltanto per semplificare l’inventario sorgente.
Preparare Categories, Dynamic Product Groups e Shopping Experiences
Le Categories Shopware possono sostenere navigazione, assegnazione Product, punti di ingresso del sito e layout di contenuto. I Dynamic Product Groups possono definire insiemi Product basati su regole. Shopping Experiences può fornire pagina di destinazione, pagine shop, layout Category, sezioni, blocchi, elementi, link e media. Queste relazioni richiedono evidenze separate anche quando per il Customer formano un unico percorso.
| Struttura del sito | Evidenza | Condizione di prontezza |
|---|---|---|
| Gerarchia Category | ID Category, parent, stato attivo, assegnazioni Product, canali di vendita, traduzioni e uso come Category principale | Gerarchia catalogo e ambito canale sono completi. |
| Dynamic Product Group | Condizioni, esempi Product, assegnazione al canale e finalità di business | L’assortimento basato su regole non viene trattato come esportazione di Category statica. |
| Shopping Experience | ID layout, tipo, Category o pagina di destinazione assegnata, sezioni, blocchi, media e Products/Categories collegati | Proprietà dei contenuti e riferimenti al catalogo sono documentati. |
| Percorso di navigazione | Canale di vendita, albero Category, finalità del menu, contesto di accesso e URL prioritari | La navigazione non viene dedotta soltanto dai record Category. |
| Link interni | Pagina sorgente, ID Product/Category/contenuto collegato, lingua e intento della destinazione | I link possono essere riscritti senza perdere l’oggetto di business referenziato. |
Identificare layout o elementi di contenuto creati da estensioni. Separare contenuti riutilizzabili dalla presentazione del tema e dai dati Product. Se una Shopping Experience contiene Product, Category, form o blocco di estensione collegati, registrare sia il layout sia il relativo proprietario.
Preparare regole, prezzi, promozioni e condizioni commerciali
Le assegnazioni Shopware Rule Builder possono influenzare prezzi avanzati, promozioni, costi di spedizione, disponibilità dei metodi di pagamento o spedizione, flussi, visibilità Product o Category e accesso ai contenuti. La preparazione deve descrivere la condizione di business e ogni punto in cui la regola viene assegnata.
| Area commerciale | Evidenza da preparare | Condizione di prontezza |
|---|---|---|
| Regola | ID regola, nome, condizioni, priorità, stato, Customers/gruppi/canali referenziati e assegnazioni | Finalità di business e tutte le aree interessate sono note. |
| Prezzo avanzato | Product/variante, valuta, regola, intervallo quantità, valori lordo/netto, prezzo di listino e contesto data | Ogni prezzo è collegato alla corretta condizione commerciale. |
| Promozione | Codice, regole, ambito sconto, esclusioni, limiti di utilizzo, date e Orders storici rilevanti | Le evidenze storiche dello sconto sono separate dalla configurazione futura della promozione. |
| Condizione di spedizione/pagamento | Regola assegnata, canale, contesto Customer, regione, soglia carrello ed eccezioni | La condizione è documentata senza trattarla come dato Order migrato. |
| Stock e consegna | Quantità Product/variante, proprietario esterno, contesto magazzino se usato, tempo di consegna e stato back-order | Autorità dello stock e chiave dell’unità vendibile sono noti. |
I totali storici degli Orders devono restare snapshot. Non pianificare di ricalcolare vecchi prezzi, sconti, imposte o costi di spedizione a partire dalle assegnazioni Rule Builder correnti.
Preparare Customers, indirizzi, Orders e stati storici
La preparazione Customer dovrebbe includere identità account, relazione con il canale di vendita, gruppi Customer, indirizzi, lingua, informazioni aziendali o fiscali, evidenze di consenso, ID esterni e dipendenze di autenticazione. La preparazione Order dovrebbe preservare righe Product storiche, selezioni di varianti, indirizzi, totali, cronologia degli stati, transazioni, consegne, documenti, rimborsi e riferimenti di integrazione.
| Area record | Responsabile | Evidenza | Condizione di prontezza |
|---|---|---|---|
| Identità Customer | Responsabile dati Customer | ID Customer, email, canale di vendita, gruppo, lingua, stato, indirizzi e ID esterno | Identità duplicate e collegate ai canali sono risolte deliberatamente. |
| Autenticazione | Responsabile sicurezza | Schema password, SSO/social login, percorso reset, MFA e comunicazioni account | L’accesso account è pianificato senza presumere la portabilità delle credenziali. |
| Righe Order | Responsabile dati Order | ID Product/variante, etichette snapshot, quantità, prezzi, promozioni, imposte e payload personalizzati | Gli articoli acquistati restano comprensibili anche se il catalogo cambia in seguito. |
| Stato Order | Responsabile operations | Stati Order, transazione e consegna con timestamp e significato di business | La cronologia può essere interpretata senza ricreare il processo sorgente. |
| Documenti e riferimenti | Responsabili finanza/integrazioni | Fattura, nota di credito, transazione, spedizione, marketplace, ERP e ID di evasione ordini | Le chiavi storiche di riconciliazione restano tracciabili. |
Selezionare Orders guest, registrati, legati a un canale, scontati, rimborsati, parzialmente consegnati e influenzati da estensioni. Questi casi espongono relazioni che gli Orders ordinari completati non mostrano.
Inventariare estensioni, entità personalizzate e integrazioni
Creare un registro di responsabilità per ogni plugin, app, entità personalizzata, set di campi personalizzati, azione Flow Builder, estensione di ricerca, integrazione pagamento o spedizione, connettore ERP/PIM/WMS, feed marketplace, estensione tema e processo pianificato che legge o scrive dati di business.
| Dipendenza | Evidenza da preparare | Condizione di prontezza |
|---|---|---|
| Estensione | Nome, versione, stato, finalità, responsabile configurazione, entità, tabelle, campi personalizzati e record interessati | I dati posseduti dall’estensione hanno una destinazione o un proprietario mantenuto. |
| Entità o campo personalizzato | Schema, assegnazione entità, relazioni, traduzioni e codice che lo utilizza | I dati personalizzati possono essere interpretati indipendentemente dall’implementazione sorgente. |
| Sistema esterno | Endpoint, autorità per entità, direzione di sincronizzazione, ID e responsabile del cutover | La migrazione non crea sistemi autorevoli concorrenti. |
| Flow o webhook | Trigger, condizione, azione, payload, destinazione e responsabile degli errori | L’automazione operativa è separata dai record statici migrati. |
| Dati generati | Indici, cache, log, sessioni, code e tabelle abbandonate di estensioni | I dati tecnici non autorevoli sono esclusi deliberatamente. |
Le estensioni inattive devono restare nel registro quando i loro dati storici compaiono ancora in Products, Customers, Orders, documenti o riconciliazioni esterne.
Preparare URL prioritari, evidenze SEO e decisioni sui redirect
Registrare gli URL prioritari di Product, Category, pagina di destinazione, shop page e contenuti per canale di vendita e lingua. Includere comportamento canonico per le varianti, relazioni con la Category principale, metadati, link interni, backlink, percorsi di campagna e qualsiasi template SEO URL o estensione di redirect coinvolta.
| Evidenza URL | Responsabile | Condizione di prontezza |
|---|---|---|
| Percorsi Product e variante | Responsabile SEO/catalogo | Ogni Product prioritario ha un percorso sorgente consapevole del canale e una destinazione prevista. |
| Percorsi Category e landing | Responsabile contenuti | Gerarchia Category, Shopping Experience e intento del percorso sono collegati. |
| Percorsi multilingue | Responsabile localizzazione | Contesto di lingua e canale di vendita è preservato. |
| Inventario redirect | Responsabile SEO | Ogni vecchio percorso di alto valore ha una decisione keep, change, merge, retire o redirect. |
| Link interni | Responsabile contenuti | I riferimenti sorgente possono essere riscritti verso gli oggetti di destinazione previsti. |
Non affidarsi soltanto alla sitemap. Includere URL provenienti da strumenti di analisi, dati di ricerca, backlink, campagne, comunicazioni ai Customers e navigazione interna di alto valore.
Selezionare campioni rappresentativi per i test di migrazione
Scegliere campioni che rappresentino l’architettura reale del negozio. Registrare ID sorgente, numeri Product, URL, canali di vendita, valori delle proprietà, regole, relazioni Customer, riferimenti Order e il motivo per cui ogni campione è stato scelto.
| Campione | Evidenza da preparare | Finalità della preparazione |
|---|---|---|
| Famiglia di varianti | Parent, varianti, opzioni, ereditarietà, stock, prezzi, immagini e canali | Rappresenta il modello Product e varianti di Shopware. |
| Product ricco di proprietà | Gruppi proprietà, valori filtro, campi personalizzati, Category e uso nella ricerca | Rappresenta scoperta dei Products e proprietà dei campi. |
| Caso dipendente da regole | Regola, area di prezzo/promozione/spedizione/pagamento assegnata e record interessati | Rappresenta il funzionamento commerciale basato su condizioni. |
| Customer multicanale | Customer, canale di registrazione, gruppi, indirizzi e contesto email duplicata | Rappresenta identità legate ai canali. |
| Order complesso | Righe varianti, promozioni, stati, transazione, consegna, documento e ID esterni | Rappresenta evidenze commerciali storiche. |
| Shopping Experience | Layout, assegnazione Category/landing, media, link e blocchi di estensione | Rappresenta le relazioni tra contenuti e commercio. |
| Record posseduto da estensione | Entità core, schema dell’estensione, campi personalizzati e chiavi integrazione | Espone l’ambito non-core prima dell’esecuzione. |
Il pacchetto di campioni Shopware è pronto quando ogni record selezionato dispone di evidenza sorgente, contesto di canale e regole, file correlati e revisore nominato.
Completare il controllo finale di prontezza per Shopware
| Area di prontezza | Condizione di prontezza |
|---|---|
| Accesso e ripristino | Administration, hosting, database/file dove applicabile, media, credenziali, backup e responsabilità del ripristino sono confermati. |
| Canali di vendita | Domini, lingue, valute, ambito Customer, visibilità Product e responsabili sono documentati. |
| Catalogo | Products, varianti, proprietà, Categories, media, prezzi, stock, campi personalizzati e identificatori sono tracciabili. |
| Cronologia commerciale | Customers, indirizzi, Orders, stati, consegne, transazioni, documenti e riferimenti esterni hanno evidenze sorgente. |
| Contenuti e URL | Shopping Experiences, navigazione, percorsi prioritari, metadati, link interni e decisioni sui redirect sono documentati. |
| Dipendenze | Regole, estensioni, entità personalizzate, flow, webhook e sistemi esterni hanno responsabili nominati. |
| Campioni | I record rappresentativi coprono ogni pattern materiale di Product, canale, Customer, Order, contenuto, regola ed estensione. |
L’ambito Shopware è pronto quando ogni record materiale può essere tracciato al proprietario sorgente, ai record correlati, all’evidenza e alla destinazione prevista o al sistema mantenuto.
Conclusione
Preparare una migrazione verso Shopware richiede evidenze coordinate per canali di vendita, Products e varianti, proprietà, campi personalizzati, Categories, Shopping Experiences, regole, Customers, Orders, estensioni, URL e integrazioni. La checklist deve rendere queste relazioni esplicite prima dell’esecuzione, invece di affidarsi a conteggi dei record o esportazioni generiche.
Un pacchetto di prontezza completo preserva evidenze sorgente recuperabili, definisce i record autorevoli, separa le transazioni storiche dalla configurazione attiva e assegna un responsabile a ogni dipendenza rilevante.
Domande frequenti
Che cosa bisogna preparare per prima cosa in una migrazione verso Shopware?
Confermare accessi ad Administration e infrastruttura, creare backup ripristinabili, registrare ambiente Shopware ed estensioni e identificare ogni canale di vendita attivo. Il lavoro dettagliato sul catalogo non dovrebbe iniziare finché il team non può ispezionare la piattaforma sorgente e ripristinarla in modo affidabile.
Perché l’ambito dei canali di vendita deve essere documentato separatamente?
Products, Customers, domini, lingue, valute, visibilità, contenuti e configurazione commerciale possono dipendere dal canale di vendita. La presenza globale dei record non dimostra che sia stato preservato il corretto contesto rivolto ai Customers.
Come bisogna preparare proprietà e varianti Shopware?
Documentare gruppi proprietà, valori, assegnazioni Product, uso nei filtri e combinazioni di opzioni che generano varianti. Registrare valori ereditati e sovrascritti per ogni variante vendibile, così da non confondere proprietà descrittive con identità di variante.
Quali regole richiedono evidenze di preparazione?
Includere le regole assegnate a prezzi, promozioni, spedizione, pagamento, flow, visibilità Product o Category e accesso ai contenuti. Registrare condizioni, priorità, entità referenziate e ogni assegnazione che dipende dalla regola.
Quali Orders Shopware vanno scelti come campioni rappresentativi?
Includere Customers guest e registrati, account legati ai canali, varianti, promozioni, rimborsi, consegne parziali, più cambi di stato, documenti, transazioni e riferimenti a integrazioni esterne.
Che cosa deve essere incluso nel registro delle estensioni Shopware?
Registrare ogni estensione, entità personalizzata, set di campi personalizzati, flow, webhook, dipendenza dal tema e connettore esterno che crea o utilizza dati di business. Ogni elemento necessita di responsabile, record interessati, evidenza sorgente e decisione sulla destinazione o sul sistema mantenuto.