Bei der Bewertung von Shopware als mögliche Zielplattform legt die Validierung fest, welche Nachweise zeigen müssen, dass Daten, Beziehungen und Geschäftsanforderungen im Ziel funktionieren.
Nach der Migration zu Shopware muss die Validierung beweisen, dass die übertragenen Datensätze das vorgesehene Vertriebskanal- und regelgesteuerte Commerce-Modell tatsächlich unterstützen. Ein Product kann vorhanden sein, während Varianten, Property-Werte, Vertriebskanal-Sichtbarkeit, Advanced Prices, Rule-Builder-Referenzen, Custom Fields oder die Zuordnung zu Shopping Experiences dennoch zu einem falschen Kaufergebnis führen. Ebenso können Customers oder Orders existieren, obwohl ihr Vertriebskanal-Kontext, Line-Item-Daten, State-Historie oder externe Identifier für Service und Reconciliation nicht mehr ausreichen.
Der Nachweis muss deshalb den Beziehungen folgen, die Shopware tatsächlich auswertet: Product zu Varianten und Properties, Product zu Vertriebskanal und Sichtbarkeit, Preis oder Promotion zu Rule-Builder-Bedingungen, Customer zu Vertriebskanal, Order zu Line Items und States, Content zu Shopping Experience oder Category sowie Custom Field zu der App, Erweiterung oder Integration, die den Wert verwendet.
Pass, Watch und Block für Shopware-Nachweis verwenden
- Pass: Repräsentative und Ausnahmefälle belegen das vorgesehene Shopware-Ergebnis.
- Watch: Das geschäftliche Ergebnis ist nutzbar, aber eine dokumentierte nicht blockierende Korrektur, Darstellungsaufgabe, Konfiguration oder akzeptierte Abweichung bleibt offen.
- Block: Das Problem beeinträchtigt Verkauf, Preisgestaltung, Product-Sichtbarkeit, Customer-Zugang, historische Orders, Content, SEO, Integrationskontinuität, Compliance oder den vereinbarten Migrationsumfang wesentlich.
| Nachweisbereich | Shopware-spezifischer Nachweis | Typischer Block |
|---|---|---|
| Product-Modell | Parent Products, Varianten, Properties, Preise, Medien, Bestand und Category-Zuordnungen unterstützen den Kauf. | Ein prioritäres Product lässt sich nicht korrekt auswählen oder kaufen. |
| Vertriebskanäle | Products, Customers, Domains, Währungen, Sprachen und Content erscheinen im vorgesehenen Kanal. | Ein wichtiger Kanal fehlt, enthält falsche Daten oder zeigt das falsche Sortiment. |
| Regeln und Preise | Rule-Builder-Referenzen, Advanced Prices, Promotions, Versand- und Zahlungskontexte lösen korrekt aus. | Ein wesentlicher Customer erhält den falschen Preis, Zugriff oder Checkout-Weg. |
| Customers und Orders | Identität, Kanalbezug, Line Items, Summen, States, Adressen und externe IDs bleiben verständlich. | Eine relevante historische Order kann nicht abgeglichen werden. |
| Content und SEO | Categories, Shopping Experiences, Medien, Routen, Metadaten und Redirects unterstützen Discovery. | Hochwertiger Content oder wichtige Routen funktionieren nicht. |
| Erweiterungen | Custom Fields, Apps, Plugins, vereinbarte Migrationsausgaben und nicht standardmäßige Deliverables funktionieren über ihren jeweiligen Verantwortung. | Ein für den Launch kritischer Ablauf verliert Daten oder notwendige Referenzen. |
Der Bericht sollte für jede Entscheidung den geprüften Vertriebskanal, die Customer Group, den Regelkontext, Product- oder Varianten-ID, Sprache, Währung und den relevanten externen Systemkontext festhalten. Ein Product kann in einer Storefront Pass und in einer anderen Block sein, wenn Sichtbarkeit, Währung, Customer-Bindung, Advanced Pricing oder Rule-Builder-Bedingungen abweichen.
Das Shopware-Modell mit repräsentativen Testfällen belegen
Repräsentative Prüfungen sollten Datensätze enthalten, die die wichtigen Shopware-Beziehungen sichtbar machen:
- einfache Products und Variantenfamilien mit mehreren Property Groups;
- Products mit ausgeschlossenen oder nicht verfügbaren Variantenkombinationen;
- Products mit unterschiedlichen Vertriebskanal-Zuordnungen und Sichtbarkeitsstufen;
- Advanced Prices mit Mengen- oder Rule-Builder-Bedingungen;
- Promotions, Versand- oder Zahlungslogik, die von Regeln abhängt;
- kanalgebundene Customers, sofern diese Funktion genutzt wird;
- Orders mit Rabatten, Steuern, Refunds, Deliveries oder Zustandswechseln;
- Categories und Shopping Experiences mit Medien und internen Links;
- Custom Fields, App Datensätze, Plugin-Daten und externe IDs.
Der Nachweis muss zeigen, dass Quellattribute korrekt als Shopware-Properties, Variantenoptionen, Custom Fields oder externe Datensätze interpretiert wurden. Würde sich ein Strukturfehler katalog- oder kanalweit wiederholen, ist er vor breiterer Migrationsausführung als Block zu behandeln.
Die Stichprobe braucht mindestens ein Product oder eine Order aus jedem kritischen Vertriebskanal und jedem wesentlichen Regelkontext. Ein einzelner Default-Store-Fall kann einen Multi-Channel-Shopware-Betrieb nicht freigeben.
Products, Varianten, Properties und Sichtbarkeit validieren
Shopware-Varianten entstehen aus ausgewählten Property-Werten. Parent Product, Variantenkombinationen, Product Numbers, Preise, Bestand, Medien, Lieferinformationen und Sichtbarkeit müssen zusammenpassen.
| Product-Nachweis | Pass | Watch | Block |
|---|---|---|---|
| Variantenstruktur | Vorgesehene Kombinationen existieren und bleiben mit dem richtigen Parent verbunden. | Geringfügige Reihenfolge- oder Benennungsarbeiten bleiben. | Varianten fehlen, sind doppelt oder entstehen aus falschen Properties. |
| Product Number und Bestand | Identität und Inventory gehören zur richtigen Variante. | Nicht kritische Bereinigung bleibt. | Fulfillment oder Integration würde den falschen Artikel verwenden. |
| Preis und Steuer | Product-/Variantenwerte ergeben das vorgesehene Storefront-Ergebnis. | Kontrollierte Rundung oder Darstellung muss noch verfeinert werden. | Ein wesentliches Product hat falschen Preis- oder Steuerkontext. |
| Medien | Parent- und Variantenmedien ermöglichen korrekte Auswahl. | Reihenfolge sekundärer Bilder bleibt. | Customers können eine benötigte Variante nicht unterscheiden. |
| Sichtbarkeit | Aktivstatus und Kanalsichtbarkeit zeigen Products nur dort, wo sie vorgesehen sind. | Kontrollierte Publication-Arbeit bleibt. | Eingeschränkte Products werden öffentlich oder gewünschte Products verschwinden. |
| Properties und Filter | Beschreibende und variantendefinierende Properties unterstützen Filter und Auswahl korrekt. | Niedrig priorisierte Filterbereinigung bleibt. | Eine wichtige Product-Familie ist nicht auffindbar oder konfigurierbar. |
Prüfen Sie Storefront, Administration, Warenkorb, Order Line und externe Systeme gemeinsam. Eine Variante, die optisch korrekt erscheint, aber falsche Product Number oder Bestandsidentität verwendet, darf nicht Pass erhalten.
Shopware kann Properties sowohl für Variantenerzeugung als auch für Product-Filter verwenden. Stellen Sie sicher, dass beschreibende Properties nicht unnötig zu Variantendimensionen wurden und echte Variantenwerte nicht zu Custom Fields abgeflacht wurden. Nehmen Sie ausgeschlossene, inaktive, medienabweichende und unterschiedlich bestückte Varianten in die Prüfung auf.
Vertriebskanäle, Domains, Sprachen und Customer-Umfang validieren
Vertriebskanäle können Storefronts, Headless APIs, Product-Comparison-Feeds, Social Channels oder andere Verkaufskontexte darstellen. Prüfen Sie Kanalzuordnung sowie Domain-, Sprach-, Währungs-, Customer-, Product-, Navigations- und Theme-Kontext.
Zu prüfen sind insbesondere:
- Product- und Category-Zuordnung zu jedem kritischen Vertriebskanal;
- Sichtbarkeitsstufe der Products innerhalb des Kanals;
- Domain- und Routenverhalten;
- Sprach- und Übersetzungswerte;
- Währung und Preisdarstellung;
- Category-Einstiegspunkte der Navigation;
- Customer-Bindung an Vertriebskanäle, wenn verwendet;
- Headless- oder Feed-Identifier, wenn relevant.
Vergeben Sie Block, wenn ein prioritäres Product oder ein Customer im falschen Kanal verfügbar, im vorgesehenen Kanal nicht verfügbar oder einer Route beziehungsweise Währung zugeordnet ist, die einen Kauf verhindert. Watch ist geeignet, wenn Daten korrekt sind und nur kontrollierte Theme-, Navigations- oder Merchandising-Arbeit offen bleibt.
Customer-Bindung benötigt eigene Nachweis. Wenn Customers an Vertriebskanäle gebunden sind, können identische E-Mail-Adressen unterschiedliche Accounts in verschiedenen Kanälen darstellen. Validieren Sie Identität und Order-Zuordnung im jeweiligen Kanal, statt Accounts ausschließlich anhand der E-Mail zusammenzuführen.
Rule Builder, Advanced Prices, Promotions sowie Versand- und Zahlungskontext validieren
Shopwares Rule Builder kann Advanced Prices, Promotions, Product-Sichtbarkeit, Versandmethoden, Zahlungsarten und weiteres kommerzielles Verhalten beeinflussen. Die Migration von Products und Customers rekonstruiert nicht automatisch jede Regel.
| Regelabhängige Nachweis | Erforderlicher Nachweis |
|---|---|
| Regelidentität | Die vorgesehene Regel existiert oder es gibt einen ausdrücklich benannten Verantwortliche Stelle für eine Zielersetzung. |
| Referenzierte Daten | Customer Groups, Vertriebskanäle, Währungen, Products, Tags, Custom Fields und weitere Referenzen lösen korrekt auf. |
| Advanced Price | Vorgesehener Customer, Menge, Product und Kanal ergeben den erwarteten Preis. |
| Promotion | Bedingungen und Ausschlüsse erzeugen den erwarteten Rabatt ohne unerwünschte Kombinationen. |
| Versand-/Zahlungsverfügbarkeit | Die Methode erscheint nur im richtigen kommerziellen Kontext. |
| Product-Sichtbarkeit | Regelgesteuerte Products werden wie vorgesehen ein- oder ausgeblendet. |
Eine kopierte Regeldefinition darf nicht Pass erhalten, wenn ihre Referenzen auf fehlende oder veränderte IDs zeigen. Prüfen Sie die Regel im Storefront-Kontext, der sie auswertet. Wesentliche Preis-, Zugriffs- oder Checkout-Fehler sind Block; klar dokumentierte Konfigurationsarbeit, die den Launch nicht verhindert, kann Watch sein.
Historische Order-Rabatte sowie Versand- und Zahlungsbezeichnungen sind Transaction-Nachweis. Sie beweisen nicht, dass aktuelle Rule-Builder-, Promotion-, Versand- oder Zahlungskonfiguration betriebsbereit ist. Erfassen Sie deshalb Bedingungen und die tatsächlich aufgelösten Referenzen einer Regel. Eine Regel kann syntaktisch gültig sein und fachlich dennoch auf das falsche Product, den falschen Kanal, die falsche Customer Group, Währung, Tag- oder Custom-Feld-Referenz zeigen.
Customers, Orders, States und historischen Kontext validieren
Customer-Validierung umfasst Identität, Adressen, Customer Groups, Vertriebskanal-Zuordnung, Sprache, Consent-Kontext, externe IDs und dublettenanfällige Accounts.
Für Orders müssen Customer- oder Gastidentität, Line Items, Varianten, Custom Fields, Preise, Rabatte, Steuern, Versandkosten, Payment- und Delivery-States, Order State, Dokumente, Refunds, Adressen und externe Referenzen geprüft werden, soweit sie zum vereinbarten Umfang gehören.
Vergeben Sie Block, wenn eine wesentliche Order Varianten- oder Custom-Line-Informationen verliert, Summen falsch sind, die Customer-Zuordnung unsicher ist, State-Historie unbrauchbar wird oder externe Reconciliation fehlschlägt. Watch eignet sich für kontrollierte kosmetische Abweichungen oder akzeptierte niedrig priorisierte Ausschlüsse.
Migrierte Orders beweisen nicht die Betriebsbereitschaft von Live Checkout, Rule Builder, Payment, Tax, Shipping, Warehouse, Fulfillment, Dokumentgenerierung, Notifications, Returns oder ERP-Export. Diese Funktionen brauchen eine eigene operative Freigabe. Beachten Sie außerdem, dass Shopware Order-, Transaction- und Delivery-States unterscheidet; ein einzelner Source-Status kann über mehrere Zielzustände interpretiert werden müssen.
Categories, Shopping Experiences, URLs und Content validieren
Shopware-Content kann Categories, Shopping Experiences, Product Layouts, Medien, SEO URLs, Metadaten, Navigation, Landingpages und App-eigenen Content umfassen. Prüfen Sie den Datensatz und seine Platzierungsbeziehung.
| Content-Nachweis | Validierungsfokus |
|---|---|
| Category Tree | Parent-Child-Hierarchie, Navigationsrolle, Product-Zuordnung und Vertriebskanal-Kontext. |
| Shopping Experience | Richtiges Layout, Content Blocks, Medien sowie referenzierte Products/Categories. |
| Product Layout | Vorgesehene Product-Seiten verwenden Layout und Daten korrekt. |
| SEO URL | Prioritäre Quellrouten erreichen im richtigen Domain- und Sprachkontext sinnvolle Ziele. |
| Medien | Dateien, Alt-Kontext, Beziehungen und gerenderte Verfügbarkeit stimmen. |
| Interne Links | Links führen auf die vorgesehenen Shopware-Routen statt auf veraltete Quellpfade. |
Block gilt für defekte prioritäre Routen, fehlende notwendige Policy-Inhalte oder Shopping Experiences, deren gebrochene Referenzen eine kritische Journey verhindern. Watch ist möglich, wenn nur kontrollierte Darstellungsarbeit offen bleibt und Content sowie Verantwortungship vollständig sind.
Ein Category-Datensatz beweist keine Navigation; ein Shopping-Experience-Datensatz beweist nicht, dass jeder Block im Ziel-Theme korrekt rendert. Der Abschlussbericht sollte daher unterscheiden, ob ein Finding zu migrierten Daten oder zur Zieldarstellung gehört. Berücksichtigen Sie außerdem wiederverwendbare Blocks und dynamische Product-Referenzen.
Custom Fields, Apps, Plugins, unterstützte Anpassungen und individuell angepasste Ergebnisse validieren
Shopware-Custom-Felder können strukturierte Werte oder Objektreferenzen an mehreren Bereichen tragen und in Templates, Cart-Daten, Store API oder Rule Builder verwendet werden. Apps und Plugins können Entities, Felder, Routes, Subscribers, Scheduled Tasks oder externe Integrationen hinzufügen.
Für jeden kritischen Wert dokumentieren Sie:
- besitzende Shopware Entity und Custom-Feld-Set;
- Datentyp oder referenziertes Objekt;
- konsumierende App, Plugin, Storefront, Rule-Builder-Regel, API oder externes System;
- stabilen Identifier;
- repräsentative Pass- und Ausnahme-Nachweis;
- Verantwortliche Stelle für noch offene Deployment- oder Konfigurationsarbeit.
Prüfen Sie vereinbarte unterstützte und individuell vereinbarte Ergebnisse genau gegen den dokumentierten Umfang. Ein transformiertes Feld oder eine Custom-Beziehung muss durch die tatsächliche App, API, Regel, Storefront-Template oder das externe System getestet werden, das den Wert nutzt.
Block gilt, wenn benutzerdefinierte Daten verwaist, Objektreferenzen falsch sind, eine Regel nicht auswerten kann oder ein externes System den Datensatz nicht identifiziert. Watch ist möglich, wenn App-/Plugin-Deployment außerhalb des Migrationsumfangs liegt, der migrierte Datenvertrag und die Referenzintegrität jedoch vollständig dokumentiert sind und ein Verantwortung feststeht.
Repräsentative Tests von Nachweise der breiteren Migrationsausführung unterscheiden
Repräsentative Tests beweisen ausgewählte strukturelle Annahmen. Die breitere Ausführung muss vollständiges Volumen, Kanalabdeckung, Beziehungen und Ausnahmen belegen.
Der breitere Prüfung sollte enthalten:
- alle wesentlichen Product- und Variantenmuster;
- vollständige Vertriebskanal-Zuordnung und Sichtbarkeit;
- Sprachen, Währungen, Domains und Customer-Bindung;
- Rule-Builder-Referenzen, Preise, Promotions, Versand- und Zahlungskontexte;
- Customers und Orders über State- und Ausnahmefälle hinweg;
- Categories, Shopping Experiences, Medien und URLs;
- alle unterstützten und individuell vereinbarte Ergebnisse;
- App-, Plugin-, Custom-Feld- und Ausnahmen bei externen IDs;
- Änderungen seit dem repräsentativen Migrationstest.
Öffnen Sie einen früheren Pass erneut, wenn breitere Ausführung fehlende Variantenkombinationen, inkonsistente Properties, Kanalzuordnungslücken, defekte Regelreferenzen, Customer-Dubletten, verwaiste Orders, Content-Referenzfehler oder nicht unterstützte Plugin-Daten zeigt. Segmentieren Sie Exceptions nach Vertriebskanal, Sprache, Product-Familie, Regelkontext, Customer Group, Quellzeitraum und Erweiterungsverantwortlichen; eine aggregierte Zahl kann einen vollständigen Fehler in einem einzelnen Kanal verdecken.
Nach späteren Migrationsaktionen erneut validieren
| Spätere Aktion | Shopware-Revalidierungsumfang |
|---|---|
| Unter akzeptierter Konfiguration fortsetzen | Neu berechtigte Datensätze prüfen und bestätigen, dass frühere Product-, Kanal-, Regel-, Customer-, Order-, Content- und Integrationsannahmen weiter gelten. |
| Unter geänderter Konfiguration fortsetzen | Jede durch geänderte Filter, Mappings, Datenkategorieauswahl oder Konfiguration betroffene Beziehung erneut prüfen, einschließlich früherer Freigaben. |
| Ein eigenständiges neues Migrationsergebnis erzeugen | Ergebnis als eigenständigen migrierten Stand behandeln und vollständige Shopware-Validierung samt Launch-Entscheidung wiederholen. |
Dokumentieren Sie alte und neue Entscheidung gemeinsam. Verändert eine Konfiguration Product-Identität, Vertriebskanal-Zuordnung oder Customer Matching, können auch bereits freigegebene Orders, Regeln und URLs erneut geprüft werden müssen. Revalidierung folgt den geänderten Referenzen: Ein neues Product Mapping kann Varianten, Dynamic Groups, Regeln, Shopping Experiences, URLs und historische Order Links betreffen; ein verändertes Customer Mapping kann Kanalbindung und Regelresultate verändern.
Shopware-Launch-Entscheidung aufbauen
Eine Launch-Freigabe erfordert:
- keinen ungelösten Block für Kauf, Vertriebskanal-Sichtbarkeit, Preisgestaltung, Customers, historische Orders, Content, SEO, Compliance oder Integrationen;
- abgeschlossene repräsentative Tests und Nachweise der breiteren Migrationsausführung;
- Nachweis vereinbarter unterstützter und individuell vereinbarte Ergebnisse;
- separate Freigabe für Live Rule Builder, Checkout, Payment, Tax, Shipping, Fulfillment, Dokumente, Returns und Extension Deployment;
- Revalidierung nach anwendbaren späteren Migrationsaktionen;
- benannte Verantwortung und Abschlussdaten für Watch-Punkte.
Führen Sie getrennte Status für Katalog-, Vertriebskanal-, Commercial-Rule-, historische Daten-, Content/SEO- und Integrations-Bereitschaft. Eine funktionierende Storefront darf keinen Block in Order- oder externes System-Abläufe verdecken. Dokumentieren Sie je Status freigebenden Verantwortung und Nachweisdatum, damit spätere Konfigurationsänderungen gezielt die richtige Entscheidung wieder öffnen.
Fazit
Shopware-Validierung muss belegen, dass Products, Varianten, Properties, Vertriebskanäle, Regeln, Customers, Orders, Content, Custom Fields und Erweiterungen im vorgesehenen Commerce-Kontext zusammenarbeiten.
Repräsentative Tests beweisen ausgewählte Beziehungen. Die breitere Migrationsausführung muss alle wesentlichen Vertriebskanäle, Regelkontexte, Product-Muster sowie Customer- und Order-Ausnahmen abdecken. Spätere Aktionen öffnen diejenigen Beziehungen wieder, die sie verändern. Launch-Freigabe folgt dokumentierter Pass-, Watch- und Block-Nachweis.
Häufige Fragen
Warum müssen Shopware-Vertriebskanäle separat validiert werden?
Products, Customers, Domains, Sprachen, Währungen, Navigation, Sichtbarkeit und Theme-Kontext können je Vertriebskanal abweichen. Ein Pass in einem Kanal genehmigt keinen anderen.
Wie sollten Shopware-Varianten validiert werden?
Prüfen Sie Parent Product, erzeugte Kombinationen, Property-Werte, Product Numbers, Preise, Bestand, Medien, Sichtbarkeit, Warenkorbergebnis und Order Line gemeinsam.
Beweisen migrierte Orders, dass Rule Builder und Checkout bereit sind?
Nein. Orders belegen historische Transaction-Lesbarkeit. Aktuelle Regeln, Promotions, Payments, Shipping, Tax, Dokumente und Fulfillment brauchen separate Konfiguration und operative Freigabe.
Wie sollten Rule-Builder-Referenzen freigegeben werden?
Testen Sie die Regel in dem Vertriebskanal- und Customer-Kontext, der sie auswertet, und bestätigen Sie, dass referenzierte Products, Groups, Währungen, Custom Fields und weitere Entities korrekt aufgelöst werden.
Was muss bei Custom Fields geprüft werden?
Bestätigen Sie besitzende Entity, Datentyp, referenziertes Objekt, Sprachverhalten, App- oder Regelkonsument, Store-API-Anforderung und gegebenenfalls externer Identifikator.
Was muss nach einer späteren Shopware-Migrationsaktion erneut validiert werden?
Prüfen Sie jeden neuen oder geänderten Shopware-Datensatz sowie jede dadurch betroffene Rule-Builder-, Vertriebskanal-, Preis-, State-, Content- oder Integrationsannahme erneut. Ein eigenständiges neues Migrationsergebnis benötigt eine eigene vollständige Launch-Entscheidung.