Weg von Magento: Behalte dein Frontend, wechsle das Backend

Wenn du auf Magento oder Adobe Commerce läufst, liegt der Druck zum Umstieg vermutlich schon auf deinem Tisch. Die Lizenz- und Hosting-Kosten steigen weiter, das Momentum der Magento-Open-Source-Community ist dünner geworden, und jede Roadmap-Diskussion läuft gegen dieselbe Wand: Frontend und Backend sind fest verschweißt, jede Änderung am einen riskiert also, das andere zu brechen. Der Reflex ist, ein komplettes Replatforming zu planen. Der bessere Zug ist, die beiden Fragen zu trennen. Du kannst den Storefront behalten, dem deine Kund:innen und dein SEO längst vertrauen, und das Commerce-Backend darunter in deinem eigenen Tempo austauschen.

Warum Händler Magento verlassen

Die Gründe fallen in drei Kategorien, und die meisten Teams spüren alle drei gleichzeitig.

Kosten sind der lauteste. Die Lizenzgebühren von Adobe Commerce skalieren mit dem Warenkorbvolumen, ein gutes Jahr erhöht also deine Rechnung, egal ob du mehr von der Plattform genutzt hast. Dazu kommen spezialisiertes Hosting, eine Magento-Agentur auf Retainer und die Extension-Lizenzen, die sich immer weiter stapeln. Die Gesamtbetriebskosten sinken selten.

Der End-of-Life-Druck ist der leise. Jede Magento-Version hat ein Support-Fenster, und sobald es schließt, betreibst du ein ungepatchtes Commerce-System, das mit Kartendaten umgeht. Security- und Compliance-Teams akzeptieren das nicht lange, und so wird aus einem technischen Upgrade eine Deadline mit festem Datum.

Agilität ist der Grund, der im Alltag wirklich weh tut. In einem klassischen Magento-Build rendert das PHP-Backend den Storefront über Luma oder ein Custom-Theme. Dein Marketing-Team kann also keine Landingpage ausspielen ohne Developer, und deine Developer können das Theme nicht anfassen, ohne den Checkout gegen Regressionen zu testen. Das System, das dich schnell machen sollte, ist genau das, was dich ausbremst.

Die Big-Bang-Replatforming-Falle

Die Standardantwort auf alle drei Druckpunkte ist, eine neue All-in-one-Plattform zu wählen und alles auf einmal neu zu bauen. Es ist auch die Antwort mit der schlechtesten Bilanz.

Ein Big-Bang-Replatforming heißt, Backend, Frontend, jede Integration und die komplette Content- und SEO-Fläche parallel neu zu bauen und dann einen Schalter umzulegen. Die Zeitpläne dehnen sich über ein Jahr hinaus. Der neue Storefront geht mit weniger Funktionen live als der alte, weil niemand die Zeit hatte, jeden Edge-Case neu umzusetzen. Die organischen Rankings fallen, wenn URLs, strukturierte Daten und Seiten-Templates alle am selben Tag wechseln. Und weil alles auf einmal umgezogen ist, kannst du bei einem Fehler nicht sagen, ob die Ursache im neuen Backend, im neuen Frontend oder in der neuen Integrationsschicht liegt.

Der Kernfehler ist, "weg von Magento" und "Storefront neu bauen" als ein Projekt zu behandeln. Das sind sie nicht. Das Backend ist der Grund, warum du weg willst. Das Frontend ist der Wert, für den du längst bezahlt hast, in Performance-Arbeit, in Barrierefreiheit, in Jahren SEO-Equity. Es gibt keinen Grund, das Zweite wegzuwerfen, um das Erste zu reparieren.

Entkoppeln: Was bleibt, was zieht um

Entkoppeln heißt, eine saubere Linie zwischen der Präsentationsschicht und den Commerce-Services dahinter zu ziehen und beide unabhängig voneinander weiterentwickeln zu lassen.

Was umzieht, ist das Commerce-Backend: Katalog, Preise, Warenkorb, Checkout, Order-Management, Promotions. Das ist die Schicht, die Kosten und EOL-Risiko erzeugt, und die Schicht, die du tatsächlich ersetzen willst, egal ob das Ziel ein Composable-Stack, ein headless-natives Backend oder eine schlankere Plattform ist.

Was bleibt, ist das Frontend: deine Komponenten-Bibliothek, deine Seiten-Templates, deine URL-Struktur, deine strukturierten Daten, deine Core-Web-Vitals-Arbeit. In einem entkoppelten Setup spricht der Storefront über eine einheitliche Datenschicht, meist GraphQL, mit dem jeweiligen Backend dahinter, statt von Magentos PHP gerendert zu werden. Tausch das Backend, behalte den Vertrag, und die Kund:innen sehen durchgehend denselben Storefront.

Die Voraussetzung ist, dass das Frontend kein Magento-Theme mehr sein darf. Es muss eine eigenständige Anwendung sein, die das Rendering besitzt und Commerce-Daten über eine API zieht. Das ist das Muster des Composable Headless Frontend, und es macht das Backend darunter zu einem austauschbaren Teil statt zu einer tragenden Wand.

Der Frontend-first-Strangler-Pfad

Das Strangler-Pattern kommt aus der Anwendungs-Modernisierung: Statt ein Legacy-System in einem Schnitt neu zu schreiben, legst du eine Hülle darum, leitest den Traffic durch die Hülle und verschiebst Funktionalität Stück für Stück, bis das alte System nichts mehr zu tun hat. Frontend-first auf einen Magento-Ausstieg angewandt, sieht das so aus.

Schritt 1: Das entkoppelte Frontend gegen Magento aufsetzen

Bau den neuen Storefront als eigenständiges Frontend und richte es über die API auf dein bestehendes Magento-Backend aus. Am Backend ändert sich noch nichts. Kund:innen bekommen einen schnelleren, flexibleren Storefront, dein Team bekommt eine Editier-Oberfläche, die nicht mehr für jede Content-Änderung ein Magento-Deploy braucht, und du hast bewiesen, dass das Frontend gegen ein echtes Commerce-Backend funktioniert. Allein dieser Schritt löst oft den Agilitäts-Schmerz.

Schritt 2: Eine Fähigkeit nach der anderen umziehen

Jetzt migrierst du das Backend nach Domäne, nicht per Big Bang. Leite die Suche auf einen dedizierten Search-Service. Verschiebe Produktinhalte in eine headless Quelle. Richte den Checkout auf einen neuen Payment- und Order-Stack aus. Weil das Frontend mit einer einheitlichen Datenschicht spricht, kann jede Fähigkeit ihre Quelle hinter dieser Schicht wechseln, ohne dass der Storefront es merkt. Du migrierst zuerst die Domäne mit den höchsten Kosten oder dem höchsten Risiko, verifizierst sie in der Produktion hinter demselben Frontend und gehst dann zur nächsten.

Schritt 3: Magento abschalten, wenn es leer ist

Während jede Domäne von Magento wegzieht, verarbeitet die alte Plattform immer weniger Traffic. Irgendwann bedient sie nichts mehr, was ein neuerer Service nicht besser bedient, und du nimmst sie außer Betrieb. Es gibt keinen Launch-Tag und keinen Schalter, denn die Migration ist längst passiert, ein verifizierter Schritt nach dem anderen. Wenn ein Schritt sich danebenbenimmt, rollst du diese eine Fähigkeit zurück, nicht den ganzen Storefront.

Der Gewinn ist, dass sich das Risiko über viele kleine, reversible Züge verteilt, statt sich in einem einzigen unumkehrbaren zu konzentrieren. Deine SEO-Fläche ändert sich nie unter den Kund:innen, weil das Frontend, das URLs und Templates besitzt, das Erste war, das du stabilisiert hast, und das Letzte, das du anfasst.

Was eine Frontend Management Platform liefert

Entkoppeln löst die Architektur, wirft aber eine neue Frage auf: Wer besitzt das Frontend jetzt, wo es kein Magento-Theme mehr ist? Wenn die Antwort "ein maßgeschneiderter Headless-Build, gewartet von einem einzigen Senior-Developer" lautet, hast du ein Lock-in gegen das nächste getauscht. Eine Frontend Management Platform ist das, was das entkoppelte Frontend während und nach dem Wechsel wartbar hält.

Während der Migration gibt sie dir die einheitliche Datenschicht, mit der das Frontend heute auf Magento und morgen auf ein neues Backend zeigt, sodass Schritt 2 oben eine Konfigurationsänderung ist statt eines Neubaus. Sie gibt Nicht-Developern eine visuelle Editier-Oberfläche, um Seiten zu bauen und zu ändern, und das ist es, was das Agilitäts-Problem tatsächlich erledigt, das dich überhaupt erst von Magento weggetrieben hat. Und sie hält Komponenten-Bibliothek, Templates und SEO-Struktur als verwaltete Assets, die jeden Backend-Wechsel überleben.

Nach der Migration ist sie die Schicht, die dich vom nächsten Monolithen fernhält. Weil das Frontend unabhängig von jedem einzelnen Backend verwaltet wird, bist du nie wieder in der Lage, dass eine Preisänderung oder ein EOL-Datum einen kompletten Storefront-Neubau erzwingt. Die nächste Backend-Entscheidung wird zu einer Backend-Entscheidung, mehr nicht. Das ist die Rolle, die Laioutr als Agentic Frontend Management Platform einnimmt: Das Frontend ist das dauerhafte Asset, und das Backend ist ein angebundener Service, den du darunter wechseln kannst.

Big-Bang-Replatforming vs. Frontend-first-Strangler

• Dimension | Big-Bang-Replatforming | Frontend-first-Strangler
• Migrations-Risiko | In einem Launch gebündelt | Auf kleine reversible Schritte verteilt
• SEO-Impact | URLs und Templates wechseln auf einmal | Frontend bleibt durchgehend stabil
• Zeit bis zum ersten Wert | Ende eines langen Projekts | Erster Schritt liefert in Wochen
• Rollback | Ganzen Storefront zurücksetzen | Eine Fähigkeit zurücksetzen
• Backend-Flexibilität danach | An die neue Plattform gebunden | Backend bleibt austauschbar
• Team-Agilität | Erst nach dem Launch zurück | Schon in Schritt 1 zurück

FAQ

Muss ich das neue Backend wählen, bevor ich anfange? Nein, und genau das ist der Punkt. Der erste Schritt ist, das entkoppelte Frontend gegen dein aktuelles Magento-Backend aufzusetzen. Das Ziel-Backend wählst du, wenn du bereit bist, eine bestimmte Fähigkeit umzuziehen, nicht bevor du beginnst.

Schadet das meinen Suchrankings? Der Strangler-Pfad ist darauf ausgelegt, sie zu schützen. Das Frontend, das deine URLs, Templates und strukturierten Daten besitzt, wird zuerst stabilisiert und bleibt konstant, während sich das Backend darunter ändert. Am stärksten sind die Rankings bei einem Big-Bang-Cutover gefährdet, wo alles am selben Tag umzieht.

Kann das neue Frontend wirklich gegen Magento laufen? Ja. Magento und Adobe Commerce stellen ihre Daten über APIs bereit, und ein entkoppeltes Frontend konsumiert diese Daten über eine einheitliche Schicht. Den neuen Storefront gegen dein bestehendes Backend zu betreiben ist genau der Weg, wie Schritt 1 die gesamte Migration entrisikt.

Ist das nur etwas für große Konzerne? Nein. Der inkrementelle Ansatz ist für Mittelstands-Händler oft sogar wertvoller, gerade weil sie ein gescheitertes einjähriges Replatforming nicht auffangen können. Kleine reversible Schritte passen besser zu einem kleineren Team und einem engeren Budget als eine einzige große Wette.

Was passiert mit unseren Magento-Extensions? Jede Extension mappt auf eine Fähigkeit, die du in Schritt 2 migrierst. Manche werden zu einem dedizierten Best-of-Breed-Service, manche gehen im neuen Backend auf, und manche stellen sich als überflüssig heraus, sobald das Frontend die Präsentation besitzt. Du nimmst sie außer Betrieb, wenn ihre Domäne umzieht, nicht alle auf einmal.

Weitere Themen aus der Laioutr-Plattform

• Composable Headless Frontend: die Architektur, die deinen Storefront in eine eigenständige Anwendung unabhängig von jedem Backend verwandelt.
• Frontend as a Service: die verwaltete Frontend-Schicht und visuelle Editier-Oberfläche, die den Developer-Engpass beseitigt.
• Agentic Frontend Management Platform: wie das Frontend das dauerhafte Asset bleibt, während Backends kommen und gehen.
• Composable Storefront: das Storefront-Modell, das sich über eine einheitliche Datenschicht an jedes Commerce-Backend anbindet.

Nächster Schritt

Du denkst über den Ausstieg aus Magento nach, willst aber kein Jahr auf einen Neubau verwetten? Sprich mit dem Laioutr-Team und wir mappen deinen Storefront auf einen Frontend-first-Strangler-Pfad, sodass du das Frontend behältst, das du hast, und das Backend in deinem eigenen Tempo wechselst.