Ein Händler aus Nordrhein-Westfalen mit 40.000 SKUs wollte im Januar einen simplen Produktdatenexport für Google Merchant Center anlegen. Standardfilter, Standardfelder, Standard-CSV. Nach zwei Stunden brach der Prozess ab — PHP-Memory-Limit. Die Datei hatte 1,8 GB erreicht und war unvollständig. Der Shopware-Support verwies auf CLI-Kommandos, die der Händler nie zuvor genutzt hatte. Solche Fälle landen regelmäßig in den Shopware-Foren, und sie markieren ein tieferes Problem: Der native Export ist ein Werkzeug für den Notfall, nicht für den Betrieb.
Shopware 6 bringt ab Werk einen Export mit, der Produkte, Kunden, Bestellungen und weitere Entitäten als CSV ausgibt. Das reicht für einen Backup-Snapshot oder eine einmalige Reporting-Anfrage. Für alles, was laufend geschehen soll — Marketplace-Synchronisation, ERP-Anbindung, PIM-Befüllung — ist er strukturell zu langsam, zu fragil und zu manuell. Wer 2026 ernsthaft mit Shopware-Daten arbeitet, braucht eine andere Architektur.
Was der native Shopware-6-Export tatsächlich kann
Die Funktion ist im Admin unter Einstellungen → Import/Export zu finden. Sie arbeitet mit Profilen, in denen Feld-Mapping, Filter und Serializer konfiguriert werden. Der Export läuft asynchron über die Message Queue, also über den Shopware-Worker. Das ist solide gebaut, setzt aber voraus, dass ein Worker-Prozess zuverlässig läuft. Wer den Standard-Cron der Shared-Hosting-Umgebung nutzt, wird bei größeren Datenmengen regelmäßig Timeouts sehen.
Der Export deckt die zentralen Entitäten ab: product, customer, order, category, manufacturer, property_group, media. Für jede lassen sich eigene Profile anlegen. Der Serializer unterstützt dabei CSV und — seit Version 6.4 — auch einige strukturierte Formate. Die Feldbreite entspricht dem Datenmodell, das heißt: Assoziationen wie Varianten, Preise pro Währung oder Custom Fields müssen explizit als Spalten aktiviert werden, sonst fehlen sie im Resultat.
Warum verlieren Händler mit dem Standard-Export Zeit und Daten?
Drei strukturelle Engstellen tauchen in fast jeder Migrations- und Integrationsdiskussion auf.
Skalierung: Der Export lädt Entitäten in den Speicher, serialisiert und schreibt am Ende. Bei 50.000 Produkten mit Varianten, Custom Fields und Media-Assoziationen sind das schnell mehrere Gigabyte RAM-Spitze. Das PHP-Memory-Limit ist keine Einstellung, die man „einfach hochsetzt“ — es ist eine Architekturgrenze. Die Lösung ist der CLI-Befehl bin/console import-export:export mit einem Profil, der ohne HTTP-Timeout läuft. Nur wissen das viele nicht.
Zweite Engstelle: Inkrementalität. Der native Export kennt keinen Delta-Modus. Er exportiert entweder alles oder eine gefilterte Teilmenge, die man händisch über einen Zeitstempel definieren muss. Für einen täglichen Abgleich mit einem Marktplatz ist das unbrauchbar — man schaufelt jeden Tag das komplette Sortiment durch die Leitung.
Dritte Engstelle: Formatstarre. CSV ist ein Austauschformat der 1970er, das sich in der Praxis nur mit Konventionen bändigen lässt: Trennzeichen, Encoding, Quoting, Zeilenumbrüche in Textfeldern. Wer schon einmal eine Shopware-CSV in Excel geöffnet und beim Speichern die führenden Nullen der EAN-13 verloren hat, kennt das Problem.
Der native Export ist für viele das Werkzeug, mit dem sie ihren ersten Datenexport überhaupt machen — und das Werkzeug, mit dem sie ihre erste Datenpanne machen.
Wie funktioniert ein produktionsreifer Export in Shopware 6?
Drei Wege haben sich 2026 etabliert, je nach Reifegrad des Setups.
Der CLI-Weg: native Exporte ohne Limits
Shopware liefert seit 6.4 den Konsolenbefehl import-export:export. Damit laufen dieselben Profile wie im Admin, aber ohne HTTP-Kontext. Kein Timeout, kein Web-Limit, dafür saubere Logs und Exit-Codes für Monitoring. Für einen monatlichen Vollbackup die pragmatischste Lösung. Für alles Häufigere fehlt weiterhin der Delta-Modus.
Der API-Weg: Admin API mit inkrementeller Filterung
Die Shopware Admin API ist die eigentliche Antwort auf laufende Datenflüsse. Über /api/search/product lassen sich Produkte mit Filtern abrufen, paginieren und inkrementell über updatedAt abgleichen. Wer das selbst skriptet, baut sich damit einen belastbaren Export-Pipeline-Ersatz. Nachteil: Man muss den Sync-Zustand selbst verwalten, Rate Limits beachten und Fehlerbehandlung implementieren.
- Header
sw-access-keyundsw-context-languagekorrekt setzen, sonst kommen Felder leer zurück. - Pro Request maximal etwa 500 Entitäten abrufen — darüber steigen Latenz und Timeout-Risiko.
- Cursor-basierte Pagination statt Offset bei großen Tabellen nutzen, weil Offset-Queries mit dem Datenwachstum quadratisch langsamer werden.
Der Middleware-Weg: PIM, ERP und iPaaS dazwischen
In der Praxis läuft bei den meisten Händlern ab einer gewissen Größe eine dritte Instanz mit: ein PIM wie Akeneo, ein ERP wie Plentymarkets oder eine iPaaS-Lösung wie Make, n8n oder celigo. Diese Systeme übernehmen den Export selbst, sprechen die Shopware-Admin-API an und kümmern sich um Felder-Mapping, Delta-Erkennung und Fehler-Retries. Der Shopware-Export wird damit vom Produktionswerkzeug zum reinen Notfall-Backup degradiert — genau die Rolle, für die er gebaut ist.
Welche Daten sollte man regelmäßig exportieren — und welche nicht?
Nicht alles gehört in eine automatisierte Pipeline. Eine grobe Priorisierung aus der Praxis:
Produkte gehören in jede Pipeline. Sie sind die Grundlage für Marktplätze, PIM, Preisvergleicher, Feed-Management. Vollständigkeit und Aktualität sind hier kritisch. Wer Produktdaten nur einmal wöchentlich synchronisiert, verliert Conversion auf Amazon und Google Shopping.
Bestellungen gehören in ERP-Anbindungen, aber nicht per CSV-Export. Order-Daten sind transaktional und müssen ereignisgetrieben übertragen werden. Der Shopware-Export ist dafür zu langsam — jede Stunde ein CSV-Dump mit neuen Bestellungen ist ein Anti-Pattern, das Latenzen von bis zu 60 Minuten erzeugt.
Kunden sind datenschutzrechtlich heikel. Ein täglicher Voll-Export aller Kundendaten ist DSGVO-seitig schwer zu rechtfertigen, wenn nur ein Bruchteil tatsächlich in ein Zielsystem überführt wird. Hier gehört eine zweckgebundene, minimierte Übertragung hin.
Custom Fields, Varianten und Medien: die drei Fallen
In jedem zweiten Projekt tauchen dieselben Probleme auf.
Custom Fields werden im nativen Export nur mitgeliefert, wenn sie im Profil explizit aktiviert werden. Sie landen dann als eigene Spalten mit dem technischen Namen (z. B. customFields_my_plugin_hersteller_code) in der CSV. Wer das einmal vergisst, wundert sich später, warum die Daten im Zielsystem fehlen.
Varianten werden als Kinder des Hauptprodukts exportiert. Die Eltern-Kind-Beziehung muss im Zielsystem rekonstruiert werden, was ohne Parent-SKU-Mapping scheitert. Wer über die API exportiert, kann die Hierarchie direkt mitliefern — beim CSV-Export ist das Fleißarbeit.
Medien werden im Standardexport als URL-Referenzen ausgegeben, nicht als Dateien. Wer Produktbilder tatsächlich migrieren will, muss sie separat herunterladen. Bei mehreren Tausend Bildern ist das ein eigener Pipeline-Schritt mit Retry-Logik. Der Admin-Export hilft hier nicht.
Was 2026 der richtige Ansatz ist
Der native Shopware-Export bleibt das richtige Werkzeug für drei Dinge: einmalige Audits, Backup-Snapshots und Notfall-Abzüge bei Integrationsausfällen. Alles andere — tägliche Marktplatz-Syncs, laufende ERP-Anbindung, PIM-Befüllung — gehört auf die Admin API oder in eine Middleware.
Wer sich 2026 nur einen einzigen Tipp mitnehmen will: Schalte den Export auf den CLI-Befehl um, plane ihn als Cron und überwache die Logs. Das behebt 80 Prozent aller Ausfälle bei mittelgroßen Shops und kostet einen halben Tag Arbeit. Der nächste Schritt wäre die inkrementelle API-Anbindung — und wer die einmal sauber aufgesetzt hat, will nie wieder eine 1,8-GB-CSV im Dateisystem sehen.