Wenn Shopware als mögliche Zielplattform in Betracht gezogen wird, beschreibt die Vorbereitung, welche Nachweise, Entscheidungen und Zielkonfigurationen vor der Migration geklärt werden müssen.
Wenn Shopware als Zielplattform ausgewählt wird, muss die Vorbereitung deutlich mehr leisten als einen vollständigen Datenexport. Sie muss nachvollziehbar machen, wie Quelldatensätze mit Vertriebskanälen, Products und Varianten, Properties, Custom Fields, Customers, Orders, Shopping Experiences, Regeln, Medien, URLs, Erweiterungen und externen Systemen zusammenhängen. Das ist besonders wichtig, weil dasselbe Product in mehreren Vertriebskanälen erscheinen kann, Varianten Werte vom Parent erben oder überschreiben können, Properties sowohl Filterung als auch Variantenerzeugung unterstützen und kommerzielles Verhalten von zugewiesenen Regeln abhängen kann.
Jede Vorbereitungsmaßnahme braucht eine verantwortliche Person oder Rolle, ein konkretes Nachweisdokument und eine eindeutige Bereitschaftsbedingung. Gleichzeitig muss die Vorbereitung Quellnachweis von der späteren Zielimplementierung trennen. Product-Beziehungen, historische Order-Zusammenhänge, bestehende URLs, externe Identifikatoren und erweiterungseigene Datensätze gehören zur Migrationsvorbereitung. Live-Zahlung, Versand, Steuerlogik, Abläufe, Theme-Verhalten und die operative Konfiguration der Vertriebskanäle bleiben dagegen Zielimplementierung und müssen in Shopware separat eingerichtet und geprüft werden.
Shopware-, Hosting-, Datenbank- und Dateizugänge absichern
Bestätigen Sie den Zugriff auf die Shopware Administration, Hosting- oder Cloud-Verwaltung, die Datenbank soweit verfügbar, Anwendungsdateien, Medienspeicher, geplante Tasks, Integrationszugänge und die Erweiterungsverwaltung. Dokumentieren Sie Shopware-Version, Bereitstellungsmodell, bei Self-Hosted-Installationen PHP- und Datenbankumgebung sowie aktive Vertriebskanäle, Sprachen, Währungen, Erweiterungen, Custom Code und verbundene Systeme.
| Vorbereitungsmaßnahme | Verantwortlich | Nachweis | Bereitschaftsbedingung |
|---|---|---|---|
| Administrativen Zugriff bestätigen | Shopware-Administration | Funktionierendes Konto und Rollenübersicht | Products, Customers, Orders, Regeln, Vertriebskanäle, Erweiterungen und Content können geprüft werden. |
| Wiederherstellbare Source-Backups erstellen | Infrastrukturverantwortung | Datenbankexport, Datei-/Medienarchiv, Konfigurationssicherung und benannte Restore-Verantwortung | Der Quell-Store kann unabhängig vom Live-System wiederhergestellt werden. |
| Technische Umgebung dokumentieren | Technische Verantwortung | Shopware-, PHP-, Datenbank-, Hosting-, Deployment- und Erweiterungsversionen | Versionsabhängige Datensätze und Anpassungen sind bekannt. |
| Custom Code und Erweiterungen erfassen | Entwicklung | Erweiterungsliste, eigene Plugins/Apps, geänderte Dateien, Custom Entities und Deployment-Hinweise | Jeder nicht zum Core gehörende Datensatz oder Ablauf hat eine verantwortliche Stelle. |
| Externe Systeme zuordnen | Integrationsverantwortliche | ERP-, PIM-, WMS-, CRM-, Marketplace-, Such-, Zahlungs- und Fulfillment-Identifikatoren | Fortbestehende Datenhoheiten und Synchronisationsschlüssel sind bekannt. |
Bewahren Sie interne Identifikatoren für Products, Varianten, Categories, Properties, Vertriebskanäle, Customers, Orders, Medien, Custom Fields und externe Systeme. Diese Schlüssel werden benötigt, wenn Datensätze zwischen Shopware-Entities abgeglichen oder Integrationen wieder verbunden werden müssen.
Vertriebskanäle, Domains, Sprachen und Customer-Umfang vorbereiten
Shopware-Vertriebskanäle können Storefronts, Headless-Kontexte, Product-Comparison-Feeds, Social Channels oder andere kundenseitige Endpunkte abbilden. Products, Categories, Domains, Sprachen, Währungen, Zahlungs- und Versandmethoden, Themes und Customer-Beziehungen können vom gewählten Vertriebskanal abhängen.
| Bereich | Vorzubereitender Nachweis | Bereitschaftsbedingung |
|---|---|---|
| Kanalinventar | Vertriebskanal-ID, Typ, Status, Domain, Sprache, Währung, Customer-Umfang und Verantwortliche | Jeder aktive kundenseitige Kontext ist genau einmal erfasst. |
| Product-Verfügbarkeit | Product-/Varianten-IDs, Sichtbarkeitsstufe, zugewiesene und ausgeschlossene Kanäle | Product-Umfang wird nicht aus der globalen Katalogpräsenz abgeleitet. |
| Domain- und Sprachkontext | Domain, Pfad, Locale, Währung, hreflang-Absicht und Fallback-Verhalten | Lokalisierte Datensätze sind dem richtigen öffentlichen Kontext zugeordnet. |
| Customer-Bindung | Registrierung, Customer-zu-Kanal-Beziehung, Fälle mit gleicher E-Mail und Account-Regel | Customer-Identitäten werden nicht ohne Beleg kanalübergreifend zusammengeführt. |
| Kanalspezifische Konfiguration | Verantwortliche für Zahlung, Versand, Steuern, Theme, Analytics und rechtliche Inhalte | Live-Konfiguration ist von migrierten Datennachweisen getrennt. |
Dokumentieren Sie, ob der Quell-Store mehrere Storefronts, Regionen, Marken, Sprachen, Wholesale-Pfade, Marketplaces oder Headless-Erlebnisse nutzt. Legen Sie fest, welche Kontexte getrennt bleiben und welche bewusst konsolidiert werden. Diese Entscheidung muss vor der Normalisierung von Katalog- und Customer-Nachweis vorliegen.
Products, Varianten, Properties und Custom Fields vorbereiten
Shopware-Products können Parent-/Variantenbeziehungen, Properties, Hersteller, Medien, Categories, Advanced Prices, Custom Fields, Lieferzeiten, Kaufmengen und Vertriebskanal-Sichtbarkeit verwenden. Properties können Storefront-Filter unterstützen und zugleich Werte zur Erzeugung von Varianten liefern; beschreibende Properties und variantendefinierende Properties sind deshalb nicht automatisch identisch.
| Katalogmuster | Vorzubereitender Nachweis | Bereitschaftsbedingung |
|---|---|---|
| Einfaches Product | Product-ID, Product Number, Preis, Bestand, Steuer, Hersteller, Category, Medien und Kanalsichtbarkeit | Das Product kann ohne verborgene Erweiterungsabhängigkeit interpretiert werden. |
| Variantenfamilie | Parent-ID, Varianten-IDs, Optionskombinationen, geerbte/überschriebene Werte, SKUs, Bestand, Preis, Gewicht und Bilder | Jede verkaufbare Variante ist dem richtigen Parent und den richtigen Optionswerten zugeordnet. |
| Filterbare Property | Property Group, Optionswerte, Product-Zuordnungen, Filternutzung und Übersetzungen | Beschreibende Discovery-Daten bleiben von kaufbarer Variantenidentität getrennt. |
| Custom Field | Feld Set, technischer Name, Typ, Entity-Zuordnung, Werte, Übersetzungen und konsumierender Prozess | Nutzung durch Mitarbeitende, Storefront, Regeln und Integrationen ist dokumentiert. |
| Multi-Channel-Product | Product-/Varianten-IDs, Kanäle, Visibility Levels, Main Category und kanalspezifischer SEO-Pfad | Kanalverfügbarkeit ist ausdrücklich dokumentiert. |
| Medienreiches Product | Haupt-/Galerie-Medien, variantenspezifische Bilder, Alt-Kontext, Sortierung und externer Speicher | Jedes Medium hat einen bekannten Product- oder Variantenbesitzer. |
Erfassen Sie inaktive, versteckte, ausgelaufene, nachbestellbare, Abverkaufs-, digitale, Bundle-ähnliche, Subscription-ähnliche oder von Erweiterungen erzeugte Products separat. Ungewöhnliche Product-Zustände dürfen nicht allein zur Vereinfachung in einen gewöhnlichen aktiven Zustand normalisiert werden.
Categories, Dynamic Product Groups und Shopping Experiences vorbereiten
Shopware-Categories können Navigation, Product-Zuordnung, Storefront-Einstiegspunkte und Content-Layouts tragen. Dynamic Product Groups können regelbasierte Product-Sets definieren. Shopping Experiences können Landingpages, Shop-Seiten, Category-Layouts, Sections, Blocks, Elements, Links und Medien enthalten. Diese Beziehungen benötigen getrennte Nachweis, auch wenn sie für Customers als eine zusammenhängende Journey erscheinen.
| Storefront-Struktur | Nachweis | Bereitschaftsbedingung |
|---|---|---|
| Category-Hierarchie | Category-IDs, Parents, Aktivstatus, Product-Zuordnungen, Vertriebskanäle, Übersetzungen und Main-Category-Nutzung | Kataloghierarchie und Kanalumfang sind vollständig. |
| Dynamic Product Group | Bedingungen, Product-Beispiele, Vertriebskanal-Zuordnung und Geschäftszweck | Regelgesteuertes Sortiment wird nicht als statischer Category-Export behandelt. |
| Shopping Experience | Layout-ID, Typ, zugewiesene Category/Landingpage, Sections, Blocks, Medien und verlinkte Products/Categories | Content-Verantwortung und Katalogreferenzen sind dokumentiert. |
| Navigationspfad | Vertriebskanal, Category Tree, Menüzweck, Zugriffskontext und prioritäre URLs | Navigation wird nicht allein aus Category-Datensätzen abgeleitet. |
| Interne Links | Quellseite, verlinkte Product-/Category-/Content-ID, Sprache und Zielabsicht | Links können neu geschrieben werden, ohne das referenzierte Geschäftsobjekt zu verlieren. |
Kennzeichnen Sie Layouts oder Content-Elemente, die durch Erweiterungen erzeugt wurden. Trennen Sie wiederverwendbaren Content von Theme-Darstellung und Product-Daten. Enthält eine Shopping Experience ein verlinktes Product, eine Category, ein Formular oder einen Erweiterungsblock, müssen sowohl das Layout als auch die verantwortliche Quelle dokumentiert werden.
Regeln, Preise, Promotions und kommerzielle Bedingungen vorbereiten
Shopware Rule Builder-Zuordnungen können Advanced Prices, Promotions, Versandkosten, Verfügbarkeit von Zahlungs- oder Versandmethoden, Flows, Product-Sichtbarkeit, Category-Sichtbarkeit und Content-Zugriff beeinflussen. Dokumentieren Sie die geschäftliche Bedingung und jede Stelle, an der eine Regel verwendet wird.
| Kommerzieller Bereich | Vorzubereitender Nachweis | Bereitschaftsbedingung |
|---|---|---|
| Regel | Rule-ID, Name, Bedingungen, Priorität, Status, referenzierte Customers/Groups/Channels und Zuweisungen | Geschäftszweck und alle betroffenen Bereiche sind bekannt. |
| Advanced Price | Product/Variante, Währung, Regel, Mengenbereich, Brutto-/Nettowerte, Listenpreis und Zeitkontext | Jeder Preis ist an die richtige kommerzielle Bedingung gebunden. |
| Promotion | Code, Regeln, Rabattumfang, Ausschlüsse, Nutzungslimits, Zeiträume und relevante historische Orders | Historische Rabatt-Nachweis ist von künftiger Promotion-Konfiguration getrennt. |
| Versand-/Zahlungsbedingung | Zugewiesene Regel, Vertriebskanal, Customer-Kontext, Region, Warenkorbschwelle und Ausnahmen | Bedingung ist dokumentiert, ohne sie als migrierte Order-Daten zu behandeln. |
| Bestand und Lieferung | Product-/Variantenmenge, externer Verantwortung, ggf. Lagerkontext, Lieferzeit und Backorder-Status | Autoritative Bestandsquelle und Schlüssel der verkaufbaren Einheit sind bekannt. |
Historische Order-Gesamtsummen bleiben Momentaufnahmen. Alte Preise, Rabatte, Steuern oder Versandkosten dürfen nicht anhand heutiger Rule-Builder-Zuordnungen neu berechnet werden.
Customers, Adressen, Orders und historische Zustände vorbereiten
Zur Customer-Vorbereitung gehören Account-Identität, Vertriebskanal-Beziehung, Customer Groups, Adressen, Sprache, Unternehmens- oder Steuerinformationen, Consent-Nachweis, externe IDs und Authentifizierungsabhängigkeiten. Für Orders müssen historische Product-Lines, Variantenwahl, Adressen, Summen, State-Machine-Historie, Transactions, Deliveries, Dokumente, Refunds und Integrationsreferenzen erhalten bleiben.
| Datensatzbereich | Verantwortlich | Nachweis | Bereitschaftsbedingung |
|---|---|---|---|
| Customer-Identität | Customer-Data-Verantwortung | Customer-ID, E-Mail, Vertriebskanal, Gruppe, Sprache, Status, Adressen und externe ID | Dubletten und kanalgebundene Identitäten werden bewusst behandelt. |
| Authentifizierung | Security | Passwortschema, SSO/Social Login, Reset-Pfad, MFA und Account-Kommunikation | Account-Zugang ist geplant, ohne Passwortportabilität vorauszusetzen. |
| Order-Lines | Order-Data-Verantwortung | Product-/Varianten-IDs, Snapshot-Bezeichnungen, Mengen, Preise, Promotions, Steuern und Custom Payloads | Gekaufte Artikel bleiben verständlich, auch wenn sich der Katalog später ändert. |
| Order-State | Operations | Order-, Transaction- und Delivery-States mit Zeitstempeln und geschäftlicher Bedeutung | State-Historie kann interpretiert werden, ohne Quellablauf neu aufzubauen. |
| Dokumente und Referenzen | Finance/Integration | Invoice-, Credit-Note-, Transaction-, Shipment-, Marketplace-, ERP- und Fulfillment-IDs | Historische Reconciliation-Schlüssel bleiben nachvollziehbar. |
Wählen Sie Gast-, registrierte, kanalgebundene, rabattierte, erstattete, teilweise gelieferte und von Erweiterungen betroffene Orders. Gerade diese Fälle legen Beziehungen offen, die gewöhnliche abgeschlossene Orders nicht zeigen.
Erweiterungen, Custom Entities und Integrationen inventarisieren
Erstellen Sie ein Verantwortungship-Ledger für jedes Plugin, jede App, Custom Entity, jedes Custom-Feld-Set, jede Flow-Builder-Aktion, Sucherweiterung, Zahlungs- oder Versandintegration, ERP/PIM/WMS-Anbindung, Marketplace-Feed, Theme-Erweiterung und jeden geplanten Prozess, der Geschäftsdaten liest oder schreibt.
| Abhängigkeit | Vorzubereitender Nachweis | Bereitschaftsbedingung |
|---|---|---|
| Erweiterung | Name, Version, Status, Zweck, Konfigurationsowner, Entities, Tabellen, Custom Fields und betroffene Datensätze | Erweiterungseigene Daten haben ein Ziel oder verbleiben bei einem benannten System. |
| Custom Entity oder Feld | Schema, Entity-Zuordnung, Beziehungen, Übersetzungen und konsumierender Code | benutzerdefinierte Daten kann unabhängig von der Quellimplementierung interpretiert werden. |
| Externes System | Endpoint, Datenhoheit je Entity, Synchronisationsrichtung, IDs und Cutover-Verantwortung | Migration erzeugt keine konkurrierenden Systems of Datensatz. |
| Flow oder Webhook | Trigger, Bedingung, Aktion, Payload, Ziel und Fehlerverantwortung | Operative Automation ist von statisch migrierten Datensätzen getrennt. |
| Generierte Daten | Indizes, Caches, Logs, Sessions, Queue Datensätze und verwaiste Erweiterungstabellen | Nicht autoritative technische Daten werden bewusst ausgeschlossen. |
Auch inaktive Erweiterungen gehören ins Ledger, wenn ihre historischen Daten noch in Products, Customers, Orders, Dokumenten oder externen Abstimmungen vorkommen.
Prioritäre URLs, SEO-Nachweis und Redirect-Entscheidungen vorbereiten
Erfassen Sie prioritäre Product-, Category-, Landingpage-, Shop-Page- und Content-URLs je Vertriebskanal und Sprache. Berücksichtigen Sie kanonisches Verhalten für Varianten, Main-Category-Beziehungen, Metadaten, interne Links, Backlinks, Kampagnenpfade sowie SEO-URL-Templates oder Redirect-Erweiterungen.
| URL-Nachweis | Verantwortlich | Bereitschaftsbedingung |
|---|---|---|
| Product- und Variantenpfade | SEO/Katalog | Jedes prioritäre Product hat einen kanalbezogenen Quellpfad und ein vorgesehenes Ziel. |
| Category- und Landingpage-Pfade | Content | Category-Hierarchie, Shopping Experience und Routenabsicht sind verbunden. |
| Mehrsprachige Pfade | Localization | Sprache und Vertriebskanal-Kontext bleiben erhalten. |
| Redirect-Inventar | SEO | Jeder hochwertige alte Pfad hat eine Keep-, Change-, Merge-, Retire- oder Redirect-Entscheidung. |
| Interne Links | Content | Quellreferenzen können auf die vorgesehenen Zielobjekte umgeschrieben werden. |
Verlassen Sie sich nicht nur auf eine Sitemap. Ziehen Sie Analytics, Suchdaten, Backlinks, Kampagnen, Customer-Kommunikation und hochwertige interne Navigation heran.
Repräsentative Migrationstestfälle auswählen
Wählen Sie Beispiele, die die tatsächliche Store-Architektur abbilden. Halten Sie Quell-IDs, Product Numbers, URLs, Vertriebskanäle, Property-Werte, Regeln, Customer-Beziehungen, Order-Referenzen und den Auswahlgrund fest.
| Testfall | Vorzubereitende Nachweis | Zweck |
|---|---|---|
| Variantenfamilie | Parent, Varianten, Optionen, Vererbung, Bestand, Preise, Bilder und Kanäle | Bildet Shopwares Product-/Variantenmodell ab. |
| Property-reiches Product | Property Groups, Filterwerte, Custom Fields, Category und Suchnutzung | Prüft Discovery und Feld Verantwortungship. |
| Regelabhängiger Fall | Regel, zugeordneter Preis/Promotion/Versand/Zahlung und betroffene Datensätze | Prüft bedingungsabhängiges Commerce-Verhalten. |
| Multi-Channel-Customer | Customer, Registrierungskanal, Gruppen, Adressen und Dubletten-Kontext | Prüft kanalgebundene Identität. |
| Komplexe Order | Variantenpositionen, Promotions, States, Transaction, Delivery, Dokument und externe IDs | Prüft historische Commerce-Nachweis. |
| Shopping Experience | Layout, Category-/Landing-Zuordnung, Medien, Links und Erweiterungsblöcke | Prüft Content-Commerce-Beziehungen. |
| Erweiterungseigener Datensatz | Core Entity, Erweiterungsschema, Custom Fields und Integrationsschlüssel | Deckt Non-Core-Umfang vor der Ausführung auf. |
Das Shopware-Testpaket ist bereit, wenn jeder ausgewählte Datensatz Quellnachweis, Vertriebskanal- und Regelkontext, zugehörige Dateien sowie eine benannte Prüfrolle besitzt.
Abschließendes Shopware-Bereitschafts-Gate durchführen
| Bereitschaftsbereich | Bereitschaftsbedingung |
|---|---|
| Zugriff und Wiederherstellung | Administration, Hosting, ggf. Datenbank/Dateien, Medien, Credentials, Backups und Restore-Verantwortung sind bestätigt. |
| Vertriebskanäle | Domains, Sprachen, Währungen, Customer-Umfang, Product-Sichtbarkeit und Verantwortliche sind dokumentiert. |
| Katalog | Products, Varianten, Properties, Categories, Medien, Preise, Bestand, Custom Fields und IDs sind nachvollziehbar. |
| Commerce-Historie | Customers, Adressen, Orders, States, Deliveries, Transactions, Dokumente und externe Referenzen haben Quellnachweis. |
| Content und URLs | Shopping Experiences, Navigation, prioritäre Pfade, Metadaten, interne Links und Redirect-Entscheidungen sind dokumentiert. |
| Abhängigkeiten | Regeln, Erweiterungen, Custom Entities, Flows, Webhooks und externe Systeme haben benannte Verantwortung. |
| Testfälle | Repräsentative Datensätze decken jedes wesentliche Product-, Kanal-, Customer-, Order-, Content-, Regel- und Erweiterungsmuster ab. |
Der Shopware-Umfang ist bereit, wenn jeder wesentliche Datensatz auf Quellverantwortung, zugehörige Datensätze, Nachweisartefakt und vorgesehenes Ziel beziehungsweise verbleibendes System zurückgeführt werden kann.
Fazit
Die Vorbereitung einer Migration zu Shopware verlangt abgestimmte Nachweis für Vertriebskanäle, Products und Varianten, Properties, Custom Fields, Categories, Shopping Experiences, Regeln, Customers, Orders, Erweiterungen, URLs und Integrationen. Die Checkliste macht diese Beziehungen vor der Ausführung explizit, statt sich auf Datensatzmengen oder generische Exporte zu verlassen.
Ein vollständiges Bereitschaftspaket bewahrt wiederherstellbare Quellnachweis, definiert autoritative Datensätze, trennt historische Transactions von Live-Konfiguration und weist jeder wesentlichen Abhängigkeit eine verantwortliche Stelle zu.
Häufige Fragen
Was sollte für eine Shopware-Migration zuerst vorbereitet werden?
Bestätigen Sie Administration- und Infrastrukturzugänge, erstellen Sie wiederherstellbare Backups, dokumentieren Sie Shopware- und Erweiterungsumgebung und identifizieren Sie jeden aktiven Vertriebskanal. Detaillierte Katalogarbeit sollte erst beginnen, wenn das Team den Quell-Store zuverlässig prüfen und wiederherstellen kann.
Warum muss der Vertriebskanal-Umfang separat dokumentiert werden?
Products, Customers, Domains, Sprachen, Währungen, Sichtbarkeit, Content und kommerzielle Konfiguration können vom Vertriebskanal abhängen. Globale Datensatzpräsenz beweist nicht, dass der richtige kundenseitige Kontext erhalten bleibt.
Wie sollten Shopware-Properties und Varianten vorbereitet werden?
Dokumentieren Sie Property Groups, Werte, Product-Zuordnungen, Filternutzung und die Optionskombinationen, aus denen Varianten entstehen. Erfassen Sie geerbte und überschriebene Werte je verkaufbarer Variante, damit beschreibende Properties nicht mit Variantenidentität verwechselt werden.
Für welche Regeln wird Vorbereitungsnachweise benötigt?
Erfassen Sie Regeln für Preise, Promotions, Versand, Zahlung, Flows, Product- oder Category-Sichtbarkeit und Content-Zugriff. Dokumentieren Sie Bedingungen, Priorität, referenzierte Entities und jede betroffene Zuweisung.
Welche Shopware-Orders sollten als repräsentative Testfälle ausgewählt werden?
Berücksichtigen Sie Gast- und registrierte Customers, kanalgebundene Accounts, Varianten, Promotions, Refunds, Teillieferungen, mehrere Zustandswechsel, Dokumente, Transactions und externe Integrationsreferenzen.
Was gehört in das Shopware-Erweiterungsledger?
Erfassen Sie jede Erweiterung, Custom Entity, jedes Custom-Feld-Set, jeden Flow, Webhook, jede Theme-Abhängigkeit und jeden externen Connector, der Geschäftsdaten erzeugt oder verwendet. Jeder Eintrag braucht Verantwortung, betroffene Datensätze, Quellnachweis und eine Entscheidung über Ziel oder verbleibendes System.