commercetools macht Core Commerce & Product Catalog standalone buchbar: Was das für deine Fronte…
Von Luma zu Edge Delivery: Die Migrationsentscheidung für euren Adobe-Commerce-Shop
Von Luma zu Edge Delivery: Die Migrationsentscheidung für euren Adobe-Commerce-Shop
Wenn euer Adobe-Commerce-Shop noch auf dem klassischen Luma-Theme läuft oder ihr in den letzten Jahren in PWA Studio investiert habt, seid ihr gerade an einem konkreten Umstiegspunkt: Adobe treibt neue Referenz-Storefronts klar in Richtung Edge Delivery Services, Luma altert technisch spürbar, und PWA Studio wird von Adobe selbst nicht mehr als Zukunftspfad beworben. Die Frage ist für euch nicht mehr, ob ihr migriert, sondern wohin: in Adobes eigenen Edge-Delivery-Stack, oder auf einen backend-agnostischen Frontend-Layer, der Adobe Commerce als Backend behält, aber den nächsten Lock-in vermeidet.
Der Luma- und PWA-Studio-Sunset-Moment
Luma ist das ursprüngliche Magento-2-Standard-Theme, PHTML-Templates, Knockout.js-Widgets, serverseitiges Rendering. Es funktioniert, aber es zeigt sein Alter: Core-Web-Vitals-Werte, die gegen moderne Storefronts nicht mehr bestehen, ein Frontend-Stack, für den kaum noch neue Entwickler ausgebildet werden, und ein Wartungsaufwand, der mit jedem Adobe-Commerce-Patch wächst. PWA Studio wiederum war Adobes erster Versuch, ein React-basiertes Headless-Frontend für Magento anzubieten. Adobe selbst hat den Fokus inzwischen auf Edge Delivery Services verschoben, PWA Studio bekommt kaum noch neue Referenz-Features. Wer auf einem der beiden Setups sitzt, hat also nicht das Luxusproblem "welche Option ist am elegantesten", sondern eine echte Entscheidung mit Zeitdruck.
Das Problem, das viele Adobe-Commerce-Teams jetzt haben
Der Reflex bei einem Sunset-Trigger ist oft: "Dann nehmen wir eben Adobes neuen Weg, das ist ja der offizielle." Das ist nachvollziehbar, blendet aber eine wichtige Tatsache aus: Ein Umstieg von Luma oder PWA Studio auf Edge Delivery Services ist selbst wieder eine vollständige Frontend-Neuimplementierung, nur in einem neuen proprietären Rendering-Modell. Ihr tauscht einen veralteten Lock-in gegen einen frischen. Wer diesen Schritt sowieso gehen muss, tut gut daran, die Gelegenheit zu nutzen und zu fragen: Wollen wir wirklich wieder ein Frontend bauen, das nur mit Adobe Commerce funktioniert, oder wollen wir diesen Umstieg als letzten machen, egal was mit dem Backend in drei oder fünf Jahren passiert?
Adobes eigener Pfad: Edge Delivery Services
Edge Delivery Services (EDS, auf Adobe.com auch als Adobe Commerce Storefront geführt) basiert auf Adobes Franklin-/Helix-Architektur: Content kommt aus Google Docs oder Sharepoint, Rendering läuft über eine Edge-Delivery-Pipeline mit sehr guten Out-of-the-box-Performance-Werten. Für Teams, die tief in Adobe Experience Manager investiert sind oder Adobe als vollständiges Ökosystem fahren wollen, ist das ein schlüssiges Angebot. Der Preis dafür: Ihr bindet euch an ein weiteres Adobe-natives Rendering-Modell, dessen Content-Pipeline und Komponentenlogik ihr innerhalb der Adobe-Welt bleibt. Eine ausführliche technische Einordnung von EDS im Vergleich zu alternativen Frontend-Frameworks für Magento findet ihr in unserem Beitrag Adobe Commerce Storefront (Edge Delivery) im Vergleich zu Hyvä. Wer alle vier gängigen Optionen (Edge Delivery, PWA Studio, Custom Headless, FMP) generisch gegenüberstellen will, findet den breiten Überblick in unserem Entscheidungs-Hub Adobe Headless in 2026. Dieser Beitrag hier geht bewusst nicht diesen Weg noch einmal, sondern bleibt konkret beim Luma-/PWA-Studio-Sunset-Fall.
Die Alternative: Ein backend-agnostischer FMP-Layer über Adobe Commerce
Der zweite Pfad setzt eine Frontend Management Platform (FMP) direkt über die bestehenden Adobe-Commerce-APIs. Product-Katalog, Preise, Warenkorb und Checkout bleiben in Adobe Commerce, das Frontend läuft komponentenbasiert auf einem eigenen, vom Backend entkoppelten Layer. Der praktische Unterschied: Wenn ihr Adobe Commerce in einigen Jahren doch ablösen wollt, oder ein zweites Backend für ein anderes Marktsegment anbinden müsst, bleibt euer Frontend stehen. Ihr baut nicht in ein weiteres Adobe-natives Modell hinein, sondern in eine Schicht, die 50+ Backends unterstützt, darunter Shopware, Shopify, commercetools und Adobe Commerce selbst. Migrationen mit Founder-Begleitung liegen im Median unter 14 Tagen, Storefronts erreichen im Feld einen LCP-Median von 1,2 Sekunden, WCAG 3.0 ist ab Werk vorbereitet statt als nachträglicher Accessibility-Sprint.
Edge Delivery Services vs. backend-agnostischer FMP-Layer
| Dimension | Edge Delivery Services (Adobe-Pfad) | Backend-agnostischer FMP-Layer |
|---|---|---|
| Backend-Bindung | Neues, Adobe-natives Rendering-Modell | Adobe Commerce bleibt Backend, Frontend ist entkoppelt |
| Zukünftiger Backend-Wechsel | Erneuter Frontend-Rewrite nötig | Frontend bleibt bei Backend-Wechsel bestehen |
| Time-to-Market | Schnell innerhalb der Adobe-Welt | Migration typischerweise unter 14 Tagen (Median) |
| Content-Pipeline | Google Docs/Sharepoint-basiert | Studio-Editor mit Live-Preview, kein PR-Review für Marketing-Content |
| Passt am besten zu | Teams, die vollständig im Adobe-Ökosystem bleiben wollen | Teams, die Replatforming-Risiko und Frontend-Lock-in minimieren wollen |
Wie ihr die Entscheidung trefft
Drei Fragen helfen bei der Priorisierung: Erstens, ist Adobe Commerce für euch eine langfristig gesetzte Entscheidung, oder ist ein Backend-Wechsel in den nächsten drei bis fünf Jahren realistisch denkbar? Zweitens, wie viel eurer Marketing-Organisation soll Landingpages und Kampagnen selbst bauen können, ohne Developer-Ticket? Drittens, wie wichtig ist euch, dass die Frontend-Investition auch dann noch trägt, wenn ihr ein zweites Markensegment auf einem anderen Backend aufbaut. Wer bei Frage eins unsicher ist oder bei zwei und drei "sehr wichtig" antwortet, sollte den backend-agnostischen Weg mindestens gegen Edge Delivery Services durchrechnen, bevor die Migration losläuft.
FAQ
Ist PWA Studio damit tot? Adobe pflegt PWA Studio weiter, priorisiert aber Edge Delivery Services in der Kommunikation und in neuen Referenz-Features deutlich stärker. Für Neuprojekte ist es kein empfohlener Startpunkt mehr.
Müssen wir Adobe Commerce als Backend aufgeben, um FMP-fähig zu werden? Nein. Der FMP-Layer setzt genau auf euren bestehenden Adobe-Commerce-APIs auf, ihr behaltet Produktdaten, Preislogik und Checkout unverändert im Backend.
Wie lange dauert so ein Umstieg typischerweise? Migrationen mit Founder-Begleitung liegen im Median unter 14 Tagen, abhängig von eurer Daten- und Theme-Komplexität.
Nächste Schritte
Wenn euer Luma-Theme oder eure PWA-Studio-Instanz gerade an ihre Grenzen kommt, lohnt sich der Vergleich, bevor ihr euch für einen der beiden Pfade entscheidet. Seht euch den Headless Frontend für Adobe Commerce an oder bucht ein 30-minütiges Strategiegespräch, in dem wir eure aktuelle Luma- oder PWA-Studio-Situation konkret durchgehen.
Weitere Themen aus der Laioutr-Plattform
Über den Autor: Marcel Thiesies ist Co-Founder von Laioutr. Er begleitet Adobe-Commerce-Teams beim Umstieg von auslaufenden Luma- und PWA-Studio-Setups auf ein Frontend, das unabhängig vom Backend bleibt.
*Alle Daten basieren auf öffentlich verfügbaren Informationen, Erfahrungen aus Sales-Gesprächen mit DACH-E-Commerce-Brands sowie eigenen Plattform-Tests. Stand: Juli 2026. Adobe-Commerce- und PWA-Studio-Funktionen können sich weiterentwickelt haben.*