I problemi nelle migrazioni verso Shopware nascono spesso quando i record vengono trasferiti senza le relazioni di canale di vendita, ereditarietà, regole, contenuti ed estensioni che ne determinano il comportamento. Un Product può esistere in Administration ma restare invisibile in un canale di vendita, una variante può ereditare prezzo o media sbagliati e una Shopping Experience può essere renderizzata senza i collegamenti a Product o Category che mostrava in precedenza.
I modelli di errore seguenti si concentrano proprio su queste interruzioni nelle relazioni. Per ciascuno vengono definiti segnali di allarme, controllo preventivo, esempio realistico e condizione Pass che dimostra che il rischio è stato contenuto.
Problema 1: importare Products senza le assegnazioni ai canali di vendita
Cosa va storto
I canali di vendita Shopware possono rappresentare vetrine, canali API headless, comparatori Product e altre destinazioni. Products, Categories, lingue, valute, domini, metodi di pagamento, metodi di consegna, registrazione Customer e temi possono differire per canale. Importare un Product senza la relativa visibilità nel canale può lasciarlo presente in Administration ma indisponibile agli acquirenti.
Segnali di allarme iniziali
| Segnale di allarme iniziale | Cosa indica |
|---|---|
| L’origine ha diversi domini, regioni, marchi o feed marketplace. | Un unico canale di vendita predefinito difficilmente conserva il modello operativo. |
| La disponibilità Product varia per vetrina o canale. | La titolarità dell’assortimento deve essere mappata per canale di vendita. |
| I Customers sono vincolati a specifici canali di vendita. | Il contesto Customer non è intercambiabile globalmente. |
| Categories o gruppi Product dinamici popolano gli assortimenti dei canali. | La visibilità dipende da relazioni che vanno oltre il record Product. |
Prevenzione
Crea una mappa di titolarità dei canali di vendita. Preserva assegnazione di Product e Category, lingua, valuta, dominio, contesto Customer, relazioni di pagamento e consegna, punto di ingresso nella navigazione e chiave del canale esterno. Non presumere che ogni Product appartenga a ogni canale.
Esempio consigliato
Usa un Product disponibile in due vetrine, un Product limitato a un canale regionale e un Product esportato tramite un canale di comparazione. Rappresenta separatamente ogni assegnazione di canale.
Condizione Pass
Ogni Product rappresentativo appare soltanto nei canali di vendita previsti, con lingua, valuta, percorso Category, accesso Customer e relazione URL o feed specifica del canale corretti.
Problema 2: appiattire varianti Product, proprietà ed ereditarietà
Cosa va storto
Le proprietà Shopware possono descrivere Products, sostenere i filtri e generare varianti. Le varianti possono ereditare dal padre prezzo, stock, media, dimensioni, testo e altri valori finché l’ereditarietà non viene rimossa. Appiattire la famiglia può duplicare contenuti del padre, perdere numeri Product dei figli o sovrascrivere valori specifici delle varianti.
Segnali di allarme iniziali
| Segnale di allarme iniziale | Cosa indica |
|---|---|
| Le combinazioni di varianti sono generate da opzioni di proprietà ma mancano gli ID dei figli. | La famiglia di varianti non ha un’identità stabile per le unità vendibili. |
| Padre e varianti condividono valori in alcuni campi ma differiscono in altri. | I confini tra ereditarietà e override non sono documentati. |
| I dati di origine non distinguono valori ereditati e sovrascritti. | La destinazione può duplicare valori o cancellare differenze intenzionali. |
| Le proprietà usate per i filtri sono mescolate con quelle che generano varianti. | Attributi di scoperta e combinazioni vendibili vengono confusi. |
Prevenzione
Preserva Product principale, proprietà che generano varianti, combinazioni di opzioni, numeri Product dei figli, stato di ereditarietà, esclusioni, prezzi, stock, media e stato attivo. Mantieni le proprietà descrittive usate per i filtri separate da quelle che definiscono varianti vendibili.
Esempio consigliato
Usa una camicia le cui varianti ereditano le descrizioni ma sovrascrivono numero Product, prezzo, stock e immagine. Includi una combinazione colore-taglia esclusa.
Condizione Pass
La famiglia rappresentativa contiene varianti ed esclusioni corrette, i campi ereditati restano ereditati, i campi sovrascritti mantengono i valori dei figli e le proprietà dei filtri non generano varianti indesiderate.
Problema 3: ricreare i prezzi senza le condizioni del Rule Builder
Cosa va storto
Le condizioni del Rule Builder di Shopware possono influire su prezzi, promozioni, consegna, pagamento, contenuti e altri comportamenti commerciali. Copiare soltanto il prezzo o lo sconto risultante elimina il gruppo Customer, il canale di vendita, la valuta, la quantità, l’orario, il carrello o la condizione Order che spiega quando il valore si applica.
Segnali di allarme iniziali
| Segnale di allarme iniziale | Cosa indica |
|---|---|
| Esistono più prezzi per lo stesso Product senza un pubblico chiaramente definito. | Mancano le condizioni che selezionano il prezzo. |
| Le promozioni sono descritte per nome ma non per condizioni e priorità. | La logica del Rule Builder non può essere ricostruita dalle sole etichette. |
| Disponibilità di consegna o pagamento dipende da proprietà Customer o del carrello. | I metodi operativi sono governati da regole, non soltanto dai record migrati. |
| Le regole referenziano gruppi Customer, tag, canali di vendita o campi personalizzati. | I dati da cui dipende la regola devono restare collegati. |
Prevenzione
Modella la regola separatamente dal risultato. Preserva nome della regola, priorità, condizioni, operatori, entità referenziate e modulo che utilizza la regola. Riassegna Customers, gruppi o canali di vendita referenziati quando gli ID dell’origine non possono essere mantenuti.
Esempio consigliato
Usa un prezzo per quantità destinato a un gruppo Customer all’ingrosso e una regola di consegna limitata a un canale regionale e a un valore del carrello. Preserva condizioni e riferimenti, non soltanto i valori finali.
Condizione Pass
Ogni regola rappresentativa si applica soltanto nel contesto previsto, resta inattiva fuori da quel contesto e referenzia Customers, gruppi, Products, canali, valute e campi personalizzati validi nella destinazione.
Problema 4: trattare alberi Category e gruppi Product dinamici come la stessa cosa
Cosa va storto
Le Categories Shopware possono organizzare navigazione e contenuti, mentre i gruppi Product dinamici selezionano Products in base a regole. Una raccolta o un gruppo di merchandising dell’origine può essere scambiato per una Category permanente, oppure una Category può essere ricostruita come regola che non fornisce più gerarchia, contenuti o percorsi.
Segnali di allarme iniziali
- Le raccolte dell’origine combinano appartenenza manuale e basata su regole.
- Una Category esiste soprattutto per mostrare Products di una campagna.
- I Products compaiono nella ricerca ma non nel ramo di navigazione previsto.
- I gruppi dinamici dipendono da proprietà o campi personalizzati non normalizzati.
Prevenzione
Classifica ogni raggruppamento in base alla titolarità: gerarchia e percorso, appartenenza manuale Product, regola di selezione dinamica, Shopping Experience o assortimento di canale. Preserva i campi usati dai gruppi dinamici e le relazioni Category usate dalla navigazione.
Esempio consigliato
Rappresenta una Category permanente “Scarpe”, un gruppo dinamico “Scorte basse” e una Category di landing stagionale alimentata da un gruppo dinamico come tre strutture collegate ma distinte.
Condizione Pass
Le Categories permanenti mantengono gerarchia e percorsi, i gruppi dinamici restituiscono i Products previsti in base a condizioni valide e i layout delle campagne referenziano il raggruppamento corretto senza duplicare la titolarità Product.
Problema 5: copiare Shopping Experiences senza il contesto assegnato
Cosa va storto
Le Shopping Experiences possono creare pagina di destinazione, pagine del negozio, layout Category e layout delle pagine Product. Sezioni, blocchi, elementi, media, link e assegnazioni dati dipendono dal tipo di pagina e dal canale di vendita. Copiare il contenuto del layout senza Category, Product o canale assegnati può produrre una pagina visivamente corretta ma irraggiungibile o fuorviante.
Segnali di allarme iniziali
| Segnale di allarme iniziale | Cosa indica |
|---|---|
| I layout contengono link Product o Category che puntano a ID dell’origine. | Il contenuto Shopping Experience contiene relazioni interne interrotte. |
| Le pagine Category usano layout differenti per canale di vendita. | L’assegnazione del layout dipende dal canale. |
| Gli elementi delle pagine Product contengono override specifici del record. | Un template generico non può riprodurre tutto il comportamento della vetrina. |
| Esistono pagina di destinazione senza navigazione o documentazione del percorso diretto. | I contenuti possono migrare senza un percorso di scoperta utilizzabile. |
Prevenzione
Preserva tipo di layout, sezioni, blocchi, elementi, media, contenuti tradotti, link, Categories o Products assegnati, compatibilità con i canali di vendita e override a livello di record. Sostituisci gli ID dell’origine con riferimenti alle entità della destinazione.
Esempio consigliato
Usa un layout Category, una pagina di destinazione autonoma e un layout di pagina Product con un override testuale specifico del Product. Traccia ogni Product, Category, elemento multimediale e percorso collegato.
Condizione Pass
Ogni Shopping Experience rappresentativa è raggiungibile tramite il percorso previsto, viene renderizzata nel canale di vendita e nella lingua corretti e mostra Products, Categories, media e override specifici dei record validi nella destinazione.
Problema 6: perdere le definizioni dei campi personalizzati o l’ereditarietà linguistica
Cosa va storto
I campi personalizzati Shopware possono estendere Products, Categories, Customers, Orders e altre entità. Il valore dipende da set di campi, tipo di dato, assegnazione, traduzione e template o regola che lo utilizza. Copiare i valori senza le definizioni crea dati invisibili o inutilizzabili. Inserire soltanto un valore tradotto può inoltre interrompere l’ereditarietà dalla lingua predefinita.
Segnali di allarme iniziali
- Esistono valori dei campi personalizzati ma il relativo set non è documentato.
- Più lingue contengono valori differenti o mancanti.
- Regole o template referenziano nomi tecnici dei campi personalizzati.
- Campi creati da app sono mescolati con quelli creati dall’azienda.
Prevenzione
Preserva identità del set di campi, nome tecnico, etichetta, tipo, valori consentiti, assegnazione all’entità, valore nella lingua predefinita, override tradotti e ogni riferimento da Rule Builder, template o integrazione. Mantieni i dati personalizzati posseduti da applicazioni sotto il relativo proprietario effettivo.
Esempio consigliato
Usa un campo Product di conformità ereditato tra lingue e un’etichetta marketing localizzata che sovrascrive intenzionalmente il valore predefinito.
Condizione Pass
I campi compaiono sulle entità corrette, conservano definizioni e valori consentiti utilizzabili, ereditano dalla lingua predefinita quando previsto e restano disponibili per ogni regola, template o integrazione che li utilizza.
Problema 7: preservare le intestazioni Order ma perdere il contesto di stato, transazione e consegna
Cosa va storto
Gli Orders Shopware possono includere righe Order, Customers, indirizzi, valute, imposte, sconti, transazioni, consegne, documenti, stati e riferimenti esterni. Importare soltanto intestazione e totale dell’Order elimina transizioni di stato e record operativi che spiegano pagamento ed evasione ordini.
Segnali di allarme iniziali
- Gli stati di pagamento e consegna vengono compressi in un unico stato Order generico.
- Spedizioni, tracking, rimborsi o documenti sono archiviati separatamente.
- I numeri Product delle varianti figlie mancano dalle righe Order.
- Riferimenti ERP o di pagamento esterni esistono soltanto nei dati delle estensioni.
Prevenzione
Preserva snapshot dell’Order, righe, identità della variante, indirizzi, totali, imposte, promozioni, stato della transazione, stato della consegna, tracking, documenti, commenti e ID esterni. Mantieni lo stato storico indipendente dalle regole e dai metodi attivi correnti.
Esempio consigliato
Usa un Order pagato e spedito, un Order evaso parzialmente e un Order rimborsato che contenga una variante e una promozione.
Condizione Pass
Ogni Order rappresentativo resta comprensibile per assistenza Customer, finanza ed evasione ordini, con relazioni valide tra righe, transazioni, consegne, documenti, stati e riferimenti esterni.
Problema 8: ricostruire gli URL SEO senza contesto di canale di vendita e canonical
Cosa va storto
I template URL SEO e i percorsi generati da Shopware possono differire per canale di vendita. Products con varianti possono inoltre usare un URL canonical condiviso oppure percorsi specifici per variante. Ricreare gli slug senza template, Category principale, percorso storico e contesto del canale può generare pagine duplicate o indirizzare i visitatori alla vetrina sbagliata.
Segnali di allarme iniziali
- Lo stesso Product ha percorsi differenti per canale di vendita o lingua.
- Gli URL dell’origine dipendono dai breadcrumb Category o dall’assegnazione della Category principale.
- Le pagine delle varianti usano comportamenti canonical differenti.
- I vecchi URL non sono collegati ai percorsi della destinazione.
Prevenzione
Preserva percorsi dell’origine, Product o Category di destinazione, canale di vendita, lingua, Category principale, impostazione canonical e relazione di redirect. Ricostruisci gli indici SEO dopo modifiche ai template in modo che i percorsi generati riflettano le regole previste.
Esempio consigliato
Usa un Product assegnato a due Categories in due canali di vendita, più una famiglia di varianti che utilizza un unico URL Product canonical. Registra ogni percorso importante dell’origine e la destinazione prevista.
Condizione Pass
I percorsi rappresentativi si risolvono nel canale di vendita e nella lingua corretti, il comportamento canonical è coerente tra le varianti e i percorsi legacy reindirizzano al Product o alla Category corrente previsti.
Problema 9: copiare dati delle estensioni senza la relativa entità e il ciclo di vita
Cosa va storto
Estensioni e applicazioni Shopware possono aggiungere entità personalizzate, campi, regole, record API, processi pianificati, componenti della vetrina, dati di pagamento o consegna, abbonamenti, collegamenti marketplace e stato delle integrazioni. Copiare campi dentro entità standard non preserva ciclo di vita o riferimenti dell’estensione.
Segnali di allarme iniziali
- I campi tecnici usano un prefisso di app o plugin.
- Entità personalizzate referenziano Products, Customers o Orders tramite ID interni.
- Il personale usa dati che non hanno un modulo Administration standard.
- Un sistema esterno aggiorna il valore tramite API o webhook.
Prevenzione
Crea una mappa di titolarità per ogni estensione. Identifica entità, riferimenti ai genitori, campi tecnici, configurazione, ID esterni, direzione degli aggiornamenti e destinazione continuativa. Separa le prove storiche dallo stato operativo attivo.
Esempio consigliato
Traccia un record di abbonamento, un listing marketplace e un identificativo Product ERP dall’entità dell’estensione al record Shopware principale e al proprietario esterno.
Condizione Pass
Ogni record di estensione mantenuto ha un’entità di destinazione definita, riferimenti ai genitori validi, identificativi esterni stabili e un’applicazione o integrazione continuativa in grado di interpretarlo e mantenerlo.
Problema 10: presumere che dati Product corretti producano automaticamente risultati di ricerca corretti
Cosa va storto
Ricerca e indicizzazione Shopware possono dipendere da campi Product ricercabili, numeri Product, parole chiave, proprietà, produttori, Categories, sinonimi, azioni e configurazione di indicizzazione specifica delle estensioni. I Products importati possono esistere ed essere attivi ma non comparire nella ricerca oppure essere classificati male perché campi indicizzati, alias o elaborazione delle code sono incompleti.
Segnali di allarme iniziali
| Segnale di allarme iniziale | Cosa indica |
|---|---|
| I Products sono visibili tramite URL diretto ma assenti dalla ricerca. | Il record Product esiste, ma indicizzazione o configurazione della ricerca è incompleta. |
| Numeri Product, EAN o valori personalizzati non sono ricercabili. | I campi di ricerca necessari non sono inclusi nella configurazione attiva. |
| Sinonimi di ricerca e azioni di inoltro non sono stati inventariati. | Il comportamento di merchandising non seguirà l’intento dell’origine. |
| La creazione dell’indice termina ma alias o elaborazione in coda restano incompleti. | L’indice generato non è ancora quello che serve le richieste della vetrina. |
Prevenzione
Preserva parole chiave di ricerca, visibilità Product, campi ricercabili, proprietà, dati del produttore, sinonimi, azioni ed eventuale configurazione Advanced Search. Includi creazione degli indici, elaborazione della coda messaggi, creazione degli alias e responsabilità sull’indicizzazione continuativa nel runbook della migrazione.
Esempio consigliato
Usa un Product trovato per nome, uno trovato tramite numero Product, uno dipendente da un sinonimo e uno interessato da un’azione di ricerca. Tracciali nei campi di ricerca e negli indici configurati.
Condizione Pass
I Products rappresentativi compaiono tramite nomi, numeri, proprietà, produttori e sinonimi previsti; le azioni di ricerca conducono a destinazioni valide e indici e alias necessari restano aggiornati.
Priorità di prevenzione trasversali ai problemi
La prevenzione dei problemi Shopware dipende dal mantenere i dati Product collegati a canali di vendita, varianti ereditate, condizioni del Rule Builder, Shopping Experiences, campi personalizzati sensibili alla lingua, stati storici degli Orders, percorsi, ricerca e titolarità delle estensioni. Un record Product corretto non può compensare una relazione mancante con canale, regola, layout o indice.
| Livello di prevenzione | Controllo richiesto |
|---|---|
| Titolarità del canale di vendita | Collega Products, Customers, Categories, domini, lingue e visibilità al canale corretto. |
| Controllo dell’ereditarietà | Distingui i valori ereditati dal padre dagli override a livello di variante. |
| Dipendenze delle regole | Preserva i dati usati dalle condizioni del Rule Builder per prezzi, promozioni, pagamenti e consegna. |
| Assegnazione delle esperienze | Mantieni Shopping Experiences collegate al tipo di pagina, all’entità, al percorso e al canale di vendita corretti. |
| Erogazione della ricerca | Allinea campi ricercabili, sinonimi, indicizzazione, alias ed elaborazione in coda. |
Conclusione
Le migrazioni Shopware falliscono quando strutture interconnesse della piattaforma vengono appiattite in record isolati. I canali di vendita definiscono la disponibilità, le proprietà generano varianti, le regole controllano il comportamento commerciale, le Shopping Experiences forniscono il contesto e le estensioni possono possedere interi domini aziendali.
La migrazione più sicura preserva ogni relazione e la dimostra tramite una condizione Pass specifica per la piattaforma. Quando Products, canali, regole, contenuti, Orders, URL, ricerca ed estensioni sono coerenti tra loro, lo Store migrato si comporta come un ambiente Shopware unitario invece che come una raccolta di entità importate.
Domande frequenti
Perché un Product può esistere in Shopware ma restare indisponibile agli acquirenti?
Il Product può essere inattivo, nascosto, escluso dal canale di vendita rilevante, assente dall’assortimento Category del canale oppure privo del contesto di lingua, valuta, dominio o visibilità richiesto da quella vetrina.
Le proprietà Shopware sono sempre varianti Product?
No. Le proprietà possono descrivere e filtrare Products senza generare varianti. Soltanto le opzioni di proprietà selezionate e usate dal generatore di varianti definiscono combinazioni vendibili.
Perché le condizioni del Rule Builder devono essere migrate separatamente dai prezzi o sconti risultanti?
Il risultato è valido soltanto in condizioni specifiche di Customer, canale, valuta, quantità, carrello, tempo o Order. Copiare il valore senza la regola lo applica in modo troppo ampio oppure non lo applica affatto.
Le Shopping Experiences possono essere migrate come normali CMS Pages?
Non in modo affidabile. Tipo di pagina, sezioni, blocchi, elementi, assegnazioni, contesto del canale di vendita, link e override specifici per Product o Category determinano dove e come funziona il layout.
Come devono essere gestiti i campi personalizzati Shopware tra più lingue?
Preserva prima la definizione del campo e il valore nella lingua predefinita, poi mantieni gli override tradotti intenzionali. In questo modo l’ereditarietà resta utilizzabile da template, regole e integrazioni.
Perché Products Shopware corretti possono comunque mancare dalla ricerca?
L’risultato di ricerca dipende da visibilità, campi ricercabili, parole chiave, proprietà, sinonimi, azioni, creazione degli indici, elaborazione delle code, alias e configurazione delle estensioni. Record Product corretti da soli non garantiscono che il contenuto venga indicizzato e trovato.