Die gefährlichste Zeile in deinem Shopware-5-Projekt steht nicht im Shop. Sie steht im ERP: ein Cronjob, der seit Jahren nachts Bestellungen abholt, geschrieben von jemandem, der längst nicht mehr im Haus ist. Solange er läuft, fühlt sich Shopware 5 stabil an. Genau deshalb ist es so verlockend, die Migration zu schieben, obwohl das System seit Juli 2024 keine Sicherheitsupdates mehr vom Hersteller bekommt.
Verkaufst du direkt an Endkunden und belieferst parallel den Handel, hängt der Shop nie allein: Bestände, Preise und Aufträge kommen aus dem ERP, und der Händlervertrieb läuft über dasselbe System. Gemessen am Online-Markt ist D2C dabei ein Nebenschauplatz: Hersteller-Versender kamen 2025 laut bevh-Jahrespräsentation auf 3,4 Prozent des deutschen Online-Umsatzes mit Waren. Trägt bei dir der Handel den Umsatz, darf er vom Shop-Wechsel nichts merken. Tauschst du hier nur den Shop, bricht die Schnittstelle.
Wie lange safefive und PHP 8.2 dir noch Luft geben
Der Sicherheitssupport für Shopware 5.7, den letzten Zweig, endete laut endoflife.date am 31. Juli 2024. Shopware verweist auf seiner Entwicklerseite inzwischen selbst auf safefive, und das Repository auf GitHub trägt seit September 2026 den Hinweis, dass es nicht mehr aktiv gepflegt wird.
safefive liefert nach eigener FAQ ab August 2024 fünf Jahre lang Sicherheitsupdates per Plugin, abgerechnet nach Nettoumsatz; Kompatibilitätspatches für neuere PHP- und MySQL-Versionen kommen als separate Downloads dazu. Was das Angebot nicht ist, hat Mitgründerin Carmen Bremen schon im März 2023 im Interview mit maxcluster klargestellt: keine Bugfixes, keine neuen Funktionen, Motto „secure, but not keep“. Für ein Übergangsjahr ist das ein sauberes Angebot. Als Strategie ist es keins.
Dazu kommt PHP. Die letzte offizielle Version 5.7.20 erlaubt laut ihrer composer.json höchstens PHP 8.2, und Stand Oktober 2026 gilt das auch für den safefive-Fork. PHP 8.2 bekommt nach php.net nur bis zum 31. Dezember 2026 Sicherheitsupdates. Art. 32 DSGVO verlangt Schutzmaßnahmen nach dem Stand der Technik; wie dein Shop dazu passt, klärst du mit deinem Datenschutzbeauftragten. Ab 2027 läuft ein Shop auf 5.7.20 damit ohne Sicherheitsupdates von Shopware auf einer PHP-Version ohne Sicherheitsupdates.
Die übrigen Risiken im Tagesgeschäft haben wir im Beitrag zu Shopware 5 in 2026 auseinandergenommen. Hier geht es um die ERP-Seite, die dort nur am Rand vorkommt.
Was bei der Shopware-5-Migration auf der ERP-Seite wegfällt
Es liegt nahe, „Shopware 5 auf 6“ wie „Windows 10 auf 11“ zu lesen. Shopware 6 wurde aber auf Symfony neu geschrieben, mit API-first-Architektur und getrenntem Core, Storefront und Administration. Einen Upgrade-Pfad, der den alten Shop aktualisiert, gibt es nicht. Du installierst Shopware 6 neu und migrierst die Daten hinein.
Damit ist jedes Shopware-5-Plugin Geschichte, das ERP-Plugin eingeschlossen, dazu dein Theme. Laut Migrationsdokumentation lassen sich alte Templates weder wiederverwenden noch migrieren, Einkaufswelten nicht übertragen, E-Mail- und Dokumentenvorlagen entstehen neu. Für Hersteller wiegt ein Satz derselben Seite schwerer: Daten der B2B Suite lassen sich nicht nach Shopware 6 übernehmen. Rollen, Freigaben und Budgets, die dort liegen, brauchen einen eigenen Export.
Das Ziel ist solide gewählt: Nach der EHI-Erhebung 2025 bleibt Shopware mit 11,5 Prozent das meistgenutzte System der deutschen Top-1.000-Shops.
Der Umzug ist für Hersteller die Gelegenheit, Sonderlocken infrage zu stellen, die sich über Jahre um das ERP gelegt haben, etwa ein Sperrkennzeichen, das nur das alte ERP-Plugin auswertet, oder ein Händlerpreis, der fest im Template steht. Kurz gesagt: Du baust einen zweiten Shop und ziehst um. Wer das als Update budgetiert, entdeckt die Wahrheit im dritten Sprint.
Ein ERP, zwei Kanäle: Warum die Schnittstelle über den Kanalkonflikt entscheidet
Der Reflex liegt nahe: das alte ERP-Plugin eins zu eins nach Shopware 6 portieren. Gemeint ist ein Plugin oder Skript, das direkt in die Shopware-5-Datenbank schreibt oder die alte REST-API bedient, über Jahre gefüttert mit Sonderfällen wie Staffelpreisen für Händler, Reservierungen und Sperrkennzeichen. Technisch lässt sich das portieren, ich rate trotzdem ab: Die Kopie bindet das Budget, das die neue Integrationsschicht bräuchte, und konserviert Sonderfälle, die nur wegen der alten Datenbank existieren.
Ein konstruiertes Beispiel: Ein Werkzeughersteller mit 6.000 Artikeln verkauft D2C über Shopware 5 und B2B über den Außendienst, die Bestände kommen aus demselben ERP. Das alte Plugin zieht alle 15 Minuten eine CSV und schreibt sie direkt in die Datenbank, Bestellungen gehen nachts als XML zurück. Zwischen zwei Läufen reserviert der Außendienst die letzten 40 Stück eines Artikels, und der D2C-Shop verkauft sie ein zweites Mal. Am Morgen stehen ein Überverkauf, eine Stornierung und ein Händler, der seine Zusage nicht halten kann.
Wichtiger ist die Topologie. Drei Muster sind üblich: ein Plugin im Shop, eine Middleware dazwischen oder eine Integrationsplattform wie Shopware Nexus. Ein Plugin reicht, solange der Shop die einzige Außenverbindung des ERP ist.
Sobald ein zweiter Abnehmer dazukommt, ein Händlerportal, ein Marktplatz, das PIM, kippt die Rechnung: Wer jede dieser Verbindungen in den Shop verlegt, macht ihn zum Integrationsserver, und der nächste Plattformwechsel wird wieder ein ERP-Bruch. Für Hersteller mit Handelsvertrieb rate ich deshalb zur Middleware, die Bestände und Preise einmal hält und an Shop, Portal und Marktplatz verteilt.
Für den Werkzeughersteller heißt das: Die Bestände liegen in der Middleware, Shopware 6 bekommt alle 6.000 als Bulk-Upsert über den Sync-Endpunkt der Admin API. Das Händlerportal speist sich aus derselben Quelle, und eine Reservierung des Außendiensts senkt den verfügbaren Bestand sofort in beiden Kanälen. Bestellungen holt das ERP über die Admin API ab, die Store API bedient das Frontend (Integrations-Guide).
Direkte Schreibzugriffe auf die Datenbank, so bequem sie in Shopware 5 waren, würde ich nicht mehr bauen. Shopware nennt die Repositories seiner Datenabstraktionsschicht den empfohlenen Weg in die Datenbank, und erst ein Schreibvorgang über sie stößt die Indexer an.
Das ist der Kanalkonflikt, der bei Herstellern technisch wird: Preise, Bestände und Kundendaten laufen durch die Schnittstelle, und dort entscheidet sich, ob Handel und D2C sich in die Quere kommen. Eine Befragung von techconsult im Auftrag von SYBIT unter 200 Konsumgüterunternehmen ab 250 Mitarbeitenden in DACH (Pressemitteilung vom 01.10.2026) passt dazu: 56 Prozent sehen die Integration von D2C in bestehende Vertriebsstrukturen als Hürde, gut ein Drittel nennt Konflikte um Preise und Margen.
Bestellungen, Medien, Kunden: Wo der Migration Assistant auf dein ERP trifft
Shopwares Migration Assistant verbindet den alten Shop per Connector-Plugin mit der neuen Installation. Er überträgt Produkte mit Varianten und Übersetzungen, Kunden und Bestellungen samt Belegen, Medien und SEO-URLs.
| Datenobjekt | Migration Assistant | Deine Aufgabe |
|---|---|---|
| Produkte, Varianten, Eigenschaften, Übersetzungen | übernimmt | Feldmapping gegen das ERP prüfen |
| Kunden, Kundengruppen, Bestellungen inkl. Belege | übernimmt | Kundengruppen und Händlerkonten gegen das ERP prüfen |
| Bestell-, Liefer- und Zahlungsstatus | Premapping beim Migrieren | Status-Mapping mit dem ERP abgleichen |
| Medien, Bewertungen, Aktionen | übernimmt | Ordnerstruktur und Dubletten bereinigen |
| SEO-URLs | übernimmt | Redirect-Mapping für geänderte Pfade ergänzen |
| Zahlungsarten, Anreden, Lieferzeiten | manuelles Mapping | vorher in Shopware 6 anlegen |
| Versandkosten | nicht automatisch | neu anlegen |
| Templates, Einkaufswelten, E-Mail- und Dokumentenvorlagen | nicht möglich | neu bauen |
| Felder aus Plugins | zusätzliches Mapping | selbst mappen |
| B2B-Suite-Daten | nicht möglich | Export und Import selbst lösen |
Was ein Plugin in Shopware 5 in eigenen Tabellen gehalten hat, etwa Seriennummern, Händlerzuordnungen oder Projektpreise, kennt der Assistant nur als zusätzliche Felder, die du selbst mappst. Bei Herstellern können das genau die Daten sein, die auch das ERP führt.
Shopware 6 führt Bestellung, Lieferung und Zahlung als drei getrennte State Machines mit wenigen Standardzuständen, erweiterbar über die API (Order-Konzept). Beim Migrieren fragt der Assistant für jeden Shopware-5-Status ab, welchem Shopware-6-Zustand er entspricht; vorbelegt sind nur die Standardstatus (Premapping im Quellcode). Ein Auftragsstatus wie „Rückstand, Liefertermin aus Werk 2 offen“ hat in Shopware 6 keinen Gegenpart.
Steht er schon in Shopware 5, ordnest du ihn im Premapping zu. Legst du vorher keinen eigenen Zustand an, bleibt nur der nächstliegende Standard, etwa „In Bearbeitung“, und der Kunde sieht im Konto weniger als vorher am Telefon. Kennt nur das ERP diesen Status, migriert ihn niemand; dann gehört er in die Synchronisation vom ERP in den Shop.
Deshalb mein Rat zur Reihenfolge: Erst klären, welche Daten künftig im ERP führend sind und welche im Shop, dann migrieren. Ein Bestand, der im Shop gepflegt wird, obwohl das ERP ihn kennt, ist nach der Migration doppelt falsch: zwei Pflegestellen, zwei Zahlen, und der Händler sieht eine andere als der D2C-Kunde.
Fahrplan: Von der Schnittstellenliste zum Abgleich am ersten Morgen
Der teuerste Fehler, den ein Fahrplan machen kann, ist die Reihenfolge: erst Design, dann Shop, dann „Schnittstelle anbinden“ als letzter Punkt vor dem Go-live. Bei Herstellern gehört die Schnittstelle an den Anfang, weil sie festlegt, welche Daten der Shop führt und welche er nur anzeigt.
Am Anfang steht die Schnittstellenliste. Sie erfasst jeden Datenfluss zwischen ERP und Shop mit Richtung, Takt und Sonderfällen, dazu jede Plugin-Tabelle mit Daten, die das ERP nicht kennt. Eine Zeile sieht so aus: Bestände, ERP an Shop, alle 15 Minuten, Außendienst-Reservierungen vorher abziehen. Auf dieser Liste baut das Angebot für die Migration auf, und dein ERP-Dienstleister zeichnet sie gegen.
Gegen die leere Shopware-6-Installation laufen dann die ERP-Flüsse, bevor ein einziger Kunde migriert ist. Zahlungsarten, Lieferzeiten, Anreden und Versandkosten sind angelegt, die Middleware steht, das Theme entsteht parallel.
Die Datenmigration läuft mehrfach. Der erste Volllauf ist ein Test: Mapping-Lücken wie den Rückstands-Status oder verwaiste Plugin-Felder siehst du erst, wenn echte Daten durch den Connector gelaufen sind. Folgeläufe übertragen nur neue und geänderte Datensätze, bis der letzte Lauf vor dem Go-live nur noch die Bestellungen der letzten Stunden holt.
Für den Go-live empfehle ich ein Bestellstopp-Fenster von wenigen Stunden: Der Shop nimmt nichts an, damit der letzte Lauf nichts verpasst, während das Händlergeschäft im ERP weiterläuft. Das Redirect-Mapping für geänderte Pfade bleibt Handarbeit; wie das ohne Ranking-Verlust geht, steht im Beitrag zur Shop-Migration ohne SEO-Verlust. Am ersten Morgen gleichst du mit dem ERP ab, ob Bestände, Preise und offene Aufträge stimmen, also genau die Zahlen, an denen beim Werkzeughersteller der Überverkauf hing.
Zu den Kosten nur ein Rahmen: Unsere Festpreis-Seite zur Shopware-Migration nennt ab 15.000 Euro für kleine B2C-Shops und ordnet Shops mit ERP-Anbindung deutlich darüber ein. Bei Herstellern geht ein großer Teil davon in die Schnittstelle zu ERP, PIM und WMS.
Fazit: Die Integrationsschicht gleich mit neu bauen
Die eigentliche Frage für Hersteller ist, ob du die Integrationsschicht beim Umzug mit neu denkst oder das alte Plugin in neuem Gewand nachbaust. Wer das alte ERP-Plugin kopiert, bezahlt einen kompletten Neuaufbau und bekommt die alte Schnittstelle zurück.
Meine Position: neu denken. Fang mit der Schnittstellenliste an, eine Zeile pro Datenfluss, bevor jemand über das Theme spricht. Der Cronjob aus dem ersten Absatz darf in Rente gehen, aber nicht, damit ein neuer Cronjob dieselbe CSV in eine neue Datenbank schreibt. Baut eure Schnittstelle so, dass sie auch den übernächsten Shop überlebt.
