Ein Shopware-6-Launch steht und fällt mit einem einzigen Profil. Wer schon einmal 8.000 Artikel per CSV in den Admin importiert hat und nach dem Lauf feststellte, dass alle Varianten als Einzelprodukte in der Kategorie „Root“ liegen, kennt den Schmerz. Der Import in Shopware 6 ist mächtig geworden — mit Version 6.6 wurde das Advanced Import/Export-Modul im Kern deutlich aufgewertet —, aber die Fehlerquelle Nummer eins bleibt derselbe: Das Mapping wird zwischen zwei Terminen gebaut, nicht beim Import selbst.
Warum die meisten Shopware-6-Importe an der zweiten Spalte scheitern
Shopware arbeitet intern mit UUIDs. Jeder Datensatz — Produkt, Kategorie, Eigenschaft, Hersteller, Custom Field — hat einen 32-stelligen Hex-Bezeichner. Die CSV aus dem Altsystem kennt diese IDs nicht. Sie kennt SKUs, Kategorienamen, vielleicht einen Herstellerstring. Genau hier entsteht die Lücke, die den Import kippen lässt.
Der Admin-Import von Shopware 6 löst das mit zwei Mechanismen: dem Mapping-Feld, in dem Händler eine CSV-Spalte auf ein Shopware-Feld ziehen, und den sogenannten Resolvern. Ein Resolver wie Product Number to Id oder Category Path übersetzt Klarnamen in die internen UUIDs. Wer diese Resolver nicht konfiguriert, importiert Referenzen ins Leere — der Artikel steht anschließend ohne Kategorie im Backend.
Ein zweiter, oft unterschätzter Punkt: Shopware-6-Importe sind reihenfolgeabhängig. Wer Produkte samt Kategorien in einer Datei einliest, muss die Kategorien im Shop vorher angelegt oder über eine separate Kategorie-CSV importiert haben. Der Import ist kein Single-Pass-Vorgang, sondern eine Sequenz — Hersteller, Kategorien, Eigenschaftsgruppen, dann Produkte, dann Preise, dann Cross-Selling.
Wie funktioniert der Import über Shopware Admin und Profile?
Seit Shopware 6.5 läuft der Import in drei Schritten ab. Händler legen unter Einstellungen → Import/Export ein Profil an, in dem der Datensatztyp (Produkte, Kategorien, Kunden, Bestellungen) und die CSV-Datei festgelegt werden. Danach folgt das Mapping: eine Spalte aus der Datei wird einem Zielfeld im Shop zugeordnet.
Im dritten Schritt — dem eigentlichen Lauf — entscheidet die Einstellung Identifikator, ob Datensätze neu angelegt (Product Number als eindeutiges Feld) oder aktualisiert werden. Ein Fehler, den ich bei jedem zweiten Migrationsprojekt sehe: Wer beim Update-Import nicht dieselbe SKU-Konvention wie beim Erst-Import verwendet, erzeugt Duplikate statt Aktualisierungen. Shopware erkennt Bestandsdaten nur über den hinterlegten Identifikator.
- Erst-Import in einen leeren Shop: Identifikator Product Number, alle Referenz-Entities müssen vorher existieren.
- Update bestehender Kataloge: Derselbe Identifikator zwingend erforderlich, sonst entstehen parallele Datensätze statt Updates.
Für Massendaten — über 5.000 Zeilen — ist der Admin-Import zu langsam. Shopware empfiehlt dann die CLI-Variante: bin/console import:entity verarbeitet dieselben Profile headless, ohne Timeout-Grenzen des Webservers. Wer regelmäßig große Kataloge aus PIM- oder ERP-Systemen zieht, landet ohnehin bei einem automatisierten Pipeline-Ansatz: Shopware-Profile exportieren, per Cron über die CLI ausführen, Logfiles überwachen.
Was leisten Erweiterungen wie der Shopware 6 Import & Export Wizard?
Der native Import deckt Produkte, Preise, Kategorien, Kunden und Bestellungen ab — nicht aber alle Referenzen. Custom Fields, individualisierte Eigenschaften-Kombinationen, spezielle Verkaufskanalzuordnungen oder verschachtelte Cross-Selling-Beziehungen lassen sich nur umständlich oder gar nicht über die Standard-Profile abbilden.
Hier setzen Plugins an. Der Import & Export Wizard (ehemals von der Shopware-Community, heute in mehreren Varianten auf dem Store) erlaubt Exporte als Vorlage: Händler exportieren einen Bestandsartikel vollständig inklusive aller Referenzen als CSV, füllen die Zeilen mit neuen Daten und spielen sie zurück. Das umgeht das Referenzproblem, weil alle IDs bereits korrekt in der Datei stehen.
Für Shopify- oder Magento-Migrationen existieren spezialisierte Migrations-Connectoren, die Produkte, Kundenhistorie und Bestellungen mappen. Die taugen für einen Einmalumzug, nicht für laufende Synchronisation. Wer zwischen Shopware und einem ERP synchron hunger, fährt mit einem Middleware-Ansatz (Shopware-API, kein CSV-Import) robuster.
Welche Fehler kosten Zeit im Shopware-6-Import — und wie lassen sie sich vermeiden?
Drei Probleme dominieren jeden Forenthread zum Thema.
Erstens die UTF-8-Kodierung. Excel exportiert CSVs standardmäßig in Windows-1252. Umlaute werden beim Import zu Fragezeichen, wenn die Datei nicht als UTF-8 gespeichert wurde. Shopware zeigt das nicht immer als Fehler an — die Daten landen einfach falsch. Wer aus Excel exportiert, muss den Kodierungsdialog beim Speichern ernst nehmen oder auf ein Tool wie LibreOffice mit expliziter UTF-8-Auswahl wechseln.
Zweitens das Trennzeichen. Der Shopware-Import erwartet Semikolon, viele Quellsysteme liefern Komma. Wer ein deutsches Excel mit deutschen Ländereinstellungen verwendet, produziert Semikolon — und wundert sich, wenn dieselbe Datei aus dem englischen Kollegensystem in der Vorschau falsch geparst wird.
Drittens die Variantenlogik. Shopware 6 unterscheidet zwischen Parent-Produkt und Varianten-Kindern. Eine CSV, die pro Variante eine Zeile führt, aber das Parent-Feld nicht mappt, erzeugt eigenständige Produkte. Das richtige Vorgehen: Alle Varianten eines Parents in dieselbe CSV, mit denselben Parent-Werten, unterschieden nur in den variierenden Eigenschaften (Farbe, Größe) und der SKU.
Ein Import ist kein Datenbank-Dump. Er ist eine Übersetzung zwischen zwei Datenmodellen — und Übersetzungen scheitern an den Stellen, an denen man sie für selbstverständlich hält.
Die dritte Fehlerquelle trifft auch Architektur-Entscheidungen: Wer Varianten aus einem PIM importiert, in dem jede Variante als eigenständiger Artikel geführt wird, braucht eine Transformationsstufe vor dem Import. Sonst produziert jeder Lauf Hunderte Orphan-Products, die später händisch zusammengeführt werden müssen.
Wann lohnt sich der Umweg über die API statt CSV?
Der CSV-Import ist das richtige Werkzeug für periodische Katalogpflege, Migrationen und Updates, die ein Mensch auslöst. Er ist das falsche Werkzeug für Echtzeit-Synchronisation oder Kataloge mit mehr als 50.000 SKUs, die mehrmals täglich aktualisiert werden.
In diesen Fällen führt der Weg über die Shopware-Admin-API oder die Storefront-API. Beide sind REST-basiert, dokumentiert und erlauben inkrementelle Updates. Ein ERP-Connector, der 200 geänderte Preiszeilen stündlich über die API pusht, ist technisch aufwendiger einzurichten, aber im Betrieb deutlich robuster als ein nächtlicher CSV-Lauf, bei dem niemand die Fehlerlogs liest.
Der pragmatische Mittelweg für die meisten Händler: CSV-Import für die Erstbefüllung und die Content-Pflege (Produkttexte, Bilder, SEO-Metadaten), API-Sync für Preise, Bestände und Bestellungen. Zwei Werkzeuge, zwei klare Zuständigkeiten. Wer versucht, alles über ein Profil abzubilden, scheitert an der Referenzlogik — und bezahlt es mit manueller Nacharbeit, die teurer ist als jede Middleware-Lizenz.