Der Shopware Migration Assistant ist ein kostenloses Plugin von Shopware, das Daten aus einem bestehenden Shopsystem in eine Shopware-6-Installation überträgt. Über austauschbare Migrationsprofile unterstützt er unter anderem Shopware 5 sowie Magento 1 und 2 als Quellsysteme. Er ist das Standardwerkzeug für den Datenteil eines Replatformings — deckt aber bewusst nur einen Teil einer vollständigen Migration ab.
Was der Migration Assistant ist und wie er arbeitet
Der Migration Assistant (technisch das Plugin SwagMigrationAssistant) wird in der neuen Shopware-6-Installation installiert. Er verbindet sich lesend mit der Datenbank des Quellsystems: Am alten Shop wird nichts verändert, er bleibt während der Migration unangetastet und weiter betreibbar. Der Assistant liest die Quelldaten aus, ordnet sie über ein Mapping den passenden Shopware-Entitäten zu und schreibt sie in die neue Installation.
Ein zentrales Merkmal ist die Wiederholbarkeit: Eine Migration kann mehrfach laufen, ohne Dubletten zu erzeugen, weil der Assistant sich merkt, welcher Quelldatensatz auf welchen Zieldatensatz abgebildet wurde. So lässt sich erst eine Teilmenge testen und später erneut abgleichen, wenn am Quellshop noch Bestellungen oder Kunden hinzugekommen sind.
Unterstützte Quellsysteme und Profile
Die Quellsystem-Unterstützung steckt in austauschbaren Migrationsprofilen. Ab Werk bringt der Assistant das Profil für Shopware 5 mit. Weitere Profile kommen als eigene Erweiterungen hinzu:
- Shopware 5: der Standardfall, im Assistant direkt enthalten.
- Magento 1 und 2: über das separate Magento-Migrationsprofil aus dem Shopware-Store.
- Weitere Profile (etwa für Gambio oder OXID) stammen aus der Community bzw. von Drittanbietern.
Für eine Migration von Magento werden also zwei Bausteine gebraucht: der Migration Assistant selbst und zusätzlich das Magento-Migrationsprofil. Erst beide zusammen verbinden eine Magento-1.9- oder Magento-2-Datenbank mit Shopware 6.
Welche Daten übertragen werden
Der Assistant deckt die strukturierten Stammdaten ab, die den Kern eines Shops ausmachen:
| Datenart | Beispiele |
|---|---|
| Katalog | Produkte, Varianten, Kategorien, Hersteller, Eigenschaften |
| Kunden | Kundenkonten, Adressen, Kundengruppen |
| Bestellungen | Bestellungen und Bestellpositionen (mit Einschränkungen) |
| Medien | Produktbilder und Medienordner |
| Konfiguration | Sprachen, Währungen, Steuersätze, Lieferländer |
Grenzen und bekannte Schwächen
Der Migration Assistant ist ein guter erster Aufschlag, kein fertiger Umzug. Er überträgt Daten, nicht das Erscheinungsbild und nicht die Funktionslogik eines Shops. Drei Bereiche bleiben grundsätzlich offen:
- Frontend und Theme: Magento-Themes (Luma, PWA Studio) lassen sich nicht in Shopware-Themes (Twig, Shopware Frontends) überführen. Das Frontend wird neu gebaut.
- Erweiterungen: Magento-Extensions haben kein automatisches Shopware-Pendant. Jede individuelle Funktion muss neu bewertet und ggf. neu entwickelt werden.
- Individuelle Geschäftslogik und Schnittstellen: ERP-, PIM- oder CRM-Anbindungen werden nicht migriert, sondern neu angebunden.
Auch bei den reinen Daten gibt es beim Magento-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; und die Tabelle, die Shopware für die korrekte Steuerberechnung der Positionen braucht, bleibt leer. Solche Importergebnisse gehören nach der Migration stichprobenartig geprüft, nicht blind übernommen. Viele Projekte migrieren historische Bestellungen deshalb bewusst nicht eins zu eins, sondern archivieren sie separat und starten Shopware mit einem sauberen Bestellstamm.
Ablauf einer Migration mit dem Assistant
In der Praxis folgt eine Migration mit dem Assistant einem wiederkehrenden Muster:
- Verbindung herstellen: Quellsystem und Zugangsdaten im Assistant hinterlegen; bei Magento zusätzlich das Magento-Profil installieren.
- Daten prüfen (Check): Der Assistant analysiert, welche Datenarten erkannt werden und wo es Lücken oder Konflikte gibt.
- Mapping bestätigen: Quell-Werte (z. B. Kundengruppen, Steuersätze, Lieferländer) werden den Shopware-Pendants zugeordnet.
- Migration ausführen: Der eigentliche Datentransfer läuft, idealerweise zuerst auf einem Testsystem.
- Nacharbeit und erneuter Abgleich: Bestelldaten verifizieren, fehlende Felder ergänzen, später hinzugekommene Datensätze erneut migrieren.
Weil Frontend, Schnittstellen und individuelle Funktionen den Ausschlag geben, ist der Migration Assistant nur der Anfang eines Replatformings. Ein realistischer Gesamtzeitrahmen für eine Magento-zu-Shopware-Migration liegt, je nach Komplexität, bei drei bis sechs Monaten.
Voraussetzungen und Einrichtung
Für eine Migration braucht es eine lauffähige Shopware-6-Installation, in der der Migration Assistant installiert und aktiviert ist, sowie einen lesenden Zugang zur Quelldatenbank. Bei einer Magento-Migration kommt das Magento-Migrationsprofil hinzu, das die Magento-spezifischen Tabellen kennt. Die Verbindung wird im Shopware-Adminbereich unter „Einstellungen → Migrationsassistent" eingerichtet: Datenbank-Host, Name, Benutzer und Passwort des Quellsystems sowie der Pfad zu den Medien-Dateien werden hinterlegt.
Wichtig ist, dass die Medien (Produktbilder) erreichbar sind — entweder über eine URL des noch laufenden Quellshops oder über einen lokalen Pfad. Fehlt dieser Zugriff, migrieren zwar die Datensätze, aber die Bilder bleiben leer. Schon an dieser Stelle zeigt sich, dass eine Migration Planung braucht: Der alte Shop muss während des Transfers erreichbar bleiben.
Wann sich der Migration Assistant lohnt — und wann nicht
Der Assistant ist das Mittel der Wahl, wenn ein bestehender Shop mit gewachsenem Datenbestand nach Shopware 6 umziehen soll und die Stammdaten — Produkte, Kunden, Bestellungen — erhalten bleiben müssen. Gerade bei Shopware-5-zu-6-Umzügen ist er nahezu konkurrenzlos, weil Quell- und Zielsystem aus demselben Haus stammen und das Mapping entsprechend ausgereift ist.
Weniger geeignet ist er, wenn ohnehin ein kompletter Neuaufbau mit frischem Katalog geplant ist. Wer sein Sortiment grundlegend neu strukturiert, fährt mitunter besser, die Produktdaten direkt aus einem PIM oder per gezieltem Import aufzubauen, statt Altlasten mitzuschleppen. Auch bei sehr exotischen Quellsystemen ohne fertiges Profil kann ein individueller Import wirtschaftlicher sein als die Entwicklung eines eigenen Profils. Die Entscheidung gehört an den Anfang des Projekts, nicht in die Umsetzungsphase.
Architektur: Reader, Converter und Writer
Technisch arbeitet der Migration Assistant in drei Schritten, die das Prinzip jeder sauberen Datenmigration abbilden. Ein Reader liest die Rohdaten aus dem Quellsystem aus — bei Magento direkt aus den EAV-Tabellen der Quelldatenbank. Ein Converter übersetzt diese Rohdaten in das Format der Shopware-Entitäten und legt dabei in einer Mapping-Tabelle ab, welcher Quelldatensatz auf welchen Zieldatensatz abgebildet wurde. Ein Writer schreibt die konvertierten Daten schließlich über die Data Abstraction Layer in die Shopware-Datenbank.
Diese Trennung erklärt zwei Eigenschaften des Werkzeugs: Erstens ist die Migration wiederholbar, weil die Mapping-Tabelle Dubletten verhindert. Zweitens ist sie erweiterbar — eigene Migrationsprofile oder zusätzliche Datenkonverter lassen sich als Plugins ergänzen, etwa um die Daten einer individuellen Magento-Extension mitzunehmen, die der Standard nicht kennt.
Migration Assistant gegenüber manuellem Export und Import
Theoretisch lässt sich eine Migration auch per CSV-Export und -Import oder per selbstgeschriebenem Skript erledigen. In der Praxis spricht einiges für den Assistant: Er kennt die Quellstruktur (etwa Magentos EAV-Aufbau), pflegt das Mapping automatisch und ist auf Wiederholbarkeit ausgelegt. Ein reiner CSV-Weg verliert dagegen schnell Beziehungen zwischen Datensätzen — welche Variante zu welchem Elternprodukt gehört, welche Bestellung zu welchem Kunden.
Umgekehrt stößt der Assistant dort an Grenzen, wo die Datenstrukturen grundverschieden sind oder eine individuelle Logik mitwandern soll. Dann ergänzt ein Mapping-Skript oder eine Middleware den Standardweg. Die Faustregel: Der Assistant übernimmt die strukturierten Massendaten zuverlässig, die Sonderfälle bleiben Projektarbeit.
Best Practices für eine saubere Migration
- Immer zuerst auf einem Testsystem migrieren und das Ergebnis prüfen, bevor das Produktivsystem entsteht.
- Bestelldaten gezielt verifizieren — gerade beim Magento-Profil, dessen Steuer- und Versandfelder bekannte Lücken haben.
- Den Umfang bewusst begrenzen: Müssen alle historischen Bestellungen mit, oder genügt ein sauberer Start mit archivierten Altbestellungen?
- Mehrfach abgleichen: kurz vor dem Go-live die zwischenzeitlich entstandenen Datensätze erneut migrieren, damit nichts verloren geht.
- Frontend, Extensions und Schnittstellen früh als eigene Arbeitspakete planen — der Assistant deckt sie nicht ab.
Richtig eingesetzt, nimmt der Migration Assistant den mühsamsten, fehleranfälligsten Teil eines Replatformings ab: den Transport der Stammdaten. Er ersetzt aber kein Projekt — er ist dessen erster, gut automatisierter Schritt.
Mehrsprachige Shops und Mehr-Shop-Setups
Anspruchsvoll wird eine Migration, wenn das Quellsystem mehrere Sprachen, Währungen oder eigenständige Verkaufskanäle führt. Magento bildet das über Websites, Stores und Store-Views ab, Shopware 6 über Verkaufskanäle (Sales Channels) und Sprachen. Diese Strukturen entsprechen einander nicht eins zu eins, weshalb das Mapping im Migrationsassistenten bewusst gesetzt werden muss: Welche Magento-Store-View wird zu welcher Shopware-Sprache, welche Website zu welchem Verkaufskanal?
Gerade hier zahlt sich eine Testmigration aus. Erst im Testsystem zeigt sich, ob Übersetzungen, Preise je Kanal und Kundengruppen korrekt landen. Werden diese Zuordnungen übersehen, entstehen typische Folgefehler — fehlende Übersetzungen, falsch zugeordnete Preise oder Produkte, die im falschen Kanal auftauchen. Für internationale Händler ist dieser Teil der Migration oft aufwändiger als der reine Produkttransfer.
Häufige Fragen zum Shopware Migration Assistant
Was kostet der Migration Assistant? Das Plugin ist kostenlos. Für Magento wird zusätzlich das Magento-Migrationsprofil benötigt, das ebenfalls über den Shopware-Store bezogen wird.
Verändert der Assistant den alten Shop? Nein. Er greift nur lesend auf die Quelldatenbank zu; der alte Shop bleibt unverändert und weiter betreibbar.
Migriert der Assistant auch das Theme? Nein. Design und Frontend werden nicht übertragen, sondern in Shopware neu aufgebaut.
Kann ich die Migration mehrfach laufen lassen? Ja. Der Assistant merkt sich die Zuordnung von Quell- zu Zieldatensätzen und kann erneut abgleichen, ohne Dubletten zu erzeugen.
Reicht der Migration Assistant für eine komplette Migration? Nein. Er deckt die strukturierten Stammdaten ab. Frontend, Extensions, Geschäftslogik, Schnittstellen und das SEO-Redirect-Mapping bleiben Projektarbeit.
Unterstützt der Assistant auch Magento 1? Ja. Das Magento-Migrationsprofil deckt sowohl Magento 1.9 als auch Magento 2 als Quellsysteme ab. Da Magento 1 seit 2020 ohne Sicherheitsupdates ist, ist es ein häufiger Ausgangspunkt für Migrationen.
Wie lange dauert eine Migration mit dem Assistant? Der reine Datentransfer hängt von Katalog- und Bestellmenge ab und reicht von Minuten bis zu mehreren Stunden. Der eigentliche Zeitfaktor eines Replatformings ist jedoch nicht der Transfer, sondern Frontend, Schnittstellen und Tests — in Summe meist drei bis sechs Monate.
Weiterführend: die offizielle Dokumentation beschreibt den Migrationsprozess im Detail in der Shopware-Migrationsdokumentation.