CSV ist ein Relikt aus den 70ern. Und trotzdem zwingt Adobe Commerce Händler im Jahr 2026 dazu, jede Produktdaten-Integration durch dieses Format zu pressen. Wer aus einem modernen PIM, einer REST-API oder einem Headless-Frontend JSON erhält — also praktisch jeder, der ernsthafte E-Commerce-Architektur betreibt — steht vor demselben Problem: Der Standard-Import von Magento 2 und Adobe Commerce schluckt kein einziges JSON-File. Der JSON Import in Magento 2 bleibt Hausaufgabe des Händlers, nicht des Systems.
Das ist kein Randphänomen. Laut dem MACH Alliance Report 2025 setzen über 85 Prozent der befragten Enterprise-Commerce-Unternehmen auf API-first-Architekturen — und JSON ist das Transportformat dieser Welt. Wer im DACH-Markt mit Systemen wie Akeneo, Pimcore (aus Österreich, im deutschen Mittelstand weit verbreitet) oder Contentserv arbeitet, bekommt seine Daten JSON-nativ geliefert. Die Konvertierung nach CSV ist dabei mehr als eine lästige Zwischenstation: Sie zerstört genau die Strukturen, für die man JSON überhaupt nutzt.
Warum scheitert der Standard-Import von Adobe Commerce an JSON?
Die Antwort ist so simpel wie unbefriedigend: Der Import/Export-Kern von Magento wurde für flache, tabellarische Daten gebaut. CSV passt dazu. JSON nicht — zumindest nicht ohne Transformation.
Konkret scheitert es an drei Stellen. Erstens: Verschachtelung. Ein JSON-Objekt beschreibt ein Produkt als Baum — Attribute, Varianten, Preisregeln pro Kundengruppe, Medien-Assets mit Metadaten. CSV kennt nur Zeilen und Spalten. Wer einen konfigurierbaren Artikel mit 40 Varianten und kundengruppenspezifischen Staffelpreisen als CSV abbildet, erzeugt entweder Monsterzeilen mit Semikolon-Ketten oder Dutzende Einzelzeilen, die Magento mühsam wieder zusammensetzen muss. Zweitens: Typsicherheit. CSV liefert Strings. Ob „19,99“ ein Preis, ein Prozentsatz oder ein Tippfehler ist, entscheidet erst die Validierung. JSON trägt Datentypen explizit. Drittens: Partial Updates. JSON-APIs liefern üblicherweise nur geänderte Felder. Der CSV-Import erwartet dagegen definierte Spaltenstrukturen — fehlt eine Spalte, wird je nach Konfiguration der vorhandene Wert überschrieben oder der Import bricht ab.
Die drei realistischen Wege zum JSON Import in Magento 2
Wer heute JSON-Daten in Adobe Commerce oder Magento Open Source bringen will, hat faktisch drei Optionen — mit sehr unterschiedlichen Kosten-Nutzen-Profilen.
Weg eins: Custom Import-Modul. Ein Entwickler schreibt eine eigene Import-Schnittstelle, die JSON parst, auf das Magento-Attributmodell mappt und über die Repository-Schicht persistiert. Das ist die sauberste Lösung — und die teuerste. Realistisch kalkulieren Agenturen im DACH-Raum dafür 15 bis 40 Personentage, je nachdem, ob neben Produkten auch Kunden, Bestellungen oder CMS-Inhalte fließen sollen. Dazu kommt Wartung: Jedes Adobe-Commerce-Update kann die internen APIs anfassen, auf die das Modul aufsetzt. Für Händler mit festem Entwicklerteam und exotischen Datenstrukturen ist das oft trotzdem der richtige Weg. Für alle anderen ist es Overkill.
Weg zwei: iPaaS und Middleware. Tools wie MuleSoft, Boomi oder im deutschen Mittelstand häufiger Alumio und Synesty übernehmen die Transformation JSON→CSV→Magento als konfigurierbaren Flow. Der Vorteil: Kein eigener Code, Monitoring und Retry-Logik inklusive. Der Nachteil: laufende Kosten. Alumio startet im vierstelligen Monatsbereich, Enterprise-iPaaS deutlich darüber. Und man importiert sich eine neue Abhängigkeit in den kritischen Datenpfad — fällt die Middleware aus, steht der Preisfeed.
Weg drei: Import-Extensions. Der Markt dafür ist reif. Amasty, Firebear Studio und Mageplaza bieten Module, die den nativen Import um JSON (und meist auch XML, XLSX und API-Quellen) erweitern. Firebear Improved Import & Export gilt als der funktional tiefste Kandidat: Mapping per UI, Cron-gesteuerte Jobs, verschachtelte Strukturen über XPath-ähnliche Pfade. Kostenpunkt: einmalig 300 bis 600 Euro, plus jährliche Update-Gebühr. Für den typischen Mittelstands-Shop — Produktdaten aus dem PIM, Lagerbestände vom Lieferanten, Preise aus einer Kalkulations-API — ist das das beste Verhältnis aus Aufwand und Ergebnis.
Wie sieht ein belastbares JSON-Mapping in der Praxis aus?
Die eigentliche Arbeit steckt nicht im Import, sondern im Mapping. Ein typischer Lieferanten-Feed sieht so aus: Ein Array von Produktobjekten, darin Attribute als Key-Value-Paare, Varianten als verschachteltes Array, Preise als Objekt mit Währung, Netto- und Bruttobeträgen, Steuerklasse als Code. Magento erwartet dagegen: SKU als Schlüssel, Attribute im richtigen Attribut-Set, Varianten referenziert über die Parent-SKU, Preise numerisch, Steuerklasse als Magento-interne ID.
Dazwischen liegt Transformationslogik, die jemand definieren muss. Drei Fallstricke erlebt jeder, der das zum ersten Mal macht:
- Attribut-IDs statt Labels. Der Feed liefert „farbe“: „Rot“ — Magento braucht die interne Option-ID des Attributs
color. Ohne Lookup-Tabelle schlägt der Import fehl oder legt Dubletten an. - Deutsche Zahlenformate. Gerade bei Feeds aus DACH-ERP-Systemen (SAP Business One, JTL-Wawi, plentymarkets) taucht „1.299,95“ auf — für den Magento-Parser ein String, keine Zahl. Ein Preprocessing-Schritt ist Pflicht.
- Varianten-Reihenfolge. Kinder vor Eltern importieren erzeugt verwaiste Simple Products; Eltern ohne Kinder erzeugt konfigurierbare Artikel ohne Auswahloptionen. Die Job-Orchestrierung muss die Abhängigkeiten kennen.
Was bringt das in Performance und Stabilität?
100.000 SKUs sind der Prüfstein. Dort trennt sich die Architektur vom Skript. Der native Magento-Import — auch der erweiterte per Extension — verarbeitet je nach Hosting und Index-Konfiguration grob 1.000 bis 5.000 Datensätze pro Minute. Ein vollständiger Katalogabgleich dauert also Stunden. Wer minutengenaue Bestands- oder Preisdaten braucht, kommt um die API-Route nicht herum: Adobe Commerce stellt mit den REST- und zunehmend den GraphQL-Bulk-Endpoints JSON-native Schnittstellen bereit — asynchron, mit Queue-Verarbeitung über RabbitMQ. Das ist der Weg, den ernsthafte Integrationen ab etwa 2024 gehen, und er liegt technisch näher am Event-Streaming als am klassischen Datei-Import.
Ehrlicherweise gehört zur Performance-Frage auch der Hinweis auf Hyvä und die generelle Magento-Modernisierung: Wer seinen Stack ohnehin umbaut, sollte den Datenimport gleich mitdenken. Ein JSON-Import, der in ein sauberes Event-Modell mündet (Produkt geändert → Queue → Index-Invalidierung), skaliert besser als jeder nächtliche Full-Import.
Die Frage ist nicht „CSV oder JSON“, sondern „Datei-Import oder Event-Stream“. Wer 2026 noch Kataloge als nächtliche Vollabzüge synchronisiert, betreibt die Architektur von 2015.
Die unbequeme Wahrheit für Adobe-Händler
Adobe hat mit dem API Mesh und den App-Builder-Erweiterungen längst die Infrastruktur für JSON-native Integrationen gebaut — im Lizenzgeschäft heißt das aber Adobe Commerce Cloud, nicht das Import-Menü im Admin-Panel. Der Datei-Import bleibt CSV. Das ist Produktpolitik: Wer moderne Datenflüsse will, soll in Adobes Cloud-Ökosystem wandern.
Für Händler im DACH-Markt ergibt sich daraus eine klare Entscheidungslogik. Unter 20.000 SKUs und täglichen Updates reicht eine Import-Extension völlig aus — die 500 Euro sind in einer Woche zurückverdient, wenn man die Alternative „Entwickler schreibt CSV-Konverter“ gegenrechnet. Ab komplexen Preislogiken, mehreren Lieferanten-Feeds oder Echtzeit-Anforderungen lohnt der Schritt Richtung Middleware oder API-Integration. Und wer heute neu plant, sollte den Datei-Import gar nicht mehr als Herzstück der Architektur vorsehen, sondern als Fallback.
Der pragmatische nächste Schritt: den eigenen häufigsten Datenfluss nehmen — meist Produktdaten aus dem PIM — und prüfen, ob die Quelle eine REST-Schnittstelle hat, die JSON liefert. Falls ja, ist die Extension-Route in einem Tag aufgesetzt. Falls nein, hat man ohnehin ein größeres Problem als das Dateiformat.