Wie migriert man zu Microfrontends – und wann hört man auf?

„Aus diesem Legacy-System lässt sich nichts mehr sinnvoll herauslösen.“

„Wir extrahieren einfach nach und nach alle Bereiche als Remotes.“

Beide Aussagen sind zu absolut.

Auch in einem stark verflochtenen System können eigenständige Capabilities geschaffen werden. Das bedeutet jedoch nicht zwangsläufig, dass bereits fertige Einheiten darauf warten, technisch herausgelöst zu werden. Häufig müssen fachliche Grenzen zunächst sichtbar gemacht, Abhängigkeiten reduziert und Verantwortlichkeiten neu geordnet werden. Was als Extraktion bezeichnet wird, ist dann in Wahrheit eine Entkopplung oder sogar eine Rekonstruktion.

Umgekehrt folgt aus der technischen Möglichkeit, einen Teil des Frontends separat zu bauen und einzubinden, noch keine tragfähige MFE-Strategie. Ein zusätzliches Deployable kann ebenso gut neue Pipelines, Verträge und Betriebsaufgaben erzeugen, ohne eine einzige relevante Wartezeit zu beseitigen.

Die zentrale Frage lautet deshalb nicht, ob sich ein bestehendes Frontend technisch in Remotes zerlegen lässt:

Welches konkrete Problem soll durch unabhängigere Veränderungswege gelöst werden?

Eine Microfrontend-Migration beginnt nicht mit dem ersten Remote. Sie beginnt mit einer ehrlichen Analyse des bestehenden Systems, seiner Risiken, seiner fachlichen Grenzen und seines tatsächlichen Autonomiebedarfs.

Microfrontends sind kein Modernisierungsziel

Microfrontends sind weder ein notwendiger Reifegrad großer Frontends noch der automatische Zielzustand einer Legacy-Modernisierung. Die Modernisierung eines Legacy-Frontends beschreibt ein Ziel. Microfrontends sind nur einer von mehreren möglichen Wegen dorthin.

Eine Modernisierung kann bedeuten, interne Modulgrenzen zu stärken, Tests und Buildprozesse zu verbessern, fachliche Verantwortungen innerhalb eines Monolithen klarer zu schneiden oder einen neuen modularen Monolithen aufzubauen. Einzelne Produktbereiche können rekonstruiert werden. In besonders verflochtenen Teilen kann ein partieller oder vollständiger Rewrite die ehrlichere Beschreibung sein. Die gezielte Extraktion einzelner Capabilities als Microfrontends ist eine weitere Möglichkeit – nicht die vorgegebene Endstufe.

Ein stabiler Ausgangszustand kann vollkommen legitim aussehen:

stabiler Monolith
├── wenige Entwickler
├── gemeinsame Prioritäten
├── kurze Abstimmungswege
├── verlässliche Releases
├── beherrschbare Tests
└── klare Verantwortung

Eine verteilte Landschaft bringt dagegen zusätzliche Anforderungen mit:

Microfrontend-Landschaft
├── Integrationsverträge
├── mehrere Deployables
├── zusätzliche Pipelines
├── verteilte Diagnose
├── Plattform-Governance
└── mehr lokale Betriebsverantwortung

Diese Kosten können sinnvoll sein, wenn sie reale Koordinationskosten ersetzen. Wenn die Verteilung jedoch keine relevante Wartezeit, Releasekopplung oder organisatorische Blockade beseitigt, fehlt ihre wirtschaftliche Begründung.

Wo dieselben Menschen ohnehin gemeinsam entscheiden, testen und veröffentlichen, erzeugt ein separates Deployable nicht automatisch einen Autonomiegewinn. Wer kein Autonomieproblem besitzt, benötigt keine Autonomiearchitektur. Ein stabiler Monolith mit wenigen Entwicklern kann der richtige Zielzustand sein.

Die Entscheidung gegen Microfrontends ist deshalb kein Zeichen mangelnder technischer Reife. Sie kann das professionellste Ergebnis einer ernsthaften Prüfung sein.

Welches Problem soll nach der Migration gelöst sein?

Bevor eine Zielarchitektur gezeichnet, ein Host eingerichtet oder ein erstes Remote angelegt wird, sollte die Organisation einen konkreten Satz vervollständigen können:

Nach der Migration kann Team X die Capability Y unabhängig verändern, testen und veröffentlichen, ohne auf Z warten zu müssen.

Zum Beispiel:

Nach der Migration kann das Abrechnungsteam regulatorische Änderungen unabhängig veröffentlichen.

Nach der Migration benötigt der Supportbereich nicht mehr den Gesamt-Release des Kundenportals.

Nach der Migration kann Business Unit A ihren Produktbereich unabhängig von Partner B betreiben.

Diese Aussagen benennen einen Veränderungsweg, eine Verantwortung und eine heute bestehende Abhängigkeit. Sie lassen sich später überprüfen. Vor dem ersten Remote sollte deshalb festgehalten werden, woran die heutige Kopplung erkennbar ist – etwa an beteiligten Teams, gemeinsamen Freigaben oder wiederkehrender Wartezeit.

Eine ungeeignete Zielbeschreibung lautet dagegen:

Nach der Migration besteht das Frontend aus mehreren Remotes.

Die Zahl der Remotes beschreibt die technische Form. Sie beschreibt noch keinen wirtschaftlichen Nutzen.

Ein Frontend kann aus zehn Remotes bestehen und weiterhin nur gemeinsam getestet, freigegeben und veröffentlicht werden. Dann wurde die technische Struktur verteilt, nicht aber die Veränderbarkeit. Ein neues Remote ist kein Beweis für erfolgreiche Migration, wenn die alte Kopplung nur über andere technische Verbindungen weiterlebt.

Wenn kein konkreter unabhängiger Veränderungsweg benannt werden kann, sollte die Migration nicht mit einer technischen Extraktion beginnen.

Den Ist-Zustand vor der Zielarchitektur verstehen

Die Ist-Analyse darf nicht bei Komponentenordnern, Importgraphen und Buildzeiten stehen bleiben. Eine belastbare MFE-Strategie verbindet mindestens fünf Perspektiven: Fachlichkeit, Technik, Organisation, Betrieb und Wirtschaftlichkeit.

Fachlicher Ist-Zustand

Zunächst ist zu klären, ob erkennbare Capabilities existieren oder plausibel rekonstruiert werden können.

Welche fachlichen Regeln gehören zusammen? Welche Bereiche verändern sich meistens gemeinsam? Welche Daten und Entscheidungen besitzt ein Bereich? Sind heutige Seiten und Komponenten nur technische Ausschnitte oder Ausdruck einer eigenen Fachlichkeit? Könnte der Bereich unabhängig von seiner aktuellen UI-Struktur beschrieben werden?

Die Suche nach einer MFE-Grenze beginnt nicht an einer Route oder einem Komponentenordner, sondern an einer fachlichen Verantwortung.

Eine Route kann lediglich eine Navigationsentscheidung sein. Ein Ordner kann historisch nach technischen Kategorien entstanden sein. Eine Komponentenstruktur kann gemeinsame Darstellung abbilden, ohne eine eigenständige Capability zu enthalten. Nicht jede herauslösbare Oberfläche ist eine eigenständige Capability.

Technischer Ist-Zustand

Danach werden die tatsächlichen Abhängigkeiten sichtbar gemacht: direkte Imports zwischen Bereichen, globaler Zustand, gemeinsam genutzte Services, zentrale Fachlogik, Abhängigkeiten zur Shell, gemeinsame Konfiguration, produktweite Tests, gemeinsame Build- und Releasepfade sowie versteckte Laufzeitkopplungen.

Entscheidend ist die Unterscheidung:

Welche Abhängigkeiten sind fachlich notwendig – und welche sind nur historisch gewachsen?

Eine Capability darf Verträge zum restlichen Produkt benötigen. Vollständige Isolation ist weder realistisch noch sinnvoll. Problematisch wird es, wenn jede lokale Änderung den internen Zustand anderer Bereiche kennen muss, zentrale Services mit fremder Fachlogik aufruft oder nur innerhalb einer vollständigen Produktumgebung verständlich wird.

Organisatorischer Ist-Zustand

Die technische Grenze muss von einer tragfähigen Verantwortung begleitet werden. Deshalb gehören dauerhafte Teams, Capability-Owner, Entscheidungsrechte, Produktverantwortung, Abnahmeverantwortung, Releasehoheit und Betriebsverantwortung in die Analyse.

Auch regelmäßig wechselnde Projektteams und zentrale Freigabegremien sind relevant. Ein Bereich kann technisch sauber geschnitten sein und organisatorisch trotzdem keine unabhängige Veränderung erlauben.

Architektur kann Ownership sichtbar machen und unterstützen. Sie kann Ownership nicht ersetzen.

Operativer Ist-Zustand

Eine Microfrontend-Migration verändert nicht nur Quellcode. Sie betrifft Releaseprozesse, Testumgebungen, Fehlerdiagnose, Incident-Verantwortung, Rollback-Fähigkeit, Observability, Abhängigkeiten von Plattform- oder Betriebsteams und manuelle Freigaben.

Ein Team ist nicht autonom, wenn es den Code selbst schreibt, für Test, Diagnose und Veröffentlichung aber auf mehrere zentrale Einheiten warten muss.

Wirtschaftlicher Ist-Zustand

Schließlich muss sichtbar werden, wo die heutige Kopplung tatsächlich Kosten erzeugt: durch blockierte Teams, gekoppelte Releases, verschobene Abnahmen, unterschiedliche Veränderungsraten, verzögerte Kundenzusagen oder wiederkehrende Prioritätskonflikte.

Die Ausgangsanalyse sucht nicht nach Stellen, an denen technisch ein Remote eingebaut werden kann. Sie sucht nach Veränderungswegen, die wirtschaftlich unabhängig werden sollten.

Kann daraus eine eigenständige Anwendung entstehen?

Eine bewusst einfache Diagnosefrage hilft dabei, vermeintliche Grenzen zu prüfen:

Könnte aus dieser Fachlichkeit eine kleine eigenständige Anwendung entstehen?

Es geht nicht darum, sie zwingend als separates Produkt auszuliefern. Die Frage zwingt jedoch zu einer präziseren Beschreibung der Verantwortung.

Welche eigenen Regeln besitzt der Bereich? Welche Daten benötigt er? Welche Entscheidungen trifft er selbst? Welche Plattformfähigkeiten müsste er simulieren? Könnte er lokal gestartet und unabhängig getestet werden? Welche fremden Zustände müsste er importieren? Welche anderen Teams wären bei jeder Änderung weiterhin erforderlich? Wer würde den Bereich vollständig verantworten? Welche wenigen stabilen Verträge benötigt er zum restlichen Produkt?

Wenn der vermeintliche Bereich fast den gesamten bestehenden Zustand, zahlreiche interne Services und mehrere fremde Teams benötigt, existiert möglicherweise noch keine belastbare Microfrontend-Grenze.

Das bedeutet nicht, dass eine Migration unmöglich ist. Es bedeutet, dass vor der Extraktion mehr Arbeit notwendig ist: fachliche Regeln zusammenführen, Zustände kapseln, Abhängigkeiten neu ordnen und Ownership klären.

Risiken der Migration, des Stillstands und des halben Übergangs

Eine seriöse Entscheidung betrachtet nicht nur das Risiko der Migration. Sie vergleicht drei unterschiedliche Risikozustände.

Risiken der Migration

Eine Microfrontend-Migration erzeugt zusätzliche Plattform- und Integrationskosten. Temporär können alte und neue Pfade parallel bestehen. Adapter, Übergangsverträge und doppelte Tests benötigen Pflege. Neue Ownership kann unklar bleiben, Kompetenzen können fehlen und während der Migration sinkt häufig die verfügbare Feature-Kapazität.

Besonders teuer werden falsch gewählte Grenzen. Sie erzeugen viele Verträge, wiederholen Fachlogik oder verschieben Kopplung in globale Events, Shell-Services und produktweite Testketten. Auch inkonsistentes Verhalten zwischen alten und neuen Bereichen sowie zu lange parallele Strukturen gehören zu den realen Risiken.

Risiken des bestehenden Zustands

Der bestehende Zustand ist nicht automatisch kostenlos oder risikoarm. Releasekopplung kann zunehmen, Tests können langsamer und unzuverlässiger werden, Wissen kann sich bei wenigen Personen konzentrieren und Modernisierung kann durch breite Abhängigkeiten blockiert werden. Wartezeiten, Änderungsrisiken und schwierige Fehleranalyse können die Prognosesicherheit verschlechtern.

Das bedeutet nicht, dass jedes Legacy-System zwangsläufig immer teurer wird. Ein stabiler Monolith kann über Jahre zuverlässig liefern. Die Risiken müssen am konkreten System beobachtet werden, nicht aus seinem Alter abgeleitet.

Risiko der halben Migration

Der gefährlichste Zustand ist häufig nicht das klare technische Scheitern, sondern eine Migration, die dauerhaft zwischen Ausgangs- und Zielarchitektur stehen bleibt:

altes System
+
neue Remotes
+
temporäre Adapter
+
alte Freigabeprozesse
+
gemeinsame Testumgebung
+
kein konsequenter Rückbau

Die größte Gefahr ist nicht immer, dass eine Migration technisch scheitert. Häufiger bleibt sie dauerhaft zwischen Ausgangs- und Zielarchitektur stehen.

Eine halbe Migration kann teurer sein als beide klaren Zielzustände, weil sie die alte Kopplung behält und zusätzliche technische Verteilung einführt. Sie besitzt mehrere Deployables, aber keine lokalen Releases. Sie besitzt neue Integrationsverträge, aber weiterhin produktweite Abnahmen. Sie besitzt temporäre Adapter, die niemand mehr entfernen kann.

Darum gehört der Rückbau von Beginn an zur Migrationsstrategie.

Passt eine MFE-Strategie zur Organisation?

Diese Frage kommt vor der technischen Extraktionsstrategie.

Eine Organisation muss nicht bereits perfekt auf autonome Teams ausgerichtet sein. Sie muss jedoch bereit sein, die notwendige Veränderung offiziell zu tragen. Eine technisch mögliche Migration ist noch keine organisatorisch tragfähige Strategie.

Zu prüfen ist:

• Benötigt das Produkt unabhängige Veränderungswege?
• Arbeiten mehrere Teams dauerhaft parallel?
• Haben Produktbereiche unterschiedliche Prioritäten oder Releasezyklen?
• Existieren langfristige Capability-Owner?
• Dürfen diese Owner lokal entscheiden?
• Können Teams ihren Bereich eigenständig testen und Releases selbst auslösen?
• Können sie Fehler diagnostizieren und im Betrieb Verantwortung übernehmen?
• Ist die Plattform auf Self-Service ausgerichtet?
• Können Governance-Regeln als stabile Leitplanken statt als Einzelfallfreigaben funktionieren?
• Tragen Stakeholder Übergangskosten und Migrationskapazität mit?

Ein Nein auf eine einzelne Frage schließt Microfrontends nicht automatisch aus. Mehrere Nein-Antworten zeigen jedoch, dass noch keine tragfähige Strategie existiert.

Eine Organisation, die Autonomie nicht zulässt, sollte keine Architektur einführen, deren wirtschaftlicher Nutzen aus Autonomie entsteht.

Warum die Migration nicht gegen die Organisation funktioniert

Eine ernsthafte Migration benötigt mehr als eine technische Freigabe:

bewusste Migration
├── reservierte Kapazität
├── Stakeholder-Mandat
├── Übergangsarchitektur
├── veränderte Ownership
├── neue Test- und Releasewege
├── Betriebsverantwortung
└── Rückbau alter Strukturen

Dem steht häufig eine Erwartung gegenüber, die in sich widersprüchlich ist:

gewünschte Migration
aber:
├── keine zusätzliche Kapazität
├── unveränderte Feature-Geschwindigkeit
├── keine neuen Verantwortlichkeiten
├── keine temporäre Doppelstruktur
├── keine unabhängigen Releases
└── kein Rückbauaufwand

Eine Microfrontend-Migration ist keine technische Nebenaufgabe. Sie verändert, wie das Produkt entwickelt, getestet, veröffentlicht und verantwortet wird. Eine Microfrontend-Migration lässt sich nicht nebenbei und nicht gegen die Organisation durchführen.

Stakeholder müssen Microfrontends nicht als Technologie wollen. Sie müssen die Investition, die veränderten Verantwortlichkeiten und den angestrebten unabhängigen Veränderungsweg mittragen.

Wenn die Organisation diese Veränderung nicht tragen will, sollte sie keine MFE-Migration beginnen. Das ist keine Schuldzuweisung. Es ist eine strategische Entscheidung gegen Kosten und Verantwortungen, deren Nutzen unter den vorhandenen Bedingungen nicht realisiert werden könnte.

Drei mögliche Ergebnisse der Voranalyse

Eine gute Voranalyse endet nicht zwangsläufig mit einem Remote. Sie kann zu drei unterschiedlichen Ergebnissen führen.

1. Keine MFE-Migration erforderlich

stabiler Monolith
+
wenige Entwickler
+
klare Verantwortung
+
verlässliche Releases
+
geringe Koordinationskosten

In diesem Fall kann es sinnvoll sein, den Monolithen zu behalten, interne Modulgrenzen zu stärken, Tests zu verbessern und technische Modernisierung ohne verteilte Deployments durchzuführen.

Manchmal endet eine gute Microfrontend-Prüfung, bevor das erste Remote entsteht.

Das ist kein Scheitern. Es verhindert eine Architektur, deren laufende Kosten keinen entsprechenden Nutzen erzeugen würden.

2. Erst fachlich und technisch vorbereiten

Autonomie wäre wertvoll
aber:
├── Fachlichkeit ist unklar
├── Ownership fehlt
├── Zustand ist global
├── Tests sind produktweit
└── Abhängigkeiten sind zu breit

Hier wäre es verfrüht, bereits ein Remote zu extrahieren. Zuerst müssen Capability-Grenzen rekonstruiert, Ownership geklärt, Datenzugriffe gekapselt, direkte Abhängigkeiten reduziert, lokale Testbarkeit hergestellt und Plattformverträge definiert werden.

Diese Vorbereitung ist bereits Teil der Migration. Sie erzeugt noch kein neues Deployable, schafft aber die Voraussetzung dafür, dass ein späteres Remote mehr als eine technische Hülle wird.

3. Schrittweise MFE-Migration

erkennbare Capability
+
dauerhafter Owner
+
realer Autonomiebedarf
+
begrenzbare Abhängigkeiten
+
unabhängiger Test- und Releaseweg

Hier ist eine Extraktion plausibel. Die technische Machbarkeit ist nur eine Voraussetzung. Der Autonomiegewinn liefert die Begründung.

Extraktion, Entkopplung oder Rekonstruktion

Nicht jede Microfrontend-Migration beginnt aus derselben Ausgangssituation. Die Unterscheidung zwischen Extraktion, Entkopplung und Rekonstruktion ist deshalb zentral.

Extraktion

Eine weitgehend geschlossene Einheit existiert bereits:

Capability
├── eigene Regeln
├── klarer Owner
├── begrenzte Abhängigkeiten
├── nachvollziehbarer Datenbedarf
└── lokal testbares Verhalten

Der vorhandene Code kann schrittweise herausgelöst werden. Integrationsverträge werden explizit, Build und Bereitstellung werden getrennt und der alte Pfad kann nach der Übernahme entfernt werden.

Das ist der günstigste Fall, aber nicht der Normalfall jedes Legacy-Systems.

Entkopplung vor der Extraktion

Die Fachlichkeit ist erkennbar, technisch jedoch verflochten:

erkennbare Capability
aber:
├── globaler Zustand
├── direkte Imports
├── gemeinsame Services
├── zentrale Navigation
└── produktweite Abnahme

Die Migration beginnt hier nicht mit dem Remote, sondern mit dem Abbau der Kopplung. Fachliche Zugriffe werden gekapselt, Abhängigkeiten in explizite Verträge überführt und lokale Tests ermöglicht.

Erst wenn die Capability außerhalb des vollständigen Produkts sinnvoll betrieben und geprüft werden kann, gewinnt die technische Extraktion an Wert.

Rekonstruktion

Manchmal existiert keine belastbare Einheit:

fachliche Regeln über das System verteilt
+
unklare Ownership
+
keine lokale Abnahme
+
historisch gewachsene Zustände
+
nahezu jede Änderung betrifft mehrere Bereiche

Dann muss die Capability neu modelliert und möglicherweise weitgehend neu implementiert werden. In stark verflochtenen Bereichen kann eine Rekonstruktion faktisch einem partiellen oder vollständigen Rewrite entsprechen.

Extraktion verschiebt eine vorhandene Einheit. Rekonstruktion schafft eine Einheit, die bisher nicht existiert.

Je weniger fachliche und organisatorische Grenze bereits vorhanden ist, desto höher werden Aufwand, Risiko und notwendige Migrationskapazität.

Nicht der einfachste, sondern der wertvollste Schnitt

Der erste Kandidat wird häufig danach ausgewählt, welcher Bildschirm technisch leicht herauszulösen ist. Das reduziert das anfängliche Risiko, kann aber die falsche Frage beantworten.

Ein geeigneter Kandidat besitzt möglichst eine erkennbare Fachlichkeit, einen dauerhaften Owner, reale heutige Kopplung, regelmäßige Veränderung, einen begrenzbaren Integrationsvertrag, lokal testbares Verhalten und einen erwartbaren Autonomiegewinn.

Nicht automatisch geeignet sind technisch isolierte, aber fachlich bedeutungslose Seiten, allgemeines Layout, zentrale Navigation, Komponentenbibliotheken oder selten veränderte Randbereiche ohne heutigen Engpass. Auch Bereiche, die bei jeder Änderung weiterhin das gesamte Produkt und mehrere andere Teams benötigen, sind schlechte Kandidaten.

Ein einfacher Schnitt ist nicht automatisch ein wertvoller Schnitt.

Eine technisch einfache Seite kann als Plattformnachweis dienen. Sie zeigt, dass Build, Deployment und Laufzeitintegration funktionieren. Sie beweist jedoch noch nicht den wirtschaftlichen Nutzen der MFE-Strategie. Der erste belastbare Erfolg entsteht dort, wo eine Capability danach tatsächlich unabhängiger verändert, getestet und veröffentlicht werden kann.

Migration ist Produktarbeit, keine Nebenaufgabe

Eine Microfrontend-Migration lässt sich als gerichtete Schleife beschreiben:

1. Zielnutzen bestimmen.
2. Capability und Owner festlegen.
3. Bestehende Abhängigkeiten sichtbar machen.
4. Fachliche und technische Grenze stabilisieren.
5. Integrationsvertrag definieren.
6. Lokale Tests und Bereitstellung ermöglichen.
7. Funktionalität schrittweise übernehmen.
8. Alten Pfad und temporäre Adapter entfernen.
9. Autonomiegewinn bewerten.
10. Nächste Extraktion bewusst entscheiden.

Jede Extraktion sollte nicht nur etwas Neues erzeugen. Sie sollte einen Teil des alten Systems überflüssig machen.

Neue Capabilities können neben dem bestehenden System aufgebaut und alte Pfade anschließend schrittweise ersetzt werden. Solche gerichteten Übergänge werden häufig mit dem Strangler-Fig-Muster beschrieben. Entscheidend ist an dieser Stelle nicht das konkrete Migrationsmuster, sondern dass jeder neue Pfad einen alten Pfad nachweisbar überflüssig macht.

Übergangsarchitektur braucht Richtung und Rückbau

Während der Migration können alte und neue Navigation nebeneinander existieren. Temporäre Adapter, parallele API-Varianten, alte und neue Zustandsmodelle, breitere gemeinsame Tests oder ein Host, der beide Welten integriert, können legitim sein.

Eine tragfähige Übergangsarchitektur besitzt jedoch klare Eigenschaften:

Übergang
├── klaren Zweck
├── bekannten Owner
├── begrenzten Wirkungsbereich
├── beobachtbare Nutzung
├── Ablösekriterium
└── geplanten Rückbau

Eine Übergangsarchitektur ist kein Scheitern. Eine dauerhaft richtungslose Übergangsarchitektur ist es.

Ein temporärer Adapter ist nur dann Teil einer Migration, wenn seine Entfernung vorgesehen ist. Ein paralleler Pfad braucht ein Ablösekriterium. Ein breiter Integrationstest darf vorübergehend notwendig sein, sollte aber nicht unbemerkt zur neuen dauerhaften Freigabeinstanz werden.

Rückbau ist deshalb keine Aufräumarbeit nach der eigentlichen Migration. Er ist ein Erfolgskriterium der Migration.

Ein Remote ohne unabhängige Abnahme ist kein Migrationsziel

Ein neues Remote ist noch kein sinnvolles Ziel, wenn es nur im vollständigen Produkt validiert werden kann.

Die Capability sollte lokal startbar sein, mit simulierten Plattformverträgen arbeiten und ohne vollständige Produktumgebung fachlich abgenommen werden können. Im Host bleiben gezielte Kompositionstests notwendig. Sie prüfen jedoch die Integration, nicht erneut die vollständige Fachlichkeit jedes beteiligten Bereichs.

Außerdem muss die Capability unabhängig veröffentlicht werden können und ihre konkrete Version im Fehlerfall eindeutig diagnostizierbar sein.

Ein Remote, das separat gebaut, aber nur produktweit getestet und freigegeben werden kann, hat die alte Releasekopplung noch nicht verlassen.

Damit ist auch Ownership mehr als Codeverantwortung. Sie umfasst Fachlichkeit, Tests, lokalen Release, Observability und Incident-Verantwortung. Der Owner sollte nicht erst nach der technischen Extraktion gesucht werden.

Ein Projektteam, das nach der Migration wieder aufgelöst wird, ist kein dauerhafter Capability-Owner. Eine zentrale Architekturgruppe kann Grenzen vorbereiten, Integrationsverträge entwickeln und Plattformfähigkeiten bereitstellen. Sie kann den Produktbereich jedoch nicht dauerhaft besitzen.

Wo niemand eine Capability dauerhaft besitzen will, sollte auch kein eigenständiges Remote geschaffen werden.

Die Verteilung sollte nicht feiner werden als die Organisation Verantwortung dauerhaft tragen kann.

Nach jeder Capability den Nutzen erneut prüfen

Nach jeder größeren Extraktion muss die MFE-Strategie erneut beweisen, dass weitere Verteilung wirtschaftlich sinnvoll ist.

Zu prüfen ist:

• Kann das Team häufiger unabhängig veröffentlichen?
• Benötigt eine lokale Änderung weniger andere Teams?
• Ist die unabhängige Abnahme möglich?
• Sind produktweite Tests gezielter geworden?
• Wurden alte Pfade entfernt?
• Wurden temporäre Adapter zurückgebaut?
• Sind Incidents klarer zuzuordnen?
• Ist Ownership verständlicher geworden?
• Ist der Releasepfad kürzer oder verlässlicher?
• Hat sich der erwartete Autonomiegewinn tatsächlich eingestellt?

Dafür sind keine universellen Zielwerte notwendig. Entscheidend ist, ob das ursprünglich benannte Problem nachvollziehbar kleiner geworden ist.

Eine Migration sollte nach jeder Capability erneut beweisen, dass weitere Verteilung wirtschaftlich sinnvoll ist.

Die erste erfolgreiche Extraktion ist keine automatische Genehmigung für alle weiteren. Jede nächste Grenze benötigt eine eigene Begründung.

Warum nicht alles ein Remote werden muss

Eine erfolgreiche Microfrontend-Migration muss nicht in einer vollständig verteilten Landschaft enden.

Ein sinnvoller Zielzustand kann so aussehen:

Produkt
├── Host und Plattform
├── Capability A als Remote
├── Capability B als Remote
├── Capability C als Remote
├── kohärenter gemeinsamer Kern
└── bewusst gemeinsame Funktionen

Das ist kein unfertiger Zustand.

Ein gemeinsamer Kern kann fachlich kohärent sein, von denselben Menschen verändert werden und keinen relevanten Autonomiebedarf besitzen. Bewusst gemeinsame Funktionen müssen nicht künstlich verteilt werden, nur weil an anderer Stelle Remotes existieren.

Eine bewusste hybride Zielarchitektur ist kein gescheiterter Zwischenstand. Sie kann genau die Grenzen verteilen, an denen unterschiedliche Veränderungsraten, Owner und Releasewege einen Vorteil erzeugen, während der verbleibende Kern gemeinsam bleibt.

Wann die nächste Extraktion keinen Nutzen mehr bringt

Stoppsignale entstehen nicht erst dann, wenn eine Extraktion technisch unmöglich wird.

Für den nächsten Bereich kann ein dauerhafter Owner fehlen. Es kann keinen relevanten Bedarf an unabhängiger Veränderung geben. Der Bereich wird möglicherweise fast immer gemeinsam mit anderen Bereichen geändert. Seine fachliche Verflechtung kann höher sein als der mögliche Autonomiegewinn.

Auch eine Grenze, die viele neue Verträge erzeugt, aber kaum Wartezeit beseitigt, ist ein Warnsignal. Dasselbe gilt, wenn nur eine technische, aber keine fachliche Grenze existiert, die Organisation zusätzliche Betriebsverantwortung nicht tragen kann oder der Übergangsaufwand den erwarteten Nutzen übersteigt.

Besonders kritisch ist die Begründung, die nächste Extraktion müsse erfolgen, weil bereits andere Remotes existieren. Frühere Entscheidungen ersetzen keine neue Analyse.

Man hört nicht erst auf, wenn sich technisch nichts mehr extrahieren lässt. Man hört auf, wenn die nächste Grenze keinen belastbaren fachlichen, organisatorischen oder wirtschaftlichen Autonomiegewinn mehr erzeugt.

Die bewusste Entscheidung aufzuhören

Eine Microfrontend-Migration kann auch dann sinnvoll sein, wenn das bestehende System heute keine sauberen technischen Module besitzt. Je weniger fachliche Grenzen, Ownership und lokale Testbarkeit vorhanden sind, desto weniger handelt es sich jedoch um eine Extraktion und desto stärker um Entkopplung oder Rekonstruktion.

Microfrontends sind nur dann ein sinnvoller Modernisierungsweg, wenn das Produkt unabhängige Veränderungswege benötigt und die Organisation bereit ist, dafür Verantwortung, Entscheidungsrechte, Testbarkeit, Releasefähigkeit, Übergangskapazität und Rückbau zu tragen.

Wo ein stabiler Monolith mit wenigen Entwicklern verlässlich liefert, besteht möglicherweise kein Autonomieproblem. Dort kann die Entscheidung gegen Microfrontends die wirtschaftlich und architektonisch bessere Entscheidung sein.

Die Ist-Analyse kommt vor der Zielarchitektur. Dabei sind die Risiken der Migration nicht gegen einen vermeintlich kostenlosen Status quo zu rechnen. Auch der bestehende Zustand und besonders der halbe Übergang besitzen eigene Risiken.

Nicht jede technisch extrahierbare Oberfläche ist eine Capability. Jede Extraktion benötigt einen konkreten Nutzen, einen dauerhaften Owner, unabhängige Abnahme und einen Rückbaupfad. Eine Organisation, die Autonomie nicht nutzen will, sollte keine Autonomiearchitektur einführen.

Der Zielzustand darf hybrid bleiben. Die Entscheidung gegen die nächste Extraktion ist Teil einer guten Migrationsstrategie. Microfrontends sind kein Selbstzweck.

Eine gute Migrationsstrategie beweist nicht, dass sich alles verteilen lässt. Sie prüft zuerst, ob Verteilung überhaupt ein Problem löst – und hört auf, sobald die nächste Grenze mehr Aufwand erzeugt als Autonomie gewinnt.