25 Jahre. So alt ist XSLT. Eine Sprache aus der Zeit, als man Websites noch mit Tabellen layoutete, gilt 2026 bei FireBear Studio als „new release“-würdiges Feature: Der XSLT-Editor in der Improved Import & Export Extension für Magento 2 soll Händlern endlich erlauben, beliebige Lieferanten-XML in ein Format zu drehen, das Magento verdaut. Die Euphorie in dem Beitrag ist echt. Meine Position ist es auch: Das ist kein Fortschritt. Das ist die Dokumentation eines Systemversagens, und Händler in DACH bezahlen die Zeche gleich dreifach.
Das eigentliche Problem heißt nicht XML, sondern Magento
Sehen wir uns an, was FireBear selbst beschreibt. Magento 2 kann XML-Dateien von Lieferanten „nicht immer out of the box verarbeiten“, heißt es im Original. Übersetzung: Die nativen Import-Fähigkeiten einer Enterprise-Plattform, für die Adobe Commerce-Kunden fünfstellige Jahresbeträge löhnen, scheitern an der banalsten Aufgabe des Handels, Produktdaten eines Großhändlers einlesen.
„When working with suppliers, you may often encounter XML files with custom table structures and formatting. Magento 2 cannot always process these files out of the box.“
Dieser Satz ist bemerkenswert, weil er so selbstverständlich daherkommt. Natürlich haben Lieferanten eigene Strukturen. Das war 2006 so und wird 2046 so sein. Eine Plattform, deren Kerngeschäft der Handel mit Waren Dritter ist, müsste Datenmapping als Kernkompetenz liefern. Stattdessen kauft der Händler eine Extension, die das Loch stopft, und bekommt dafür ein Feature verkauft, das so klingt, als hätte jemand die Enterprise-Service-Bus-Ära wiederentdeckt.
Ich will FireBear hier nicht schlechtmachen. Die Extension ist handwerklich solide, der XSLT-Editor pro Job ist clever gelöst, und die Firma verdient seit Jahren gutes Geld damit. Genau das ist der Punkt: Es existiert ein profitabler Markt dafür, dass Magento seine Hausaufgaben nicht macht. Der Kunde zahlt die Plattformlizenz und dann noch einmal für das, was die Lizenz eigentlich abdecken sollte.
Der Lock-in sitzt im Template, nicht in der Datenbank
Nun das, was in keinem Release-Post steht. Der XSLT-Editor ist, Zitat FireBear, „job-specific“, Sie bauen pro Import-Job ein eigenes Template. Klingt flexibel. Ist es auch. Aber denken Sie zwei Jahre weiter: Fünfzehn Lieferanten, fünfzehn handgeschriebene XSLT-Templates, gepflegt von der einen Agentur oder dem einen Entwickler, der XSLT noch kann. Ihre gesamte Lieferketten-Integration liegt als proprietäres Transformations-Wissen in den Jobs einer einzelnen Extension eines einzelnen Vendors.
Wechseln Sie die Extension, migrieren Sie auf ein PIM, ziehen Sie zu Shopify oder einem Composable-Stack, die Templates kommen nicht mit. Sie sind kein Asset, sie sind Altlast. Die ehrliche Rechnung lautet: Jeder Euro, den Sie in XSLT-Mappings stecken, erhöht die Wechselkosten Ihrer Datenarchitektur. Das ist Lock-in durch die Hintertür, getarnt als Flexibilität.
Für den DACH-Mittelstand ist das kein akademisches Problem. Der typische deutsche Onlinehändler mit zwei, drei Großhändlern und einem WaWi-System hat weder ein Integrations-Team noch einen Enterprise-Architect. Er hat eine Agentur und ein Budget. Wenn die Integrationslogik im XSLT-Editor einer Magento-Extension lebt, hat er faktisch keinen Überblick mehr darüber, was zwischen Lieferant und Shop eigentlich passiert. Der erste Fehler im Template, ein falsch gemapptes Attribut, ein Steuersatz, der im falschen Feld landet, und es verkauft sich munter mit 7 statt 19 Prozent.
Was Händler stattdessen verlangen sollten
Meine Forderung ist unspektakulär und darum unbequem: Datenmapping gehört in die Plattform oder in ein PIM mit offener Spezifikation, nicht in die Job-Konfiguration einer kostenpflichtigen Extension. Wer heute eine Magento-Architektur plant, sollte die Frage „Wo leben unsere Transformationsregeln, und wem gehören sie?“ genauso ernst nehmen wie die Frage nach dem Hosting.
Konkret heißt das: Mappings als versionierten, portablen Code behandeln, idealerweise außerhalb der Extension abgelegt und dokumentiert. Lieferanten-XML nicht ad hoc pro Job biegen, sondern zentral auf ein kanonisches Datenmodell normalisieren. Und bei der Plattformwahl den nativen Import als das bewerten, was er ist: ein Ausschlusskriterium, kein Fußnotenthema. Wer 2026 eine Plattform kauft, die Lieferanten-XML nicht nativ schluckt, kauft die Extension gleich mit, nur eben auf Raten.
FireBear hat mit dem XSLT-Editor ein gutes Produkt für ein schlechtes Problem gebaut. Chapeau. Aber die interessantere Frage stellt der Release-Post nicht: Warum muss es dieses Produkt überhaupt geben? Solange die Antwort „weil Magento es so will“ lautet, bleibt der XSLT-Editor das, was er ist, ein Pflaster auf einer Wunde, die der Plattformanbieter geschlagen hat. Und Pflaster werden bekanntlich nach Stückzahlen abgerechnet.