Ein Migrationsprojekt bei einem mittelständischen Händler aus dem Münsterland, 14.000 Artikel, gewachsene Strukturen aus zwölf Jahren Magento 1: Der Import lief technisch durch. 9.400 Produkte landeten im Shopware-6-Backend, alle mit grünem Häkchen. Zwei Wochen später brach der Kundenservice zusammen, weil 3.100 Artikel die falsche Steuersatz-Klassifizierung trugen und der Checkout bei B2B-Kunden mit Netto-Preisen abschmierte. Die Daten waren importiert. Das Geschäft war es nicht.
Genau hier liegt der Kern des Shopware 6 Imports: Es ist kein Knopfdruck, sondern ein Datenmodellierungsproblem. Wer 2026 migriert, kämpft weniger mit dem CSV-Parser als mit der Frage, wie Varianten, Eigenschaften, Kategorien und Preise logisch zusammenhängen. Der Import ist nur die Ausführung einer Entscheidung, die vorher getroffen werden muss.
Wie funktioniert der Shopware 6 Import wirklich?
Shopware 6 bietet drei Wege, Daten in den Shop zu bekommen. Das native CSV-Profil im Backend ist der Einstieg, gedacht für überschaubare Kataloge und schnelle Updates. Die Migration von Shopware 5 kommt mit einem eigenen Tooling, das Mapping-Tabellen für Kunden, Bestellungen und Medien mitbringt. Und dann ist da die API — die Admin API und die Sync API, über die Agenturen und größere Händler faktisch alles steuern, was das Backend nur unvollständig abbildet.
Der entscheidende Unterschied zu Shopware 5: Shopware 6 arbeitet konsequent mit
UUIDs statt Auto-Increment-IDs — jede Entität hat eine global eindeutige ID, und jede Verknüpfung referenziert diese ID. Wer aus einem Altsystem importiert, muss diese IDs erzeugen und über alle abhängigen Tabellen konsistent halten. Ein Produkt ohne gültige Tax-ID oder ohne verknüpfte Kategorie landet nicht sichtbar, sondern im Nirwana.
Das erklärt, warum so viele Importe „erfolgreich“ durchlaufen und trotzdem nichts anzeigen. Der Import validiert technisch. Er validiert nicht inhaltlich.
Welche Daten lassen sich importieren — und welche nicht?
Produkte, Varianten, Kategorien, Eigenschaften, Hersteller, Preise, Bestände, Kunden, Bestellungen und Medien: All das ist über die entsprechenden Endpunkte erreichbar. Die Admin API deckt praktisch das gesamte Datenmodell ab, inklusive Custom Fields, die seit Shopware 6.4 eine zentrale Rolle für individuelle Attribute spielen.
Die Grenzen liegen woanders. Cross-Selling-Beziehungen, individuelle Preisregelungen über die Rule Builder und abgestufte Preise für Kundengruppen lassen sich nur über verschachtelte API-Aufrufe sauber setzen. Das native CSV-Profil stößt hier an seine Grenzen. Wer B2B-Preise mit Staffelung und kundengruppenspezifischen Sichtbarkeiten importieren will, kommt um die API nicht herum — oder um einen spezialisierten Import-Connector wie den von Pickware oder ähnliche Lösungen aus dem Ökosystem.
- Bestellungen aus Altsystemen lassen sich technisch importieren, verlieren aber häufig ihre historischen Statusverläufe — das verfälscht jede Auswertung.
- Medien brauchen eine saubere Reihenfolge und Zuordnung, sonst steht das Hauptbild im Shopware-Produkt an Position sieben — und niemand merkt es im Import-Log.
Warum scheitern die meisten Shopware 6 Importe?
Nicht an der Technik. An drei Dingen, die vorher passieren müssten.
Erstens: fehlende Attribut-Harmonisierung. Altsysteme haben gewachsene Freitextfelder, Shopware 6 erwartet strukturierte Eigenschaften mit definierten Options-IDs. Wer „Farbe: dunkelblau“ aus einem Magento-Feld importiert, ohne es einer Eigenschafts-Option zuzuordnen, erzeugt Datenmüll, der später jede Filterfunktion unbrauchbar macht.
Zweitens: unterschätzte Variantenlogik. Shopware 6 modelliert Varianten über Parent-Child-Beziehungen mit Optionszuordnung. Ein CSV-Import, der 200 Varianten als eigenständige Produkte anlegt, statt sie einem Hauptartikel zuzuordnen, produziert einen Katalog, in dem jeder Größe einzeln in der Kategorie erscheint. Die Suchfunktion findet dann 40 Mal dasselbe T-Shirt.
Drittens: keine Vorab-Validierung. Der Import ist kein Testlauf. Wer 14.000 Artikel importiert und danach feststellt, dass das Preis-Mapping die Mehrwertsteuer doppelt einrechnet, hat 14.000 Artikel zu korrigieren. Der Werkzeugkasten dagegen ist unspektakulär: Testimport mit 50 Artikeln, gezieltes Mapping-Dokument, Abgleich Steuersätze vor dem Vollimport.
Jeder Euro, der in die Datenaufbereitung vor dem Import fließt, spart zehn Euro in der Nachkorrektur. Das ist keine Beratungsfloskel, sondern die Erfahrung aus jedem Migrationsprojekt, das schiefgeht.
Migration von Shopify, Magento oder WooCommerce: Was ist anders?
Die Herkunft bestimmt das Mapping-Problem. Shopify liefert ein relativ sauberes Modell mit festen Variantenstrukturen — der Import nach Shopware 6 ist meist gradlinig, sofern Tags und Metafelder korrekt auf Eigenschaften übersetzt werden. Magento 2 bringt komplexere Attributsets und konfigurierbare Produkte mit, deren Optionslogik nicht eins zu eins auf Shopware-Varianten abbildet. WooCommerce ist der unangenehmste Fall: Als WordPress-Plugin historisch gewachsen, tummeln sich Produktdaten oft über Postmeta-Tabellen, Plugin-Felder und Custom-Taxonomien verteilt. Hier beginnt jede Migration mit Datenarchäologie, nicht mit Import.
Für alle gilt: Bestands- und Bestellhistorien gehören nicht zwingend in den neuen Shop. Viele Händler importieren nur Produkte, Kunden und offene Bestellungen, lassen abgeschlossene Aufträge aber im Altsystem archiviert. Das reduziert Komplexität erheblich und ist rechtlich zulässig, solange die Aufbewahrungsfristen im Altsystem eingehalten werden.
Was ändert sich 2026?
Die Richtung ist klar: weniger manuelles CSV-Mapping, mehr deklaratives Schema. Shopware hat in den vergangenen Releases die Admin API konsolidiert und die Sync API für Hochvolumen-Szenarien ausgebaut, was Importe mit mehreren zehntausend Datensätzen in vertretbarer Zeit möglich macht. Wer regelmäßig Kataloge aus ERP-Systemen wie Plentymarkets, JTL oder SAP synchronisiert, kommt an einer API-basierten Pipeline ohnehin nicht vorbei — der einmalige CSV-Import ist ein Auslaufmodell.
Die eigentliche Verschiebung liegt aber nicht in der Technik. Sie liegt in der Erwartungshaltung. Der Shopware 6 Import wird 2026 weniger als Projekt und mehr als laufender Prozess verstanden — als Datenpipeline, die Produktstammdaten, Preise und Bestände kontinuierlich zwischen ERP und Shop abgleicht. Wer das versteht, plant den Import nicht als einmaligen Meilenstein vor dem Launch, sondern als Infrastruktur, die jeden Tag laufen muss.
Und dann ist da noch die Frage, die sich jede Migrationsplanung stellen sollte, bevor die erste CSV-Datei geöffnet wird: Ist die bestehende Datenstruktur überhaupt wert, importiert zu werden? Oft ist die ehrlichste Antwort, den Katalog im Zuge der Migration neu zu strukturieren — statt zwölf Jahre gewachsene Fehler mitzunehmen. Der Import ist dann nicht das Ziel, sondern der Anlass.