Analyse Shop-Management

Shopware 6 Import Guide 2026: Produkte, Kunden und Bestellungen sauber migrieren

Ein Import in Shopware 6 klingt nach einem Nachmittag Arbeit: CSV laden, Profil wählen, Daumen drücken. In der Praxis kippt genau dort die Migration, wo niemand mehr hinschaut — bei Varianten, Staffelpreisen, Kategorien und dem einen Pflichtfeld, das der Validator erst beim 4.000. Datensatz anmahnt. Wer aus Magento, WooCommerce oder einem ERP umzieht, merkt spätestens dann: Der Shopware-6-Import ist weniger eine Funktion als eine Disziplin.

Der Ausgangspunkt für 2026 ist eindeutig: Shopware hat in Version 6.6 und 6.7 die Import-Werkzeuge deutlich ausgebaut. Das Standardprofil im Admin verarbeitet CSV-Dateien mit bis zu 5.000 Zeilen pro Durchlauf, versteht Punkt- und Komma-Trennung gleichermaßen und unterstützt Multi-Threading für große Kataloge. Für alles darüber greift man zur Konsole. Wer das nicht trennt, verbringt Wochen im Browser-Tab.

Warum der Standard-Import für 80 Prozent der Shops ausreicht

Die verbreitete These, man brauche für jeden Ernstfall eine externe Middleware, hält der Prüfung nicht stand. Das Admin-Import-Profil deckt genau die Felder ab, die den Shop-Alltag bestimmen: Produktnummer, Name, Beschreibung, Preise, Steuern, Bestand, Kategorie-Zuordnung, Hersteller, Eigenschaften und Bilder.

Das reicht für den Erstaufbau eines Katalogs bis etwa 100.000 Produkte — vorausgesetzt, die Quelldaten sind konsistent. Genau da liegt der Fehler. Die meisten fehlgeschlagenen Importe scheitern nicht an Shopware, sondern an Excel-Tabellen, in denen ein ERP-System Gewichte in Gramm und Preise in Cent ausgibt, während der Shop Kilogramm und Euro erwartet.

Kernsatz: Ein Import ist zu 80 Prozent Datenvorbereitung und zu 20 Prozent Software. Wer das Verhältnis ignoriert, debuggt Shopware statt seiner Quelltabelle.

Bevor die erste Zeile importiert wird, lohnt ein Trockenlauf mit 50 Datensätzen. Dieses Sample muss jede Variante des Katalogs enthalten: ein einfaches Produkt, ein Variantenprodukt mit zwei Achsen, ein Produkt mit Staffelpreis, ein Produkt mit Pflicht-Eigenschaft. Wer diesen Test besteht, hat den Großteil der Mapping-Arbeit erledigt.

Wie funktioniert der Shopware-6-Import via CLI für große Kataloge?

Der Konsolen-Import läuft über den Befehl bin/console import:entity und ist für alles jenseits von 5.000 Datensätzen die einzige vernünftige Option. Er umgeht die Browser-Timeouts, arbeitet transaktional und lässt sich in Cronjobs einbinden — ein Punkt, der 2026 wichtiger ist als noch vor zwei Jahren, weil immer mehr DACH-Händler nächtliche PIM-Synchronisationen fahren.

Ein typischer Aufruf für Produktdaten sieht so aus:

  • Profile-Anlage: Eine XML-Datei definiert, welche CSV-Spalte auf welches Entitätsfeld mappt — inklusive Konvertierungen.
  • Ausführung: Der Befehl liest die CSV, validiert gegen die Felder und schreibt in Batches von 250 Datensätzen.
  • Fehlerlog: Fehlgeschlagene Zeilen landen in einer separaten CSV, die nach Korrektur erneut eingelesen wird.

Wer diesen Weg geht, sollte zwei Dinge wissen. Erstens: Die CLI validiert strenger als das Admin-Profil. Ein leeres taxId-Feld oder eine ungültige Kategorie-ID bricht den Lauf ab, statt die Zeile zu überspringen. Zweitens: Die Reihenfolge der Importe ist nicht optional. Kategorien müssen vor Produkten existieren, Eigenschaftsgruppen vor ihren Werten, Kunden vor Bestellungen. Ein falsch geordneter Lauf produziert Waisen-Datensätze, die sich nur per SQL-Query aufräumen lassen.

In der Praxis scheitern Migrationen selten an der Technik. Sie scheitern daran, dass niemand die Abhängigkeiten der Entitäten dokumentiert hat.

Welche Felder kosten beim Shopware-6-Import die meiste Zeit?

Vier Baustellen tauchen in jedem Projekt auf, das ich begleitet habe.

Varianten. Shopware 6 modelliert Varianten über Eltern-Kind-Beziehungen. Die CSV braucht eine Elternzeile mit parentId und eine Zeile pro Kind, das auf die Produktnummer des Elternprodukts verweist. Wer aus Magento kommt, kennt dieses Modell nicht und importiert Configurable Products als Einzelprodukte — der Shop zeigt dann 40.000 statt 8.000 Artikel.

Kategorien. Der Pfad-basierte Import über categoryPath ist bequem, aber tückisch: Ein Tippfehler im Pfad erzeugt eine neue Kategorie „Schuhe & Zubehör“ statt der bestehenden „Schuhe & Zubehoer“. Nach drei fehlerhaften Läufen hat der Shop vier Kategoriebäume. Empfehlung: Kategorien einmal mit festen IDs anlegen und im Produktimport ausschließlich IDs referenzieren.

Preise und Steuern. Shopware erwartet Nettopreise als Dezimalzahl mit Punkt als Trennzeichen. Deutsche ERPs liefern Bruttopreise mit Komma. Ohne eine Konvertierungsregel im Profil landen Bruttopreise als Netto im Shop — ein Fehler, der bei einer Steuerprüfung unangenehm wird.

Medien. Bilder lassen sich per URL importieren, aber nur, wenn die URLs öffentlich erreichbar sind und der Server nicht durch Rate-Limiting blockiert. Ein 10.000-Bilder-Import gegen eine langsame Quelle dauert Stunden und produziert gern Timeouts. Wer das sauber will, lädt Dateien vorab per SFTP in public/media und importiert relative Pfade.

Was unterscheidet einen sauberen Import von einer Datenruine?

Der entscheidende Unterschied liegt nicht im Werkzeug, sondern in der Versionierung. Jeder Importlauf sollte auf einer Staging-Umgebung laufen, die ein Abbild der Live-Datenbank hat. Klingt nach Overhead, spart aber im Zweifel den Livegang.

Dasselbe gilt für Rücksetzbarkeit. Shopware überschreibt bei einem erneuten Import bestehende Datensätze anhand der Produktnummer — das ist praktisch und gefährlich zugleich. Wer versehentlich eine Spalte vertauscht, überschreibt 20.000 Produktbeschreibungen mit Bestandsdaten. Ohne Datenbank-Backup vor dem Lauf ist das nicht rückgängig zu machen.

Die Migration ist damit weniger ein technisches als ein organisatorisches Problem. Der beste Shopware-Import ist der, bei dem vorher jemand eine Liste mit fünf Spalten geschrieben hat: Entität, Quelle, Ziel-Feld, Konvertierung, Abhängigkeit. Diese Liste ist wichtiger als jedes Plugin.

Kernsatz: Ein Import, der nicht wiederholbar ist, ist kein Import, sondern ein Einmaleffekt — und damit eine technische Schuld.

Wann sich externe Werkzeuge lohnen — und wann nicht

Für einmalige Migrationen ist der Bord-Import die richtige Wahl. Für laufende Synchronisationen mit einem PIM, ERP oder Marktplatz wird er zur Sackgasse, weil er keine inkrementellen Updates kennt. Wer täglich Preise und Bestände abgleicht, braucht einen Connector oder eine eigene Sync-Logik über die Admin-API.

Die Admin-API ist 2026 die unterschätzte Option. Wer ohnehin einen Entwickler im Team hat, baut eine 200-Zeilen-Sync in wenigen Tagen — flexibler als jedes Standardprofil und ohne Lizenzkosten. Die Kehrseite: Die API ist kein Werkzeug für Nicht-Entwickler. Für alles dazwischen, also gelegentliche Massenupdates ohne Entwicklerteam, bleibt das Admin-Profil die pragmatische Antwort.

Der vielleicht ehrlichste Rat: Testet den Import mit Blick auf den Tag nach dem Livegang, nicht auf den Tag selbst. Ein Katalog, der sauber importiert wurde und sich danach nicht pflegen lässt, ist teurer als manuelles Anlegen. Migrieren heißt nicht, Daten zu verschieben. Migrieren heißt, eine Struktur zu erschaffen, mit der das Team die nächsten drei Jahre arbeitet.