Warum eine Shopware-Migration kein Update ist
Zwischen Shopware 5 und Shopware 6 hat Shopware AG die Architektur grundlegend neu gebaut. Das Templating ist von Smarty auf Twig gewechselt, das Backend von Enlight auf Vue 3, die API ist von SOAP/REST auf eine vollständige REST- und Admin-API umgestellt. Die Datenstruktur in der Datenbank ist auf Mehrsprachigkeit, Multi-Channel und Multi-Tenant ausgelegt, ein Konzept, das in SW5 nicht 1:1 abbildbar war. Wer von SW5 auf SW6 wechselt, übersetzt also nicht nur Daten, sondern wechselt das Plattform-Modell.
Der Migrations-Audit als Pflicht-Schritt
Bevor ich an die eigentliche Migration gehe, steht ein dokumentierter Migrations-Audit. Inhalte: vollständige Plugin-Liste mit Status (aktiv, inaktiv, custom, gekauft), Theme-Customizing-Tiefe, Code-Anpassungen außerhalb der vorgesehenen Plugin-Wege, ERP- und Schnittstellen-Verträge, SEO-Inventar (Top-Rankings, Sitemap, Schema-Markup, hreflang bei mehrsprachigen Shops), Datenbank-Erweiterungen, Performance-Stand. Das Ergebnis ist ein priorisierter Migrations-Plan mit klaren Entscheidungen pro Plugin und realistischen Aufwandsschätzungen. Ohne diesen Audit sind Festpreis-Angebote im Wesentlichen ein Versprechen ins Blaue.
Plugin-Migration: das größte Risiko
Die meisten verzögerten oder aus dem Ruder laufenden Shopware-Migrationen scheitern an Plugins. Typische Befunde im Audit: 30 bis 80 Plugins, davon sind rund 40 Prozent aktiv, 20 Prozent installiert aber inaktiv, 10 Prozent völlig veraltet. Plugins aus dem Shopware Store haben in der Regel eine SW6-Version mit eigener Lizenz, manchmal mit Migrations-Pfad. Custom-Plugins (oft als „kleine Anpassung" gestartet und dann gewachsen) müssen neu für SW6 entwickelt werden. Mein Vorgehen: Jede Plugin-Anforderung wird im Audit einzeln bewertet. „Brauchen wir das überhaupt noch?" ist eine der häufigsten und produktivsten Fragen. Eine schlanke Plugin-Liste nach der Migration zahlt sich über Jahre aus.
Theme-Strategie: Child-Theme oder Custom?
Die Storefront-Architektur in Shopware 6 ist auf Child-Themes ausgelegt: das mitgelieferte Default-Storefront oder ein kommerzielles Drittanbieter-Theme (zum Beispiel NOVAChild) als Basis, ein eigenes Child-Theme für die individuellen Anpassungen. Update-sicher, wartbar, schnell zu pflegen. Vollständig eigene Themes sind möglich, lohnen sich aber meist nur bei Marken mit sehr spezifischen Anforderungen an Layout, Performance oder Brand-Konsistenz. Für die meisten Migrationen ist ein Child-Theme mit gezielten Custom-Komponenten die richtige Wahl. Auch weil die Migration des alten SW5-Themes auf Twig praktisch immer ein Neubau ist, kein Refactoring.
Datenmigration in Iterationen statt im großen Wurf
Shopware bietet ein offizielles Migrations-Tool für SW5 → SW6, das die wichtigsten Daten überträgt: Produkte mit Varianten, Kategorien, Kunden, Bestellungen, CMS-Inhalte, Voucher-Codes, Bewertungen. In der Praxis reicht das offizielle Tool selten allein. Individuelle Datenbank-Erweiterungen aus eigenen Plugins, Custom-Felder, spezielle Variantenmodelle oder ERP-spezifische Stammdaten brauchen meist eigene Migrations-Plugins oder Scripts. Die Migration läuft typischerweise mehrfach in Iterationen: erster Lauf auf Staging zur Identifikation der Lücken, mehrere Test-Läufe, finaler Cutover. So lassen sich Datenfehler vor dem Go-Live identifizieren und beheben, statt nach Live-Schaltung Notfall-Recovery zu fahren.
ERP-Schnittstellen neu verdrahten
Die meisten B2B-Shopware-Shops hängen an einem ERP: Sage, JTL Wawi, Plentymarkets, DATEV oder einer Eigenentwicklung. SW6 hat eine völlig andere API-Architektur als SW5, was bestehende Schnittstellen-Anbindungen praktisch immer in Neuverdrahtung resultiert. Das ist Aufwand, aber auch Chance: Viele ERP-Integrationen aus der SW5-Zeit waren Workarounds, die in SW6 deutlich sauberer lösbar sind, über die offizielle Admin-API, Webhooks oder dedizierte Sync-Plugins. Im Migrations-Audit wird die ERP-Anbindung als eigener Block behandelt, weil hier oft die größten Stundenposten liegen.
SEO-Migration: oft unterschätzt, schnell teuer
Eine technische Migration ohne SEO-Plan ist eine der zuverlässigsten Methoden, mühsam aufgebaute Sichtbarkeit zu verbrennen. Pflicht-Bausteine: vollständiges 301-Mapping aller relevanten URLs (Kategorien, Produkte, CMS-Seiten, alte Blog-Beiträge), Sitemap-Generierung auf neuer Plattform, Search-Console-Property entweder per Domain-Migration weitergeführt oder neu eingerichtet mit klarer Cutover-Logik, Schema-Markup gleichwertig oder besser umgesetzt, hreflang-Tags für mehrsprachige Shops korrekt portiert. Als Sistrix-zertifizierter SEO mache ich diese Schritte als integralen Teil der Migration. Nicht als „SEO macht jemand anderes nach Go-Live".
Performance-Setup von Anfang an
Shopware 6 ist deutlich performanter als SW5, aber das gilt nicht automatisch, sondern nur, wenn das Setup die Architektur nutzt. HTTP-Cache sauber konfiguriert, ESI (Edge Side Includes) für personalisierte Bereiche, Asset-Pipeline mit WebP/AVIF-Bildern, Lazy-Loading, Critical-CSS-Strategie, sauberes Hosting-Setup. Wenn diese Punkte schon in der Migration mitgehen, startet der neue Shop mit LCP unter 2,5 s und Core-Web-Vitals im grünen Bereich, statt im ersten Quartal nach Launch nachgelagerte Performance-Sanierung zu brauchen.
Plattform-Wechsel von Magento, JTL oder Shopify
Der Wechsel von einer anderen Plattform auf Shopware 6 folgt grundsätzlich derselben Logik, hat aber eigene Spezifika. Magento-Wechsel: Datenmigration über CSV-Exports oder dedizierte Migrations-Skripte, Plugin-Mapping (Magento-Erweiterungen haben keine SW6-Entsprechung, Anforderungen müssen neu interpretiert werden), URL-Mapping für oft komplexe Magento-Kategorie-Strukturen. JTL-Wechsel: Stärke des Shopware-Modells sind häufig die feineren B2B-Funktionen, der Wechsel ist aus geschäftlicher Sicht oft begründet. Shopify-Wechsel: meist getrieben von komplexeren B2B-Anforderungen, individueller Preisstruktur oder ERP-Tiefenanbindung, die Shopify nicht abdeckt. Vor jedem Plattform-Wechsel kommt eine Beratung, die ergebnisoffen ist. Auch „bleiben Sie auf Ihrer Plattform" gehört zum möglichen Outcome.
Verwandte Themen
Eine Migration ist selten ein isoliertes Projekt, meistens berührt sie umliegende Disziplinen. Wenn die Plugin-Migration der Hauptaufwand wird, ist Shopware-Freelancer die nähere Sicht auf das Thema. Wenn der Migrations-Anlass eine Full-Service-Frage ist (Konzept, Design, Entwicklung, Marketing), passt eher Shopware-Agentur. SEO-Migration als Begleitprojekt ist eng verbunden mit dem SEO-Freelancer-Angebot. Wer den Migrations-Anlass nutzt, um auch die Shop-Konzeption neu zu denken, findet einen Einstieg auf Online Shop erstellen lassen.
Aus Münster für DACH
Sitz in Münster (NRW), persönliche Termine in der Region und im Münsterland jederzeit möglich. Der überwiegende Teil meiner Migrations-Projekte läuft remote über gemeinsame Repositories, Staging-Systeme und Video-Abnahmen, von Norddeutschland über NRW bis in den DACH-Raum.
