Magento in 2026: drei Architekturen für drei Wachstumsphasen

Einleitung

Die eine Magento-Architektur, die zu jedem Unternehmen passt, gibt es nicht. Die richtige Wahl hängt davon ab, was Sie heute brauchen und wie viel Spielraum Sie beim Wachsen benötigen. 2026 reicht die Bandbreite von einem schlanken Setup aus Magento und Hyvä über eine Headless-Plattform bis zu einem vollständig gemanagten Adobe-Service - jeweils mit anderen Kompromissen bei Kosten, Kontrolle und Komplexität.

Dieser Leitfaden vergleicht drei Magento-basierte Architekturen für drei Wachstumsphasen: Magento mit Hyvä, Headless Magento sowie Adobe Commerce mit Edge Delivery Services. Wir zeigen, was jede ermöglicht, was ihr Betrieb verlangt und wie die Gesamtkosten über drei Jahre die Entscheidung prägen.

Die meisten Plattformen scheitern nicht am ersten Tag. Sie scheitern, wenn das Wachstum kommt: ein zweites Land, eine App, B2B-Kunden mit eigenen Preislisten. Hat die Architektur das nicht vorgesehen, wird jeder neue Schritt zum Workaround - und Workarounds summieren sich. Das Fundament gleich richtig zu legen, ist die günstigste Entscheidung, die Sie treffen werden.

Die gute Nachricht: Mit Magento gab es noch nie so viele Wege, es richtig zu machen. Im November 2025 wurde das Hyvä Theme kostenlos und Open Source. Adobe betreibt Adobe Commerce inzwischen als Cloud Service, mit einem Storefront auf Edge Delivery Services. Und seit 2.4.9 erscheint jedes Jahr im Mai ein Major Release, jeweils drei Jahre lang unterstützt.

Gleiches Fundament. Auf jeder Stufe.

Den Storefront sehen die Kunden. Ob eine Plattform den Produktivbetrieb übersteht, entscheidet sich darunter. Diese Prinzipien gelten auf jeder Stufe - nur die Werkzeuge, mit denen sie umgesetzt werden, unterscheiden sich.

• Backoffice-Systeme bremsen nie den Shop. ERP, PIM und CRM sind über eine eigene, asynchrone Integrationsschicht angebunden. Ein langsames oder ausgefallenes ERP hält niemanden vom Kaufen ab.
• Keine Bestellung geht verloren. Queues, automatische Wiederholungen und regelmäßiger Abgleich finden Probleme, bevor es der Kundenservice tut.
• Preise und Merchandising gehören dem Business. Preislisten, Promotions und Produktranking werden ohne Entwicklertickets gepflegt, mit vollständigem Audit-Trail.
• Viele Märkte, eine Plattform. Lokale Preise, Sortimente und Inhalte laufen auf gemeinsamer Infrastruktur, die SEO bleibt unter Kontrolle.
• Alles ist beobachtbar. Fachliche und technische Dashboards zeigen hängende Bestellungen, fehlgeschlagene Syncs und langsame Seiten. Alarme schlagen an, bevor das Telefon klingelt.
• Lastspitzen werden geprobt, nicht erhofft. Integrationen werden automatisch getestet, Lasttests laufen mit einem Vielfachen des heutigen Traffics.

Weil das Fundament gleich bleibt, heißt der Wechsel auf die nächste Stufe nicht, Integrationen neu zu schreiben. Sie ändern nur die Schicht, die sich ändern muss.

Stufe 1: Magento + Hyvä

Schnell am Markt, gebaut für die Dauer. Ideal für kleine und mittlere Unternehmen mit einem Hauptvertriebskanal, einem oder wenigen Märkten und dem klaren Bedarf nach Tempo und planbarem Budget.

Die Architektur

Magento Open Source oder Adobe Commerce läuft als sauber strukturierter, modularer Monolith. Das Hyvä Theme ersetzt das alte Luma-Frontend, Hyvä Checkout ist vom ersten Tag an dabei. Integrationen mit ERP und anderen Systemen laufen asynchron außerhalb des Shop-Kerns - nie als fragile, zeitgesteuerte Skripte darin.

Was Sie bekommen

• Die kürzeste Time-to-Market der drei Stufen.
• Eine Codebasis und ein Team für den Betrieb.
• Starke Core Web Vitals ohne separate Frontend-Anwendung.
• Ein ausgereiftes Ökosystem Hyvä-kompatibler Extensions.

Womit Sie rechnen sollten

Das Theme selbst ist kostenlos, Hyvä Checkout aber eine kommerzielle Lizenz - ebenso Adobe Commerce, falls Sie sich dafür entscheiden. Frontend und Backend sind gekoppelt, eine App oder ein Partnerportal nachzurüsten wird damit zum größeren Projekt. Fortgeschrittene B2B-Funktionen brauchen auf Magento Open Source Extensions.

Zeit für die nächste Stufe ist es, wenn ein zweiter Kanal dazukommt oder der Storefront bremst, wie schnell sich das Geschäft verändern kann.

Stufe 2: Headless Magento

Eine Engine, beliebige Frontends. Ideal für mittlere und große Unternehmen, die über mehrere Kanäle und Märkte verkaufen, oft mit komplexem B2B, ihre Plattform selbst besitzen und beim Frontend frei bleiben wollen.

Die Architektur

Magento bleibt Commerce-Engine und Backoffice und wird über seine APIs angesprochen. Zwischen Magento und Kunden sitzt eine eigene API-Schicht, oft Backend for Frontend (BFF) genannt. Sie fasst Commerce-Daten, Inhalte und Suche zu einer fertigen Antwort pro Kanal zusammen und entscheidet, was gecacht werden darf.

Der Storefront entsteht in einer beliebigen modernen Frontend-Technologie, serverseitig gerendert und am Edge gecacht. Marketinginhalte liegen in einem Headless CMS. Eine eventgetriebene Integrationsschicht verbindet ERP, Payment, E-Mail und Marketing-Tools. Die Infrastruktur ist als Code definiert und wird automatisch ausgerollt.

Was Sie bekommen

• Neue Kanäle ohne Replatforming.
• Volle Hoheit über den Code und geringer Vendor-Lock-in.
• Caching je Markt und Kundensegment, damit Seiten auch bei wachsendem Katalog schnell bleiben.
• Unabhängige Release-Zyklen für Marketing-, Commerce- und Frontend-Teams.

Womit Sie rechnen sollten

Mehr bewegliche Teile bedeuten eine höhere Anfangsinvestition und ein reiferes Team - intern oder mit Partner, inklusive solidem DevOps. Dafür kostet jeder weitere Kanal nur einen Bruchteil des ersten.

Stufe 3: Adobe Commerce + Edge Delivery Services

Enterprise als Service. Ideal für große Organisationen, die lieber einen gemanagten Service einkaufen als Infrastruktur zu betreiben, und die Adobe Experience Cloud bereits nutzen oder einführen wollen.

Die Architektur

Adobe Commerce as a Cloud Service betreibt die Commerce-Engine; Infrastruktur, Skalierung und Updates übernimmt Adobe. Der Storefront ist Adobes Commerce Storefront auf Edge Delivery Services, zusammengesetzt aus fertigen Drop-in-Komponenten - inzwischen auch für B2B, etwa Firmenverwaltung und Bedarfslisten. Fachanwender pflegen Inhalte in vertrauten Dokumenten oder in einem visuellen Editor.

Anpassungen und Integrationen liegen außerhalb des Kerns im Adobe App Builder, API Mesh bündelt mehrere APIs in einem Endpunkt. Es gelten dieselben Integrationsprinzipien: Das ERP ist asynchron über Events angebunden.

Was Sie bekommen

• Sehr schnelle Seiten, ohne ein Frontend von Grund auf zu bauen.
• Keine Upgrade-Projekte, weil sich die Plattform selbst aktualisiert.
• Native Anbindung an die Adobe Experience Platform für Daten und Personalisierung.
• Inhaltsänderungen macht das Marketing, nicht die Entwicklung.

Womit Sie rechnen sollten

Die Lizenzkosten sind die höchsten der drei Stufen, ebenso die Abhängigkeit von einem einzigen Anbieter. Der Kern lässt sich nicht verändern, jede Anpassung ist eine Out-of-Process-Extension. Einige vertraute Magento-Funktionen werden in der Cloud-Service-Edition durch Adobe-Services ersetzt - jede davon muss bei der Migration geprüft werden.

Ist ein vollständig gemanagtes SaaS ein Schritt zu weit, funktionieren Edge Delivery Services auch mit Adobe Commerce on Cloud infrastructure, der PaaS-Edition.

Die passende Stufe wählen

Keine Stufe ist grundsätzlich besser - jede ist für ein anderes Unternehmen die günstigere. Die Gesamtbetriebskosten (TCO) entscheiden mehr als das Launch-Budget, also lohnt der Blick auf drei Jahre.

Das Muster ist einfach. Stufe 1 gewinnt, solange Sie bei einem Kanal bleiben. Stufe 2 zahlt sich aus, sobald sich die Kanäle vervielfachen. Stufe 3 tauscht Lizenzkosten gegen geringeren Betriebsaufwand und den schnellsten Weg zu Adobes Personalisierungswerkzeugen.

Wo Sie anfangen sollten

Beginnen Sie mit dem riskantesten Ablauf, nicht mit der Startseite. Für die meisten Unternehmen ist das eine Bestellung auf dem Weg vom Checkout ins ERP und zurück, mit der Zahlung dazwischen. Funktioniert sie unter Last und im Fehlerfall, hat die übrige Plattform einen soliden Kern. Danach stellt sich die Frage, wohin sich das Geschäft in den nächsten Jahren entwickeln soll.

Unsere Projekte beginnen mit einer kurzen Discovery Ihrer Anforderungen und einem Proof of Concept genau dieses Ablaufs. Er verrät viel über die Anforderungen an die Plattform: welche Stufe passt, was sie im Betrieb kostet und wo die Risiken liegen - bevor Sie sich auf den vollständigen Aufbau festlegen. Und weil das Fundament dasselbe bleibt, verbaut ein Start mit Stufe 1 nie den späteren Weg zu Stufe 2.