Shopware 5 zu Shopware 6 migrieren

Wer „Shopware 5 auf 6 updaten“ sucht, erwartet meist einen Knopf im Backend. Den gibt es nicht — und das ist keine Bequemlichkeitsfrage, sondern eine Architekturfrage. Shopware 6 ist keine Weiterentwicklung von Shopware 5, sondern eine vollständige Neuentwicklung auf einer anderen technischen Grundlage.

Shopware 5 basiert auf einem über Jahre gewachsenen Unterbau mit Smarty als Template-Sprache und einem eigenen Plugin-System. Shopware 6 setzt auf Symfony, Twig im Storefront, eine Vue-basierte Administration und eine API-first-Architektur, bei der Storefront und Admin selbst nur Clients der API sind. Zwischen beiden Systemen liegt kein Versionssprung, sondern ein Systemwechsel.

Praktisch heißt das: Ihre Daten werden überführt, Ihr Frontend wird neu gebaut und Ihre Funktionen werden nachgebildet. Shopware selbst stellt dafür den Migrations-Assistenten bereit, der sich mit einem bestehenden Shopware-5-Shop verbindet und Stammdaten überträgt. Er löst den Datenteil — er löst weder Theme noch Plugins noch die SEO-Struktur.

Der unsichtbarste und zugleich folgenreichste Unterschied steckt in der Datenbank. Shopware 5 arbeitet mit fortlaufenden Ganzzahl-IDs: Ein Artikel hat die ID 1543, eine Kategorie die ID 12. Shopware 6 nutzt stattdessen UUIDs — lange, nicht fortlaufende Bezeichner.

Das klingt nach einem Detail, entscheidet aber darüber, ob eine Migration wiederholbar ist. Jede Beziehung im Shop — Artikel zu Kategorie, Bestellung zu Kunde, Variante zu Stammartikel — muss beim Übertragen neu verknüpft werden. Wird diese Zuordnung nicht sauber protokolliert, lässt sich ein zweiter Durchlauf nicht sauber wiederholen, und Sie bekommen Dubletten statt Aktualisierungen.

Wir migrieren deshalb grundsätzlich in mehreren Durchläufen auf ein Testsystem, bevor irgendetwas live geht: ein erster vollständiger Lauf zur Prüfung, Korrekturen an den Zuordnungsregeln, dann ein finaler Delta-Lauf kurz vor dem Go-Live, der nur die seitdem hinzugekommenen Bestellungen und Kundendaten nachzieht. So bleibt die Zeitspanne, in der im alten Shop noch bestellt wird, für Sie unkritisch.

Eine Frage, die in fast jedem Migrationsprojekt kommt: Müssen sich alle Kunden nach dem Umstieg neu registrieren? Nein — jedenfalls dann nicht, wenn die Passwort-Hashes korrekt mitgenommen werden.

Passwörter liegen in keinem Shopsystem im Klartext vor, sondern als Hash. Shopware 6 kann Hashes aus Shopware 5 übernehmen und beim ersten erfolgreichen Login des Kunden transparent auf das aktuelle Verfahren umstellen. Der Kunde merkt davon nichts und behält sein gewohntes Passwort.

Schiefgehen kann das an zwei Stellen: wenn die Hashes bei der Übertragung gar nicht mitgenommen werden, oder wenn das Zielsystem das Altverfahren nicht kennt. Beides führt zu demselben unangenehmen Ergebnis — einer Sammel-E-Mail an alle Bestandskunden mit der Bitte, das Passwort zurückzusetzen. Das kostet erfahrungsgemäß spürbar Wiederkäufe.

Ihr Shopware-5-Theme lässt sich nicht übernehmen. Shopware 5 nutzt Smarty als Template-Sprache, Shopware 6 nutzt Twig. Die Dateien sind nicht nur anders benannt — sie folgen einer anderen Vererbungslogik und greifen auf andere Datenstrukturen zu.

In der Praxis gibt es zwei sinnvolle Wege. Entweder Sie nutzen den Wechsel für einen Neuanstrich und bauen auf dem Shopware-6-Standard-Theme auf, das von Haus aus mobil optimiert und auf Core Web Vitals ausgelegt ist. Oder Ihr bestehendes Design soll erhalten bleiben — dann bauen wir es als eigenes Theme in Twig nach.

Der zweite Weg ist aufwendiger, aber oft der richtige: Ein vertrautes Design senkt das Risiko, dass Stammkunden nach dem Relaunch abspringen, und macht Conversion-Veränderungen überhaupt erst messbar. Wer Design und System gleichzeitig ändert, weiß hinterher nicht, woran eine veränderte Conversion-Rate lag.

Shopware-5-Plugins laufen unter Shopware 6 nicht. Das ist die Stelle, an der Migrationsprojekte am häufigsten teurer werden als geplant — meist, weil vorher niemand gezählt hat, wie viele Erweiterungen tatsächlich im Einsatz sind und welche davon überhaupt noch gebraucht werden.

Unsere Erfahrung aus den Projekten: Ein relevanter Teil der Plugins aus einem gewachsenen Shopware-5-Shop wird nach dem Wechsel nicht mehr benötigt. Manche Funktionen sind in Shopware 6 im Standard enthalten — etwa Regelwerke für Versandkosten und Zahlarten über den Rule Builder oder Automatisierungen über den Flow Builder, für die in Shopware 5 oft eigene Erweiterungen im Einsatz waren. Andere Plugins wurden vor Jahren installiert und sind längst verwaist.

Deshalb beginnt jede unserer Shopware-Migrationen mit einer Plugin-Inventur: Was ist installiert, was ist aktiv, was nutzt jemand tatsächlich, und wofür gibt es in Shopware 6 ein Gegenstück? Erst danach steht fest, was nachgekauft, was selbst entwickelt und was ersatzlos gestrichen werden kann. Diese Liste ist zugleich der größte Hebel auf den Preis.

Rankingverluste nach einem Systemwechsel sind kein Naturgesetz, sondern fast immer die Folge von drei konkreten Versäumnissen: fehlende Weiterleitungen, geänderte URL-Muster und verlorene Meta-Daten.

Shopware 5 und Shopware 6 verwalten sprechende URLs unterschiedlich. Wenn Sie nichts unternehmen, erzeugt Shopware 6 nach eigenen Regeln neue URLs — und jede alte URL, die Google im Index hat, läuft ins Leere. Bei einem Shop mit ein paar tausend Artikeln sind das ein paar tausend Fehlerseiten an dem Tag, an dem Sie live gehen.

Wir ziehen deshalb vor dem Go-Live die vollständige URL-Liste aus drei Quellen zusammen: aus dem alten Shop, aus der Google Search Console und aus den Server-Logfiles. Jede dieser URLs bekommt ein Ziel im neuen Shop und eine 301-Weiterleitung. Danach prüfen wir stichprobenartig gegen den Live-Index, statt uns auf die Weiterleitungsliste zu verlassen.

Nach dem Go-Live beobachten wir die Entwicklung sechs Monate lang. Fallen Rankings migrationsbedingt, bessern wir kostenlos nach. Das ist bewusst an eine Bedingung geknüpft: Auf Google-Positionen hat niemand Einfluss, auf saubere Migrationsarbeit schon.

Die reine Daten-Migration starten wir als Festpreis ab 1.990 €. Darin enthalten sind Artikel, Varianten, Kategorien, Kunden und die Bestellhistorie sowie die Weiterleitungsstruktur — also der Teil, der sich sauber standardisieren lässt.

Was ein komplettes Projekt kostet, hängt von vier Faktoren ab, und deshalb nennen wir dafür keine Hausnummer, sondern schauen vorher kurz hin: die Datenmenge, die Zahl der tatsächlich genutzten Plugins, der gewünschte Theme-Umfang und angebundene Drittsysteme wie ERP, PIM oder Versanddienstleister.

Den mit Abstand größten Ausschlag geben die Plugins und die Schnittstellen — nicht die Artikelanzahl. Ein Shop mit 30.000 Artikeln und Standardfunktionen ist schneller migriert als ein Shop mit 800 Artikeln, fünfzehn Individualerweiterungen und einer gewachsenen ERP-Anbindung.

Den Festpreis nennen wir vor Projektstart, nicht am Ende. Dafür brauchen wir ein kurzes Gespräch und einen Blick in Ihr System — danach steht die Zahl.

Shopware 5 hat am 31. Juli 2024 das End-of-Life erreicht. Der Shop funktioniert danach weiter — das ist genau der Grund, warum viele Händler den Umstieg schieben. Das Risiko wächst trotzdem, nur eben unsichtbar.

Sicherheitslücken, die nach dem EOL bekannt werden, werden nicht mehr geschlossen. Gleichzeitig altert die Umgebung: PHP-Versionen laufen aus, Hoster stellen alte Versionen ab, und Zahlungs- sowie Versanddienstleister passen ihre Schnittstellen an, ohne Rücksicht auf ein abgekündigtes System. Der Ausfall kommt dann selten durch einen Angriff, sondern weil ein Zahlungsdienstleister eine API abschaltet.

Dazu kommt die kaufmännische Seite: Ein Umstieg unter Zeitdruck — weil eine Schnittstelle gestorben ist oder ein Sicherheitsvorfall eingetreten ist — kostet mehr als ein geplanter. Planbar heißt: Testsystem, Abnahme, Go-Live im Zeitfenster Ihrer Wahl.

Wenn Sie den Umstieg dennoch strecken müssen, sollten Sie wenigstens die Angriffsfläche verkleinern: Backend-Zugänge einschränken, ungenutzte Plugins deinstallieren, aktuelle Backups an einem zweiten Ort und ein realistisches Wiederanlaufkonzept.