Bei der Bewertung von Shopware als mögliche Zielplattform zeigt die Fehleranalyse, welche wiederkehrenden Migrationsfehler bei diesem Ziel auftreten können und wie sie vermieden werden.
Wenn Shopware als Zielplattform eingesetzt wird, entstehen typische Migrationsfehler meist nicht dadurch, dass einzelne Datensätze vollständig fehlen, sondern dadurch, dass die Beziehungen verloren gehen, die ihr Verhalten bestimmen. Ein Product kann in der Administration vorhanden sein und trotzdem in einem Vertriebskanal unsichtbar bleiben. Eine Variante kann den falschen Preis oder das falsche Medium erben. Eine Shopping Experience kann rendern, obwohl die Product- oder Category-Links nicht mehr auf die vorgesehenen Zielobjekte zeigen.
Die folgenden Fehlerbilder konzentrieren sich deshalb auf solche Beziehungsbrüche. Jeder Abschnitt benennt frühe Warnsignale, eine vorbeugende Kontrolle, ein realistisches Beispiel und eine Pass-Bedingung, mit der sich nachweisen lässt, dass das Risiko tatsächlich beherrscht ist.
Fehler 1: Products ohne ihre Vertriebskanal-Zuordnung importieren
Was schiefgeht
Shopware-Vertriebskanäle können Storefronts, Headless-API-Kanäle, Product-Comparisons und weitere Ziele darstellen. Products, Categories, Sprachen, Währungen, Domains, Zahlungsarten, Versandmethoden, Customer-Registrierung und Themes können je Kanal unterschiedlich sein. Wird nur das Product importiert, kann es in der Administration existieren und für Customers trotzdem nicht verfügbar sein.
Frühe Warnsignale
| Warnsignal | Bedeutung |
|---|---|
| Source enthält mehrere Domains, Regionen, Marken oder Marketplace-Feeds. | Ein einzelner Standard-Vertriebskanal wird das Betriebsmodell wahrscheinlich nicht bewahren. |
| Product-Verfügbarkeit unterscheidet sich je Storefront oder Kanal. | Sortimentsverantwortung muss kanalbezogen abgebildet werden. |
| Customers sind an bestimmte Vertriebskanäle gebunden. | Customer-Kontext ist nicht global austauschbar. |
| Categories oder Dynamic Product Groups steuern Kanalsortimente. | Sichtbarkeit hängt von Beziehungen jenseits des Product Datensätze ab. |
Vorbeugung
Erstellen Sie eine Verantwortungship-Map der Vertriebskanäle. Bewahren Sie Product- und Category-Zuordnung, Sprache, Währung, Domain, Customer-Kontext, Zahlungs- und Versandbeziehungen, Navigationseinstieg und externe Kanalschlüssel. Gehen Sie niemals davon aus, dass jedes Product in jeden Kanal gehört.
Beispiel für die Empfehlung
Prüfen Sie ein Product, das in zwei Storefronts verfügbar ist, ein regional eingeschränktes Product und ein Product für einen Comparison Channel. Jede Kanalzuordnung muss getrennt nachvollziehbar sein.
Pass-Bedingung
Jedes repräsentative Product erscheint nur in den vorgesehenen Vertriebskanälen und dort mit korrekter Sprache, Währung, Category-Struktur, Customer-Zugriff und kanalspezifischer URL- oder Feed-Beziehung.
Fehler 2: Product-Varianten, Properties und Vererbung abflachen
Was schiefgeht
Shopware-Properties können Products beschreiben, Filterung unterstützen und Varianten erzeugen. Varianten können Preis, Bestand, Medien, Dimensionen, Texte und andere Werte vom Parent erben, solange die Vererbung nicht aufgehoben wird. Wird die Familie abgeflacht, können Parent-Inhalte dupliziert, Child Product Numbers verloren oder variantenspezifische Werte überschrieben werden.
Frühe Warnsignale
| Warnsignal | Bedeutung |
|---|---|
| Variantenkombinationen entstehen aus Property Options, Child-IDs fehlen aber. | Der Variantenfamilie fehlt stabile Identität der verkaufbaren Einheit. |
| Parent und Varianten teilen manche Werte, unterscheiden sich aber in anderen. | Grenzen zwischen Vererbung und Override sind nicht dokumentiert. |
| Quelldaten unterscheiden geerbte und überschriebene Werte nicht. | Ziel kann Werte duplizieren oder beabsichtigte Unterschiede löschen. |
| Filter-Properties werden mit variantenerzeugenden Properties vermischt. | Discovery-Attribute und kaufbare Kombinationen werden verwechselt. |
Vorbeugung
Bewahren Sie Main Product, variantenerzeugende Properties, Optionskombinationen, Child Product Numbers, Vererbungsstatus, Ausschlüsse, Preise, Bestand, Medien und Aktivstatus. Beschreibende Filter-Properties bleiben getrennt von den Properties, die verkaufbare Varianten definieren.
Beispiel für die Empfehlung
Verwenden Sie ein Shirt, dessen Varianten Beschreibungen erben, Product Number, Preis, Bestand und Bild aber überschreiben. Nehmen Sie eine ausgeschlossene Farb-Größen-Kombination auf.
Pass-Bedingung
Die repräsentative Familie enthält die richtigen Varianten und Ausschlüsse; geerbte Felder bleiben geerbt, überschriebene Felder behalten Child-Werte und Filter-Properties erzeugen keine unbeabsichtigten Varianten.
Fehler 3: Preise ohne ihre Rule-Builder-Bedingungen rekonstruieren
Was schiefgeht
Shopware Rule Builder kann Preise, Promotions, Versand, Zahlung, Content und weiteres kommerzielles Verhalten steuern. Wird nur der resultierende Preis oder Rabatt kopiert, gehen Customer Group, Vertriebskanal, Währung, Menge, Zeit, Warenkorb- oder Order-Bedingung verloren, die erklärt, wann der Wert gilt.
Frühe Warnsignale
| Warnsignal | Bedeutung |
|---|---|
| Für dasselbe Product existieren mehrere Preise ohne klaren Empfängerkreis. | Bedingungen zur Preisauswahl fehlen. |
| Promotions sind nur über Namen beschrieben, nicht über Bedingungen und Prioritäten. | Rule-Builder-Logik lässt sich aus Labels nicht rekonstruieren. |
| Versand-/Zahlungsverfügbarkeit hängt von Customer- oder Warenkorbdaten ab. | Operative Methoden werden von Regeln gesteuert, nicht allein von migrierten Datensätze. |
| Regeln referenzieren Customer Groups, Tags, Vertriebskanäle oder Custom Fields. | Abhängige Daten müssen verbunden bleiben. |
Vorbeugung
Modellieren Sie Regel und Ergebnis getrennt. Bewahren Sie Rule Name, Priorität, Conditions, Operators, referenzierte Entities und das konsumierende Modul. Wenn Quell-IDs nicht übernommen werden können, müssen Customers, Groups oder Vertriebskanäle auf gültige Zielreferenzen neu zugeordnet werden.
Beispiel für die Empfehlung
Prüfen Sie einen Mengenpreis für eine Wholesale Customer Group und eine Versandregel, die auf einen regionalen Vertriebskanal und einen Warenkorbwert begrenzt ist. Bewahren Sie die Bedingungen und Referenzen, nicht nur die Endwerte.
Pass-Bedingung
Jede repräsentative Regel wirkt ausschließlich im vorgesehenen Kontext, bleibt außerhalb inaktiv und referenziert gültige Ziel-Customers, Groups, Products, Channels, Währungen und Custom Fields.
Fehler 4: Category Trees und Dynamic Product Groups gleich behandeln
Was schiefgeht
Shopware-Categories können Navigation und Content strukturieren; Dynamic Product Groups wählen Products regelbasiert aus. Eine Quell-Collection oder Merchandising-Gruppe kann fälschlich als permanente Category behandelt werden, oder eine Category wird als Regel neu aufgebaut und verliert dabei Hierarchie, Content oder Route.
Frühe Warnsignale
- Quell-Collections kombinieren manuelle und regelbasierte Mitgliedschaft.
- Eine Category existiert hauptsächlich zur Darstellung von Campaign Products.
- Products erscheinen in der Suche, aber nicht im vorgesehenen Navigationszweig.
- Dynamic Groups hängen von Properties oder Custom Fields ab, die nicht normalisiert wurden.
Vorbeugung
Klassifizieren Sie jede Gruppierung nach ihrer Funktion: Hierarchie/Route, manuelle Product-Mitgliedschaft, dynamische Auswahlregel, Shopping Experience oder Kanalsortiment. Bewahren Sie Felder, die Dynamic Groups verwenden, und Category-Beziehungen für Navigation.
Beispiel für die Empfehlung
Behandeln Sie eine permanente Category „Schuhe“, eine dynamische Gruppe „Niedriger Bestand“ und eine saisonale Landing-Category, die von einer Dynamic Group gespeist wird, als drei verbundene, aber unterschiedliche Strukturen.
Pass-Bedingung
Permanente Categories behalten Hierarchie und Routen, Dynamic Groups liefern anhand gültiger Bedingungen die vorgesehenen Products, und Campaign Layouts referenzieren die richtige Gruppierung ohne doppelte Product Verantwortungship.
Fehler 5: Shopping Experiences ohne ihren zugewiesenen Kontext kopieren
Was schiefgeht
Shopping Experiences können Landingpages, Shop Pages, Category Layouts und Product-Page-Layouts bilden. Sections, Blocks, Elements, Medien, Links und Datenzuordnungen hängen vom Seitentyp und Vertriebskanal ab. Wird nur der Layout-Content kopiert, kann eine optisch attraktive Seite entstehen, die nicht erreichbar ist oder falsche Inhalte zeigt.
Frühe Warnsignale
| Warnsignal | Bedeutung |
|---|---|
| Layouts enthalten Product-/Category-Links mit Quell-IDs. | Content enthält defekte interne Beziehungen. |
| Category Pages verwenden je Vertriebskanal unterschiedliche Layouts. | Layout-Zuordnung ist kanalspezifisch. |
| Product-Page-Elemente enthalten datensatzspezifische Overrides. | Ein generisches Template kann nicht jedes Storefront-Verhalten abbilden. |
| Landingpages existieren ohne dokumentierte Navigation oder direkte Route. | Content kann migriert sein, ohne auffindbar zu werden. |
Vorbeugung
Bewahren Sie Layout-Typ, Sections, Blocks, Elements, Medien, übersetzten Content, Links, zugewiesene Categories/Products, Vertriebskanal-Kompatibilität und datensatzspezifische Overrides. Quell-IDs müssen durch gültige Referenzen auf Ziel-Entities ersetzt werden.
Beispiel für die Empfehlung
Verwenden Sie ein Category Layout, eine eigenständige Landingpage und ein Product-Page-Layout mit einem Product-spezifischen Text-Override. Verfolgen Sie jedes verlinkte Product, jede Category, jedes Medium und jede Route.
Pass-Bedingung
Jede repräsentative Shopping Experience ist über die vorgesehene Route erreichbar, rendert im richtigen Vertriebskanal und in der richtigen Sprache und zeigt gültige Ziel-Products, Categories, Medien sowie datensatzspezifische Overrides.
Fehler 6: Custom-Feld-Definitionen oder Sprachvererbung verlieren
Was schiefgeht
Shopware-Custom-Felder können Products, Categories, Customers, Orders und andere Entities erweitern. Ein Wert hängt von Feld Set, Datentyp, Assignment, Übersetzung und dem Template beziehungsweise der Regel ab, die ihn nutzt. Werte ohne Definition können unsichtbar oder unbrauchbar werden. Wird nur ein übersetzter Wert gesetzt, kann außerdem die Vererbung aus der Standardsprache brechen.
Frühe Warnsignale
- Custom-Feld-Werte existieren, aber das Feld Set ist nicht dokumentiert.
- Sprachen enthalten abweichende oder fehlende Werte.
- Rules oder Templates referenzieren technische Custom-Feld-Namen.
- App-erzeugte Felder sind mit Händler-erzeugten Felder vermischt.
Vorbeugung
Bewahren Sie Feld-Set-Identität, technischen Namen, Label, Typ, erlaubte Werte, Entity-Zuordnung, Wert der Standardsprache, übersetzte Overrides sowie jede Rule-Builder-, Template- oder Integrationsreferenz. Anwendung-eigene benutzerdefinierte Daten bleibt unter ihrem tatsächlichen Verantwortung.
Beispiel für die Empfehlung
Prüfen Sie ein Product-Compliance-Feld, das über Sprachen geerbt wird, und ein lokalisiertes Marketing-Label, das den Standardwert bewusst überschreibt.
Pass-Bedingung
Felder erscheinen an den richtigen Entities, besitzen nutzbare Definitionen und erlaubte Werte, erben den Standardwert dort, wo dies vorgesehen ist, und bleiben für jede Regel, jedes Template und jede Integration verfügbar, die sie nutzt.
Fehler 7: Order Header bewahren, aber State-, Transaction- und Delivery-Kontext verlieren
Was schiefgeht
Shopware-Orders können Order Lines, Customers, Adressen, Währungen, Steuern, Rabatte, Transactions, Deliveries, Dokumente, States und externe Referenzen enthalten. Wird nur Header und Total importiert, gehen Zustandswechsel und operative Datensätze verloren, die Payment und Fulfillment erklären.
Frühe Warnsignale
- Payment- und Delivery-States werden in einen generischen Order-Status zusammengefasst.
- Shipments, Tracking, Refunds oder Dokumente liegen separat.
- Varianten-Child-Product-Numbers fehlen in Order Lines.
- Externe ERP- oder Payment-Referenzen existieren nur in Erweiterungsdaten.
Vorbeugung
Bewahren Sie Order Snapshot, Line Items, Variantenidentität, Adressen, Totals, Taxes, Promotions, Transaction State, Delivery State, Tracking, Dokumente, Kommentare und externe IDs. Historische States bleiben von aktuellen Live-Regeln und Methoden getrennt.
Beispiel für die Empfehlung
Prüfen Sie eine bezahlte und versandte Order, eine teilweise erfüllte Order sowie eine erstattete Order mit Variante und Promotion.
Pass-Bedingung
Jede repräsentative Order bleibt für Customer Service, Finance und Fulfillment verständlich und besitzt gültige Line-, Transaction-, Delivery-, Dokument-, State- und Beziehungen zu externen Referenzen.
Fehler 8: SEO URLs ohne Vertriebskanal- und Canonical-Kontext neu aufbauen
Was schiefgeht
Shopware SEO-URL-Templates und generierte Pfade können sich je Vertriebskanal unterscheiden. Varianten können eine gemeinsame Canonical URL oder eigene Pfade verwenden. Werden Slugs ohne Template, Main Category, historischen Pfad und Kanalkontext neu erzeugt, können Duplicate Pages entstehen oder Besucher im falschen Storefront-Kontext landen.
Frühe Warnsignale
- Dasselbe Product besitzt je Vertriebskanal oder Sprache unterschiedliche Pfade.
- Quell-URLs hängen von Category Breadcrumbs oder Main-Category-Zuordnung ab.
- Variantenseiten verwenden gemischtes Canonical-Verhalten.
- Alte URLs sind nicht mit Zielrouten verknüpft.
Vorbeugung
Bewahren Sie Quellpfad, Ziel-Product oder -Category, Vertriebskanal, Sprache, Main Category, Canonical-Einstellung und Redirect-Beziehung. Nach Template-Änderungen müssen SEO-Indizes neu aufgebaut werden, damit generierte Pfade die vorgesehenen Regeln widerspiegeln.
Beispiel für die Empfehlung
Verwenden Sie ein Product, das zwei Categories in zwei Vertriebskanälen zugeordnet ist, plus eine Variantenfamilie mit einer gemeinsamen Canonical Product URL. Dokumentieren Sie jeden relevanten Quellpfad und das vorgesehene Ziel.
Pass-Bedingung
Repräsentative Routen lösen im richtigen Vertriebskanal und in der richtigen Sprache auf, Canonical-Verhalten bleibt über Varianten hinweg konsistent, und Legacy-Pfade redirecten auf das vorgesehene aktuelle Product oder die Category.
Fehler 9: Erweiterungsdaten ohne Entity und Lifecycle kopieren
Was schiefgeht
Shopware-Erweiterungen und Anwendungs können Custom Entities, Felder, Rules, API Datensätze, Scheduled Processes, Storefront Components, Zahlungs-/Versanddaten, Subscriptions, Marketplace Links und Integrationszustände hinzufügen. Das Kopieren einzelner Felder in Standard-Entities bewahrt weder Lifecycle noch Referenzen der Erweiterung.
Frühe Warnsignale
- Technische Felder verwenden App- oder Plugin-Präfixe.
- Custom Entities referenzieren Products, Customers oder Orders über interne IDs.
- Mitarbeitende nutzen Daten, für die es kein Standard-Administrationsmodul gibt.
- Ein externes System aktualisiert den Wert per API oder Webhook.
Vorbeugung
Erstellen Sie eine Verantwortungship-Map für jede Erweiterung. Erfassen Sie Entities, Parent-Referenzen, technische Felder, Konfiguration, externe IDs, Aktualisierungsrichtung und das fortbestehende Ziel. Historische Nachweis bleibt von Live Operational State getrennt.
Beispiel für die Empfehlung
Verfolgen Sie einen Subscription Datensatz, ein Marketplace Listing und einen ERP Product Identifier von der Extension Entity über den Core Shopware Datensatz bis zum externen Verantwortung.
Pass-Bedingung
Jeder beibehaltene Erweiterungsdatensatz besitzt eine definierte Ziel-Entity, gültige Parent-Referenzen, stabile externe Identifikatoren und eine fortbestehende Anwendung oder Integration, die ihn interpretieren und pflegen kann.
Fehler 10: Davon ausgehen, dass korrekte Product-Daten automatisch korrekte Suchergebnisse erzeugen
Was schiefgeht
Shopware-Suche und Indexierung können von searchable Product Felder, Product Numbers, Keywords, Properties, Manufacturers, Categories, Synonyms, Actions und erweiterungsspezifischer Indexkonfiguration abhängen. Importierte Products können vorhanden und aktiv sein, während die Suche sie auslässt oder schlecht rankt, weil indizierte Felder, Aliases oder Message-Queue-Verarbeitung unvollständig sind.
Frühe Warnsignale
| Warnsignal | Bedeutung |
|---|---|
| Products sind per direkter URL erreichbar, fehlen aber in der Suche. | Product Datensatz existiert, Suchindexierung oder Konfiguration ist unvollständig. |
| Product Numbers, EANs oder Custom Values sind nicht suchbar. | Erforderliche Suchfelder fehlen in der aktiven Suchkonfiguration. |
| Suchsynonyme und Forwarding Actions wurden nicht inventarisiert. | Merchandising-Verhalten folgt nicht der Absicht der Quelle. |
| Indexerstellung ist abgeschlossen, aber Aliases oder Queue Processing nicht. | Der erzeugte Index bedient noch nicht zwingend die Storefront-Anfragen. |
Vorbeugung
Bewahren Sie Suchbegriffe, Product-Sichtbarkeit, searchable Felder, Properties, Manufacturer-Daten, Synonyms, Actions und gegebenenfalls Advanced-Suchkonfiguration. Indexerstellung, Message-Queue-Verarbeitung, Alias-Erzeugung und fortlaufende Indexing-Verantwortung gehören in das Migrationsrunbook.
Beispiel für die Empfehlung
Prüfen Sie ein Product über Name, eines über Product Number, eines über Synonym und eines über eine Suchaktion. Verfolgen Sie die Fälle durch konfigurierte Suchfelder und Indizes.
Pass-Bedingung
Repräsentative Products erscheinen über vorgesehene Namen, Nummern, Properties, Manufacturers und Synonyms; Suchaktionen führen zu gültigen Zielen, und benötigte Indizes und Aliases bleiben aktuell.
Prävention über alle Fehlerbilder hinweg
Shopware-Fehlerprävention hängt davon ab, Product-Daten mit Vertriebskanälen, geerbten Varianten, Rule-Builder-Bedingungen, Shopping Experiences, sprachabhängigen Custom Fields, historischen Order States, Routen, Suche und Extension Verantwortungship verbunden zu halten. Ein korrekter Product Datensatz kann keinen fehlenden Kanal, keine fehlende Regel, kein fehlendes Layout und keinen fehlenden Index kompensieren.
| Präventionsebene | Erforderliche Kontrolle |
|---|---|
| Vertriebskanal-Verantwortungship | Products, Customers, Categories, Domains, Sprachen und Sichtbarkeit mit dem richtigen Kanal verbinden. |
| Vererbungskontrolle | Geerbte Parent-Werte von variantenbezogenen Overrides unterscheiden. |
| Rule Dependencies | Daten erhalten, die Rule-Builder-Bedingungen für Preis-, Promotion-, Payment- und Shipping-Verhalten verwenden. |
| Experience Assignment | Shopping Experiences mit richtigem Seitentyp, Entity, Route und Vertriebskanal verbinden. |
| Suchbereitstellung | durchsuchbare Felder, Synonyms, Indexing, Aliases und Queue Processing aufeinander abstimmen. |
Fazit
Shopware-Migrationen scheitern, wenn miteinander verbundene Plattformstrukturen zu isolierten Datensätze abgeflacht werden. Vertriebskanäle bestimmen Verfügbarkeit, Properties erzeugen Varianten, Rules steuern kommerzielles Verhalten, Shopping Experiences liefern Kontext und Erweiterungen können ganze Geschäftsbereiche besitzen.
Die sicherste Migration bewahrt jede dieser Beziehungen und belegt sie durch eine plattformspezifische Pass-Bedingung. Stimmen Products, Channels, Rules, Content, Orders, URLs, Suche und Erweiterungen überein, verhält sich der migrierte Store als kohärente Shopware-Umgebung statt als bloße Sammlung importierter Entities.
Häufige Fragen
Warum kann ein Product in Shopware existieren und für Customers trotzdem nicht verfügbar sein?
Es kann inaktiv, verborgen, aus dem relevanten Vertriebskanal ausgeschlossen, nicht im Kanalsortiment vertreten oder ohne den Sprach-, Währungs-, Domain- oder Sichtbarkeitskontext sein, den die Storefront benötigt.
Sind Shopware-Properties immer Product-Varianten?
Nein. Properties können Products beschreiben und filtern, ohne Varianten zu erzeugen. Nur ausgewählte Property Options, die von der Variantenerzeugung verwendet werden, definieren verkaufbare Kombinationen.
Warum müssen Rule-Builder-Bedingungen getrennt von resultierenden Preisen oder Rabatten migriert werden?
Der Wert gilt nur unter bestimmten Customer-, Kanal-, Währungs-, Mengen-, Warenkorb-, Zeit- oder Order-Bedingungen. Wird nur das Ergebnis kopiert, wirkt es zu breit oder gar nicht.
Können Shopping Experiences wie gewöhnliche CMS Pages migriert werden?
Nicht zuverlässig. Seitentyp, Sections, Blocks, Elements, Assignments, Vertriebskanal-Kontext, Links und Product-/Category-spezifische Overrides bestimmen, wo und wie das Layout funktioniert.
Wie sollten Shopware-Custom-Felder über mehrere Sprachen hinweg behandelt werden?
Bewahren Sie zuerst die Feld-Definition und den Wert der Standardsprache und übernehmen Sie anschließend beabsichtigte übersetzte Overrides. So bleibt die Vererbung für Templates, Regeln und Integrationen nutzbar.
Warum können korrekte Shopware-Products trotzdem in der Suche fehlen?
Suchergebnis hängt von Sichtbarkeit, searchable Felder, Keywords, Properties, Synonyms, Actions, Indexerstellung, Queue Processing, Aliases und Erweiterungskonfiguration ab. Korrekte Product Datensätze allein garantieren keine indexierte Auffindbarkeit.