Die meisten Magento-zu-Shopware-Migrationen scheitern nicht am Datenimport. Sie scheitern an dem, was der Importer nicht anfasst, und das merkt man oft erst, wenn der neue Shop schon live ist.
Das ist die unbequeme Wahrheit hinter einem Projekt, das auf dem Papier harmlos aussieht. Shopware liefert ein kostenloses Werkzeug, das Produkte, Kunden und Bestellungen aus der Magento-Datenbank zieht. Demo läuft, Zahlen erscheinen, Häkchen grün. Genau diese Glätte ist die Falle. Die eigentliche Arbeit, und das eigentliche Risiko, liegt in den Bereichen, die der Assistent bewusst offenlässt: Frontend, Schnittstellen, Geschäftslogik, SEO. Wer das Projekt entlang des Importers plant statt entlang dieser Lücken, kalkuliert das falsche Projekt.
Dieser Artikel ist für Händler und Teams, die den Wechsel auf Shopware 6 grundsätzlich entschieden haben und jetzt wissen wollen, wo es im Detail klemmt. Ob sich der Wechsel überhaupt lohnt, ist eine andere Frage. Hier geht es um die Umsetzung: die fünf Herausforderungen, an denen Migrationsprojekte real hängenbleiben, und wie du sie vorab einplanst, statt sie hinterher zu reparieren.
Der Zeitdruck ist dabei kein Hirngespinst. Für Magento Open Source 2.4.6 endet der Support am 11. August 2026, für 2.4.7 im April 2027. Ein „Magento 3" ist nicht geplant; Adobe hat die strategische Richtung auf cloud-native Dienste verlagert. Das macht aus dem Replatforming für viele Bestandsshops keine Stil-, sondern eine Terminfrage.
Herausforderung 1: Der Importer migriert Daten, aber nicht sauber
Fangen wir bei dem an, was am unverdächtigsten wirkt. Shopware stellt mit dem Migration Assistant ein kostenloses Plugin bereit, das über das Magento-Migrationsprofil Magento 1 und 2 als Quellsysteme unterstützt. Die neue Shopware-Installation verbindet sich lesend mit der Magento-Datenbank, an der Quelle wird nichts verändert, und überträgt Produkte, Kategorien, Hersteller, Kunden, Bestellungen und Medien.
So weit das Marketing. In der Praxis hat genau dieses Profil dokumentierte Schwächen, vor allem bei Bestelldaten. Bestellungen werden teilweise als Netto-Aufträge importiert, obwohl sie Brutto sein müssten. Lieferadresse, Versandart, Versandstatus und Versandkosten fehlen nach dem Import. Die Tabelle, die Shopware für die korrekte Steuerberechnung der Positionen braucht (order_delivery_position), bleibt leer. Das sind keine kosmetischen Mängel. Das sind falsche Zahlen in der Buchhaltungs- und Bestellhistorie, und sie fallen erst auf, wenn jemand eine alte Rechnung nachschlägt oder die Umsatzsteuer am Monatsende nicht aufgeht.
Kurz gesagt: Der Importer ist ein guter erster Aufschlag, kein fertiger Umzug. Bestelldaten gehören nach der Migration stichprobenartig geprüft und nicht blind übernommen. Historische Bestellungen sind ohnehin ein Sonderfall. Viele Projekte migrieren sie bewusst nicht 1:1, sondern archivieren sie separat und starten Shopware mit einem sauberen Bestellstamm. Für die meisten Händler ist das die belastbarere Lösung, weil die Buchhaltung dann auf einem System ohne stille Importfehler aufsetzt.
Herausforderung 2: Die Datenmodelle passen nicht aufeinander
Der Grund für diese Reibung liegt tiefer als in einem fehlerhaften Plugin. Magento und Shopware beschreiben dieselben Dinge, ein Produkt, eine Variante, ein Attribut, auf grundverschiedene Weise.
Magento speichert Produktdaten im EAV-Modell (Entity-Attribute-Value), einer hochflexiblen, aber zersplitterten Struktur, in der ein einzelnes Produkt über Dutzende Tabellen verteilt liegt. Shopware 6 nutzt ein moderneres, klarer geschnittenes Entitätsmodell. Zwischen beiden gibt es keine 1:1-Übersetzung, besonders nicht bei Varianten. Ein Beispiel, an dem Migrationen real stocken: ein konfigurierbares Produkt mit drei Achsen, etwa Größe mal Farbe mal Material. In Magento hängen die Varianten als eigene „configurable product"-Konstruktion an einem Elternprodukt, in Shopware entstehen sie aus Eigenschaften (Properties) und einer Variantenmatrix. Wer die Magento-Struktur stumpf überträgt, bekommt entweder doppelte Produkte, fehlende Kombinationen oder Varianten, die der Kunde im Shop nicht mehr auswählen kann. Genau deshalb braucht es in vielen Projekten ein Mapping-Skript oder ein Middleware-Werkzeug, das die Magento-Logik in die Shopware-Logik überführt. Nach unserer Erfahrung ist eine Magento-Migration damit aufwändiger als ein Umstieg von Shopware 5 auf 6, wo die Strukturen wenigstens verwandt sind.
Praktisch heißt das: Je individueller dein Magento-Datenmodell ist (viele eigene Attribute, komplexe Varianten-Achsen, gewachsene Kategoriestrukturen), desto weniger trägt der Standard-Importer und desto mehr wird die Migration zum Datenprojekt. Saubere Produktdaten sind hier kein Nebenschauplatz; ein durchdachtes Produktdatenmanagement entscheidet darüber, ob die Migration ein Umzug oder ein Neuaufbau des Katalogs wird.
Herausforderung 3: Extensions ohne Pendant, der eigentliche Kostentreiber
Wenn ein Migrationsprojekt aus dem Budget läuft, liegt es selten an den Produkten. Es liegt an einer Magento-Extension, für die es in Shopware nichts Gleichwertiges gibt.
Jeder gewachsene Magento-Shop trägt eine Schicht aus Erweiterungen: ein Produktkonfigurator, eine spezielle Steuer- oder Preislogik für B2B-Staffeln, eine ERP-Anbindung, ein Marktplatz-Connector, ein selbstgebautes Bonusprogramm. Nimm die ERP-Anbindung als Beispiel, weil sie fast jeden Shop betrifft. In Magento war das oft ein fertig gekauftes Connector-Plugin, einmal installiert, konfiguriert, läuft. In Shopware existiert für genau dieses ERP womöglich kein passendes Plugin, und dann wird aus dem gekauften Connector eine Eigenentwicklung mit Anforderungsanalyse, Schnittstellen-Design und Testphase. Aus einem Konfigurationsposten wird ein Entwicklungsposten. Diese Verschiebung ist der Grund, warum die Extension-Frage Zeitpläne kippt, nicht die Produktzahl.
Welcher Weg pro Funktion der richtige ist (vorhandenes Shopware-Plugin, Eigenentwicklung oder externe Anbindung), lässt sich nur einzeln entscheiden, nicht pauschal. Genau deshalb ist die Extension-Inventur die wichtigste Aufgabe der gesamten Vorbereitung, und sie wird am häufigsten unterschätzt. Wer am Anfang ehrlich auflistet, welche Extension welchem Geschäftsprozess dient und was davon wirklich erhaltenswert ist, hat die halbe Projektkalkulation in der Hand. Oft entpuppt sich die Migration sogar als Gelegenheit, jahrelang mitgeschleppte Funktionen endlich auszusortieren. Die wirklich geschäftskritischen Schnittstellen zu ERP, PIM und CRM dagegen gehören in eine saubere API-Integration und Drittanbieter-Anbindung, und sie sind es, die den Zeitplan bestimmen.
Herausforderung 4: Das Frontend ist ein Neubau, keine Migration
Hier räumen wir mit dem hartnäckigsten Missverständnis auf: Das Design wandert nicht mit. Es kann nicht mitwandern.
Magento-Themes basieren auf Luma oder PWA Studio, Shopware 6 auf Twig-Templates und für composable Setups auf den Vue/Nuxt-basierten Shopware Frontends. Das sind unterschiedliche Technologien, die nichts gemeinsam haben außer dem Zweck, einen Shop anzuzeigen. Es gibt keinen Konverter, der ein Magento-Theme in ein Shopware-Theme verwandelt. Das Frontend wird in jedem Migrationsprojekt neu aufgebaut: Storefront-Templates, Komponenten, Checkout-Anpassungen, das Responsive-Verhalten. Wer schon einmal einen Checkout mit drei Zahlarten, Gutschein-Logik und B2B-Preisanzeige nachgebaut hat, weiß, dass darin Wochen stecken, nicht Tage.
Das klingt nach Mehrarbeit, ist aber die eigentliche Chance der Migration. Statt ein in die Jahre gekommenes Theme zu konservieren, baust du die Storefront auf dem aktuellen Stand neu: performanter, wartbarer und gleich barrierefrei. Shopware 6.7 (Mai 2025) hat die Standardthemes gezielt auf die Anforderungen des European Accessibility Act ausgerichtet, mit semantischem HTML. Das trifft sich gut, denn die Barrierefreiheit nach BFSG ist für Onlineshops bereits seit dem 28. Juni 2025 Pflicht, nicht erst künftig. Wer ohnehin neu baut, nimmt sie direkt mit, statt sie nachträglich unter Druck nachzurüsten. Den Frontend-Neubau trotzdem als „Migration" zu budgetieren ist einer der teuersten Planungsfehler. Er ist ein Entwicklungsprojekt mit eigenem Scope.
Herausforderung 5: SEO, das größte Geschäftsrisiko des ganzen Projekts
Und damit zum Punkt, der über Erfolg oder Misserfolg entscheidet, technisch unscheinbar und kaufmännisch riesig: die URLs.
Magento und Shopware bauen ihre URL-Strukturen unterschiedlich auf. Eine Magento-Produktseite läuft im Zweifel über einen Pfad wie /catalog/product/view/id/1234, während Shopware standardmäßig sprechende URLs erzeugt. Wenn beim Relaunch jede Produkt- und Kategorieseite eine neue Adresse bekommt und die alten ins Leere laufen, verlierst du in einem Schlag die Rankings, die über Jahre entstanden sind, und damit den organischen Traffic, der den Umsatz trägt. Stell dir 5.000 Produktseiten vor, jede mit Jahren an aufgebautem Linkjuice, die am Tag des Go-live alle auf 404 zeigen. Das ist kein hypothetisches Risiko, sondern der häufigste Grund, warum ein technisch sauberer Relaunch trotzdem Geld kostet. Ein Einbruch der organischen Sichtbarkeit über Wochen oder Monate ist teurer als jede Extension-Neuentwicklung.
Die Absicherung ist konzeptionell simpel und in der Ausführung fehleranfällig: ein vollständiges Redirect-Mapping, das jede alte Magento-URL per 301 auf ihr neues Shopware-Pendant lenkt, plus Übernahme von Meta-Daten, strukturierten Daten und einer korrekten XML-Sitemap. „Vollständig" ist das entscheidende Wort. Es reicht nicht, die Top-100-Seiten umzuleiten, denn gerade der lange Tail aus tausenden Produkt- und Filterseiten trägt in der Summe den größten Teil des organischen Traffics. Dieses Mapping gehört in die Projektplanung von Tag eins an, nicht in die Woche vor dem Go-live.
Kurz gesagt: Die Migration ist erst dann fertig, wenn Google den neuen Shop genauso findet wie den alten. Alles davor ist Technik; das hier ist Geschäft.
Was das für deine Projektplanung heißt
Fügt man diese fünf Herausforderungen zusammen, ergibt sich ein realistisches Bild, und es sieht anders aus als die Marketing-Demo des Importers. Eine Magento-zu-Shopware-Migration ist selten ein reiner Datenumzug. Sie ist ein Replatforming-Projekt mit fünf parallelen Baustellen, von denen der Datenimport die kleinste ist. Als groben Zeitrahmen sind, je nach Komplexität, drei bis sechs Monate realistisch.
Mein Rat als jemand, der solche Projekte begleitet: Mach die Extension-Inventur und das Redirect-Konzept zur ersten Aufgabe, nicht zur letzten. Behandle Frontend und Schnittstellen als das, was sie sind, nämlich Entwicklungsprojekte mit eigenem Budget. Und prüfe die importierten Bestelldaten, bevor du dich auf sie verlässt. Der nächste konkrete Schritt ist deshalb keine Migration auf Verdacht, sondern eine ehrliche Bestandsaufnahme: Welche Extensions hängen an welchem Geschäftsprozess, wie sieht das URL-Inventar aus, wo liegen die Schnittstellen? Diese Standortbestimmung ist die Grundlage jeder belastbaren Shopware-Migration mit erfahrener Begleitung. Sie kostet ein paar Tage und spart die Monate, die ein blind gestartetes Projekt verbrennt.
Denn die eingangs gestellte Rechnung bleibt dieselbe: Wer das Projekt entlang des Importers plant, kalkuliert das falsche Projekt. Wer es entlang der fünf Lücken plant, kalkuliert das richtige, und erlebt am Go-live-Tag keine Überraschungen.
