Monolith modernisieren, ohne alles neu zu bauen

Fast jedes Unternehmen, das länger Software betreibt, hat irgendwann den Wunsch, den Monolith loszuwerden. Er ist langsam geworden, schwer zu testen, gefürchtet bei jedem Deployment. Die erste Idee ist meist: alles neu bauen. Das ist fast immer die teuerste und riskanteste Option.

Der Grund ist einfach: Ein Monolith ist nicht nur Code. Er ist Code, Daten, Prozesse, Organisation und Jahre an Randbedingungen, die niemand mehr benennen kann. Alles gleichzeitig ersetzen zu wollen, bedeutet, diese Komplexität auf einmal neu zu lösen — mit einem Team, das die alte Lösung gerade erst verlässt und die neue noch nicht versteht.

Warum der große Rewrite scheitert

Rewrites scheitern selten an der Technik. Sie scheitern an:

• Unterschätzung der Geschäftslogik: Was im alten System als fünfzehn Sonderfällen wirkt, ist oft fünfzehn legitime Geschäftsregeln, die im neuen System erst wiederentdeckt werden müssen.
• Langlebigkeit des Altsystems: Solange das neue System nicht fertig ist, läuft das alte weiter — und wird gleichzeitig weiterentwickelt. Das Ziel bewegt sich.
• Mangelnder Nutzen in der Zwischenzeit: Monate oder Jahre vergehen, ohne dass das Unternehmen einen messbaren Vorteil sieht. Das frisst Rückhalt und Budget.
• Organisatorischer Widerstand: Menschen, die im alten System arbeiten, werden als Bremser wahrgenommen, obwohl sie oft genau diejenigen sind, die die Ausnahmen kennen.

Der bessere Weg: Strangler Fig Pattern

Das Strangler-Fig-Pattern ersetzt den Monolith nicht auf einen Schlag, sondern wächst ihn aus. Neue Funktionen werden außerhalb des Monolithen gebaut, Altlasten werden Schritt für Schritt durch neue Implementierungen ersetzt, die Daten fließen über eine Fassade oder API.

Der entscheidende Vorteil: Jeder Schritt liefert eigenständigen Nutzen. Die ersten neuen Services sind nicht Architekturziele, sondern Geschäftsfeatures. Sie werden produktiv genutzt, bevor der Großteil des Monolithen angefasst wird.

Den richtigen Schnitt finden

Der erste Schritt ist nicht technisch, sondern fachlich. Wir modellieren mit dem Team und dem Fachbereich die Kernabläufe als Ereignisstrom. Dabei zeigt sich oft, dass der Monolith fachlich bereits in mehrere Teile zerfallen würde, wenn man die Datenflüsse genau betrachtet. Ein Event-Modeling-Sprint ist dafür der passende Einstieg.

Der nächste Schnitt sollte:

• einen Geschäftswert liefern, der sich in wenigen Wochen messen lässt;
• Daten und Prozesse entkoppeln, die heute noch im selben Modul verklebt sind;
• risikoarm sein — also nicht die am meisten genutzte Funktion zuerst, aber auch nicht eine vergessene Ecke, die niemanden interessiert.

Domain-Driven Slices statt Microservices

Wir sprechen bewusst nicht von „Microservices" als Ziel. Microservices sind eine Betriebsform, kein Architekturziel. Das Ziel ist, fachlich zusammenhängende Slices zu identifizieren, die eigenständig besitzbar und weiterentwickelbar sind. Ob ein Slice ein Service, ein Modul oder ein bounded context im Monolith bleibt, ist eine sekundäre Frage.

Diese Slices haben drei Eigenschaften:

• Fachliche Kohärenz: Sie gehören zu einem Geschäftsprozess, nicht zu einer technischen Schicht.
• Klare Ownership: Ein Team oder eine Person ist verantwortlich.
• Eigenständige Lieferfähigkeit: Änderungen können deployed werden, ohne den Rest des Systems zu berühren.

Datenmigration ohne Stillstand

Die größte Herausforderung bei einer Modernisierung ist nicht der Code, sondern die Daten. Wer Daten umzieht, braucht eine Strategie für beide Richtungen:

• Neue Schreibwege: Daten, die neu erfasst werden, landen im neuen System.
• Altbestände: Bestehende Daten bleiben zunächst im Monolith und werden bei Bedarf projiziert oder synchronisiert.
• Cutover: Irgendwann wechselt die führende Quelle. Das passiert nicht an einem Wochenende, sondern über einen kontrollierten Zeitraum, in dem beide Systeme parallel laufen.

Ownership und Übergabe

Ein Monolith, der über Jahre gewachsen ist, hat oft keinen einzelnen Besitzer. Bevor Technik modernisiert wird, sollte geklärt werden, wer die neuen Slices verantwortet. Sonst entsteht ein neues System, das technisch sauberer ist, aber organisatorisch immer noch niemandem gehört.

Deshalb ist die Modernisierung bei uns eng mit unserem Ownership- und Team-Setup verbunden: Neue Slices bekommen von Anfang an einen Namen, nicht nur eine Rolle.

Kurzfassung

Der große Rewrite ist fast immer die schlechteste Option. Der Monolith lässt sich Schritt für Schritt modernisieren, wenn man den richtigen fachlichen Schnitt findet, Daten vorsichtig umzieht und neue Slices von Anfang an ein klares Ownership bekommen. Dann liefert jeder Schritt Nutzen, bevor der Großteil des Altsystems angefasst wird — und das Team behält den Boden unter den Füßen.

Wenn Sie prüfen wollen, was Ihr System heute tatsächlich belegen kann: Der Nachweis-Check stellt zehn Fragen dazu. Den größeren Rahmen — von NIS2 bis EU AI Act — sammeln wir unter Nachweisbarkeit.