Warum Magento behalten und Frontend tauschen für wachsende DACH-Händler das bessere Replatforming ist

Wenn bei DACH-Händlern die Magento-Frage aufkommt, klingt sie fast immer gleich: "Sollen wir komplett weg von Adobe Commerce?" Die Antwort liegt selten dort, wo sie gesucht wird. Wer genauer hinschaut, stellt fest, dass der eigentliche Schmerz fast nie in der Bestellabwicklung, der Katalogverarbeitung oder der Preislogik sitzt, sondern im Frontend: langsame Ladezeiten, schwache Core Web Vitals, ein Redaktionsteam, das für eine Landingpage ein Ticket an die Entwicklung schreiben muss, und Kampagnen, die erst zwei Wochen nach der Idee live gehen. Ein vollständiges Replatforming löst diesen Schmerz, oft aber um den Preis von Monaten Datenmigration, Prozess-Reimplementierung und Integrations-Neuaufbau, den viele Händler unterschätzen. Dieser Beitrag zeigt die günstigere Achse: Backend behalten, Frontend entkoppeln, und wann diese Rechnung trotzdem nicht aufgeht.

Der Schmerz sitzt im Frontend, nicht im Backend

Die meisten Beschwerden, die wir von Magento- und Adobe-Commerce-Betreibern hören, haben ein gemeinsames Muster: Sie betreffen das, was Kundinnen und Kunden sehen und was Redaktionsteams täglich anfassen. Ladezeiten auf mobilen Geräten, die Conversion kostet. Core Web Vitals, die im Google-Ranking spürbar werden. Theme-Anpassungen, die bei jedem Adobe-Commerce-Update erneut getestet werden müssen. Kampagnenfähigkeit, die an Entwicklungskapazität gebunden ist statt an Marketing-Ideen.

Das Backend dagegen, also Bestellverarbeitung, Katalogstruktur, Preisregeln, Lagerbestandsführung und die Kernlogik von Adobe Commerce, funktioniert bei den meisten Installationen zuverlässig. Es ist selten der Grund, warum ein Replatforming-Projekt überhaupt auf den Tisch kommt. Wenn ein Händler dennoch das komplette System austauscht, weil das Frontend träge wirkt, wird ein Backend mit entfernt, das eigentlich funktioniert und dessen Wissen im Team bereits vorhanden ist.

Diese Unterscheidung ist keine akademische Feinheit. Sie entscheidet, ob ein Projekt sechs Monate oder achtzehn Monate dauert, ob bestehende ERP- und PIM-Integrationen erhalten bleiben oder neu gebaut werden müssen, und ob das Team, das Adobe Commerce seit Jahren betreut, weiterarbeiten kann oder komplett neu geschult werden muss. Wer den Schmerzpunkt präzise benennt, bevor er die Lösung wählt, spart sich einen erheblichen Teil des Risikos.

Was am Magento-Backend tatsächlich tragfähig bleibt

Adobe Commerce beziehungsweise Magento Open Source bringt eine ausgereifte Katalogverwaltung mit, die komplexe Produktstrukturen, Konfigurierbarkeit und mehrstufige Preislogik zuverlässig abbildet. Für B2B-Händler mit Kundengruppen-Preisen, individuellen Katalogen und Vertragskonditionen ist das eine Stärke, die man nicht leichtfertig aufgibt. Die Bestellabwicklung, inklusive Checkout-Logik, Steuerregeln für mehrere DACH-Märkte und Retourenprozesse, ist über Jahre gehärtet und in den meisten Fällen produktionsstabil.

Auch die Erweiterbarkeit über das Modul-System bleibt ein Argument für den Verbleib im Adobe-Commerce-Ökosystem. Wer über Jahre spezifische Business-Logik in Modulen abgebildet hat, etwa für Sonderregeln bei Versand oder branchenspezifische Preisfindung, verliert dieses Investment bei einem vollständigen Wechsel des Systems. Bleibt das Backend erhalten, bleibt auch dieses Investment nutzbar.

Nicht zuletzt ist da das Team-Wissen. Entwicklerinnen und Entwickler, die Adobe Commerce seit Jahren betreuen, kennen die Eigenheiten des Systems, die Update-Zyklen und die typischen Stolperfallen. Dieses Wissen lässt sich nicht in wenigen Monaten auf ein neues System übertragen. Es ist ein operativer Vorteil, der bei einem Full-Replatforming faktisch neu aufgebaut werden muss, während er bei einer Frontend-Entkopplung vollständig erhalten bleibt.

Welche Frontend-Probleme sich entkoppelt tatsächlich lösen lassen

Ein entkoppeltes Frontend, technisch als Composable Commerce oder Headless Frontend Setup bezeichnet, trennt die Präsentationsschicht vom Adobe-Commerce-Backend und spricht dieses ausschließlich über APIs an. Das eröffnet konkrete Verbesserungen dort, wo der Schmerz tatsächlich sitzt. Ladezeiten und Core Web Vitals lassen sich signifikant verbessern, weil das Frontend nicht mehr durch die serverseitige Rendering-Logik von Adobe Commerce ausgebremst wird, sondern auf modernen Frontend-Architekturen mit gezieltem Caching und Edge-Auslieferung läuft. Mehr dazu, konkret für Adobe Commerce, findet sich unter Performance und Core Web Vitals als eigenem Themenfeld.

Der Redaktions-Workflow ist der zweite große Hebel. Statt jede Landingpage-Änderung über ein Entwicklungsticket zu beauftragen, arbeitet das Marketing-Team in einem visuellen Editor direkt an Inhalten, Layouts und Kampagnenseiten, ohne die Katalog- oder Bestelllogik im Adobe-Commerce-Backend zu berühren. Das verkürzt die Zeit von Kampagnenidee bis Live-Schaltung von Wochen auf Tage, in manchen Fällen auf Stunden.

Mobile Conversion und Theme-Wartung hängen eng zusammen. Ein modernes, entkoppeltes Frontend lässt sich für mobile Endgeräte gezielt optimieren, ohne dass jede Anpassung mit dem monolithischen Adobe-Commerce-Theme-System kollidiert. Updates am Backend, etwa Sicherheitspatches oder Versionswechsel, betreffen das Frontend nicht mehr direkt, weil beide Systeme entkoppelt sind. Das reduziert Regressionstests und Release-Risiko spürbar.

Welche Integrationen bestehen bleiben

Ein häufiges Missverständnis ist, dass eine Frontend-Entkopplung automatisch bedeutet, dass alle bestehenden Integrationen neu aufgebaut werden müssen. Das Gegenteil ist der Fall, wenn der Schnitt richtig gesetzt wird. ERP-Anbindungen, die Bestandsdaten, Aufträge und Rechnungsinformationen synchronisieren, bleiben unverändert am Adobe-Commerce-Backend hängen. Sie kommunizieren weiterhin mit dem System, das sie kennen.

Das Gleiche gilt für PIM-Systeme, die Produktdaten pflegen und an Adobe Commerce ausspielen. Diese Datenflüsse ändern sich durch eine Frontend-Entkopplung nicht, weil das Frontend die Produktdaten über die Adobe-Commerce-API abruft und nicht direkt aus dem PIM. Payment-Provider und Versanddienstleister, die tief in die Checkout- und Fulfillment-Logik von Adobe Commerce integriert sind, bleiben ebenfalls auf Backend-Ebene bestehen, sofern der Checkout selbst nicht Teil des Entkopplungsprojekts ist.

Diese Kontinuität ist der eigentliche wirtschaftliche Hebel der Entkopplungsstrategie. Jede Integration, die nicht neu verhandelt, neu getestet und neu abgenommen werden muss, spart Projektzeit, reduziert Risiko und schont Budget, das sonst in Integrationsarbeit statt in Kundenerlebnis fliesst.

Der realistische Migrationspfad: stufenweise statt Big Bang

Ein Big-Bang-Wechsel, bei dem an einem Stichtag das gesamte Frontend ausgetauscht wird, ist selten der klügste Weg. Realistischer und risikoärmer ist ein Vorgehen nach Seitentyp. Kampagnen- und Landingpages sind meist der erste Kandidat, weil sie den größten Redaktionsschmerz verursachen und am wenigsten mit der Bestelllogik verzahnt sind. Hier lässt sich der Umstieg auf ein entkoppeltes, visuell editierbares Frontend testen, ohne den Checkout anzufassen.

Kategorie- und Produktseiten folgen typischerweise als nächster Schritt, weil sie messbar von besserer Performance und besseren Core Web Vitals profitieren, gleichzeitig aber präzise Produktdaten aus Adobe Commerce beziehen müssen. Der Checkout selbst bleibt in vielen Fällen bewusst zuletzt oder sogar dauerhaft im bestehenden Adobe-Commerce-Frontend, weil er die höchste Regressionsgefahr trägt und der Nutzen einer Entkopplung dort geringer ausfällt als das Risiko.

Dieser stufenweise Ansatz erlaubt es, nach jedem Schritt zu messen, ob die erwarteten Effekte eintreten, bevor der nächste Seitentyp migriert wird. Er reduziert auch das organisatorische Risiko, weil Redaktions- und Entwicklungsteams parallel eingearbeitet werden können, statt an einem Stichtag komplett auf neue Werkzeuge umzusteigen. Wer sich näher mit dem technischen Muster dahinter befassen will, findet unter Composable Headless Frontend die architektonische Einordnung, und unter Headless Frontend für Magento 2 die spezifische Umsetzung für diese Plattform.

Wann Full-Replatforming trotzdem die richtige Wahl ist

Die Entkopplungsstrategie löst nicht jedes Problem, und das offen zu benennen gehört zu einer ehrlichen Entscheidungsgrundlage. Wenn die Backend-Performance selbst bei Katalog-Operationen das Problem ist, etwa bei sehr großen Produktkatalogen mit komplexen Preisregeln, die Adobe Commerce an seine Grenzen bringen, löst ein entkoppeltes Frontend das nicht. Die API-Antwortzeiten bleiben dann der begrenzende Faktor, unabhängig davon, wie schnell das Frontend selbst rendert.

Genauso wenig löst eine Frontend-Entkopplung Prozess-Altlasten. Wenn die eigentliche Ursache für Trägheit in gewachsenen, überkomplexen internen Workflows liegt, die sich seit Jahren um das Adobe-Commerce-System herum angesammelt haben, hilft ein neues Frontend wenig. Das Gleiche gilt für Datenqualität: Fehlerhafte oder unvollständige Produktdaten im Katalog wirken sich auch im schnellsten Frontend negativ aus, weil das Problem an der Quelle liegt, nicht in der Darstellung.

Ein vollständiges Replatforming kann zudem sinnvoll sein, wenn die Lizenzkosten von Adobe Commerce im Verhältnis zum Geschäftsvolumen nicht mehr passen, oder wenn strategische Gründe wie eine geplante internationale Expansion mit stark abweichenden Anforderungen an Multi-Brand- und Multi-Market-Fähigkeiten für ein anderes Backend sprechen. In solchen Fällen ist die Entscheidung nicht in erster Linie technisch, sondern geschäftlich, und sollte auch so getroffen werden.

Einordnung: Entscheidungshilfe für DACH-Händler

Die zentrale Frage vor jedem Replatforming-Projekt lautet nicht "Behalten oder wechseln?", sondern "Wo genau sitzt der Schmerz, und was kostet es, ihn dort zu lösen, wo er sitzt?" Für die meisten wachsenden DACH-Händler mit Adobe Commerce oder Magento Open Source liegt die Antwort im Frontend: Core Web Vitals, Redaktionsgeschwindigkeit, Kampagnenfähigkeit und mobile Conversion. Diese Probleme lassen sich durch eine gezielte Entkopplung lösen, ohne die Investition in Backend-Logik, Integrationen und Team-Wissen aufzugeben, die über Jahre gewachsen ist.

Der Weg dorthin ist selten ein Sprint, sondern ein stufenweiser Umbau nach Seitentyp, beginnend bei Kampagnen- und Landingpages, gefolgt von Kategorie- und Produktseiten, mit dem Checkout als bewusst später oder gar nicht migriertem Bestandteil. Das reduziert Risiko, erhält Integrationen zu ERP, PIM, Payment und Versand, und macht das Ergebnis in jeder Phase messbar.

Wo Backend-Performance, Prozess-Altlasten oder Datenqualität die eigentliche Ursache sind, ist Ehrlichkeit gefragt: Diese Probleme löst kein Frontend-Tausch, und ein Full-Replatforming kann dann die richtige Antwort sein. Für alle anderen Fälle gilt: Anschlussfähigkeit statt Ablösung ist die günstigere, schnellere und risikoärmere Achse. Wer wissen will, wie sich diese Entkopplung für Adobe Commerce konkret umsetzen lässt, findet weiterführende Informationen unter Headless Frontend für Adobe Commerce.