Bei einer Migration von Shopware 5 auf 6 reden alle zuerst über die Daten. Artikel, Kunden, Bestellungen, Kategorien: Das ist der sichtbare Teil, dafür gibt es Werkzeuge, und in den meisten Projekten ist es der kleinere Aufwand.
Der größere Aufwand steckt in den Plugins, und zwar aus einem strukturellen Grund: Shopware 6 ist keine neue Version von Shopware 5, sondern eine andere Anwendung. Kein Plugin für 5 läuft in 6. Nicht „mit Anpassungen", sondern gar nicht.
Damit ist jedes installierte Plugin eine eigene Entscheidung, und die Summe dieser Entscheidungen bestimmt, ob die Migration drei Monate oder ein Jahr dauert. Dieser Artikel beschreibt, wie man sie trifft, bevor jemand eine Zahl nennt.
Die Bestandsaufnahme: drei Listen, nicht eine
Die Frage „welche Plugins habt ihr" wird meist mit einem Blick in die Verwaltung beantwortet. Das liefert eine Liste, die zu lang ist, weil sie Installiertes mit Benutztem vermischt. Drei Listen sind nötig, und sie unterscheiden sich stärker als erwartet.
Installiert. Alles, was im Shop liegt. Enthält regelmäßig Plugins, die vor Jahren einmal getestet wurden.
Aktiv. Die Teilmenge, die eingeschaltet ist. In der Datenbank direkt ablesbar, und schon dieser Vergleich halbiert die Liste oft.
-- Shopware 5: installiert und aktiv, mit Herkunft
SELECT name, label, version, active, installation_date, source
FROM s_core_plugins
WHERE source IS NOT NULL
ORDER BY active DESC, source, name;Wirksam. Die Teilmenge, die tatsächlich etwas tut. Ein aktives Plugin, dessen Funktion niemand benutzt, ist bei der Migration ein Kandidat für die Streichung, und diese Liste steht nirgends. Sie entsteht aus drei Quellen: den Abfrageprotokollen für Plugins mit eigenen Tabellen, dem Webserver-Protokoll für Plugins mit eigenen Seiten, und einem Gespräch mit dem Shopbetreuer für den Rest.
Der Ertrag dieser Trennung ist erheblich. In den Projekten, die ich gesehen habe, war die Liste der wirksamen Plugins regelmäßig halb so lang wie die der installierten. Jeder gestrichene Eintrag ist Aufwand, der nicht anfällt.
Vier Kategorien, vier Antworten
Was übrig bleibt, sortiert sich in vier Gruppen. Die Einordnung ist die eigentliche Arbeit der Bestandsaufnahme, und sie braucht je Plugin fünf bis zwanzig Minuten.
Erstens: Es gibt eine Fassung für Shopware 6. Der Anbieter hat das Plugin portiert. Das ist der beste Fall und trotzdem nicht kostenlos: Die Fassung für 6 hat oft einen anderen Funktionsumfang, andere Einstellungen und eine andere Oberfläche. Aufwand liegt in der Konfiguration und im Test, nicht in der Entwicklung.
Zweitens: Die Funktion ist in Shopware 6 eingebaut. Ein erheblicher Teil dessen, wofür man in 5 ein Plugin brauchte, gehört in 6 zum Kern. Das ist die angenehmste Kategorie, weil der Aufwand negativ ist: eine Abhängigkeit weniger. Die Prüfung ist trotzdem nötig, weil „eingebaut" nicht „identisch" heißt.
Drittens: Es gibt einen anderen Anbieter. Die Funktion existiert, von jemand anderem. Hier entscheidet nicht die Funktionsliste, sondern die Frage, was mit den Daten des alten Plugins passiert. Ein Plugin für Produktbewertungen hat Bewertungen gespeichert, und die will niemand verlieren.
Viertens: Es gibt nichts. Das ist der teure Fall, und er trifft fast immer die Eigenentwicklungen und die Anpassungen für genau diesen Shop. Jedes dieser Plugins ist ein eigenes kleines Vorhaben, und die Summe dieser Vorhaben ist die Laufzeit der Migration.
Für die Planung ist wichtig, dass die vierte Kategorie zuerst geklärt wird. Sie bestimmt den Umfang, und sie ist die einzige, bei der eine Schätzung überhaupt schwierig ist.
Der Eigenbau: was davon wirklich Geschäftslogik ist
Bei Eigenentwicklungen lohnt eine zweite Frage, bevor jemand sie nachbaut: Muss das überhaupt ein Plugin sein?
In gewachsenen Shops steckt in den eigenen Plugins regelmäßig Logik, die dort nur gelandet ist, weil das in Shopware 5 der einzige Ort war, an dem man Code unterbringen konnte. Drei Muster tauchen immer wieder auf.
Eine Anbindung an ein anderes System. Ein Plugin, das nachts Bestellungen an das Warenwirtschaftssystem übergibt. Das ist keine Shopfunktion, sondern eine Schnittstelle, und sie ist außerhalb des Shops besser aufgehoben: als eigener kleiner Dienst, der über die Schnittstelle von Shopware 6 liest und schreibt. Damit überlebt sie die nächste Migration.
Eine Preis- oder Rabattregel. Oft die eigentliche Geschäftslogik des Hauses, versteckt in einem Plugin. Hier lohnt die Prüfung, ob Shopware 6 das mit seinen eigenen Mitteln abbilden kann. Häufig ja, und dann ist die Antwort Konfiguration statt Code.
Eine Darstellungsanpassung. Ein Plugin, das eine Seite anders aussehen lässt. Das gehört in 6 in das Theme, nicht in ein Plugin, und der Umbau ist meist kleiner als die Portierung.
Diese Sortierung ist der Punkt, an dem eine Migration zu einer Aufräumaktion wird: Was als Plugin nachgebaut werden müsste, ist am Ende oft ein Drittel dessen, was installiert war.
Das Theme ist der unterschätzte Posten
In fast jedem Angebot steht das Theme als eine Zeile, und in fast jedem Projekt ist es einer der größten Einzelposten.
Der Grund ist derselbe wie bei den Plugins: Shopware 6 hat eine andere Vorlagensprache, ein anderes Theme-System und eine andere Art, Oberflächenbestandteile zu bauen. Ein Theme aus 5 wird nicht portiert, es wird neu gebaut.
Was die Größenordnung bestimmt, ist nicht das Aussehen, sondern die Zahl der Abweichungen vom Standard. Die lässt sich vor der Migration zählen, und die Zahl ist meist überraschend:
# Shopware 5: wie viele Standard-Vorlagen sind ueberschrieben?
find themes/Frontend/*/frontend -name "*.tpl" | wc -l
# Und welche davon weichen wirklich ab, statt nur zu existieren?
for f in $(find themes/Frontend/*/frontend -name "*.tpl"); do
orig="engine/Shopware/Themes/Frontend/Bare/${f#*frontend/}"
[ -f "$orig" ] && ! diff -q "$f" "$orig" >/dev/null && echo "$f"
done | wc -lZwanzig überschriebene Vorlagen sind ein überschaubares Theme. Zweihundert sind ein eigenes Projekt, und dann ist die ehrliche Frage, ob der neue Shop dieselben zweihundert Abweichungen wirklich braucht oder ob ein Teil davon Geschichte ist.
Was so ein Vorhaben insgesamt kostet und welche Posten im ersten Angebot fehlen, steht in Was eine Modernisierung kostet.
Die Reihenfolge: Plugins vor Daten
Aus der Bestandsaufnahme ergibt sich eine Reihenfolge, die dem üblichen Vorgehen widerspricht und die Projektlaufzeit deutlich beeinflusst.
- Die drei Listen erstellen und die vierte Kategorie klären. Eine Woche, und danach ist der Umfang bekannt statt geschätzt.
- Das Theme entscheiden. Neu aufsetzen auf Standardbasis oder die Abweichungen nachbauen. Das ist eine Entscheidung, keine Aufgabe, und sie gehört vor die Umsetzung.
- Die fehlenden Plugins bauen, auf einem leeren Shopware 6 mit Beispieldaten. Ohne echte Daten, weil die noch nicht gebraucht werden.
- Erst dann die Daten migrieren. Die Werkzeuge dafür sind ausgereift, der Lauf ist wiederholbar, und er wird auch mehrfach laufen.
- Parallelbetrieb und Umschaltung.
Der vierte Punkt ist der, der überrascht. Datenmigration wird in Angeboten oft als erste und größte Position geführt. Sie ist wiederholbar und deshalb ungefährlich: Ein Lauf, der nicht stimmt, wird korrigiert und wiederholt. Ein fehlendes Plugin dagegen hält die ganze Umschaltung auf.
Der Parallelbetrieb zweier Stände ist ein Thema für sich: Dual-Write und Backfill.
Parallelbetrieb und der Punkt ohne Rückweg
Anders als bei einem Framework-Upgrade ist bei einem Shopwechsel der Parallelbetrieb die Regel: Der alte Shop läuft, der neue wird aufgebaut, und irgendwann wird umgeschaltet.
Zwei Dinge entscheiden darüber, wie riskant dieser Moment wird.
Die Datenmigration läuft mehrfach, zuletzt kurz vor dem Umschalten. Alles andere heißt, dass die Bestellungen der letzten Tage fehlen. Der letzte Lauf gehört geübt, mit gemessener Dauer, weil daraus das Zeitfenster für die Umschaltung folgt.
Die Umleitungen der alten URLs stehen vor dem Umschalten. Ein Shop, der Sichtbarkeit in Suchmaschinen hat, verliert sie, wenn die alten Adressen ins Leere laufen. Die Zuordnung alt zu neu entsteht aus den Daten und gehört in dieselbe Auslieferung wie die Umschaltung, nicht in die Woche danach.
Der Rückweg besteht darin, die Umleitung zurückzunehmen und wieder auf den alten Shop zu zeigen. Er endet in dem Moment, in dem die erste Bestellung im neuen Shop eingegangen ist, und zwar unwiderruflich: Diese Bestellung im alten Shop nachzutragen ist keine technische Aufgabe mehr, sondern Handarbeit in der Buchhaltung.
Deshalb gehört vor die Umschaltung eine nüchterne Prüfung der Kernwege: Artikel finden, in den Warenkorb legen, bestellen, bezahlen, Bestätigung erhalten, im Warenwirtschaftssystem ankommen. Nicht als Klickliste, sondern mit echten Zahlungsmitteln in einer Umgebung, die der Produktion entspricht.
Wie ich eine Shopware-Migration aufsetze, steht auf einer eigenen Seite. Die Bestandsaufnahme oben ist dort der erste Arbeitsblock, und sie lohnt sich auch dann, wenn die Migration danach jemand anderes macht.
Dieser Artikel gehört zu einer Reihe über Systeme, die es schon gibt. Der Rückblick ordnet alle Artikel der Reihe nach Anlass.
