Die Frage kommt in fast jedem Erstgespräch, und zwar in dieser Form: „Die Daten kommen doch mit, oder?" Die Antwort ist ja — und sie hilft trotzdem kaum weiter. Denn was in einer Shopware-6-Installation ankommt, sind Artikel, Kunden und Bestellungen. Was nicht ankommt, ist der Shop: die Plugins, die Template-Anpassungen, die gewachsenen URL-Strukturen, die Schnittstelle zum ERP. Der Datenbestand ist der einfache Teil. Er wird nur zuerst besprochen, weil er sich am besten in einem Satz beantworten lässt.
Wir haben in den letzten Jahren eine Reihe solcher Umstiege begleitet, vom kleinen B2C-Shop mit 800 Artikeln bis zum B2B-Shop mit Kundenpreisen aus dem ERP. Die Reihenfolge der Arbeitsschritte ist dabei erstaunlich stabil. Die Menge an Überraschungen unterwegs hängt fast nur davon ab, wie gründlich Schritt eins war.
Was der Migrationsassistent tatsächlich übernimmt
Shopware liefert einen Migrationsassistenten, der eine Shopware-5-Datenbank ausliest und in ein Shopware-6-System schreibt. Er übernimmt Artikel mit Varianten, Eigenschaften und Bildern, Kategorien, Hersteller, Kunden mit Adressen, Bestellungen mit Positionen, Newsletter-Empfänger und Medien. Das funktioniert in der Regel ohne Drama, wenn der Altbestand sauber ist.
Bemerkenswert ist ein Punkt, den viele nicht erwarten: Kundenpasswörter kommen mit. Shopware 6 kann die alten Hashes prüfen und beim ersten erfolgreichen Login auf das aktuelle Verfahren umstellen. Deine Kunden müssen also nicht alle ihr Passwort zurücksetzen — ein Reset-Mailing an den gesamten Bestand ist einer der zuverlässigsten Wege, Bestellungen zu verlieren, und du brauchst es nicht.
Die Bestellhistorie kommt ebenfalls mit, aber sie kommt kalt. Die Positionen verweisen nicht mehr zwingend auf existierende Artikel, Zahlungs- und Versandarten aus dem Altsystem werden auf neue Entitäten abgebildet, und generierte Belegdokumente sind ein eigenes Thema. Wenn du Rechnungen aus dem Shop heraus erzeugt hast statt aus dem ERP, plane ein Archiv ein, statt darauf zu hoffen, dass die PDFs im neuen Kundenkonto liegen. Für Steuerprüfung und Reklamation reicht ein Archiv völlig; für den Kunden reicht meist die Liste seiner Bestellungen.
Custom Fields — in Shopware 5 Freitextfelder — kommen mit, wenn sie im Standard angelegt waren. Alles, was ein Plugin in eigene Tabellen geschrieben hat, kommt nicht mit. Das betrifft regelmäßig Dinge, die im Alltag wichtig sind: Staffelpreise aus einem Drittanbieter-Plugin, Artikelzubehör, Downloads, B2B-Freigaben.
SEO-URLs sind kein Datenfeld, sondern eine Umzugsliste
Shopware 6 erzeugt SEO-URLs aus Templates. Das heißt, die neuen Adressen folgen einer Regel, nicht dem Altbestand. Selbst wenn du die Regel so einstellst, dass sie der alten Struktur nahekommt, bleiben Abweichungen: Kategorienpfade, Varianten-URLs, Endungen, Sonderzeichen.
Der praktikable Weg ist immer derselbe. Du exportierst vor der Umschaltung alle indexierten URLs — aus der Sitemap, aus der Datenbank und aus der Search Console, weil die drei Listen nie identisch sind — und legst sie neben die neuen. Daraus entsteht eine Weiterleitungsliste, die du regelbasiert abarbeitest und für die Ausreißer manuell ergänzt. Landingpages, die über Jahre Links gesammelt haben, sind wichtiger als der 400. Artikel aus einer Auslaufserie. Wer diesen Schritt überspringt, sieht das Ergebnis vier bis sechs Wochen später im Traffic, und dann ist die Ursache schwer zu belegen.
Plugins und Template: hier endet die Migration
Ein Shopware-5-Plugin läuft nicht in Shopware 6. Es gibt keinen Kompatibilitätsmodus und keinen Konverter. Das Gleiche gilt für das Template: Shopware 5 nutzt Smarty, Shopware 6 nutzt Twig, und die Storefront ist anders aufgebaut. Anpassungen werden nicht migriert, sie werden neu gemacht.
Das klingt schlimmer, als es meistens ist. Wenn wir uns die Plugin-Liste eines gewachsenen Shopware-5-Shops ansehen, sind darin viele Erweiterungen, die vor Jahren installiert und nie deinstalliert wurden. Ein Teil ist inaktiv, ein Teil löst ein Problem, das Shopware 6 im Standard löst — Erlebniswelten, Regelbuilder, Mehrsprachigkeit, Zahlungsarten über die offiziellen Erweiterungen. Übrig bleibt eine überschaubare Zahl echter Abhängigkeiten.
Für die geht man drei Fälle durch. Erstens: Es gibt eine Shopware-6-Version desselben Herstellers, dann ist es eine Lizenz- und Konfigurationsfrage. Zweitens: Es gibt sie nicht, aber eine Alternative eines anderen Anbieters, dann ist es eine Bewertungsfrage — und meist der Moment, in dem jemand feststellt, dass die Funktion nie wirklich genutzt wurde. Drittens: Es gibt nichts Passendes, dann ist es eine Entwicklungsfrage, und die gehört in die Budgetplanung, nicht in die Testphase. Genau dieser dritte Fall wird am häufigsten zu spät entdeckt.
Datenmigration oder Neuaufbau — die Entscheidung fällt am Katalog
Es gibt Projekte, in denen die Migration der Artikeldaten der falsche Weg ist. Das ist dann der Fall, wenn der Katalog im ERP führend ist und ohnehin vollständig in den Shop gepusht wird. Dann baut man den Shop neu auf, lässt das ERP die Artikel schreiben und migriert nur Kunden und Bestellungen. Das Ergebnis ist sauberer, weil du keine zehn Jahre alten Varianten-Konstruktionen mitschleppst.
Umgekehrt gilt: Wenn der Shop das führende System für Texte, Bilder und Kategoriestruktur ist und diese Pflege echte Arbeitszeit gekostet hat, migriere. Ein Neuaufbau des Katalogs von Hand wird regelmäßig unterschätzt, weil niemand die Stunden aus der Vergangenheit zusammenzählt.
Die Zwischenform kommt am häufigsten vor: Stammdaten und Preise aus dem ERP, redaktionelle Inhalte aus der Migration. Dafür muss aber vorher feststehen, welches System welches Feld führt. Diese Festlegung ist der wichtigste Nebeneffekt eines Umstiegs, und sie ist der Grund, warum die ERP-Anbindung nicht am Ende steht.
Die ERP-Anbindung wird neu gebaut, nicht umgezogen
Egal ob JTL-Wawi, plentyONE oder ein anderes System: die Verbindung zu Shopware 6 ist eine andere als die zu Shopware 5. Andere Connectoren, andere Feldzuordnungen, teilweise anderes Verhalten bei Varianten und Kundengruppen. Plane das als eigenes Teilprojekt und nicht als Häkchen in der Checkliste.
Zwei Dinge fallen dabei fast immer auf. Erstens die Nummernkreise: Bestellnummern und Kundennummern müssen so weiterlaufen, dass Buchhaltung und Support keine Dubletten sehen. Zweitens die Zahlungsanbindung. Gespeicherte Zahlarten, Abonnements, Mandate und Tokens beim Zahlungsdienstleister ziehen nicht einfach mit. Das ist ein Punkt, den du mit dem Anbieter klären musst, bevor du einen Umschalttermin nennst.
Getestet wird nicht mit Testdaten, sondern mit echten Bestellungen durch die gesamte Kette: Shop, ERP, Versanddienstleister, Rechnung, Retoure. Eine Retoure ist der bessere Test als eine Bestellung, weil sie mehr Systeme berührt.
Umschaltung und Nachlauf
Die Umschaltung selbst ist der unspektakulärste Teil, wenn die Reihenfolge stimmt. Du frierst die Pflege im Altsystem für ein definiertes Fenster ein, fährst eine Delta-Migration für Kunden und Bestellungen, die zwischen Erstmigration und Stichtag entstanden sind, schaltest DNS um, aktivierst die Weiterleitungen und lässt die alte Instanz erreichbar, aber gesperrt. Nicht löschen — du wirst in den ersten Wochen mehrfach hineinschauen.
Der Nachlauf dauert länger, als die meisten einplanen. Sinnvoll sind vier bis sechs Wochen, in denen jemand täglich die 404-Meldungen, die Fehlerprotokolle der Schnittstelle und die Zahlungsabbrüche ansieht. Die typischen Funde in dieser Phase sind keine Katastrophen: eine Versandart, die für ein Land fehlt; ein Kundengruppen-Preis, der nicht greift; ein Mail-Template ohne Logo. Sie fallen nur dann früh auf, wenn jemand hinsieht, statt auf Kundenmeldungen zu warten.
Wenn du gerade am Anfang stehst, ist der nächste sinnvolle Schritt keine Angebotsanfrage, sondern eine Liste: alle installierten Plugins mit der Angabe, wer sie im Alltag braucht, alle Template-Anpassungen, die euch wichtig sind, und die Festlegung, welches System künftig welches Feld führt. Diese drei Punkte entscheiden über Aufwand und Reihenfolge des ganzen Projekts. Alles andere ist danach Handwerk.
KI-generierter Inhalt.