Ein Tutorial, das gar keins sein will
Firebear Studio hat Anfang September einen neuen Guide veröffentlicht: „Magento 2 REST API Import“ — auf den ersten Blick ein hilfreiches Tutorial für alle, die ihr ERP, ihr PIM oder einen Lieferanten-Feed an den Shop anbinden wollen. Wer genauer hinschaut, erkennt die Dramaturgie in drei Akten. Erst erklärt der Artikel, was REST ist. Dann listet er sämtliche Probleme auf, die ein echter Datenimport mit sich bringt: Authentifizierung, Attribut-Mapping, Transformationen, Scheduling. Und schließlich präsentiert er — welch Überraschung — das eigene Plugin „Improved Import & Export“ als Rettung aus der selbst beschriebenen Misere.
Das ist keine redaktionelle Arbeit. Das ist Content-Marketing mit Lehrbuch-Anstrich. Ich sage das nicht als Vorwurf — Firebear macht damit gutes Geschäft, und die Extension selbst ist solide. Der interessante Teil ist ein anderer: Der Artikel funktioniert nur deshalb als Verkaufsargument, weil die Ausgangslage so desaströs ist, dass man ein Problem erst aufbauschen muss, das eigentlich keines sein dürfte.
„When you need to retrieve product, customer, order, category, inventory, or other data regularly, you also need to handle authentication, data formats, attribute mapping, transformations, and import scheduling. This is where the Improved Import & Export extension for Magento 2 comes in.“
Lesen Sie diesen Absatz noch einmal. Firebear beschreibt hier den Normalfall eines jeden mittelständischen Händlers: regelmäßig Bestände synchronisieren, Preise aktualisieren, Produkte aus dem PIM einspielen. Kein Edge-Case, kein Raketenwissenschaft-Setup. Und die Antwort von Adobe Commerce auf diesen Normalfall ist — nichts. Ein CSV-Uploader mit Cronjob und ein natives Import-Modul, das bei mehr als ein paar tausend SKUs zur Geduldsprobe wird. Der Rest ist Selbstbau oder Plugin-Marktplatz.
Die Ökosystem-Ausrede zieht nicht mehr
Die übliche Verteidigung kenne ich aus jedem Agentur-Gespräch der letzten zehn Jahre: Magento ist eben ein Framework, kein fertiges Produkt. Die Stärke liegt in der Erweiterbarkeit. Für alles gibt es eine Extension.
Das war 2016 ein Argument. 2026 ist es eine Ausrede. Shopify hat seine Admin-API so weit ausgebaut, dass Bulk-Operationen über GraphQL mit Webhook-Benachrichtigung zum Standard gehören — ein Händler mit einem kompetenten Freelancer bekommt einen Lieferanten-Sync an einem Nachmittag ans Laufen. commercetools ist ohnehin API-first gebaut, Import und Export sind dort kein Thema, über das man Blogposts schreibt. Sogar Shopware, das in DACH um dieselbe Kundschaft buhlt, liefert mit der Sync-API und dem Import-Export-Profil eine native Lösung, die für die meisten Mittelständler ausreicht. Kein Plugin-Kauf. Kein Lizenz-Abo. Kein Vendor-Lock beim Erweiterungs-Hersteller.
Und Magento? Der Händler in Deutschland, der seinen WaWi-Bestand alle vier Stunden sauber im Shop haben will, steht vor drei Optionen. Er baut selbst — und beschäftigt fortan einen Entwickler für das Thema Authentifizierung, Rate-Limits und Fehlerhandling. Er kauft Firebear oder einen der Konkurrenten — und hängt an einem weiteren Lizenzmodell, das bei jedem Magento-Update mitgetestet werden will. Oder er macht es wie viele Mittelständler: CSV-Export aus dem ERP, nächtlicher Import per Cron, Daumen drücken. Ich habe Shops gesehen, in denen der „Echtzeit-Bestand“ auf diese Weise einen Tag hinterherhinkt — mit allen Folgen für Overselling und Stornierungen.
Was das für DACH-Händler konkret heißt
Der deutsche Mittelstand tickt bei dieser Frage anders als der US-Markt, für den Adobe primär entwickelt. Hier ist die Warenwirtschaft Chef — JTL, plentymarkets, VARIO, BüroWare, ein Dutzend SAP-Varianten. Die Integration Shop-zu-ERP ist nicht ein Feature unter vielen, sie ist die Existenzgrundlage des gesamten Setups. Wenn diese Integration ein Plugin-Geschäftsmodell darstellt, zahlt der Händler doppelt: einmal für die Extension, dann nochmal für die Agentur, die sie konfiguriert und bei Updates nachzieht.
Rechnen Sie es durch. Die Firebear-Extension kostet je nach Umfang einen mittleren dreistelligen bis vierstelligen Betrag pro Jahr, dazu Agenturstunden für Mapping und Transformation — bei einem typischen Mittelständler mit 20.000 Artikeln und zwei Lieferanten-Feeds landen Sie schnell bei fünfstelligen Einmalkosten plus laufendem Unterhalt. Geld, das nicht in Sortiment, Marketing oder Conversion fließt, sondern in das Herstellen eines Zustands, den andere Plattformen als Grundausstattung betrachten. Man könnte es die Magento-Integrationssteuer nennen.
Fairerweise gehört zur Wahrheit auch: Wer einmal sauber aufgesetzt ist, hat mit Improved Import & Export ein mächtiges Werkzeug. Die Transformations-Logik, das Scheduling, das Mapping — das ist erwachsene Software, und der Guide erklärt sie ordentlich. Wer bereits auf Magento sitzt und die Migration scheut, macht mit Firebear nichts falsch. Das Problem ist nicht das Plugin. Das Problem ist, dass das Plugin existieren muss.
Die unbequeme Frage zum Schluss
Adobe verdient an Adobe-Commerce-Lizenzen, nicht an der Leichtigkeit der Anbindung. Jede native Import-Funktion, die den Marktplatz für Extensions kleiner macht, beschneidet ein Ökosystem, in dem Adobe prozentual mitverdient. Es gibt also keinen internen Anreiz, dieses Loch zu stopfen — und genau deshalb wird es 2027 und 2028 identische Guides geben, nur mit aktualisierter Versionsnummer im Titel.
Für jeden DACH-Händler, der gerade eine Plattform-Entscheidung vorbereitet, stellt sich damit eine Frage, die man nicht dem Magento-Partner stellen sollte, sondern der eigenen Kostenrechnung: Was kostet es Sie über fünf Jahre, wenn Ihr Shop-System die Anbindung Ihrer Warenwirtschaft als Geschäftsmodell für Dritte behandelt? Wer diese Summe ehrlich beziffert und trotzdem bei Magento bleibt — aus guten Gründen, etwa B2B-Komplexität oder bestehenden Anpassungen — trifft eine informierte Entscheidung. Wer sie nie gestellt hat, subventioniert ein Versäumnis, ohne es zu merken.