Vom Kiwop-Team · Digitale Agentur spezialisiert auf Softwareentwicklung und angewandte Künstliche Intelligenz · Veröffentlicht am 7. Mai 2026 · Letzte Aktualisierung: 7. Mai 2026
TL;DR — Magento Headless ergibt in weniger Fällen Sinn, als die Branche verkauft. Wenn Dein GMV unter 2 Mio. € liegt, Dein Team weniger als 3 Entwickler hat oder Dein Katalog relativ standard ist, wirst Du höchstwahrscheinlich Geld und wertvolle Monate verschwenden. Die echte Alternative für 80% der klassischen Magento-Shops ist Hyvä Themes plus Infrastruktur-Optimierung, oder partiell headless nur für mobile Apps oder spezifische B2B-Portale.
Seit Jahren bekommen wir denselben Auftrag von Kunden mit klassischem Magento: „Wir müssen zu Headless migrieren, weil die Großen das so machen." Das Gespräch folgt meistens demselben Skript. Der E-Commerce-Manager kommt von einer Konferenz, hat eine spektakuläre Demo von PWA Studio oder Next.js mit GraphQL gesehen und ist zu dem Schluss gekommen, dass seine langsame Website an der monolithischen Architektur liegt.
In 70% der Fälle liegt die Ursache der Langsamkeit, wenn wir den echten Stack auditieren, woanders: schlecht konfiguriertes Varnish, unkomprimierte Bilder, Extensions, die 400 KB JavaScript im kritischen Rendering-Pfad laden, oder einfach ein Hosting, das für den Traffic ungeeignet ist. Headless löst keines dieser Probleme. Es verteuert sie.
Dieser Artikel ist nicht anti-headless. Er ist anti-Headless-aus-der-Mode. Es gibt Fälle, wo eine entkoppelte Architektur für Magento oder Adobe Commerce klaren Geschäftssinn und nachweisbaren ROI hat. Aber diese Fälle sind eine Minderheit. Was wir hier tun, ist Dir die echten Kriterien zu geben, um zu wissen, ob Du in dieser Minderheit bist oder in den anderen 80%.
Was Magento Headless ist (und was NICHT)
Vor den Szenarien ist es notwendig, die Terminologie abzustimmen. Der Begriff „Headless" wird im Magento-Ökosystem so weit gefasst verwendet, dass er an Präzision verloren hat.
Headless ist nicht gleich reines React
Im gebräuchlichsten Sinne bedeutet Magento Headless, das Frontend vom Backend zu trennen: Die Commerce-Engine (Katalog, Preise, Inventar, Checkout, ERP) lebt in Magento/Adobe Commerce, während die Benutzeroberfläche in einem unabhängigen JavaScript-Framework gebaut wird — Next.js, Nuxt.js, Remix oder ähnliches — das die Daten über die GraphQL-API von Adobe Commerce konsumiert. Das Frontend wird unabhängig deployt, hat seine eigene Build-Pipeline und seine eigene Cache-Schicht.
Das Ergebnis ist eine Zwei-Repository-Architektur, zwei potenzielle Teams, zwei Monitoring-Oberflächen und zwei Update-Systeme, die bei jeder API-Vertragsänderung synchronisiert bleiben müssen.
PWA Studio: Adobes offizielle Wette
Adobe hat PWA Studio 2018 als offizielles Framework für den Aufbau von PWA-Frontends auf Magento 2 gestartet. Es ist auf React aufgebaut, verwendet Peregrine (Logik-Hooks) und Venia UI (Interface-Komponenten). Theoretisch ist es der kanonische Weg für Headless mit Magento.
In der Praxis war die Adoption moderat. Das öffentliche Repository auf GitHub verzeichnet Version 14.5.0 als neueste (veröffentlicht im Februar 2026), mit 2.700 Commits im develop-Branch und 5 offenen Pull Requests. Es ist ein aktives Projekt, aber das Extension-Ökosystem im Magento-Marketplace ist nicht für PWA Studio bereit: Die große Mehrheit der Drittanbieter-Extensions wurde für das Luma-Frontend entwickelt und bietet kein PWA-natives Äquivalent. Die Migration zu PWA Studio bedeutet, jede verwendete Extension neu zu schreiben oder zu ersetzen.
Custom Frontend (Next.js, Nuxt) mit GraphQL
Die Alternative ist, PWA Studio zu umgehen und das Frontend direkt auf einem modernen Framework mit der GraphQL-API von Adobe Commerce zu bauen. Mehr architektonische Flexibilität, weniger Meinung von Adobe — und mehr eigene Arbeit. Die Projekte, die wir mit dieser Architektur auditiert haben, widmen 30-40% der Entwicklungszeit der Neuerfindung von Funktionalität, die Magento bereits gelöst hatte: Katalog-Paginierung, Facetten-Filter, Versandadressenverwaltung, komplexe Promotionen. Nicht weil es schwierig ist, sondern weil es vom Scratch im Frontend gemacht werden muss.
Warum die Grenze zwischen „Headless" und „Composable Commerce" verschwommen ist
Der Begriff Composable Commerce fügt eine weitere Verwirrungsschicht hinzu. Composable bedeutet, dass jede Capability des Stacks (Suche, Zahlungen, CMS, PIM, Checkout) ein unabhängiger und austauschbarer Dienst ist. Headless ist eine Voraussetzung für Composable, aber Headless impliziert nicht Composable. Ein Magento mit Next.js-Frontend kann perfekt headless und dennoch im Backend monolithisch sein, wenn es weiterhin gleichzeitig von Magento für Suche, Checkout, Content-Management und Preisregeln abhängt.
Diese Unterscheidung ist wichtig, weil die Kosten einer wirklich composablen Architektur substanziell höher sind als die von „Headless mit Next.js". Wenn Dir jemand „Composable" zum Preis von „einfachem Headless" verkauft, gibt es irgendwo im Gespräch ein Missverständnis.
Die 5 Szenarien, in denen Du NICHT migrieren solltest
Die Branche spricht viel darüber, wann Headless die Lösung ist. Wir, nach Dutzenden von Audits und mehreren Migrationsprojekten, werden Dir sagen, wann es das nicht ist.
1. GMV unter 2 Mio. € jährlich
Die realen Kosten einer Headless-Migration für ein Magento Mid-Market — Discovery, Architektur, Frontend-Entwicklung, GraphQL-Hardening, Migration und Cutover — liegen bei einem gut gemachten Projekt zwischen 105.000 und 210.000 €. Die Details schlüsseln wir unten auf.
Mit einem GMV von 2 Mio. € jährlich und einer typischen E-Commerce-Betriebsmarge von 10-20% liegt Dein Jahresgewinn im Bereich von 200.000-400.000 €. 25-100% des Jahresgewinns für eine Architekturmigration auszugeben, die keine direkten Einnahmen generiert, ist eine Wette, die sich selten in dem Zeithorizont amortisiert, den Anteilseigner oder Partner akzeptieren.
Die Mathematik lügt nicht: Damit die Investition Sinn ergibt, muss der Einfluss auf Conversion oder operative Effizienz messbar und vorhersagbar sein. Mit einem GMV unter 2 Mio. € stimmen diese Zahlen fast nie. Headless verdoppelt nicht Deinen Umsatz. Eine bessere Nutzererfahrung kann die Conversion bewegen, aber es gibt viel günstigere Wege, das zu erreichen.
2. Technisches Team mit 1-2 Entwicklern
Headless multipliziert nicht nur die Kosten des initialen Projekts: Es multipliziert die dauerhaften operativen Kosten.
Ein klassisches Magento mit Luma- oder Hyvä-Frontend erfordert einen Entwickler, der PHP/Magento, Server-Administration und CSS versteht. Ein Magento Headless erfordert gleichzeitig: einen Backend-Entwickler, der den Magento-Core pflegt und Probleme mit der GraphQL-API löst; einen Frontend-Entwickler, der das JavaScript-Framework, die Build-Pipeline und die CDN-Cache-Schicht pflegt; und idealerweise ein DevOps-Profil, das die zwei Deploy-Systeme, die zwei Staging-Umgebungen, das getrennte Monitoring von Frontend und Backend und die Sicherheitsupdates von zwei parallelen Stacks verwaltet.
Mit einem Team von 1 oder 2 Entwicklern bleibt eine dieser drei Rollen standardmäßig unbesetzt. Und die erste, die vernachlässigt wird — normalerweise das Backend, weil das Frontend das „Sichtbare" ist — akkumuliert technische Schulden, Versionsrückstände in Magento und schließlich Sicherheitslücken.
Ein System, das niemand gut warten kann, ist keine moderne Architektur. Es ist ein Problem, das darauf wartet zu explodieren.
3. Einfacher Katalog ohne komplexe Geschäftsanpassungen
Wenn Dein Magento einen relativ standardmäßigen Katalog hat — einfache oder konfigurierbare Produkte, wenige komplexe Preisregeln, keine fortgeschrittene B2B-Logik — ist die Lücke zwischen „was bereits in Luma funktioniert" und „was im neuen Frontend neu geschrieben werden muss" enorm.
Das Magento-Extension-Ökosystem enthält Tausende getesteter Lösungen für Suche, Katalogfilter, Rezensionen, Vergleiche, Wunschlisten, Treueprogramme, Multi-Währung und Dutzende Funktionalitäten, die Käufer erwarten. Wenn Du zu Headless migrierst, verlierst Du nativen Zugang zu diesem Ökosystem. Jede Extension muss einen GraphQL-Endpoint oder eine API-Alternative anbieten — und die meisten tun das nicht, weil 90% der Magento-Installationen noch immer Luma sind.
Laut Daten von BuiltWith hat Magento mehr als 89.000 aktive Websites. Die überwiegende Mehrheit verwendet den klassischen Stack. Extension-Anbieter entwickeln zuerst für diesen Stack. Wenn Du zu Headless gehst, wirst Du zum Nischenkunden, der für jede Integration Custom-Arbeit braucht.
4. Starkes organisches SEO, das Du nicht riskieren kannst
Das ist das Szenario, das wir am meisten unterschätzt haben, als wir in die Branche eingestiegen sind.
Schlecht ausgeführte Headless-Migrationen sind für das SEO verheerend. Der Grund ist nicht, dass Headless inhärent schlecht für SEO ist — ein gut konfiguriertes Next.js mit Server-Side Rendering kann perfekt indexierbar sein — sondern dass die Ausführung extrem sensibel gegenüber Details ist: korrekte 301-Redirects, Metadaten-Bewahrung, Canonicals, Hreflang, Structured Data, LCP-Bild-Preload, Cache von Kategorieseiten, Paginierung mit korrektem rel=canonical.
Wir haben E-Commerces mit konsolidiertem organischem Traffic gesehen, die in den ersten 3-6 Monaten einer Headless-Migration 30-40% verloren haben, wo die SEO-Komplexität unterschätzt wurde. Die Erholung davon dauert zusätzliche Monate. Die Kosten an entgangenen Verkäufen in dieser Periode übersteigen häufig die Kosten des Migrationsprojekts selbst.
Wenn Dein organischer Kanal mehr als 30% Deiner Verkäufe generiert, brauchst Du einen SEO-Migrationsplan, der genauso detailliert und gut budgetiert ist wie der technische Migrationsplan. Wenn dieser Plan nicht im Budget enthalten ist, sollte das Projekt nicht beginnen.
5. Du hast keine 6+ Monate und kein Runway von 100.000 €+
Der ehrliche Zeitplan einer Headless-Migration für ein Magento mittlerer Größe ist folgender: Discovery und Architekturdefinition (1 Monat), Design des Komponentensystems und API-Vertrags (1 Monat), Frontend-Entwicklung (3-4 Monate), ausführliches QA und Performance-Optimierung (1 Monat), Datenmigration, Redirects und Cutover (1 Monat). Gesamt: 7 bis 9 Monate vom Kickoff bis zu dem Tag, an dem das neue Frontend in Produktion ist und das alte deaktiviert wurde.
Während dieser Monate läuft das klassische Magento weiterhin in Produktion, nimmt Bestellungen entgegen und erfordert Wartung. Zwei parallele Systeme, zwei Teams, zwei konkurrierende Prioritäten. Wenn ein wichtiger Verkaufskampagne mitten im Projekt stattfindet, wird das neue Frontend pausiert. Wenn es eine Sicherheitslücke in Magento gibt, brauchen beide Systeme einen Patch. Wenn sich das Projekt verlängert (und es wird sich verlängern), ist der Runway erschöpft, bevor der Cutover kommt.
Ohne mindestens 6 Monate operativen Puffer und ein Budget von 100.000 €+ das speziell für die Migration reserviert ist — nicht für „IT im Allgemeinen" — ist die Wahrscheinlichkeit, dass das Projekt erfolgreich abgeschlossen wird, gering. Projekte, die mit engem Runway beginnen, enden unweigerlich mit einem halbfertigen Headless-Frontend, das dauerhaft mit dem klassischen Magento koexistiert, die Wartungskosten von beiden trägt, ohne den Vorteil von keinem.
Reale Kosten (Zahlen, keine Agentenschätzungen)
Der Markt tendiert dazu, Migrationskosten in so breiten Spannen zu präsentieren, dass sie für Entscheidungen nutzlos sind. Wir werden mit den Daten konkret sein, die wir in echten Projekten handhaben.
Aufschlüsselung einer echten Migration (Kiwop-Kunde, anonymisiert)
B2C-Kunde mit 3,8 Mio. € GMV jährlich, Katalog von 2.400 konfigurierbaren Produkten, 15 aktive Extensions, starker organischer Traffic (40% des Umsatzes). Entschiedene Architektur: Next.js 14 mit App Router + GraphQL-API von Adobe Commerce + Algolia für die Suche. Die evaluierte und verworfene Headless-Alternative war PWA Studio wegen der Kosten für Extensions.
Das Projekt dauerte 8 Monate. Die LCP-Verbesserung war von 4,1 s auf 1,8 s. Die Conversion verbesserte sich um 14% in den 3 Monaten nach dem Cutover. Das organische SEO verlor im Monat 1 18% der Impressionen, erholte das Basisniveau im Monat 4 und übertraf die Baseline im Monat 7. Für diesen Kunden mit seinem GMV und seinem technischen Team von 5 Personen ergab die Investition Sinn. Was wir bezahlten, war nicht das Headless: Es war die SEO-Erholung nach der Migration.
Versteckte Kosten: die dauerhafte Dual-Wartung
Was das initiale Budget nicht erfasst, sind die dauerhaften Kosten des Betriebs zweier Systeme.
Ein gut betriebenes klassisches Magento kostet zwischen 500 und 1.500 € pro Monat an Wartungs-Engineering (Sicherheitsupdates, Extension-Patches, Performance-Optimierungen, Monitoring). Ein Magento Headless fügt zu diesen Kosten die Wartung des Frontends hinzu: Node.js- und React-Abhängigkeiten, Framework-Updates, CDN-Verwaltung, Monitoring von Hydrations-Fehlern, Alarme bei Core Web Vitals-Regression bei jedem Deploy.
Die Gesamtbetriebskosten eines Mid-Market-Magento-Headless sinken selten unter 2.500-4.000 € pro Monat, wenn echte Engineering-Arbeit einbezogen wird. Gegenüber den 1.000-1.500 € eines gut optimierten klassischen Magento. Die Differenz sind 18.000-30.000 € zusätzlich jährlich, die dauerhaft aus der Geschäftsmarge fließen.
Die Kosten der Über-Engineering: zwei Repos, zwei Pipelines, zwei Monitorings
Jedes Mal, wenn ein Entwickler des Teams eine Änderung im Frontend einführt, muss er überprüfen, ob der GraphQL-Vertrag sich nicht geändert hat. Jedes Mal, wenn Magento seine API aktualisiert — etwas, das bei jedem Minor Release passiert — muss auditiert werden, ob das Frontend bricht. Jede Marketingkampagne, die einen neuen Rabatttyp oder eine spezielle Preisregel einführt, erfordert die Koordination von Änderungen in Backend und Frontend getrennt.
E-Commerces haben sehr stressige Kalender: Black Friday, Weihnachten, Saisonverkäufe. Eine Headless-Architektur ist eine Architektur, die bei jedem Kampagnen-Sprint doppelte Koordination erfordert. Wenn Dein Team bereits mit einem System leidet, löst Du das nicht durch das Hinzufügen eines weiteren.
Wann es Sinn ergibt, zu Headless zu migrieren
Wir haben die fünf Szenarien gegeben, in denen man nicht migrieren sollte. Um fair zu sein, gibt es Fälle, wo Headless die richtige Antwort ist.
Echter Multi-Kanal mit einem einzigen Backend. Wenn Du dieselbe Katalog-, Preis- und Inventarlogik an eine Website, eine iOS-App, eine Android-App, einen Kiosk im physischen Geschäft und ein B2B-Portal für Händler liefern musst, hat ein Magento-Backend mit GraphQL-API als einzige Datenquelle klaren architektonischen Sinn. Ein Frontend pro Kanal, ein Backend, das alle versorgt. Die Wartungskosten verteilen sich auf mehrere Oberflächen, die früher separate Backends erforderten.
Kritische Performance, die der klassische Stack nicht lösen kann. Wenn Dein Magento einen LCP von konstant über 3 Sekunden hat und Du die Optimierungen von Varnish, Redis, Bildkomprimierung und Eliminierung von blockierendem JavaScript ausgeschöpft hast, und wenn Dein Unternehmen Evidenz hat, dass jede Zehntelsekunde LCP die Conversion messbar beeinflusst, kann die Headless-Investition gerechtfertigt sein. Aber zuerst müssen die Alternativen ausgeschöpft worden sein. Die meisten Magento mit schlechtem LCP haben wir ohne Architekturänderung unter 2 Sekunden gebracht.
GMV über 5 Mio. € mit einem technischen Team von mehr als 5 Entwicklern. Die Streuung der Investitions- und Wartungskosten über ein größeres Volumen verändert die Mathematik. Ein Team von 5+ Entwicklern kann spezialisierte Rollen organisieren, ohne Lücken zu lassen. Ein GMV von 5 Mio. €+ erzeugt die Marge, um die zusätzlichen Betriebskosten zu absorbieren und den Performance- und Flexibilitäts-Upside zu rechtfertigen.
Echtes Composable, nicht Magento als verkleidetes Monolith. Wenn die Strategie ist, Magento als Suchsystem (durch Algolia oder Elastic), als Content-CMS (durch Contentful oder Sanity), als Zahlungssystem (durch Stripe oder Adyen direkt) und als Checkout (durch einen spezialisierten Headless Checkout) zu ersetzen, sodass Magento nur noch als OMS und Preismotor verbleibt, dann ist Headless die logische Konsequenz dieser Composable-Strategie. Aber diese Strategie hat ihre eigenen Kosten und Komplexität — weit über ein Frontend-Projekt hinaus.
Die Alternativen, die für 80% der klassischen Magento funktionieren
Wenn Du nicht in den „JA"-Szenarien bist, sind das die Alternativen mit echtem ROI.
Alternative 1: Hyvä Themes — das „leichte Headless", das es nicht ist
Hyvä Themes ist die pragmatischste Alternative und in unserer Erfahrung die am meisten unterschätzte. Es ist ein Frontend-Theme für Magento 2, das den Luma-Stack (KnockoutJS + RequireJS + jQuery, das mehr als 200 JS/CSS-Ressourcen lädt und 1,5 MB Assets überschreitet) durch einen modernen Stack auf Basis von Tailwind CSS und Alpine.js ersetzt, das nur zwei Ressourcen mit einem Gesamtgewicht von ca. 0,2 MB lädt.
Das Ergebnis bei Core Web Vitals ist signifikant. Laut der Hyvä-Benchmark-Dokumentation ist das Theme darauf ausgelegt, Core Web Vitals beim ersten Deploy in Standardkonfigurationen zu bestehen, mit JavaScript-Gewichtsreduzierungen von mehr als 85% gegenüber Luma. In Produktion nutzen es bereits mehr als 7.000 Shops, einschließlich Marken wie Audio-Technica und Nestlé.
Was Hyvä nicht ist: Es ist nicht Headless. Das Frontend ist weiterhin Teil des Magento-Monoliths, läuft im selben PHP-Prozess. Du hast kein separates Repository. Du hast keine separate Deploy-Pipeline. Du brauchst keinen React-Entwickler. Was Du hast, ist ein erheblich schnelleres und wartbareres Frontend mit vollständigem Zugriff auf das Magento-Extension-Ökosystem.
Kosten und Zeitplan: Ein Luma-zu-Hyvä-Migrationsprojekt für ein Standard-Magento Mid-Market liegt im Bereich von 15.000-30.000 € und wird in 4-8 Wochen abgeschlossen. Zehnmal günstiger als Headless, ohne operative Komplexitäten und mit intaktem SEO.
Die einzige Einschränkung von Hyvä ist, dass verwendete Drittanbieter-Extensions Hyvä-Kompatibilität haben müssen. Das Kompatibilitäts-Ökosystem ist in den letzten Jahren stark gewachsen, aber es bleibt eine notwendige Überprüfung vor dem Projektstart.
Alternative 2: Klassisches Magento gründlich optimiert
Bevor über Architekturwechsel gesprochen wird, mache die Arbeit, die die meisten Magento nicht korrekt gemacht haben: Infrastruktur- und Rendering-Optimierung.
Der Optimierungs-Stack, der 80% der Performance-Probleme in klassischem Magento löst:
- Varnish korrekt konfiguriert für Full-Page-Cache mit granularem Purge per Tag. Ohne Varnish oder mit schlecht konfiguriertem Varnish kann Magento nicht schnell sein.
- Redis für Session- und Block-Cache. Magento hat zwei interne Caches zusätzlich zum Full-Page-Cache; ohne Redis in beiden leidet der TTFB.
- Bildoptimierung mit ImageMagick, WebP- oder AVIF-Komprimierung und korrektem Lazy Loading. Die meisten Magento mit schlechtem LCP haben unkomprimierte Bilder oder fehlendes
loading="lazy"-Attribut bei Bildern außerhalb des initialen Viewports. - Eliminierung von blockierendem JavaScript im kritischen Pfad. Eine durchschnittliche Magento-Extension fügt 20-80 KB JavaScript hinzu, das das Rendering blockiert. Ein JS-Coverage-Audit in Chrome DevTools zeigt typischerweise 60-80% nicht genutzten Code beim ersten Laden.
- CDN mit Edge Caching für statische Assets. Cloudflare im kostenlosen Plan löst bereits einen großen Teil des Problems für internationale Besucher.
Mit diesem Stack gut konfiguriert ist es üblich, Magento von einem LCP von 4-5 Sekunden auf unter 2 Sekunden zu bringen, ohne den Anwendungscode anzufassen. Die Kosten: zwischen 5.000 und 15.000 € an Engineering-Arbeit, plus die monatlichen Kosten des geeigneten Servers.
Alternative 3: Partiell Headless nur für mobile Apps oder B2B-Portale
Wenn Du einen spezifischen Anwendungsfall hast, wo Headless Sinn ergibt — eine native mobile App, ein B2B-Einkaufsportal für Händler mit eigener Preislogik — kannst Du Headless genau dort implementieren, ohne die Hauptwebsite zu migrieren.
Das Magento-Backend exponiert seine GraphQL-API für die mobile App oder das B2B-Portal. Die Hauptwebsite bleibt klassisches Magento (idealerweise mit Hyvä) und führt keine zusätzliche Wartungskomplexität ein. Du erhältst den Headless-Vorteil dort, wo er echten Wert liefert, ohne den Preis zu zahlen, wo der klassische Stack gut funktioniert.
Dieses Muster hat einen direkten SEO-Vorteil: Die Hauptwebsite, die 90% des organischen Traffics konzentriert, wird nicht angetastet. Das Regressionsrisiko ist minimal.
Alternative 4: Migration zu Shopify Plus (ja, wirklich)
Dieser Vorschlag irritiert viele im Magento-Ökosystem, aber es ist die ehrliche Antwort für ein spezifisches Kundensegment: E-Commerces mit GMV zwischen 500.000 € und 2 Mio. €, Standardkatalog ohne kritische Geschäftsanpassungen und ohne eigenes technisches Team.
Shopify Plus hat monatliche Kosten von 2.300 bis 4.000 € je nach Volumen, eliminiert aber praktisch alle Kosten für Infrastrukturwartung, Sicherheitsupdates, Server-Management und akkumulierte technische Schulden. Das Shopify-App-Ökosystem deckt die meisten Funktionalitäten ab, die Magento-Extensions lösen. Der Shopify Checkout konvertiert by Design besser als jeder Custom Checkout.
Die technische Migration von Magento zu Shopify hat ihre eigenen Kosten und Komplexität, besonders beim Katalog, Bestellhistorie und SEO. Aber wenn die Alternative ist, 150.000 € für ein Magento-Headless für ein Unternehmen mit 1 Mio. € GMV auszugeben, kann Shopify bei den Gesamtbetriebskosten über 3 Jahre günstiger herausgehen.
Unsere Empfehlung: Die TCO-Analyse (Total Cost of Ownership) über 3 Jahre durchführen, bevor zwischen Magento-Beibehaltung, Headless oder Plattformwechsel entschieden wird.
Entscheidungs-Checkliste: Headless ja oder nein?
Bevor Budget und Monate Arbeit committed werden, gehe durch diese Fragen. Das sind dieselben, die wir in unseren initialen Audits stellen.
Wenn Du 5 oder mehr „gegen Headless"-Indikatoren hast, muss das Projekt überdacht werden, bevor es startet. Wenn Du 6 oder mehr „für Headless"-Indikatoren hast, macht das Gespräch über Architektur Sinn.
Echter Fall: als wir einem Kunden NEIN sagten (und wie es endete)
Ein B2B-Kunde aus dem Industriesektor kontaktierte uns für die Migration seines Magento 2 zu Headless. GMV: 1,2 Mio. € jährlich. Technisches Team: 1 interner Entwickler mit Magento-Profil. Erklärter Grund für Headless: „Die Website ist langsam und die Konkurrenz hat PWA."
Wir machten das Audit, bevor wir das Projekt annahmen — eine Praxis, die wir bei Kiwop immer bei Magento-Entwicklungs-Projekten anwenden, wenn ein Architekturwechsel im Spiel ist. Die Ergebnisse:
- Mittleres LCP: 4,8 s. Hauptursache: Varnish deaktiviert (es war installiert, aber der Full-Page-Cache funktionierte seit 8 Monaten nicht wegen eines ungelösten Extension-Konflikts). Nebenursache: 14 Extensions laden JS im kritischen Pfad ohne defer.
- CLS: 0,31. Ursache: Bilder des Haupt-Sliders ohne deklarierte Dimensionen.
- Der Katalog hatte 340 Produkte mit Standard-Preiskonfigurationen. Null Custom-B2B-Logik.
Unsere Empfehlung: Migration zu Hyvä Themes, Varnish korrekt aktivieren und konfigurieren, Lazy Loading bei Bildern implementieren und das JavaScript der Extensions verzögern. Kein Headless.
Ergebnis: Core Web Vitals bestanden in 3 Wochen. LCP: 1,6 s. CLS: 0,02. Organischer Traffic ohne Einfluss. Gesamtkosten: 22.000 € gegenüber den für Headless budgetierten 135.000 €. Der interne Entwickler seines Teams konnte das System ohne zusätzliche Schulung warten.
Das schwierige Gespräch war, dem Kunden zu sagen, dass das Headless, das er wollte, nicht die Lösung war. Das einfache Gespräch war, ihm drei Wochen später die Ergebnisse zu zeigen.
Häufig gestellte Fragen
Ist klassisches Magento veraltet?
Nein. Adobe veröffentlicht weiterhin Versionen von Adobe Commerce und Magento Open Source mit aktivem Support. Die Version 2.4.x ist der aktuelle Branch mit regelmäßigen Sicherheits- und Kompatibilitätsupdates. Das Extension-Ökosystem ist weiterhin aktiv. Was veraltet ist, ist das Luma-Frontend in Bezug auf Performance — aber das wird mit Hyvä Themes gelöst, nicht notwendigerweise mit Headless.
Wird Adobe Headless in Zukunft erzwingen?
Adobe hat Headless als strategische Richtung von Adobe Commerce positioniert, insbesondere für Enterprise-Kunden. Aber „strategische Richtung" bedeutet keine kurzfristige Aufgabe des klassischen Stacks. PWA Studio erhält weiterhin Updates (v14.5.0 im Februar 2026). Adobe pflegt offiziellen Support für monolithische Installationen. Für die meisten Merchants wird der Druck zu Headless vom Markt kommen — nicht davon, dass Adobe den klassischen Stack deaktiviert.
Ist Hyvä Themes production-ready?
Ja. Mit mehr als 7.000 Shops in Produktion, einschließlich Implementierungen großer Marken, ist Hyvä ein reifes Projekt. Das Ökosystem kompatibler Extensions hat sich signifikant vergrößert. Vor jedem Hyvä-Projekt muss die Kompatibilität der spezifischen Extensions, die Du verwendest, überprüft werden — die offizielle Website und der Hyvä-Kompatibilitätsmarktplatz sind die Referenz.
Kann ich „partiell Headless" machen?
Ja, und es ist häufig die beste Lösung. Das Web-Frontend in klassischem Magento (oder Hyvä) zu behalten und nur die mobile App oder das B2B-Portal gegen die GraphQL-API zu bauen, ist eine valide Strategie, die Dir den Headless-Vorteil gibt, wo er echten Wert liefert, ohne die operativen Kosten der Migration der Hauptwebsite zu zahlen.
Wie lange dauert eine gut gemachte Headless-Migration?
Für ein Magento Mid-Market (1-5 Mio. € GMV, 1.000-10.000 SKUs, 10-20 aktive Extensions) ist der realistische Zeitplan 7-9 Monate vom Kickoff bis zum Cutover in Produktion. Projekte, die versprechen, in 3-4 Monaten fertig zu sein, haben entweder sehr begrenzten Umfang oder werden Probleme in QA und Migration haben. Der lange Zeitplan ist kein Projektfehler: Er ist die Konsequenz, Dinge richtig zu machen.
Was ist, wenn ich direkt von Magento zu Shopify migrieren möchte?
Es ist eine legitime Option für ein spezifisches Segment. Die technische Migration umfasst Katalog, Bestellhistorie, Kundenkonten und SEO-Redirects — es gibt spezialisierte Tools dafür. Die Migrationskosten sind typischerweise geringer als ein Headless-Projekt bei Magento. Die Einschränkung ist die Anpassbarkeit: Shopify hat Grenzen bei der Checkout-Erweiterbarkeit und sehr spezifischer Geschäftslogik. Wenn Dein Unternehmen komplexe B2B-Preisregeln, sehr angepasste Bundles oder proprietäre ERP-Integrationen hat, kann Shopify zu kurz greifen. Wenn nicht, kann es die sinnvollste Option sein.
Wenn Du einen Plattformwechsel evaluierst, lohnt es sich auch, PrestaShop für Unternehmen im Bereich 200.000-1 Mio. € GMV zu berücksichtigen, wo der TCO sogar unter Shopify Plus mit einem flexibleren Stack liegen kann.
Fazit: Die Mode sollte nicht Deine Architektur entscheiden
Gescheiterte Magento-Headless-Migrationen haben etwas gemeinsam: Sie begannen mit der Lösung im Kopf, bevor das Problem verstanden wurde. Jemand sah eine Demo, las einen Erfolgsfall eines E-Commerce mit 50 Mio. € und nahm an, dass dieselbe Architektur nach unten skaliert. Das tut sie nicht.
Die richtige Architektur ist diejenige, die das spezifische Problem Deines Unternehmens zu den Kosten löst, die Du mit dem Team, das Du hast, absorbieren kannst. Für die meisten klassischen Magento bedeutet das Hyvä Themes plus Infrastruktur-Optimierung, nicht ein 8-Monate-Projekt für 150.000 €, das die dauerhafte operative Komplexität verdoppelt.
Headless ergibt Sinn, wenn: Du echten Multi-Kanal, GMV >5 Mio. €, Team >5 Entwickler hast, klassische Optimierungen ausgeschöpft hast und das Runway hast, es richtig zu machen.
Es ergibt keinen Sinn, wenn: Irgendeine dieser Bedingungen fehlt.
Bei Kiwop — Digitale Agentur spezialisiert auf Softwareentwicklung und angewandte Künstliche Intelligenz für globale Kunden in Europa und den USA — führen wir technische Audits vor jeder Architekturentscheidung im E-Commerce durch. Wenn Dein Magento Performance-Probleme hat, lass uns das analysieren, bevor Du annimmst, dass die Lösung Headless ist. Die richtige Diagnose kostet einen Bruchteil des falschen Projekts.
Sieh Dir unsere Dienste für Magento-Entwicklung, Composable Commerce, PWA-Entwicklung und Softwareentwicklung an — oder schreib uns direkt und wir bewerten gemeinsam, ob Headless die richtige Option für Deinen Fall ist.
