Magento zu Shopware Migration: Der Importer ist das kleinste Problem

Die eigentliche Arbeit liegt in der Abbildung von Magentos EAV-Datenmodell auf Shopware-Entitäten, dem Neuaufbau des Frontends und dem Ersetzen der Extensions. Wer sein Budget daran ausrichtet, was der Importer kostet, hat etwa ein Drittel des Projekts kalkuliert.

Wir entwickeln seit Jahren auf beiden Plattformen. Dieser Artikel beschreibt, was der Importer leistet, wo er aufhört – und wann ein Verbleib auf Magento die bessere Entscheidung ist. Die allgemeine Migrationsmethodik findest du im Shopware-5-zu-6-Migrations-Artikel und im Replatforming Guide; hier konzentrieren wir uns auf das, was Magento-spezifisch ist.

Was dieser Artikel behandelt

• Warum Magento-Händler 2026 wechseln – und wann sie es nicht sollten

• Was das Shopware-Magento-Migrationsprofil überträgt und was nicht

• Wie Magentos EAV-Modell auf Shopware-Entitäten abgebildet wird

• Was neu gebaut wird: Frontend, Extensions, Integrationen

• Zeitplan und Budget-Realitäten

• Wann ein Verbleib auf Magento sinnvoller ist

Warum Händler 2026 von Magento zu Shopware migrieren

Drei Kräfte treiben die meisten Projekte an: Adobes Ausrichtung mit Magento, die sich mit jeder Extension vergrößernde Gesamtkostenlücke und die Tatsache, dass die Shopware B2B Suite für Mid-Market-Händler Feature-Parität erreicht hat.

Adobe Commerce Cloud ist Enterprise-Software – so bepreist und so gemanagt. Händler, die nicht den gesamten Adobe Experience Cloud Stack benötigen, sehen sich mit Lizenzkosten, verpflichtenden Serviceverträgen und einem Release-Rhythmus konfrontiert, den sie nicht beeinflussen können. Magento Open Source löst das Lizenzproblem, entfernt aber die Supportstruktur: Händler sind dann selbst für Sicherheits-Patches, PHP-Upgrades und Extension-Kompatibilität verantwortlich.

Extension-Kosten sind der zweite Hebel. Eine typische Mid-Market-Magento-Installation trägt 20–40 bezahlte Extensions. Jede hat ihre eigene Kompatibilitätsmatrix, ihren eigenen Update-Zyklus und ihren eigenen Support-Vertrag. Jedes Magento Minor Release löst einen Kompatibilitätscheck über den gesamten Stack aus. Shopware liefert mehr Funktionalität im Core, und der Extension-Marktplatz ist kleiner, aber kuratierter.

Der dritte Faktor ist das Frontend. Magentos Luma- und Blank-Themes altern; Hyvä hat die Situation verbessert, erfordert aber ein eigenes Ökosystem kompatibler Extensions. Shopwares Storefront ist eine saubere Twig-basierte Schicht, und Shopware Frontends (die Headless-Option) nutzt eine dokumentierte API, die sich nicht mit jedem Minor Release ändert.

Wann du nicht migrieren solltest

Shopware ist nicht die richtige Antwort für jeden Magento-Händler. Prüfe vor der Scoping-Phase, ob eines der folgenden Szenarien zutrifft.

Du betreibst Adobe Commerce und nutzt aktiv das B2B-Modul, Shared Catalogues oder die Adobe Experience Cloud Integrationen (AEM, Target, Analytics). Die Shopware B2B Suite deckt viele Szenarien ab, aber die Adobe-Stack-Integrationen haben kein Äquivalent in Shopware – ihr Neuaufbau ist ein eigenständiges Projekt.

Dein Katalog umfasst mehr als 500.000 SKUs mit komplexen konfigurierbaren Produkten und Custom Options. Shopware verarbeitet große Kataloge, aber das Datenmapping vom Magento Configurable/Simple-Product-Modell auf Shopwares Varianten-System erfordert sorgfältige Planung; Performance-Tests im Produktionsmaßstab sollten vor der Entscheidung stattfinden.

Du hast das Magento-Admin stark angepasst oder interne Tools gegen die Magento-API gebaut. Diese Integrationen müssen gegen Shopwares Admin-API neu gebaut werden, die eine andere Struktur und ein anderes Authentifizierungsmodell hat.

Trifft keines davon zu, ist Shopware ein realistisches Migrationsziel. Trifft eines davon zu, kalkuliere die Rebuild-Kosten, bevor du entscheidest.

Was das Shopware-Magento-Migrationsprofil leistet

Shopware liefert ein Migration-Assistant-Plugin, das sich mit einer Magento-2-Datenbank verbindet und Daten über ein vordefiniertes Profil importiert. Das Profil übernimmt:

• Kunden und Adressen

• Bestellungen und Bestellpositionen (Statusmapping ist konfigurierbar)

• Produkte: einfache, konfigurierbare, virtuelle und herunterladbare

• Kategorien und Kategoriebaum

• CMS-Seiten und -Blöcke (einfacher Content, kein Page Builder)

• Produktbilder (werden vom Quellshop heruntergeladen)

• Kundengruppen

• Steuerregeln und -sätze

• Eigenschafts-Sets und Attribute (auf Shopware-Properties und Custom Fields gemappt)

Der Importer läuft im Shopware-Admin. Er liest direkt aus der Magento-2-Datenbankverbindung, die du konfigurierst – der Quellshop bleibt während der Migration live. Delta-Läufe sind möglich: Du kannst die Migration erneut ausführen, und nur geänderte Datensätze werden aktualisiert.

Was das Migrationsprofil nicht abdeckt

Die Lücken sind dort, wo die meisten Projekte den Aufwand unterschätzen.

• Bundle-Produkte und gruppierte Produkte haben kein direktes Äquivalent in Shopware und erfordern manuelles Remapping oder eine Custom Extension.

• Custom-Option-Daten auf einfachen Produkten (Magentos produktbezogene Anpassungsschicht) werden nicht migriert. Wenn du Custom Options für Personalisierung oder Konfiguration verwendest, plane deren Ersatz.

• Geschenkkarten sind nicht im Migrationsprofil enthalten.

• Magento Page Builder-Content importiert nicht in Shopwares Shopping Experiences (CMS). Mit Page Builder erstellte Seiten müssen im Shopware-CMS-Editor neu erstellt werden.

• URL-Rewrites werden als Redirects importiert, aber die Mapping-Logik muss überprüft werden: Magento generiert eine große Anzahl von URL-Rewrites, von denen viele interne Redirects sind, die keine Shopware-SEO-URLs werden müssen.

• Promotions und Cart-Price-Rules werden nicht migriert. Shopwares Promotion-Engine hat eine andere Regelstruktur; alle Promotions müssen neu erstellt werden.

• Reward Points und Store Credit haben keinen äquivalenten Migrationspfad.

• Newsletter-Abonnenten können aus Magento exportiert und in Shopware importiert werden, aber das Migrationsprofil behandelt dies nicht automatisch. Du musst die Abonnentenliste exportieren und über das Shopware-Import/Export-Modul importieren.

Wie Magentos EAV-Modell auf Shopware abgebildet wird

Hier liegt der größte Teil der technischen Komplexität. Magento verwendet ein Entity-Attribute-Value (EAV)-Datenbankmodell für Produkte und Kunden. Attribute sind Zeilen in einer separaten Tabelle, keine Spalten. Das gibt Magento Flexibilität bei großen Attribut-Sets, macht Abfragen aber teuer und das Schema für externe Tools unübersichtlich.

Shopware verwendet ein relationales Modell mit einem festen Produkt-Schema und zwei Erweiterungsmechanismen: Properties (für filterbare Attribute wie Farbe und Größe) und Custom Fields (für nicht-filterbare Zusatzdaten). Das Migrationsprofil mappt Magento-Attribute auf einen dieser beiden Mechanismen anhand von Regeln, die du konfigurierst – aber das Mapping ist nicht immer offensichtlich und muss für jedes Attribut-Set überprüft werden.

Konkrete Planungspunkte:

• Magento-Attribut-Sets werden zu Shopware-Property-Gruppen. Wenn du viele Attribut-Sets mit überlappenden Attributen hast, vereinfacht eine Konsolidierung vor der Migration das Shopware-Datenmodell.

• Konfigurierbare Produktoptionen in Magento (Größen-, Farb-Selektoren) werden zu Varianten-Optionen in Shopware. Das Mapping funktioniert bei einfachen Fällen, bricht aber zusammen, wenn konfigurierbare Produkte mehr als zwei Dimensionen haben oder die Optionswerte im Katalog nicht konsistent sind.

• Magento-Tier-Preise (mengenbasierte Preise) werden auf Shopwares erweiterte Preisregeln gemappt. Die Logik ist ähnlich, aber die Datenstruktur unterscheidet sich; plane manuelle Überprüfung für komplexe Preistabellen ein.

• Multi-Store-Setups in Magento (mehrere Websites, Store Views) werden auf Shopwares Sales-Channel- und Sprachstruktur gemappt. Das Mapping ist nicht eins zu eins: Ein Magento Store View, der für eine Sprache verwendet wird, ist ein Shopware Language; ein Store View für eine andere Domain ist ein Shopware Sales Channel. Überprüfe deine Magento-Store-Struktur vor dem Start der Migration.

Was neu gebaut wird

Nach dem Datenimport sind drei Bereiche unabhängig vom Ergebnis der Migration neu zu bauen.

Das Frontend. Dein Magento-Theme wird nicht übertragen. Egal ob Luma, Blank oder Hyvä – das Frontend muss in Shopwares Storefront (Twig) oder als Headless-Frontend mit Shopware Frontends neu aufgebaut werden. Für die meisten Mid-Market-Händler ist dies der größte Einzelposten im Projektbudget.

Extensions. Jede Magento-Extension, auf die du angewiesen bist, braucht ein Shopware-Äquivalent oder einen Custom-Ersatz. Beginne mit einem Audit deiner Extension-Liste und mappe jede auf eine Shopware App, ein Shopware Plugin oder eine Custom-Entwicklung. Extensions ohne Shopware-Äquivalent, die Kern-Geschäftslogik abdecken, sind die Hochrisiko-Positionen im Projekt.

Integrationen. ERP, PIM, CRM, Zahlungsanbieter, Versandanbieter und alle individuellen API-Integrationen müssen gegen Shopwares APIs neu gebaut oder konfiguriert werden. Shopware bietet eine dokumentierte REST-API und ein Webhook-System, aber Endpunkte und Authentifizierungsmodell unterscheiden sich von Magentos API. Plane für jede Integration separat Zeit ein.

Zeitplan und Budget-Realitäten

Eine Magento-zu-Shopware-Migration für einen Mid-Market-Händler mit einem Standardkatalog (unter 50.000 SKUs, ein Storefront, 10–20 Extensions) dauert typischerweise vier bis acht Monate vom Kickoff bis zum Go-live. Die Datenmigration selbst dauert Tage. Der Rest des Zeitplans entfällt auf Frontend-Entwicklung, Extension-Ersatz, Integrationsarbeit, Testing und Content-Aufbau.

Budget-Ankerpunkte zur Planung:

• Frontend-Neuaufbau: typischerweise 30–40 % des Gesamtprojektbudgets

• Extension-Ersatz und Custom-Entwicklung: 20–30 %

• Integrations-Neuaufbau: 15–25 %

• Datenmigration, QA und Go-live: der Rest

Das sind Planungsankerpunkte, keine Angebote. Die tatsächliche Aufteilung hängt von der Komplexität des Frontends, der Anzahl und Art der Extensions und der Anzahl der Integrationen ab. Ein Projekt mit Headless-Frontend und einer umfangreichen ERP-Integration sieht sehr anders aus als ein Standard-Storefront mit Off-the-Shelf-Extensions.

SEO-Kontinuität während der Migration

URL-Struktur ist das erste SEO-Thema. Magento und Shopware generieren URLs unterschiedlich. Wenn dein Magento-Store Kategoriepfade in Produkt-URLs verwendet (z. B. /kategorie/unterkategorie/produkt.html), wird Shopwares Standard-URL-Struktur nicht übereinstimmen. Plane deine Shopware-URL-Struktur vor der Migration und richte 301-Weiterleitungen für jede geänderte URL ein. Das Migrationsprofil importiert Magento-URL-Rewrites als Shopware-SEO-URL-Redirects, aber überprüfe die Ausgabe: Magento hat oft Tausende interner Redirects, die Rauschen erzeugen.

Meta-Daten (Title-Tags und Meta-Descriptions) migrieren mit den Produkt- und Kategorie-Daten. Prüfe die Zeichenlängen nach der Migration: Magento und Shopware haben unterschiedliche Standard-Feldlängen, und einige Meta-Felder können abgeschnitten werden.

Strukturierte Daten ändern sich mit dem Frontend-Neuaufbau. Wenn dein Magento-Theme Custom-schema.org-Markup hatte, stelle sicher, dass es im Shopware-Theme neu aufgebaut wird. Shopwares Storefront enthält grundlegendes Produkt-Schema, aber überprüfe es gegen deine aktuelle Implementierung.

Die Migration in der Praxis

Eine Magento-zu-Shopware-Migration, die gut läuft, folgt einem konsistenten Muster: eine gründliche Discovery-Phase, in der das Magento-Setup vor Beginn der Entwicklung auditiert wird, eine Datenmigration, die früh startet und iteriert, ein parallel entwickeltes Frontend und ein Cutover-Plan, der Downtime minimiert.

Projekte, die in Schwierigkeiten geraten, teilen typischerweise eines von drei Merkmalen: Die Discovery-Phase wurde übersprungen oder war zu kurz, die Datenmigration wurde als einmaliges Ereignis behandelt statt als iterativer Prozess, oder Extension-Ersatz wurde ohne vorherige Prüfung des Shopware-Marktplatzes gescoped.

Wenn du an dem Punkt bist, eine Magento-zu-Shopware-Migration zu scopen, und eine unabhängige Einschätzung möchtest, was dein spezifisches Setup bedeutet, schauen wir gerne drauf.