Drei Marken, drei Magento-Instanzen, drei Theme-Stacks, und eine Marketing-Roadmap, die jedes Mal an der Mehrfacharbeit zerschellt. Wenn du heute eine neue Kampagne für alle drei Brands ausrollst, machst du dieselbe Arbeit dreimal: drei Deployments, drei QA-Durchläufe, drei Abstimmungsrunden mit dem Entwicklungsteam. Das ist kein Kapazitätsproblem, das eine neue Stelle löst. Das ist ein Architektur-Problem.

Eine Frontend Management Platform (FMP) als Konsolidierungs-Layer oben drauf, statt eines 18-Monats-Replatforming-Projekts. Wie das in der Praxis aussieht, erklären wir hier.

Warum Multi-Store-Magento oft mehrere Instanzen bedeutet

Die Antwort auf die Frage, warum Unternehmen mit mehreren Magento-Instanzen landen, ist fast immer die gleiche: Akquisitionen. Ein Münsteraner Maschinenbau-Unternehmen kauft 2019 einen Wettbewerber in Hamburg. Beide laufen auf Magento 2, aber auf unterschiedlichen Versionen (2.4.4 und 2.4.6), mit unterschiedlichen Custom-Extensions und unterschiedlichen Checkout-Flows, die Jahre an Anpassungen für ihre jeweiligen Kunden reflektieren.

Das klassische Magento-Multi-Store-Setup innerhalb einer Instanz setzt voraus, dass man von Anfang an mit mehreren Brands auf derselben Basis gestartet ist. In der M&A-Realität ist das die Ausnahme. Was man stattdessen bekommt: zwei oder drei Instanzen, die sich gegenseitig nicht kennen, mit Teams, die ihre jeweilige Instanz wie ein eigenes Terrain behandeln.

Dazu kommt die Versions-Fragmentierung. Magento 2.4.6 läuft noch bis August 2026 mit Security-Patches, aber danach wird der Patch-Aufwand pro Instanz signifikant höher. Drei Instanzen bedeuten den dreifachen Ops-Aufwand bei End-of-Life-Wellen. Wenn du drei Brands auf deiner Magento-Infrastruktur verwaltest, ist die Frage nicht, ob du konsolidieren willst, sondern wie.

Was die Replatforming-Versuchung verspricht und was sie kostet

Der typische Reflex bei diesem Problem: alles auf eine neue Plattform migrieren. Ein MACH-Stack, eine neue Instanz, ein frischer Start. Das klingt ordentlich. Die Realität ist aufwändiger.

Replatforming-Projekte in dieser Größenordnung (drei Magento-Instanzen, EU-Maschinenbau, B2B-Checkout-Logik mit Kundenpreislisten und Freigabe-Workflows) landen erfahrungsgemäß bei 12 bis 18 Monaten Laufzeit und Projektbudgets ab 1,5 Millionen Euro aufwärts. Das schließt die Daten-Migration, die Re-Integration aller Custom-Extensions, den SEO-Risiko-Puffer, parallele Betriebsphase und das Change-Management für die Marketing-Teams ein.

Dabei löst Replatforming das eigentliche Problem oft nicht einmal: dass drei Marken drei unterschiedliche Design-Entscheidungen, drei unterschiedliche Kampagnen-Logiken und drei unterschiedliche Editor-Workflows haben, die auch nach der Migration parallel laufen müssen, weil die Brands eigene Identitäten behalten sollen.

Ein Replatforming konsolidiert das Backend. Es löst nicht, wie Marketing-Teams über Brands hinweg gemeinsam auf einer Oberfläche arbeiten können.

FMP als Konsolidierungs-Layer: was er konkret liefert

Eine Frontend Management Platform setzt oben auf deinen bestehenden Magento-Instanzen auf. Sie ersetzt nicht das Backend, nicht die Checkout-Logik, nicht die Order-Management-Workflows. Sie entkoppelt den Frontend-Layer, sodass alle drei Brands eine gemeinsame Oberfläche zum Editieren, Deployen und Personalisieren nutzen können, während die jeweiligen Magento-Instanzen im Hintergrund weiter ihren Job machen.

Was das konkret bedeutet, an drei Punkten:

Gemeinsames Design-System, pro Brand ausgespielt. Du baust einmal das Component-Set, also Header, Navigation, Produktkarte, Checkout-Button-Styling, Banner-Slot. Jede Brand kriegt ihre eigene Aussteuerung: Farben, Fonts, Ton in den Texten. Das Design-System bleibt eins, die visuelle Identität bleibt dreifach. Aenderungen an der Produktkarten-Logik gibst du einmal frei und sie rollen auf alle drei Brands aus, wenn du das willst.

Editor-Velocity ohne Entwickler-Ticket. Marketing-Teams können Kampagnenseiten, saisonale Banner und Produkthighlight-Blöcke direkt im Editor setzen, ohne für jede Aenderung ein Dev-Ticket aufzumachen. Das ist der Unterschied zwischen einer Kampagne in zwei Stunden und einer Kampagne in zwei Wochen. Für drei Brands multipliziert sich dieser Geschwindigkeitsvorteil.

Personalisierung über Brand-Grenzen. Wenn ein Kunde Brand A und Brand B kennt, weil dein Unternehmen beide betreibt, kannst du im FMP-Layer erste Cross-Brand-Personalisierungs-Logiken setzen, ohne dass die Magento-Backends dafür gekoppelt werden müssen. Das ist nicht trivial, aber es ist möglich, weil die FMP-Schicht die Aggregations-Instanz ist.

Du kannst hier im Detail nachlesen, welche Konsolidierungs-Pattern für unterschiedliche Brand-Konstellationen passen: Multibrand, Multistorefront, One Frontend: A Playbook.

Konkrete Setup-Skizze mit drei Stores

Nehmen wir ein realistisches Beispiel: ein DACH-Maschinenbau-Unternehmen mit drei Brands, die alle B2B-Kunden bedienen, aber in unterschiedlichen Segmenten (Präzisionswerkzeuge, Messtechnik, Automatisierung). Alle drei Brands laufen auf Magento 2, alle drei haben eigene Kundenpreislisten und Freigabe-Workflows.

Der FMP-Layer verbindet sich über die Magento GraphQL-API mit allen drei Instanzen. Die Verbindung ist read-write für den Storefront-Teil (Produktdaten, Kategorie-Strukturen, Preise nach Kundengruppe), aber der Checkout bleibt an der jeweiligen Magento-Instanz. Das ist Absicht, weil der B2B-Checkout komplex ist und nicht migriert werden sollte.

Im FMP-Editor sieht das Marketing-Team aller drei Brands eine einheitliche Oberfläche. Jede Brand hat ihren eigenen Workspace, aber die Komponenten-Library ist geteilt. Ein neuer Banner-Typ, den das Präzisionswerkzeuge-Team entwickelt, steht bei Bedarf auch für die anderen zwei Brands zur Verfügung.

Deployments laufen pro Brand separat (weil die Staging-Umgebungen unterschiedliche Magento-Instanz-Endpunkte ansprechen), aber die Deployment-Logik ist einheitlich. Du deployst nicht mehr dreimal mit drei unterschiedlichen Pipelines, sondern einmal mit einem konfigurierten Multi-Target-Setup.

Ein kritischer Punkt beim Setup: die Produkt-Daten-Qualität variiert zwischen den Instanzen, weil sie historisch unabhängig gewachsen sind. Das ist keine FMP-Aufgabe zu lösen, das ist eine PIM-Aufgabe. Wenn du weißt, dass du nach dem FMP-Layer perspektivisch ein PIM einführen willst, ist jetzt der richtige Moment, die Daten-Felder im FMP-Schema so zu definieren, dass ein PIM später sauber angebunden werden kann. Mehr dazu in unserer Cross-Border-Analyse für Multi-Brand-Setups.

Risiken und Governance: wer entscheidet was zwischen den Brands

Ein FMP-Konsolidierungs-Projekt ist nicht nur ein technisches Projekt. Es ist ein Governance-Projekt. Die größten Reibungspunkte in der Praxis sind nicht technische Limits, sondern Entscheidungen über Brand-Souveränität.

Welche Komponenten-Aenderungen können alle Brands gleichzeitig bekommen, und welche müssen pro Brand kontrolliert werden? Das klingt nach einer Detail-Frage, aber es entscheidet darüber, ob das zentrale Design-System eine Erleichterung oder eine neue Konfliktquelle wird.

Unsere Empfehlung für den Governance-Rahmen, basierend auf Setups, die wir begleitet haben:

Unterscheide klar zwischen Brand-Konstanten (Farben, Primary-Fonts, Logo-Platzierungen) und Brand-Variablen (Seiten-Layouts, Kampagnen-Blöcke, Personalisierungs-Logik). Brand-Konstanten werden zentral versioniert und können nur durch ein gemeinsames Brand-Review für alle drei Brands geändert werden. Brand-Variablen können Workspaces eigenständig setzen.

Definiere im Voraus, welche Editor-Rollen es gibt. Wer darf was in welchem Workspace deployen? Wer kann Cross-Brand-Komponenten schreiben? Ein klares Rollen-Konzept verhindert, dass das zentrale Team zum Flaschenhals wird.

Plane die Migrationsreihenfolge der Brands. Fang nicht mit allen drei gleichzeitig an. Eine pilotierende Brand gibt dir drei bis vier Monate echtes Feedback zu Editor-Workflows und Deployment-Prozessen, bevor die anderen zwei Brands drauf angewiesen sind.

Für eine detaillierte Architetur-Beratung zu Multi-Brand-Setups auf Magento findest du alles Wichtige auf unserer Magento-Hub-Page.

Wann FMP der richtige Weg ist, wann nicht

Ein FMP-Konsolidierungs-Layer ist dann die passende Antwort, wenn:

• Du mehrere Magento-Instanzen hast, die durch M&A entstanden sind und deren Backends stabil und nicht migriert werden sollen
• Das größte operative Problem deine Marketing-Teams haben, nicht deine Backend-Teams
• Du in 8 bis 12 Wochen einen messbaren Fortschritt zeigen musst, nicht in 18 Monaten
• Die Brands eigene Identitäten behalten, aber auf einer gemeinsamen Editor-Logik arbeiten sollen

FMP ist dann nicht die richtige Antwort, wenn:

• Die Magento-Instanzen technisch am Ende sind (EOL, keine aktuelle Version, massive Schulden) und ohnehin migriert werden müssen - dann ist Replatforming unvermeidlich und du solltest es richtig machen
• Das primae Problem im Backend liegt (Order-Management, Pricing-Logik, Lagersystem-Kopplung) - das löst kein Frontend-Layer
• Du weniger als zwei Marketing-Mitarbeiter hast, die einen Editor tatsächlich nutzen würden - dann fällt der Editor-Velocity-Vorteil zu gering aus

Wenn du dir nicht sicher bist, auf welcher Seite du stehst: wir machen dafür Multi-Brand-Workshops, in denen wir gemeinsam die Setup-Realität eurer Instanzen aufnehmen und einen ehrlichen Pfad entwickeln.

Der nächste Schritt

Ein Frontend für mehrere Magento-Stores klingt auf den ersten Blick wie ein technisches Projekt. Es ist vor allem eine operative Entscheidung: willst du die nächsten drei Jahre mit dreifachem Deployment-Aufwand leben, oder investierst du jetzt in eine Schicht, die diesen Aufwand einmal löst?

Die technische Grundlage, wie ein headless Frontend sauber mit Magento 2 zusammenspielen kann, erklären wir ausführlich auf unserer Magento Hub-Page.

Der direkte Einstieg für deine Brand-Konstellation: buche unseren Multi-Brand-Workshop. Wir schauen uns gemeinsam an, wie deine drei Instanzen heute aufgestellt sind, und entwickeln einen konkreten Konsolidierungs-Plan, der in deinem Zeitrahmen realistisch ist.