Ein Shopware-5-Shop kann noch Bestellungen abwickeln und trotzdem zum operativen Risiko werden. Wenn Plugins nicht mehr wartbar sind, Updates ausbleiben, Ladezeiten steigen oder die ERP-Anbindung nur über Sonderlösungen funktioniert, kostet der Betrieb täglich Zeit und Marge. Die Shopware 5 zu 6 Migration ist deshalb kein reines Technikprojekt. Sie betrifft Datenqualität, Prozesse, Sichtbarkeit und den laufenden Umsatz.
Der häufigste Fehler: Der bestehende Shop wird möglichst identisch nachgebaut. Das klingt sicher, übernimmt aber oft alte Abhängigkeiten, unklare Datenstrukturen und Funktionen, die niemand mehr wirklich braucht. Besser ist ein kontrollierter Neubau auf Basis dessen, was im Geschäft tatsächlich funktioniert – und dessen, was künftig schneller, automatisierter oder leichter skalierbar werden muss.
Warum die Shopware 5 zu 6 Migration mehr als ein Update ist
Shopware 6 folgt einer anderen technischen Architektur als Shopware 5. Themes, Plugins, APIs, Datenmodelle und Erweiterungen lassen sich nicht einfach übernehmen. Produkte, Kunden und Bestellungen können migriert werden, individuelle Logik jedoch nicht automatisch. Das gilt besonders für selbst entwickelte Plugins, komplexe Preisregeln, B2B-Funktionen, ERP-Schnittstellen und Checkout-Anpassungen.
Genau darin liegt auch die Chance. Wer die Migration sauber vorbereitet, reduziert historisch gewachsene Sonderwege und schafft eine Shop-Architektur, die sich besser an ERP, JTL-WaWi, Odoo, PIM, Marktplätze oder Marketingkanäle anbinden lässt. Der neue Shop soll nicht nur moderner aussehen. Er muss im Tagesgeschäft verlässlich arbeiten: Lagerbestände müssen stimmen, Bestellungen sauber übergeben werden und Mitarbeitende dürfen nicht mit manuellen Korrekturen beschäftigt sein.
Der Umfang hängt stark vom Geschäftsmodell ab. Ein kleiner D2C-Shop mit überschaubarem Sortiment braucht einen anderen Ansatz als ein Händler mit kundenspezifischen Preisen, mehreren Lagern, B2B-Freigaben und mehreren Verkaufskanälen. Eine pauschale Migrationsdauer wäre unseriös. Entscheidend ist, wie viel Fachlogik außerhalb des Shopware-Standards steckt.
Vor der Migration: Den Ist-Zustand ehrlich erfassen
Eine belastbare Planung beginnt nicht mit dem Importtool, sondern mit einem technischen und fachlichen Audit. Dabei wird geklärt, welche Daten übernommen werden müssen, welche Erweiterungen geschäftskritisch sind und welche Prozesse aktuell nur funktionieren, weil einzelne Mitarbeitende improvisieren.
Daten sind nicht gleich Daten
Produktdaten wirken auf den ersten Blick unkompliziert. In der Praxis liegen Varianten, Eigenschaften, Staffelpreise, Medien, Kategorien, Herstellerdaten und SEO-Felder häufig uneinheitlich vor. Werden diese Strukturen ungeprüft übertragen, zieht der neue Shop dieselben Datenprobleme wieder ein.
Auch Kunden- und Bestelldaten brauchen eine klare Entscheidung. Historische Bestellungen können für Service, Buchhaltung und Auswertungen relevant sein. Sie müssen aber nicht zwingend vollständig im neuen Shop verfügbar sein, wenn ein ERP oder Archivsystem diese Aufgabe besser abbildet. Es geht nicht darum, möglichst viele Datensätze zu bewegen, sondern die richtige Informationsbasis für Kundenservice und Betrieb zu sichern.
Prozesse und Schnittstellen gehören auf den Prüfstand
Besondere Aufmerksamkeit verdienen Zahlungsanbieter, Versandlogik, Retourenprozesse, Rechnungserstellung, Gutscheine, Produktfeeds, Suche, Tracking und Consent-Management. Ebenso wichtig sind Anbindungen an JTL-WaWi, Odoo, PIM-Systeme, Lagerdienstleister oder Marktplätze.
Hier zeigt sich oft, ob eine Funktion wirklich im Shop liegen sollte. Ein Beispiel: Bestände manuell im Shop und parallel im ERP zu pflegen, schafft fast zwangsläufig Differenzen. In einer sauberen Zielarchitektur ist klar definiert, welches System führend ist, welche Daten synchronisiert werden und wie Fehler erkannt werden. Diese Entscheidung verhindert später Bestellabbrüche wegen falscher Lieferzeiten oder Überverkäufe.
Die Zielarchitektur vor dem ersten Import festlegen
Nach dem Audit braucht das Projekt ein konkretes Zielbild. Dazu gehören Shopware-Version, Hosting, Theme-Konzept, Plugin-Strategie, Schnittstellen, Rollen und Verantwortlichkeiten. Auch die Frage nach Standard oder Individualentwicklung gehört früh auf den Tisch.
Shopware 6 bietet viele Funktionen bereits im Kern oder über etablierte Erweiterungen. Standard ist meist günstiger zu warten und schneller updatefähig. Individualentwicklung ist sinnvoll, wenn sie einen messbaren Prozessvorteil schafft oder ein entscheidendes Kundenerlebnis abbildet. Eine Sonderfunktion nur deshalb nachzubauen, weil sie im alten Shop vorhanden war, ist kein guter Grund.
Für das Frontend empfiehlt sich ein Designsystem statt einer Ansammlung einzelner Seitentemplates. Wiederverwendbare Komponenten für Produktlisten, Teaser, USP-Bereiche, Beratungselemente und Contentseiten beschleunigen spätere Anpassungen. Gleichzeitig müssen Conversion und Performance zusammen gedacht werden: große Bilder, aufwendige Skripte oder zu viele externe Dienste können den neuen Shop trotz modernem Design ausbremsen.
Datenmigration in Testläufen statt als Einmalaktion
Die Datenmigration sollte in mehreren kontrollierten Durchläufen erfolgen. Zunächst werden Felder, Zuordnungen und Bereinigungsregeln definiert. Danach folgt ein Testimport in eine abgesicherte Umgebung. Erst dort lässt sich prüfen, ob Varianten korrekt erscheinen, Preise stimmen, Medien zugeordnet sind und Kategorien logisch aufgebaut wurden.
Besonders kritisch sind abhängige Daten. Wenn Produktnummern, Kundennummern oder IDs in ERP, Feed-Systemen und individuellen Schnittstellen verwendet werden, können Änderungen Folgeschäden auslösen. Deshalb braucht jede Migration klare Prüfregeln: Welche Werte dürfen sich ändern? Welche müssen erhalten bleiben? Und welche Systeme erhalten die Information über Änderungen?
Ein Delta-Import kurz vor dem Go-live sorgt dafür, dass neue Kunden, Bestellungen und Produktänderungen aus der Übergangszeit nicht verloren gehen. Voraussetzung ist ein festgelegter Cutover-Plan. Ohne ihn entsteht genau die Unsicherheit, die viele Teams vor einer Migration fürchten: Niemand weiß, ab wann welches System führend ist.
Plugins, Theme und Individualcode richtig bewerten
Ein Plugin-Verzeichnis ist keine Migrationsstrategie. Für jede Erweiterung muss geprüft werden, ob eine Shopware-6-Version existiert, ob sie gepflegt wird und ob sie mit den übrigen Komponenten kompatibel ist. Ein vermeintlich günstiges Plugin kann teuer werden, wenn es Updates blockiert oder zentrale Checkout-Prozesse beeinträchtigt.
Beim Theme gilt dasselbe. Ein Shopware-5-Theme lässt sich nicht einfach übernehmen. Statt Pixel für Pixel zu kopieren, sollte geprüft werden, welche Elemente Umsatz oder Orientierung wirklich verbessern. Häufig reichen eine klare Navigation, überzeugende Produktseiten, gute Filter, schnelle Suche und nachvollziehbare Versandinformationen weiter als ein visuell überladener Relaunch.
Custom Code benötigt Dokumentation, Versionsverwaltung und eine Wartungsperspektive. Das ist kein Luxus. Wer später Fehler analysieren oder Funktionen erweitern will, muss nachvollziehen können, warum eine Lösung gebaut wurde und welche Systeme davon abhängen.
SEO und Tracking dürfen nicht bis zum Go-live warten
Eine technisch gelungene Migration kann organische Sichtbarkeit verlieren, wenn URLs, Weiterleitungen und Metadaten erst kurz vor dem Launch geprüft werden. Bestehende Rankings hängen oft an Produkt-, Kategorie- und Ratgeberseiten, die intern längst nicht mehr als wichtig wahrgenommen werden.
Für die Shopware 5 zu 6 Migration gehört deshalb ein URL-Konzept zum Pflichtprogramm. Relevante alte URLs erhalten gezielte 301-Weiterleitungen auf passende neue Seiten. Canonicals, Indexierungsregeln, XML-Sitemap, strukturierte Daten, Breadcrumbs und Pagination müssen im neuen Shop geprüft werden. Eine pauschale Weiterleitung aller alten Seiten auf die Startseite löst das Problem nicht.
Auch Tracking und Produktfeeds müssen vor dem Launch getestet werden. Wenn Google Ads, Shopping, Meta-Kampagnen oder Affiliate-Tracking plötzlich keine Umsätze mehr erfassen, fehlen nicht nur Daten. Dann werden Budgets auf Basis falscher Signale gesteuert. Consent-Management, Events, Transaktionswerte und Feed-Attribute gehören deshalb in die Abnahme.
Go-live: Kontrolliert starten, eng überwachen
Ein Go-live ist kein Moment, in dem ein Projekt einfach endet. In den ersten Tagen müssen Bestellungen, Zahlungsstatus, Versandübergaben, Bestände, Gutscheine, E-Mails, Tracking und Fehlermeldungen eng kontrolliert werden. Dafür braucht es feste Ansprechpartner auf Händler- und Agenturseite sowie einen klaren Eskalationsweg.
Vor der Umschaltung empfiehlt sich ein vollständiger Abnahmekatalog. Dazu zählen typische Kaufwege auf Desktop und Mobilgerät, Gastbestellung, Kundenkonto, unterschiedliche Zahlungsarten, Rabattcodes, Varianten, Versandkostenlogik und Storno- oder Retourenprozesse. Bei B2B-Shops kommen Login, Kundengruppen, individuelle Preise und Freigaben hinzu.
Ein Staging-System, Backups und ein Rückfallplan geben Sicherheit. Trotzdem sollte der Rückfallplan nicht als Ausrede dienen, halb getestet live zu gehen. Die beste Absicherung bleibt eine saubere Vorbereitung mit realistischen Testdaten und klaren Verantwortlichkeiten.
Was eine Migration unnötig teuer macht
Teuer werden Projekte selten wegen eines einzelnen Problems. Meist kommen unklare Entscheidungen zusammen: Funktionen werden ohne Priorisierung übernommen, Datenbereinigung wird verschoben, Schnittstellen werden zu spät einbezogen und Fachabteilungen testen erst kurz vor dem Launch.
Ebenso problematisch ist ein Festpreis ohne belastbare Bestandsaufnahme. Ein klar abgegrenzter Leistungsumfang ist sinnvoll. Wird jedoch die unbekannte Komplexität von individuellen Plugins, Daten oder ERP-Prozessen ignoriert, folgen später Nachträge oder Qualitätsabstriche. Transparenz vor Projektstart ist günstiger als Überraschungen im Endspurt.
Aventux betrachtet die Migration deshalb nicht isoliert als Shop-Relaunch, sondern als Verbindung aus Storefront, Warenwirtschaft, Prozessen und Vermarktung. Das schafft eine bessere Entscheidungsgrundlage, wenn technische Anforderungen gegen Betriebsaufwand und Umsatzwirkung abgewogen werden müssen.
Der sinnvollste nächste Schritt ist kein vorschneller Relaunch-Termin, sondern ein gemeinsamer Blick auf Daten, Schnittstellen und die Prozesse hinter dem Warenkorb. Wenn diese Basis steht, wird aus einer riskanten Plattformablösung ein Shop, der den Betrieb wirklich entlastet.
