Headless-Magento-Migration: Das sagen die echten Zahlen

Headless-Magento-Migrationen "revolutionieren" keinen Shop, aber das Muster im Markt ist konsistent: Core Web Vitals wechseln von rot auf grün, die mobile Conversion legt typischerweise im niedrigen bis hohen einstelligen Prozentbereich zu, und Marketing kann neue Seiten wieder ohne Engineering-Ticket ausspielen. Wie groß der Effekt ausfällt, hängt vor allem davon ab, wie schlecht das bestehende Luma- oder Hyvä-Setup wirklich war, nicht von der Vertriebsfolie.

Die drei Zahlen, die Product Owner wirklich interessieren

Jedes Gespräch über Magento-Headless landet irgendwann bei denselben drei Fragen: Was passiert mit den Core Web Vitals, was passiert mit der Conversion, und wie lange dauert es? Die ehrliche Antwort lautet "kommt auf Eure Ausgangslage an", aber die Bandbreiten sind gut genug dokumentiert, um damit zu planen. Dieser Pillar-2-Vergleich zeigt, was ein entkoppeltes Frontend auf Magento oder Adobe Commerce tatsächlich bringt, mit Branchenwerten statt einer einzelnen geschönten Case Study.

Core Web Vitals: von Luma zum entkoppelten Frontend

Magento-Shops mit Standard-Luma-Theme zeigen auf Mobile häufig eine LCP zwischen 4 und 7 Sekunden, INP fällt unter echter Nutzerlast oft durch. Das ist keine Magento-spezifische Schwäche, sondern das typische Ergebnis eines serverseitig gerenderten PHP-Themes mit viel JavaScript, sobald Katalogumfang und Third-Party-Tags zunehmen.

Eine Hyvä-Migration bringt die mobile LCP meist in den Bereich von 2 bis 3 Sekunden, sofern sich der Custom-Modul-Stack sauber portieren lässt. Ein entkoppeltes, Backend-agnostisches Frontend liegt üblicherweise unter der 2,5-Sekunden-Schwelle, die 2026 als "gut" gilt, gut optimierte Setups erreichen 1,2 bis 1,8 Sekunden. Nach den aktuellsten Chrome-UX-Report-Daten bestehen knapp 56 % aller erfassten Domains alle drei Core Web Vitals gleichzeitig, und LCP bleibt in der Breite die schwierigste der drei Metriken, schwieriger als CLS oder INP.

Mehr zur Frage, was "ab Werk" auf Komponenten-Ebene tatsächlich bedeutet, auf der Produkt-Seite zu Performance und Core Web Vitals.

Conversion: was die Daten tatsächlich hergeben

Studien zur Ladezeit zeigen durchgängig, dass E-Commerce-Seiten mit Ladezeit unter 2 Sekunden bei rund 3 % Conversion liegen, gegenüber unter 2 % im Bereich von 3 bis 4 Sekunden. Eine häufig zitierte Faustregel: Jede eingesparte 100-Millisekunde Ladezeit bewegt die Conversion um rund 1 %, und eine Verzögerung von 2 Sekunden kann die Absprungrate nahezu verdoppeln.

Das heißt nicht, dass Geschwindigkeit allein den Umsatz treibt. Preis, Sortiment und Merchandising entscheiden weiterhin den größten Teil des Ergebnisses, Korrelation ist keine Kausalität. Was die Daten stützen, ist eine realistische Bandbreite: Ein wirklich langsames Luma-Setup zu reparieren bewegt die mobile Conversion typisch im mittleren einstelligen bis niedrigen zweistelligen Prozentbereich, nicht die "verdoppelt sich"-Zahlen, die manche Migrations-Pitches suggerieren. Wenn Euer aktuelles Magento-Frontend schon vernünftig optimiert ist, rechnet eher mit dem unteren Ende dieser Spanne.

Time-to-Market: was "Wochen statt Monate" wirklich wert ist

Hier ist der Unterschied zwischen den Migrationswegen am größten. Eine Hyvä-Migration dauert typisch 6 Wochen bis 8 Monate, abhängig davon, wie viele Custom-Module und Checkout-Anpassungen portiert werden müssen. PWA Studio ist faktisch ein Neubau in React. Ein vollständiges Backend-Replatforming zu Adobe Commerce, Shopware oder einer anderen Plattform dauert 12 bis 24 Monate, sobald Datenmigration und Parallel-Betrieb eingerechnet sind.

Eine Frontend-First-Migration, die das Magento-Backend unverändert lässt und über die Standard-GraphQL-API anbindet, ist ein deutlich kürzeres Projekt: Median unter 14 Tagen für ein Single-Store-Setup im DACH-Raum mit Founder-Begleitung, bei Multi-Store- oder B2B-Setups skaliert das in etwa linear. Nach dem Go-live verkürzt ein Studio-Editor die Zeit bis zur neuen Landingpage typisch um rund 65 % gegenüber einem klassischen Headless-Stack, weil Marketing die Seite direkt baut und in der Live-Preview sieht, statt ein Engineering-Ticket aufzumachen.

Was das kostet, im Vergleich zu dem, was es ersetzt

Eine Hyvä-Lizenz plus Implementierung liegt typisch bei € 30.000 bis € 150.000, je nach Shop-Komplexität. Ein Custom-PWA-Studio-Build kostet oft € 100.000 oder mehr, sobald laufende React-Wartung eingerechnet wird. Dazu kommen € 1.000 bis € 10.000 pro Monat Hosting- und DevOps-Overhead, den ein Magento-Open-Source-Shop unabhängig von der Theme-Wahl trägt.

Der relevante Vergleich lautet nicht "Headless-Frontend kostet extra". Er lautet: Rund 30 bis 50 % dieser Ausgaben sind ohnehin Frontend-Arbeit, egal welche Theme-Engine dahintersteckt. Decoupling konsolidiert diesen Anteil in eine planbare Frontend-Schicht, statt in ein paralleles Hyvä-Migrationsprojekt plus laufende Theme-Pflege.

Wo das Frontend nach der Migration tatsächlich sitzt

Das Magento-Backend bleibt exakt, wo es ist: Katalog, Preise, Bestand, Checkout-Logik, alles unverändert. Ein Composable Headless Frontend verbindet sich über die Magento-GraphQL-API und wird zur Schicht, in der Marketing und Engineering gemeinsam arbeiten, unabhängig von Luma, Hyvä oder PWA Studio. Das ist die praktische Bedeutung von Frontend as a Service: Das Frontend wird als eigene Schicht betrieben, mit eigenem Build, Deploy und Performance-Budget, statt als Theme an die Commerce-Engine angeflanscht zu sein.

Diese Optionalität zahlt sich über die eigentliche Migration hinaus aus. Wechselt ein Shop später von Magento Open Source zu Adobe Commerce oder replatformt komplett zu Shopware oder einem anderen Backend, muss das Frontend nicht neu gebaut werden. Nur der Connector wechselt. Das dreht die übliche Reihenfolge eines Replatforming-Projekts um, in dem der Frontend-Neubau normalerweise der längste Posten ist.

Details zur Magento-spezifischen Integration stehen auf der Seite Headless Frontend für Magento 2.

Risiken, die Ihr einplanen solltet, statt sie zu übergehen

Frontend-First-Migrationen senken das Risiko gegenüber einem vollständigen Replatforming, aber sie sind nicht risikofrei. Drei Dinge solltet Ihr explizit einplanen: URL- und Redirect-Mapping, falls sich die Storefront-Struktur überhaupt ändert, ein Parallel-Betrieb-Fenster, in dem altes und neues Frontend nebeneinander Traffic bedienen, um Regressionen vor dem vollständigen Cutover zu erkennen, und Extension-Parität, also eine klare Liste, welche der 30 bis 80 Extensions, die ein typischer Magento-Shop mitschleppt, durch Frontend-Layer-Funktionalität (Suche, Tracking, Personalisierung) ersetzt werden und welche backend-seitig bleiben. Diesen Schritt zu überspringen ist der häufigste Grund, warum ein Migrationszeitplan über den Median hinausrutscht.

Eine realistische Art, diese Zahlen zu lesen

Behandelt diese Bandbreiten als Planungswerkzeug, nicht als Garantie. Ein Shop mit unangetastetem Standard-Luma und ohne vorherige Performance-Arbeit liegt am oberen Ende jeder Gewinn-Spanne oben. Ein Shop, der bereits in Bildoptimierung, CDN und eine schlanke Extension-Auswahl investiert hat, sieht kleinere, aber weiterhin reale Verbesserungen. Die ehrliche Frage vor jeder Migration lautet nicht "wie hoch ist der durchschnittliche Uplift", sondern "wie weit liegt unser aktuelles Setup gerade unter den Core-Web-Vitals-Schwellen von 2026".

Wenn Ihr die Zahlen gegen Euren eigenen Shop rechnen wollt statt gegen einen Branchendurchschnitt, führt Euch unser Readiness-Check für Magento-Decoupling durch die Diagnose, und unser Vergleich Magento 2 Headless vs. Hyvä für den DACH-Mittelstand vertieft die Entscheidung.