Wer bei Shopware 6 auf „Exportieren“ klickt, bekommt eine CSV-Datei. Das klingt harmlos, ist aber der Moment, in dem sich die Spreu vom Weizen trennt. Bei 500 Produkten läuft der native Export sauber durch. Bei 50.000 Varianten, sechs Verkaufskanälen und einem PIM im Hintergrund wird daraus ein Prozess, der den Server in die Knie zwingt und den Lagerbestand in anderen Marktplätzen veraltet zurücklässt.
Die 2026er-Realität im DACH-E-Commerce: Der eingebaute Shopware-Export bleibt das Standardwerkzeug für Backups, Reporting und kleine Datenmigrationen. Doch sobald Omnichannel-Synchronisation, Amazon-Listings oder ein ERP-Anbindung ins Spiel kommen, reicht er nicht mehr. Dieser Leitfaden zeigt, wo die Grenzen liegen — und mit welchen Werkzeugen Händler sie verschieben.
Was der native Shopware-6-Export 2026 tatsächlich leistet
Der eingebaute Export ist im Kern ein Datenbank-Abfrage-Generator mit CSV-Ausgabe. Händler wählen im Admin unter Einstellungen → Import/Export das Profil — Produkte, Bestellungen, Kunden, Kategorien, Varianten — und definieren Spalten-Mapping über die Feldzuordnung.
Brauchbar ist das für drei Szenarien:
- Backups einzelner Datenbestände: Ein Katalog-Snapshot vor einer Preisaktion oder einer Plugin-Installation lässt sich in unter einer Minute ziehen.
- Ad-hoc-Reporting: Bestellungen eines Quartals für die Buchhaltung, Kundenliste für eine CRM-Kampagne.
- Migration kleiner Shops: Wer unter 5.000 Artikeln bleibt und keine Varianten-Explosion hat, kommt mit dem Bordmittel aus.
Die Schmerzgrenze liegt niedriger, als Shopware kommuniziert. Ab etwa 20.000 Datensätzen oder bei tief verschachtelten Variantenprodukten steigen die Laufzeiten sprunghaft. Der Export läuft als synchroner HTTP-Prozess — bricht der Browser ab oder läuft das PHP-Timeout, ist die Datei korrupt. Für einen Shop mit 80.000 SKUs und sechs Sprachen ist das keine Option, sondern ein Wochenendprojekt mit ungewissem Ausgang.
Warum Händler den nativen Export schnell verlassen
Drei strukturelle Probleme tauchen in jeder Skalierungsdebatte auf.
Das erste ist die fehlende inkrementelle Logik. Der native Export kennt keinen Delta-Modus. Jeder Lauf ist ein Vollabzug. Für einen Marketplace-Sync, der alle 15 Minuten den Bestand abgleichen soll, bedeutet das: 15 Minuten Rechenzeit für vielleicht 40 geänderte Artikel. Amazon und OTTO erwarten aber genau diese Frequenz — wer zu spät aktualisiert, riskiert Over-Selling und damit Sperrungen.
Das zweite ist das Format. CSV ist der kleinste gemeinsame Nenner, aber die Encoding-Hölle bleibt: UTF-8 mit BOM, Semikolon- oder Komma-Trennung, Dezimaltrennzeichen. Beim Import in Excel franst die Datei aus. Beim Übergang zu einem PIM oder ERP müssen Händler regelmäßig nachbessern.
Das dritte Problem ist die fehlende Rückkanal-Fähigkeit. Wer Produktdaten nach Amazon exportiert, will Preis- und Bestandsänderungen von dort auch wieder zurückbekommen. Der native Export ist strikt unidirektional.
Welche Werkzeuge 2026 den Export übernehmen
Der Markt hat sich in drei Kategorien sortiert.
Plugins im Shopware Store. Anbieter wie Sync-Systeme, Pickware oder Datero bieten Export-Profile mit Cron-Scheduling, Mapping-Vorlagen für Amazon, eBay, Kaufland und Google Shopping. Der Vorteil: Die Daten bleiben im Shop, kein externer Dienstleister sieht sie. Der Nachteil: Jedes Plugin ist eine zusätzliche Abhängigkeit, die bei Shopware-Updates brechen kann. Vor jedem Major-Update gehört der Plugin-Kompatibilitätscheck auf die Checkliste — nicht optional.
Middleware und iPaaS
Plattformen wie n8n, Make oder spezialisierte E-Commerce-Middleware verbinden Shopware über die Admin-API mit Zielsystemen. Hier liegt 2026 die eigentliche Professionalisierung: Statt zu exportieren, wird synchronisiert. Der Shopware-Admin-API-Endpunkt liefert paginierte JSON-Responses, Middleware verarbeitet Deltas über den updatedAt-Filter, und bei Konflikten greifen Retry-Logiken.
Der Preis dafür ist Komplexität. Wer eine Middleware betreibt, betreibt auch Monitoring, Alerting und Fehlerbehandlung. Ein stiller Sync-Ausfall, der drei Tage unbemerkt bleibt, kostet mehr als jede Plugin-Lizenz.
ERP-gesteuerte Datenhoheit
Im gehobenen Mittelstand — ab etwa 500 Bestellungen pro Tag — verschiebt sich die Datenhoheit ins ERP. Shopware wird zum Frontend, das Produktdaten aus SAP, Microsoft Dynamics oder Plentymarkets konsumiert. Der „Export“ wird dann eigentlich zu einem Import in den Shop. Für Reporting und Marktplatz-Feeds gilt das umgekehrte Muster.
Diese Architektur ist sauber, aber teuer: ERP-Anbindung, Middleware, Shop-Anpassungen. Unter 30.000 Euro Initialaufwand läuft wenig — und dann kommen laufende Betriebskosten.
Welche Daten sollten Sie wann exportieren?
Die Antwort hängt vom Ziel ab. Ein Bestandsabgleich mit einem Marktplatz braucht nur SKU, Bestand, Preis — kein Kunden-Kommentar, keine Marketing-Felder. Ein vollständiger Katalog-Export für ein PIM dagegen enthält 80 bis 200 Attribute pro Produkt.
Ein direkter Antwortsatz vorweg: Für Bestands- und Preis-Synchronisation reicht ein schlanker Export mit maximal acht Feldern, alle fünf bis 15 Minuten. Für Katalog-Migration oder PIM-Befüllung braucht es den vollen Satz — aber dann nur einmalig oder wöchentlich, nicht im Minutentakt.
Für Kunden- und Bestelldaten gilt die DSGVO-Faustregel: Jeder Export ist ein Verarbeitungsvorgang und gehört ins Verzeichnis. Wer Kundendaten an einen Marktplatz oder ein Marketing-Tool weitergibt, braucht Auftragsverarbeitungsvertrag und Rechtsgrundlage. Die technische Frage „Wie exportiere ich?“ hat eine rechtliche Schwester, die viele Händler erst nach der ersten Abmahnung stellen.
Die häufigste Fehlentscheidung 2026: Händler lösen ein Synchronisationsproblem mit einem Export. Ein Export ist ein Snapshot. Ein Sync ist ein Zustand.
Wie sieht ein belastbarer Export-Workflow 2026 aus?
Für einen Shop zwischen 5.000 und 50.000 SKUs hat sich in der Praxis folgende Struktur bewährt:
- Stammdaten: Einmal täglich nachts ein Voll-Export aus Shopware in ein Data-Warehouse oder eine Staging-Datenbank. Format: JSON statt CSV. Versioniert.
- Bestände und Preise: Inkrementell über die Admin-API, alle 10 bis 15 Minuten, gefiltert nach
updatedAt. Ziel: Marktplätze und Preisvergleichsportale. - Bestellungen: Push über Webhook oder Event in das ERP, sobald der Status
completederreicht wird. Kein Polling. - Kunden: Export nur anlassbezogen und mit Protokoll. Kein Dauerabzug.
Kritisch ist der Fallback: Was passiert, wenn der Sync 24 Stunden ausfällt? Ohne eine Reconciliation-Routine, die täglich Voll- und Delta-Bestand vergleicht, merkt das niemand, bis der erste Kunde zwei Mal bestellt hat.
Der native Shopware-Export bleibt in diesem Setup eine Rolle: als Notausgang. Wenn die Middleware streikt, will man innerhalb von Minuten einen vollständigen Katalog-Snapshot ziehen können — für den Worst Case, den hoffentlich nie eintretenden.
Wer heute noch ohne Delta-Logik arbeitet und Katalogdaten per Hand als CSV in Marktplätze hochlädt, wird 2026 mehr Zeit in Fehlerbehebung stecken als in Sortimentsarbeit. Die Werkzeuge sind da — es fehlt selten an Technik, sondern an der Bereitschaft, Synchronisation als eigene Disziplin zu behandeln statt als Nebenaufgabe des Shop-Admins.