Mittlere bis große B2C-Unternehmen – insbesondere Markenhersteller oder Marken-Einzelhändler – stoßen mit Adobe Commerce (ehemals Magento Enterprise) oft an ihre Grenzen. Diese Unternehmen haben komplexe, inhaltsreiche Anforderungen, die über die Standardfunktionen hinausgehen. In diesem Blogbeitrag analysieren wir die wichtigsten Herausforderungen, denen solche Unternehmen mit Adobe Commerce gegenüberstehen, und warum ein Headless Commerce-Ansatz oft die überzeugendere Lösung ist. Außerdem zeigen wir einige Beispiele für Händler, die von Magento weg migrieren.
Einschränkungen der Frontend-Flexibilität beim traditionellen Magento-Theming
Einer der größten Schwachpunkte ist die mangelnde Flexibilität des traditionellen Frontend-Systems von Magento. In einer herkömmlichen Adobe Commerce-Konfiguration ist das Frontend eng mit dem Backend verbunden und basiert auf Magento's eigenem Template-System (PHP und Knockout.js). Diese Headful Architektur bedeutet, dass jede wesentliche Änderung der Benutzeroberfläche innerhalb des Theme-Frameworks von Magento erfolgen muss – ein Ansatz, der sich starr und veraltet anfühlt. Das Standard-Theme „Luma“ von Magento (und sogar das „Blank“-Theme) basieren auf älteren Technologien (RequireJS usw.), die nicht die Performance oder Entwicklerflexibilität moderner JavaScript-Frameworks bieten.
Magento wird regelmässig für sein leistungsschwaches Frontend und die Komplexität bei der Umsetzung von Verbesserungen der Benutzererfahrung kritisiert. Die laufende Anpassung des Storefronts erfordert umfangreiche Arbeiten mit XML-Layoutdateien, wenig intuitiven JavaScript-Widgets und CSS-Preprocessors – all dies verlangsamt die Entwicklung. Für ein markenorientiertes Unternehmen, das ein pixelgenaues, innovatives Webdesign umsetzen möchte, sind diese Theme-Einschränkungen frustrierend. Selbst mit dem Page Builder von Magento, der einige No-Code-Designfunktionen bietet, bleibt dies im Vergleich zur Nutzung eines modernen CMS oder Frontend-Stacks eingeschränkt. Kurz gesagt, das monolithische Frontend von Magento schränkt die kreative Freiheit und schnelle Experimente ein, was viele Marken dazu veranlasst, nach flexibleren Headless-Frontends zu suchen.
Herausforderungen bei der Integration eines Best-of-Breed-CMS
Content ist König im markenorientierten Handel, aber die Integration eines Best-of-Breed-CMS in Magento ist nicht trivial. Das native CMS von Adobe Commerce (Seiten, Blöcke und Page Builder) deckt zwar die Grundanforderungen ab, verfügt jedoch nicht über die fortschrittlichen Funktionen für Content-Modellierung, Workflows und Omni-Channel-Bereitstellung, die dedizierte CMS-Plattformen bieten (z. B. Contentful, Storyblok, Optimizely, Adobe Experience Manager usw.). Marken, die Wert auf reichhaltiges Storytelling, Blog-Inhalte oder komplexe Landingpages legen, empfinden die integrierten Tools von Magento oft als zu einschränkend, mit begrenzten Anpassungsmöglichkeiten und Flexibilität.
Sie können Magento natürlich mit einem Headless CMS kombinieren, aber in einer traditionellen gekoppelten Architektur wird dies schnell umständlich. Das Einbetten von CMS-verwalteten Inhalten in Magento-Vorlagen – oder die Synchronisierung der beiden Datenmodelle – erfordert in der Regel benutzerdefinierten Code oder Middleware. Händler greifen oft auf unelegante Lösungen wie Iframes, instabile API-Ketten oder nächtliche Synchronisierungsjobs zurück, die alle die Komplexität erhöhen und jede Inhaltsaktualisierung verzögern. Anstatt das Kundenerlebnis zu optimieren, verbringen die Teams den Großteil ihrer Zeit damit, zwei widerstrebende Systeme zur Zusammenarbeit zu bewegen.
Im Gegensatz dazu übernimmt bei einem Headless-Commerce-Modell das CMS die Präsentationsschicht (und entscheidet, wo und was angezeigt wird) und ruft die Commerce-Funktionen über APIs ab – eine klarere Trennung. Unter dem Strich haben Händler, die eine „Best-of-Breed“-Content-Lösung wünschen, oft Schwierigkeiten mit dem monolithischen Aufbau von Magento.
Komplexität der Integration
Unternehmensretailer betreiben in der Regel eine Reihe von Systemen – ERP für Bestellungen und Lagerbestände, PIM für Produktdaten, CRM für Kundendaten usw. Die Integration dieser Systeme in Magento ist ein großes Unterfangen, das oft als Problem für IT-Teams genannt wird. Adobe Commerce bietet zwar APIs und einige sofort einsatzbereite Konnektoren, aber für die Integration in der Praxis sind in der Regel kundenspezifische Entwicklungen oder Middleware von Drittanbietern erforderlich. Jeder zusätzliche Touchpoint (ERP, CRM, Lagerverwaltung usw.) bedeutet neue Schnittstellen und Datenflüsse, die aufgebaut und gewartet werden müssen. Tatsächlich kann die Vielzahl der Integrationsmöglichkeiten IT-Abteilungen an ihre Grenzen bringen.
In mittelständischen und großen Unternehmen ist es üblich, mehrere ERPs oder andere Backend-Systeme zu haben (aufgrund globaler Aktivitäten oder Übernahmen). Alle müssen mit der E-Commerce-Plattform synchronisiert werden, um konsistente Produktinformationen, Preise und Lagerbestände zu gewährleisten. Genau das macht die Integration von Adobe Commerce so komplex – der Erfolg hängt stark von der bestehenden IT-Architektur und oft von einer robusten PIM- oder Übersetzungsschicht ab. Ohne einen entkoppelten Ansatz werden Datenintegrationsaufgaben in der Regel zu einem fragilen „Spaghetti-Nudel-System“ aus Punkt-zu-Punkt-Verbindungen. Jede Änderung (wie der Austausch eines Altsystems oder das Hinzufügen eines neuen Kanals) erfordert erhebliche Nacharbeiten auf der Magento-Seite. Eine solche Rigidität steht im Widerspruch zu der Agilität, die der moderne digitale Handel erfordert.
Probleme mit Leistung und Skalierbarkeit
Eine weitere häufige Herausforderung ist die Erreichung einer hohen Leistung und Skalierbarkeit mit Magento, insbesondere bei B2C-Websites mit hohem Datenverkehr oder schnellen Verkaufsaktionen. Der umfangreiche Funktionsumfang und die umfangreiche Codebasis von Magento können zu einem hohen Ressourcenverbrauch führen – wenn die Seiten nicht stark optimiert sind, laden sie langsam und die Serverkosten steigen. Große Kataloge, viele Erweiterungen oder benutzerdefinierter Code belasten das System zusätzlich. Die Plattform hat oft mit Skalierbarkeitsproblemen zu kämpfen, was zu langen Ladezeiten oder Ausfällen während Spitzenzeiten führt. Dies birgt nicht nur das Risiko von Umsatzverlusten, sondern untergräbt auch das Vertrauen der Kunden durch eine schlechte Erfahrung.
Die Skalierung von Magento bedeutet traditionell die Skalierung des gesamten Anwendungsstacks (da Frontend und Backend eine Einheit bilden), was kostspielig und komplex ist. Im Gegensatz dazu können Sie mit einer Microservices- oder Headless-Architektur bestimmte Dienste (z. B. Checkout, Produktkatalog, Storytelling-Seiten, Suche) unabhängig voneinander skalieren. Viele Magento-Nutzer versuchen Notlösungen – Vollseiten-Caching, CDN oder Umstieg auf das Cloud-Angebot von Adobe –, aber diese lindern nur die Symptome. Das Kernproblem bleibt, dass die monolithische Architektur erhebliche Anpassungen und eine umfangreiche Infrastruktur erfordert, um in großem Maßstab zu funktionieren, was für wachsende Marken ein ständiges Problem darstellt.
Inflexibilität der monolithischen Architektur
Monolithische Plattformen wie Adobe Commerce weisen im Vergleich zu modernen komponierbaren Setups inhärente Flexibilitätsbeschränkungen auf. Im „All-in-One“-Design von Magento sind Frontend, Backend und Datenbank eng integriert und werden als eine Einheit bereitgestellt. Das bedeutet, dass jede Änderung (eine neue Funktion, ein Upgrade, eine Fehlerbehebung) die erneute Bereitstellung und das Testen der gesamten Anwendung erfordert. Es ist schwierig, Teile des Systems für unabhängige Updates zu isolieren. Für Unternehmen, die kundenorientierte Funktionen schnell iterieren müssen, wird diese Kopplung zu einem Engpass. Im Gegensatz dazu trennt Headless Composable Commerce die Präsentationsschicht und unterteilt die Backend-Commerce-Funktionen in Dienste, sodass sich jeder Teil nach seinem eigenen Zeitplan weiterentwickeln kann.
In der Praxis behindert die Architektur von Magento die Einführung neuer Frontend-Technologien oder -Dienste. Die Implementierung einer neuen Suchmaschine oder eines neuen Personalisierungstools erfordert beispielsweise eine tiefgreifende Integration von Magento-Modulen, während Sie bei einem komponierbaren Ansatz eine SaaS-API mit weniger Reibungsverlusten einbinden können. Die Anpassungsmöglichkeiten in Magento sind zwar leistungsstark, aber mit einem hohen Aufwand verbunden – Entwickler müssen viele Erweiterungen und umfangreichen benutzerdefinierten Code jonglieren, um das zu erreichen, was ein maßgeschneiderter Microservice eleganter leistet.
Entwicklererfahrung, Markteinführungszeit und Wartungsaufwand
Adobe Commerce gibt Ihnen „vollständige Kontrolle“, aber diese Kontrolle zu erlangen, kostet Zeit und Geld. Die meisten mittelständischen und großen Händler beschäftigen ein eigenes Magento-Team – oder bezahlen teure Agenturen –, um die Website anzupassen und zu warten. Selbst eine kleine Funktion kann bedeuten, dass ein neues Modul geschrieben, mit Dutzenden von bestehenden Erweiterungen abgeglichen und umfangreiche Regressionstests durchgeführt werden müssen, was jede Veröffentlichung in die Länge zieht und die Markteinführungszeit verlangsamt.
Upgrades sind nicht einfacher: Jeder Sicherheitspatch oder jede kleinere Version kann zu einem Mini-Projekt werden, da Sie überprüfen müssen, ob der benutzerdefinierte Code und die Module von Drittanbietern weiterhin reibungslos zusammenarbeiten. Im Laufe der Jahre führt diese ständige Nachrüstung zu technischen Schulden, wodurch Magento immer anfälliger und teurer in der Betrieb wird. Teams müssen entweder Ressourcen in Magento-Spezialisten investieren oder die Weiterentwicklung des Shops einstellen – kaum eine agile Entscheidung. Kein Wunder, dass viele Entwickler Magento als „Schwergewicht“ betrachten: leistungsstark, aber im Vergleich zu schlankeren JAMstack- oder Headless-Frameworks schwerfällig.
Magento als Schwergewicht in einer agilen Frontend-Welt
Für markenorientierte Unternehmen, die Wert auf Frontend-Innovation legen, ist Magento einfach zu viel Plattform. Diese Unternehmen stellen häufig fest, dass sie nur einen Bruchteil der umfangreichen Funktionen von Magento nutzen, aber dennoch die volle Last seiner Komplexität tragen. Im Wesentlichen wird die Stärke von Magento – eine Vielzahl integrierter Funktionen – zu einer Schwäche, wenn Sie eine schlanke, zweckgebundene Lösung benötigen.
Die Notwendigkeit, schnell neue digitale Erlebnisse zu liefern (von interaktiven Lookbooks über AR-Anproberäume bis hin zu progressiven Web-Apps), ist für moderne Einzelhandelsmarken von entscheidender Bedeutung. Ein agiles (schnell, anpassungsfähig, reaktionsschnell) Frontend ist für diese Art von Innovation unerlässlich. Die Architektur von Magento und die Abhängigkeit von seinem eigenen Theme-Ansatz erschweren jedoch schnelle Änderungen am Frontend und erfordern oft Anpassungen am Backend oder komplexe Workarounds. Der Update-Zyklus der Plattform hinkt ebenfalls hinterher, was zu einem veralteten Frontend-Stack und wachsenden technischen Schulden in den Standard-Themes führt. Community-Initiativen wie das Hyvä-Theme (ein leichtgewichtiges alternatives Frontend für Magento, über das wir kürzlich berichtet haben) entstanden, um die Leistungs- und Komplexitätsprobleme von Magento anzugehen – im Wesentlichen wurden Teile des Frontends von Magento entfernt, um es agiler zu machen (mit neueren Frontend-Technologien und einer verbesserten Entwicklererfahrung). Das ist bezeichnend: Es zeigt, wie weit Entwickler gehen, um Magento frontendfreundlicher zu machen.
Die Serverseite ist auf Stabilität ausgelegt und wird nur gelegentlich geändert, während die Kundenseite mit neuen Geräten, frischen Designs und steigenden Nutzererwartungen Schritt halten muss. Da sie unterschiedlichen Zeitplänen folgen, altern sie unterschiedlich schnell: Code, der im Backend noch „modern“ wirkt, kann im Browser nach ein oder zwei Jahren veraltet aussehen. In der monolithischen Struktur kollidiert früher oder später der Bedarf des Frontends an schnellen Updates mit dem langsameren Tempo des Backends, und die gesamte Website wird am Ende so langsam wie ihr schwerster Teil.
Sicherheitsrisiken und Patch-Aufwand in Magento
Die Größe und Beliebtheit von Magento machen es zu einem bevorzugten Ziel für Angreifer, was sich auch in seiner Sicherheitsbilanz widerspiegelt. Adobe veröffentlicht jedes Jahr mehrere kritische Patches, deren Anwendung jedoch selten mit einem Klick erledigt ist. Infolgedessen verzögern viele Händler die Installation von Patches – manchmal um Monate –, wodurch bekannte Schwachstellen offen bleiben und Magecart-ähnliche Card-Skimming-Angriffe ermöglicht werden. Mitte 2024 zeigte eine kritische XML-External-Entity-Sicherheitslücke mit dem Spitznamen „“, wie kostspielig diese Verzögerung sein kann. Innerhalb weniger Tage nach der Bekanntgabe begannen sieben verschiedene Hackergruppen, den Fehler auszunutzen, um Card-Skimming-Malware zu installieren. Forscher schätzen, dass etwa 5 % aller Adobe Commerce- und Magento-Shops – mehr als 4.000 Websites, darunter Marken wie Ray-Ban und Whirlpool – kompromittiert wurden. Eine Woche nach der Veröffentlichung des Patches durch Adobe waren drei Viertel der Shops noch immer nicht gepatcht.
Auch das Hosting-Modell spielt eine Rolle. Selbst gehostetes Magento erfordert gehärtete Server, WAF-Regeln, PCI-Compliance und eine Überwachung rund um die Uhr. Adobe Commerce Cloud entlastet Sie zwar teilweise, doch sind Sie weiterhin für Schwachstellen auf Code-Ebene und die Sicherheit Ihrer Erweiterungen verantwortlich. Im Vergleich zu SaaS- oder modularen Setups, bei denen der Commerce-Kern gesperrt und Frontend-Services isoliert sind, bündelt die monolithische Architektur von Magento Risiken: Sobald ein Angreifer eindringt, sind alle Daten, von Produktdaten bis hin zu Zahlungs-APIs, gefährdet.
Kurz gesagt: Die Sicherheit eines Magento-Shops zu gewährleisten, ist ein kontinuierlicher, ressourcenintensiver Kampf. Entweder investieren Sie viel in Sicherheitsexpertise und schnelle Patch-Zyklen oder Sie akzeptieren ein erhöhtes Risiko – ein unbequemer Kompromiss für Marken, die Wert auf Kundenzufriedenheit und die Einhaltung gesetzlicher Vorschriften legen.
Beispiele für die Migration von Magento zu Headless/Composable Commerce
In den letzten Jahren sind viele Unternehmen von Magentos Monolith zu einem Headless- oder Composable-Modell gewechselt, um ihren Anforderungen besser gerecht zu werden. Im Folgenden finden Sie einige kurze Beispiele, die die Beweggründe und Ergebnisse veranschaulichen:
Gymshark
Von Magento zu Headless Shopify
Ausfälle und langsame Suchvorgänge bei Magento veranlassten Gymshark zu einem Headless-Stack: Shopify Plus für den Handel, Algolia für die Suche und andere Best-of-Breed-Services. Die neue Konfiguration bewältigte 450.000 gleichzeitige Nutzer am Black Friday und lieferte eine deutlich schnellere Benutzererfahrung.
LoveCrafts
Composable statt Magento 2
Angesichts des Endes des Lebenszyklus von Magento 1 übersprang LoveCrafts Magento 2 und führte einen Composable-Stack mit Commercetools als Kern ein, wobei separate Dienste für Inhalte und Suche ausgetauscht wurden. Das API-First-Modell beschleunigte die Entwicklung und eröffnete neue Vertriebskanäle.
Kaporal
Headless Front-End, Magento Back-End
Kaporal behielt Magento (mit Upgrade auf v2) bei, ersetzte jedoch das Front-End durch einen React-basierten Headless Storefront. Die Ladezeiten der Seiten verkürzten sich, die Absprungraten sanken um 60 % und die Konversionsraten stiegen um 15 % auf Desktop-Geräten und um 8 % auf Mobilgeräten.
Fazit
Adobe Commerce (Magento) ist seit langem eine leistungsstarke All-in-One-Plattform, doch für erfahrungsorientierte, integrationsintensive B2C-Marken zeigt sie zunehmend Schwächen. Starre Themes, arbeitsintensive Integrationen und hoher Wartungsaufwand können Innovationen verlangsamen und die Gesamtbetriebskosten in die Höhe treiben. Headless/Composable Commerce beseitigt diese Engpässe, indem es die Storefront vom Kernsystem trennt und Teams die Möglichkeit gibt, Best-of-Breed-Services für Inhalte, Suche, Personalisierung und mehr zu integrieren. Das Ergebnis sind eine schnellere Markteinführung, eine einfachere Skalierung und die Freiheit, einzigartige Kundenerlebnisse zu schaffen.
Selbst Adobe hat sich dieser Richtung angeschlossen. Anfang 2024 stellte das Unternehmen Adobe Commerce Storefront vor, ein SaaS-Frontend, das auf Edge Delivery Services basiert. Das neue Angebot bietet:
Headless-Architektur out of the box
– die Storefront ist vollständig entkoppelt und kommuniziert über GraphQL und API Mesh mit Adobe Commerce.
Vorkonfigurierte „Drop-in“-Komponenten
(PDP, Warenkorb, Kasse usw.), die die Entwicklung beschleunigen und dennoch eine vollständige Anpassung ermöglichen.
Leistungsorientierte Bereitstellung
am Edge, die Lighthouse-Werte im Bereich von 90 bis 100 erreicht und die für Luma-basierte Websites typischen Payloads reduziert.
Einen Migrationspfad, den Adobe selbst als „ähnlich wie die Umstellung auf eine Headless-Storefront“ beschreibt, was erneut bestätigt, dass die API-gesteuerte Trennung nun das empfohlene Modell ist.
Die Entwicklungen von Adobe bestätigen den allgemeinen Trend: Der moderne Handel erfordert einen flexiblen, serviceorientierten Stack. Für Händler, die bereit sind, sorgfältig zu planen – und oft einen erfahrenen Integrationspartner hinzuzuziehen –, bietet Headless die Agilität, mit der Magento als Monolith nur schwer mithalten kann.
Headless ist jedoch kein Allheilmittel. Der Erfolg hängt nach wie vor von der Architektur, der Governance und der kompetenten Implementierung ab. Da jedoch Adobe selbst eine entkoppelte Frontend-Architektur befürwortet, ist die Botschaft klar: Der Commerce der Zukunft wird headless, modular und für den Einsatz am Edge optimiert sein. Händler, die diesen Schritt wagen, können sich mit den Marktanforderungen weiterentwickeln, anstatt durch den All-in-One-Stack von gestern ausgebremst zu werden.
Da Adobe sich zunehmend auf große Unternehmen konzentriert, sollten mittelständische Marken nach Anbietern Ausschau halten, die einen entkoppelten Commerce-Stack besser unterstützen. Shopify (mit ShopifyPlus) und Medusa.js, die beide mit Blick auf Headless-Architekturen entwickelt wurden, sind starke Optionen für Composable Commerce.
