Shopware 5 auf Shopware 6 migrieren, ohne den alten Shop nachzubauen.

Eine Shopware-Migration wird häufig zunächst als technisches Upgrade verstanden: Produkte, Kunden und Bestellungen werden übertragen, das bestehende Design wird nachgebaut und für die verwendeten Plugins werden möglichst ähnliche Erweiterungen gesucht. Das wirkt risikoarm, weil das neue System am Ende möglichst genau so funktionieren soll wie das alte.

Genau darin liegt jedoch ein erhebliches Risiko. Ein über viele Jahre gewachsener Shop enthält nicht nur bewährte Geschäftslogik, sondern auch historische Umwege, inzwischen überflüssige Funktionen, doppelte Verantwortlichkeiten und technische Entscheidungen, die nur unter den damaligen Bedingungen sinnvoll waren. Wer all das eins zu eins überträgt, erhält zwar eine modernere technische Basis – aber häufig weiterhin ein altes Systemmodell.

Eine gute Migration trennt deshalb bewusst zwischen erhaltenswerter fachlicher Substanz und mitgeschleppter technischer Vergangenheit.

Eine Migration ist zuerst eine Produktentscheidung

Vor der technischen Planung sollte geklärt werden, welche Aufgabe der Shop heute und in den kommenden Jahren erfüllen soll. Das ist nicht automatisch dieselbe Aufgabe, für die das Shopware-5-System ursprünglich gebaut wurde.

Typische Veränderungen sind:

• aus einem B2C-Shop ist ein kombiniertes B2B-/B2C-System geworden,
• Produktdaten werden heute zentral in einem PIM gepflegt,
• Preise stammen inzwischen aus einem ERP,
• weitere Länder, Sprachen oder Vertriebskanäle sind hinzugekommen,
• das Kundenkonto soll mehr Self-Service-Funktionen übernehmen,
• Marketing, Content und Commerce sollen enger zusammenarbeiten,
• bisher manuelle Prozesse sollen automatisiert werden,
• der Shop soll nicht mehr führendes System für Informationen sein, die anderswo gepflegt werden.

Damit ändert sich die richtige Zielarchitektur. Die zentrale Frage lautet nicht:

Sondern:

Nicht mit der Pluginliste beginnen

Eine lange Liste installierter Plugins ist kein belastbares Anforderungsdokument. Ein Plugin kann eine wichtige geschäftliche Funktion erfüllen. Es kann aber ebenso ein Problem kompensieren, das im neuen System anders oder gar nicht mehr existiert.

Deshalb sollte jede Erweiterung zunächst in eine fachliche Fähigkeit übersetzt werden.

Beispiele:

Erst nach dieser Übersetzung wird entschieden, ob Shopware 6 die Fähigkeit bereits abdeckt, eine Standarderweiterung sinnvoll ist, eine individuelle Implementierung benötigt wird oder der Prozess künftig vollständig anders gelöst werden sollte.

Fachlogik von technischer Umsetzung trennen

In älteren Systemen ist Geschäftslogik häufig an Stellen verteilt, an denen sie schwer erkennbar ist:

• Plugin-Konfigurationen,
• Template-Anpassungen,
• Datenbankfelder,
• Importskripte,
• ERP-Schnittstellen,
• manuelle Workarounds,
• Wissen einzelner Mitarbeiter.

Eine Migration muss diese Logik zunächst sichtbar machen. Dabei geht es nicht darum, jede Zeile Code des alten Systems zu verstehen. Entscheidend ist, welche fachlichen Regeln der Betrieb tatsächlich voraussetzt.

Zum Beispiel:

• Wann darf ein Produkt verkauft werden?
• Welche Preise sieht ein bestimmter Kunde?
• Welche Bestellungen benötigen eine Freigabe?
• Welche Daten dürfen Händler sehen?
• Wann wird Bestand reserviert?
• Welche Dokumente gehören zu welchem Produkt?
• Welche Informationen müssen in das ERP zurückfließen?

Diese Regeln werden anschließend bewusst einer Zielkomponente zugeordnet. Preislogik kann im ERP verbleiben, Produktstammdaten im PIM, Content in Shopware und eine komplexe Freigabelogik in einem eigenen Service. Das neue System wird dadurch nicht zwingend kleiner, aber klarer.

Das Zielbild braucht definierte Verantwortlichkeiten

Eine Migration scheitert selten daran, dass Daten technisch nicht übertragen werden können. Schwieriger ist die Frage, welches System nach der Migration für welche Information verantwortlich ist.

Für zentrale Entitäten sollte deshalb eine Verantwortungsmatrix entstehen:

Ohne diese Klarheit wird das neue System schnell von Rücküberschreibungen, Kreissynchronisationen und unklaren Zuständen geprägt.

Ein erster vertikaler Durchstich statt vollständiger Vorabkopie

Eine belastbare Migration sollte möglichst früh einen kleinen, aber vollständigen Commerce-Prozess abbilden.

Beispielsweise:

1. 1Ein echtes Produkt wird aus der künftigen Datenquelle übernommen.
2. 2Es erscheint mit Varianten, Preis, Bestand und Medien im neuen Shop.
3. 3Ein realer Kundentyp kann es bestellen.
4. 4Zahlung, Versand und Steuerlogik funktionieren.
5. 5Die Bestellung gelangt in das ERP.
6. 6Statusänderungen fließen zurück.
7. 7Der Kunde sieht den Vorgang in seinem Konto.

Dieser Durchstich zeigt früh, ob Datenmodell, Schnittstellen, Shopkonfiguration und Betriebsprozesse zusammenpassen. Er ist wertvoller als eine große Zahl isoliert fertiggestellter Seiten oder importierter Datensätze.

Bewährte Logik darf bleiben – aber bewusst

Modernisierung bedeutet nicht, jede individuelle Funktion abzuschaffen. Manche Sonderlogik ist ein echter Wettbewerbsvorteil oder bildet einen unverzichtbaren Geschäftsprozess ab.

Der Unterschied liegt darin, dass sie nicht ungeprüft portiert wird. Sie wird fachlich beschrieben, gegen das Zielbild bewertet und anschließend bewusst neu umgesetzt.

Ein guter Entscheidungsrahmen ist:

• Beibehalten: Die Funktion ist fachlich notwendig und im neuen System sinnvoll abbildbar.
• Vereinfachen: Das Ziel bleibt, aber der Prozess kann deutlich reduziert werden.
• Ersetzen: Eine native oder standardisierte Funktion erfüllt die Aufgabe besser.
• Verlagern: Die Verantwortung gehört künftig in ERP, PIM, CRM oder einen Service.
• Abschalten: Die Funktion wird nicht mehr genutzt oder erzeugt mehr Komplexität als Nutzen.

Datenmigration und Prozessmigration sind zwei unterschiedliche Aufgaben

Produkte, Kunden, Bestellungen und Medien zu übertragen ist nur ein Teil der Migration. Ebenso wichtig ist die Überführung der operativen Abläufe.

Dazu gehören:

• Wer pflegt künftig welche Daten?
• Wie werden Fehler in Importen sichtbar?
• Wie erfolgt die Freigabe neuer Produkte?
• Welche Mitarbeiter bearbeiten Bestellungen?
• Welche Reports oder Exporte werden weiterhin benötigt?
• Was passiert bei Ausfällen eines Quellsystems?
• Wie werden Supportfälle nach dem Go-live analysiert?

Ein Shop kann technisch live sein und organisatorisch trotzdem nicht betriebsfähig. Deshalb gehören Schulung, Monitoring, Fehlerprozesse und klare Verantwortlichkeiten in denselben Migrationsplan wie Code und Daten.

Der Go-live ist der Beginn der Stabilisierung

Auch eine sorgfältig vorbereitete Migration trifft im Echtbetrieb auf Konstellationen, die in Testdaten nicht vollständig sichtbar waren. Alte Kundenkonten enthalten Sonderfälle, Zahlungsarten verhalten sich anders, Suchbegriffe zeigen Lücken im Produktmodell oder einzelne ERP-Zustände wurden nicht berücksichtigt.

Für die Zeit nach dem Go-live sollten deshalb vorgesehen werden:

• engmaschiges technisches und fachliches Monitoring,
• priorisierte Fehlerkanäle,
• tägliche Prüfung zentraler Commerce-Kennzahlen,
• Vergleich von Bestellungen zwischen Shop und ERP,
• Beobachtung von Suchanfragen und Nulltreffern,
• schnelles Nachziehen fehlender Weiterleitungen,
• klarer Umgang mit noch benötigten Altdaten.

Eine Migration ist erfolgreich, wenn der neue Shop nicht nur startet, sondern als neues operatives System stabil übernommen wird.