Shopware 5 auf Shopware 6 migrieren: Was wirklich auf Sie zukommt

Wer eine Shopware-5-auf-6-Migration als Update betrachtet, unterschätzt das Projekt. Shopware 6 ist eine komplette Neuentwicklung — anderes Framework, andere Template-Engine, andere Datenbankstruktur, andere Plugin-API. In der Praxis bedeutet das: Der alte Shop wird parallel durch einen neuen ersetzt. Produkte, Kunden und Bestellungen werden migriert, aber Theme, Plugins und Schnittstellen müssen neu aufgebaut werden.

Dieser Ratgeber fasst zusammen, was bei einer Migration tatsächlich anfällt, welche Fehler vermeidbar sind und wie eine realistische Planung aussieht.

Warum die Migration nicht mehr optional ist¶

Shopware 5 ist seit Juli 2024 End of Life. Keine Sicherheitsupdates, keine Bug-Fixes, keine neuen Features. Das hat drei konkrete Konsequenzen:

1. Zahlungsanbieter stellen um. Stripe, PayPal und andere aktualisieren ihre Integrationen nicht mehr für Shopware 5. Wenn ein Anbieter sein API ändert, bricht die Zahlungsabwicklung ohne Vorwarnung ab.
2. PHP-Kompatibilität endet. Moderne Server laufen auf PHP 8.3+. Shopware 5 ist damit nur eingeschränkt kompatibel. Hosting-Anbieter werden alte PHP-Versionen irgendwann abkündigen.
3. Sicherheitslücken bleiben offen. Bekannte Schwachstellen in Shopware 5 und seinen Plugins werden in öffentlichen Datenbanken dokumentiert und aktiv ausgenutzt. Ein ungepatchtes Shopsystem ist ein offenes Einfallstor.

Jeder Monat Verzögerung vergrößert die technische Lücke und damit den Migrationsaufwand.

Technische Unterschiede: Kein Update, ein Neubau¶

Diese Unterschiede bedeuten: Kein Shopware-5-Plugin läuft in Shopware 6 ohne Anpassung. Kein Theme ist direkt übertragbar. Das ist der wichtigste Kostentreiber bei der Migration.

Phase 1: Bestandsaufnahme und Audit¶

Bevor eine einzige Zeile Code geschrieben wird, steht eine vollständige Bestandsaufnahme. Ohne diesen Schritt sind belastbare Aufwandsschätzungen nicht möglich.

Technisches Audit¶

• Welche Shopware-5-Version und PHP-Version laufen?
• Wurden Core-Dateien direkt modifiziert? (häufiges Problem bei älteren Shops)
• Wie sauber sind die Produktdaten? Doppelte Kategorien, fehlende Pflichtfelder, inkonsistente Varianten?
• Gibt es Custom-Tabellen in der Datenbank, die nicht über Plugins verwaltet werden?

Plugin-Inventur¶

Die Plugin-Frage ist der emotionale und finanzielle Kern jeder Migration. Ein typischer mittelständischer Shop hat 15–25 aktive Plugins. Für jedes einzelne muss eine Entscheidung fallen:

Das Vorgehen im Detail:

1. Alle aktiven Shopware-5-Plugins dokumentieren — Name, Anbieter, Funktion, Version
2. Im Shopware 6 Store prüfen, ob eine kompatible Version existiert
3. Für jedes fehlende Plugin entscheiden: Eigenentwicklung, Alternativanbieter oder Funktionsverzicht
4. Kosten für Eigenentwicklungen ins Projektbudget aufnehmen

Erfahrungswerte aus der Branche zeigen: 20 bis 40 Prozent der aktiven Plugins sind in keiner Form für Shopware 6 verfügbar. Bei stark individualisierten B2B-Shops kann dieser Anteil höher liegen.

Schnittstellen und Drittsysteme¶

Welche externen Systeme sind angebunden?

• ERP / Warenwirtschaft (SAP, Microsoft Dynamics, Lexware, DATEV, JTL, Xentral)
• PIM-System (Akeneo, Pimcore, eigene Lösung)
• Marktplatz-Anbindungen (Amazon, eBay, Otto via Magnalister o.ä.)
• Payment-Provider (PayPal, Stripe, Klarna, Mollie)
• Versanddienstleister (DHL, DPD, GLS, Hermes)
• Marketing-Tools (Newsletter-Systeme, Tracking, Feeds)
• Buchhaltung (DATEV-Export, Rechnungstools)

Jede dieser Schnittstellen muss für Shopware 6 neu konfiguriert oder neu entwickelt werden. Bei Middleware-Lösungen für SAP oder Dynamics sollte vorab das Gespräch mit dem IT-Partner gesucht werden.

Stakeholder identifizieren¶

Eine Shop-Migration betrifft nicht nur die IT. Folgende Personen müssen eingebunden werden:

• Geschäftsführung — Budget, Timeline, Go-Live-Termin
• Marketing / E-Commerce-Manager — SEO, Content, Kampagnen-Planung
• Einkauf / Produktmanagement — Produktdatenqualität, Kategoriestruktur
• Logistik / Fulfillment — Versandprozesse, Lageranbindung
• Buchhaltung — DATEV-Export, Rechnungsstellung, Zahlungsabgleich
• Externer ERP-Dienstleister — Schnittstellenmigration
• Agentur / Entwicklerteam — Umsetzung

Wer Stakeholder zu spät einbindet, entdeckt fehlende Anforderungen erst in der Testphase — der teuerste Zeitpunkt für Änderungen.

Phase 2: Shopware 6 aufsetzen und Architektur planen¶

Edition wählen¶

Shopware 6 bietet verschiedene Editionen. Die Wahl beeinflusst Kosten und verfügbare Features:

Die Lizenzkosten kommen zu den Migrationskosten hinzu. Für viele mittelständische Shops ist die Community Edition mit gezielten Plugin-Ergänzungen die wirtschaftlichste Wahl.

Hosting-Umgebung vorbereiten¶

Shopware 6 hat andere Anforderungen als Shopware 5:

PHP 8.2+
MySQL 8.0 / MariaDB 10.11+
Composer 2
Node.js 20 LTS oder neuer (für Storefront-Build, je nach Shopware-Version)
OpenSearch für Advanced Search; Elasticsearch/OpenSearch nur bei konkretem Such- und Listing-Bedarf einplanen
Redis oder Varnish (empfohlen für Caching)

Die vollständigen Systemanforderungen hängen von der Zielversion ab und sind in der offiziellen Shopware-Dokumentation aufgeführt. Vor Projektstart sollte die Zielversion festgelegt werden, weil Shopware 6.7 andere Runtime-Anforderungen haben kann als ältere 6.x-Installationen.

Die Staging-Umgebung sollte die Produktionsumgebung so exakt wie möglich abbilden. Migrationstest auf einem abweichenden Setup führen zu bösen Überraschungen beim Go-Live.

Phase 3: Datenmigration¶

Was der Migration Assistant leistet¶

Shopware liefert den offiziellen Migration Assistant als Plugin. Er überträgt:

• Produkte (inkl. Varianten, Preise, Bilder)
• Kategorien
• Kunden und Kundengruppen
• Bestellhistorie
• Medien
• Hersteller
• Bewertungen

Der Assistant arbeitet inkrementell — er kann mehrfach ausgeführt werden, bis der Datenstand stimmt. Das erlaubt eine parallele Entwicklung: Der alte Shop läuft weiter, während der neue befüllt wird.

Was der Migration Assistant nicht leistet¶

• Einkaufswelten / Erlebniswelten — müssen manuell in den Shopware-6-Erlebniswelten nachgebaut werden
• Statische CMS-Seiten — Inhalte manuell übertragen
• Custom Fields und eigene Datenbankfelder — benötigen manuelles Mapping
• Plugin-Daten — Plugin-spezifische Tabellen werden nicht migriert
• Cross-Selling-Konfigurationen — müssen neu angelegt werden
• SEO-URLs — werden übernommen, aber die URL-Logik ist anders und erzeugt oft abweichende Pfade

Datenqualität vor der Migration bereinigen¶

Produktdaten aus gewachsenen Shopware-5-Installationen sind selten sauber. Typische Probleme:

• Verwaiste Kategorien ohne zugeordnete Produkte
• Doppelte Artikelnummern oder inkonsistente Variantenstrukturen
• Fehlende oder abgeschnittene Beschreibungstexte
• Bilder ohne Alt-Texte
• Inaktive Produkte, die seit Jahren nicht verkauft wurden

Erfahrungswert: Shops ohne saubere Produktdaten verbringen 30 bis 50 Prozent der Migrationszeit mit Datenbereinigung. Es lohnt sich, diesen Aufwand vorher einzuplanen.

Phase 4: Theme und Design¶

Warum ein Komplettneubau nötig ist¶

Shopware 5 nutzt Smarty-Templates und ein eigenes CSS-Framework. Shopware 6 setzt auf Twig-Templates und Bootstrap 5. Eine direkte Übernahme des Themes ist technisch nicht möglich.

Das ist gleichzeitig eine Chance: Die meisten Shops profitieren von einer Modernisierung des Designs. Mobile-First-Umsetzung, bessere Core Web Vitals und ein aufgeräumter Checkout sind mit der neuen Storefront deutlich einfacher umzusetzen.

Einkaufswelten werden Erlebniswelten¶

Shopware 5 nutzt „Einkaufswelten" für Landingpages und individuelle Layouts. Shopware 6 hat dieses Konzept als „Erlebniswelten" komplett neu aufgebaut. Die Inhalte sind technisch nicht übertragbar — jede Seite muss manuell nachgebaut werden.

Für Shops mit dutzenden Einkaufswelten ist das ein erheblicher Aufwand, der oft unterschätzt wird. Ein pragmatischer Ansatz: Die 10–15 wichtigsten Seiten (gemessen am Traffic) werden für den Go-Live nachgebaut, der Rest folgt nach dem Launch.

Theme-Entwicklung ist selten nur Design¶

Besonders bei B2B-Shops steckt im Theme deutlich mehr als Corporate Design. Häufig werden im Frontend gleichzeitig implementiert:

• Preislogiken für Kundengruppen (Netto/Brutto, Staffelpreise)
• Login-Bereiche und geschützte Kataloge
• Individuelle Bestellprozesse mit Freigabe-Workflows
• Schnellbestellfunktionen mit Artikelnummern-Eingabe

Phase 5: ERP und Schnittstellen neu anbinden¶

API-First macht alles anders¶

Shopware-5-ERP-Anbindungen basierten oft auf direkten Datenbankverbindungen oder proprietären APIs. Shopware 6 ist API-First: Alle Daten fließen über die dokumentierte Admin-API oder die Store-API.

Das bedeutet: Jede bestehende ERP-Anbindung muss auf die Shopware-6-API migriert werden. Bestehende Konnektoren von Drittanbietern sind in SW6-Versionen oft nicht direkt verfügbar oder funktionieren anders.

Die Datenströme, die neu implementiert werden müssen:

Erfahrungswert: Für eine ERP-Neuanbindung sollten mindestens vier bis acht Wochen Entwicklungszeit eingeplant werden — auch wenn das ERP-System selbst unverändert bleibt.

Zahlungsanbieter und Versand¶

Payment-Provider wie Mollie, Stripe oder Klarna bieten Shopware-6-Plugins an. Trotzdem müssen alle Zahlungsarten neu konfiguriert und getestet werden — insbesondere:

• Testbestellungen mit jeder Zahlungsart im Staging
• Rückerstattungen und Stornierungen
• Webhook-Konfigurationen
• PCI-DSS-Compliance bei Kreditkartenzahlungen

Für Versanddienstleister gilt dasselbe: DHL, DPD, GLS und Hermes haben eigene Shopware-6-Plugins, die neu eingerichtet werden müssen. Wer Versandregeln mit Gewichts- oder Wertgrenzen nutzt, muss diese komplett neu konfigurieren.

Phase 6: SEO-Absicherung¶

SEO-Fehler bei der Migration führen zu Ranking-Verlusten, die Monate brauchen, um sich zu erholen. Diese Phase wird am häufigsten unterschätzt.

URL-Mapping und 301-Redirects¶

Shopware 6 generiert URLs nach anderen Regeln als Shopware 5. Kategoriebasierte Pfade, Produktdetailseiten und Filter-URLs können sich komplett ändern.

Jede URL, die in Google indexiert ist und Traffic bringt, braucht eine korrekte 301-Weiterleitung:

1. Alle indexierten URLs aus der Google Search Console exportieren
2. Crawl der aktuellen Shopware-5-Instanz mit Screaming Frog oder ähnlichem Tool
3. Mapping-Tabelle erstellen: alte URL → neue URL
4. 301-Weiterleitungen in Shopware 6 oder auf Server-Ebene implementieren
5. Nach Go-Live: alle Weiterleitungen auf korrekte Statuscodes prüfen (301, nicht 302)

# Beispiel: nginx Redirect-Map für typische SW5-URL-Muster
map $uri $redirect_url {
    ~^/detail/sArticle/(\d+)$     /product-detail-page;
    ~^/listing/$                  /category-page;
    ~^/blog/detail/sCategory/     /blog-category;
}

server {
    if ($redirect_url) {
        return 301 $redirect_url;
    }
}

Häufiger Fehler: Filter-URLs und Suchergebnis-URLs werden nicht mitgemappt. Das verursacht massenhaft 404-Fehler für intern verlinkte Seiten.

Metadaten und strukturierte Daten¶

• Meta-Titles und -Descriptions prüfen und übertragen
• H1-Überschriften auf allen wichtigen Seiten kontrollieren
• Structured Data (Schema.org) überprüfen und ggf. neu aufsetzen
• Canonical-Tags kontrollieren
• XML-Sitemap für Shopware 6 generieren und bei Google Search Console einreichen
• hreflang-Tags bei mehrsprachigen Shops korrekt konfigurieren

Phase 7: Testing und Go-Live¶

Testumfang¶

Die Testphase wird oft als letzter Schritt vor dem Launch abgehakt. In Wirklichkeit ist sie ein eigenständiges Teilprojekt:

• Bestellstrecke komplett durchspielen — Warenkorb, Checkout, Bestätigungs-E-Mail, Bestellübersicht im Kundenkonto
• Alle Zahlungsarten testen — in Test- und Live-Modus
• Benutzerkonten — Login, Registrierung, Passwort-Reset, Adressverwaltung
• ERP-Synchronisation — Bestellt ein Testprodukt, kommt die Bestellung korrekt im ERP an?
• Versandprozess — Label-Erstellung, Tracking-Nummer, Status-Updates
• Performance — Core Web Vitals messen, Ladezeiten unter Last prüfen
• B2B-spezifisch — Nettopreise, Freigabeprozesse, Kontingente, Debitorennummern
• Mobile — Kompletter Bestellprozess auf Smartphone und Tablet

Go-Live-Strategie¶

Der Umstieg selbst sollte als kontrollierter Prozess geplant werden:

1. Finaler Datenabgleich — Letzte Datenmigration mit aktuellen Bestellungen und Kundenänderungen
2. DNS-Umschaltung — Domain auf den neuen Shop zeigen lassen
3. Monitoring — In den ersten 48 Stunden aktiv überwachen: 404-Fehler, Server-Last, Conversion-Rate
4. Rollback-Plan — Für den Notfall: DNS zurück auf den alten Shop. Der alte Shop sollte mindestens zwei Wochen nach Go-Live noch lauffähig bleiben

Bewährt hat sich ein Go-Live an einem Montag oder Dienstag — nicht vor dem Wochenende, nicht vor Feiertagen. So bleibt genug Zeit, um Probleme zu beheben, bevor Traffic-Spitzen kommen.

Kosten und Zeitrahmen¶

Realistische Erfahrungswerte aus der DACH-Region:

Faktoren, die den Aufwand in die Höhe treiben:

• ERP-Integration — Wenn SAP, Dynamics oder JTL neu angebunden werden, ist das ein eigenständiges Teilprojekt
• Schlechte Datenqualität — 30–50 % der Migrationszeit geht für Datenbereinigung drauf
• Individuelle B2B-Logiken — Freigabe-Workflows, Kontingente, Kundengruppenpreise
• Mehrsprachigkeit — Jede zusätzliche Sprache multipliziert den Aufwand für Content, SEO und Testing
• Internationaler Versand — Länderspezifische Steuerregeln, Zollabwicklung, lokale Zahlungsarten

Typische Fehler und wie sie sich vermeiden lassen¶

1. Migration ohne Audit starten¶

Wer ohne vollständige Bestandsaufnahme loslegt, entdeckt fehlende Anforderungen erst in der Testphase. Das ist der teuerste Zeitpunkt für Änderungen.

2. Plugin-Aufwand unterschätzen¶

„Das Plugin gibt es bestimmt auch für SW6" — oft stimmt das nicht. 20–40 % der Plugins müssen neu entwickelt oder durch Alternativen ersetzt werden. Dieser Aufwand wird regelmäßig um den Faktor 2–3 unterschätzt.

3. SEO als Nachgedanke behandeln¶

301-Redirects nach dem Go-Live einrichten reicht nicht. URL-Mapping, Metadaten und strukturierte Daten müssen vor dem Launch stehen. Rankings, die einmal verloren sind, brauchen Monate, um sich zu erholen.

4. Keinen Rollback-Plan haben¶

Wenn beim Go-Live etwas schiefgeht — ERP-Sync fehlerhaft, Zahlungsanbieter reagiert nicht — muss der alte Shop innerhalb von Minuten wieder erreichbar sein. Ohne Rollback-Plan wird aus einem technischen Problem ein Geschäftsausfall.

5. Go-Live vor einem Wochenende oder Sale-Event¶

Freitagnachmittag live gehen, damit übers Wochenende alles „einläuft"? Keine gute Idee. Probleme treten fast immer in den ersten 48 Stunden auf. Der Go-Live braucht das gesamte Team in Bereitschaft.

Weiterführende Links¶

• Offizielle Migrationsdokumentation — Shopwares eigene Anleitung für die SW5-auf-SW6-Migration
• Migration Assistant: Einrichtung und Ablauf — Schritt-für-Schritt-Anleitung für den Migration Assistant
• Systemanforderungen Shopware 6 — PHP, MySQL, Node.js und weitere Voraussetzungen
• Plugin-Entwicklung in Shopware 6 — Einstieg in die neue Plugin-API für Eigenentwicklungen
• Shopware 6 Store — Plugins und Erweiterungen für Shopware 6

Fazit¶

Eine Shopware-5-auf-6-Migration ist kein Nachmittagsprojekt. Es ist ein Plattformwechsel, der 3–6 Monate dauert und alle Bereiche des Unternehmens betrifft — von der IT über Marketing und Einkauf bis zur Buchhaltung.

Der wichtigste Erfolgsfaktor ist die Vorbereitung: Ein sauberes Audit, eine vollständige Plugin-Inventur und eine realistische Zeitplanung verhindern die meisten Probleme. Wer diese Phase überspringt, zahlt später doppelt.

Meine Empfehlung: Mit dem technischen Audit starten, Budget auf Basis der Ergebnisse festlegen, und erst dann die Umsetzung beauftragen. Migration-Projekte, die ohne Audit mit einem Festpreisangebot starten, geraten fast immer in Schwierigkeiten.