50.000 Artikel, drei Storeviews, zwei Sprachen: Wer einen Magento-Shop in dieser Größenordnung betreibt, kommt am Thema Datenexport per Kommandozeile nicht vorbei. Doch hier liegt das Problem: Magento 2 Open Source und Adobe Commerce bieten von Haus aus keinen nativen CLI-Befehl für den Produktdaten-Export. Wer über bin/magento nach einem passenden Kommando sucht, wird nicht fündig.
Der Standardweg führt über den Adminbereich: System, dann Data Transfer, dann Export. Dort wählen Administratoren den Entity-Typ – etwa Products –, setzen Filter auf Attribute oder Kategorien und erhalten eine CSV-Datei. Für den gelegentlichen Abzug reicht das. Für wiederkehrende Prozesse wie die Synchronisation mit einem PIM-System, ein Warenwirtschafts-Update oder den Feed-Abgleich mit Marktplätzen ist der manuelle Klickweg allerdings ein Nadelöhr. Keine Automatisierung, kein Cron, kein Skripting – und bei großen Katalogen auch kein verlässliches Timeout-Verhalten im Browser.
Warum fehlt der CLI-Export in Magento 2?
Die Antwort liegt in der Architektur: Magento trennt die Data-Transfer-Komponente strikt vom Kommandozeilen-Layer. Die CLI-Registrierung deckt Cache, Indexer, Setup und Module ab – Import und Export laufen dagegen als Web-Prozesse über den Admin-Controller. Adobe hat diese Lücke auch in den aktuellen Releases der 2.4.x-Linie, zuletzt mit den Security-Patches für 2.4.7 und 2.4.6-pX, nicht geschlossen. Es gibt keine offizielle Roadmap, die einen nativen bin/magento export:products-Befehl andeutet.
Für technische Teams heißt das konkret: Wer Exports in Deployments, CI-Pipelines oder nächtliche Jobs einbauen will, muss nachrüsten. Drei Wege haben sich in der Praxis etabliert.
Welche Optionen haben Shopbetreiber?
Der direkteste Weg ist eine Extension. Der Platzhirsch ist Improved Import & Export von Firebear Studio, verfügbar für Open Source und Adobe Commerce. Die Erweiterung ergänzt genau das, was der Core fehlen lässt: CLI-Kommandos für Import und Export, Cron-basierte Jobs, zusätzliche Formate wie XML, XLSX und JSON sowie Anbindungen an Google Sheets, FTP und REST-APIs. Ein Export-Job lässt sich damit per Befehl anstoßen – etwa bin/magento export:job:run <job-id> – und damit in jedes Deployment-Skript hängen. Die Lizenz kostet je nach Edition im dreistelligen Bereich und gehört in vielen Agentur-Projekten ohnehin zum Standard-Stack.
Wer keine Drittanbieter-Extension will, bleibt die Eigenentwicklung: Über die REST-API (/V1/products mit Search-Criteria-Filtern) lassen sich Produktdaten paginiert auslesen und per Skript in CSV oder JSON überführen. Das funktioniert stabil, erfordert aber sauberes Rate-Limiting und ist bei 50.000 SKUs deutlich langsamer als ein direkter Datenbank-Export. Für einmalige Migrationen ausreichend, für tägliche Feeds nur bedingt geeignet.
Was bedeutet das für den Shop-Alltag?
Für Händler ab einer Million Euro Jahresumsatz ist der Admin-Export selten das eigentliche Thema – entscheidend ist die Automatisierbarkeit dahinter. Preislisten für B2B-Kunden, Bestandsabgleiche mit der Warenwirtschaft, Feeds für Google Shopping oder Idealo: All das will getaktet laufen, idealerweise ohne manuellen Eingriff. Shops, die hier noch auf Klick-Exporte setzen, verlieren pro Woche spürbar Arbeitszeit und riskieren veraltete Datenstände in Verkaufskanälen.
Unsere Empfehlung: Prüfen Sie, welche Exporte in Ihrem Shop tatsächlich wiederkehrend sind. Alles, was öfter als einmal pro Monat läuft, gehört in einen automatisierten Job – sei es über eine Extension, ein API-Skript oder eine Middleware wie eine iPaaS-Lösung. Und bevor Sie ein Upgrade auf die nächste 2.4.x-Version planen, testen Sie die Export-Kette auf einer Staging-Umgebung: Gerade Dritt-Extensions für Import und Export reagieren empfindlich auf Core-Updates, und ein gebrochener Feed fällt meist erst dann auf, wenn die Preise auf dem Marktplatz schon falsch stehen.