Monolith in Microservices zerlegen

Ein gewachsenes System schrittweise ablösen, ohne Betriebsstillstand und ohne den Umschalttag, der nie kommt.

Die häufigste Art, einen Monolithen abzulösen, ist die Neuentwicklung daneben: ein zweites Team, ein leeres Repository, ein Termin in zwei Jahren. Der Termin verschiebt sich, weil das Altsystem nicht stehen bleibt. Die Alternative ist unspektakulärer und funktioniert: Man nimmt dem Monolithen einen fachlichen Bereich nach dem anderen weg.

Der Umbau, der nie fertig wird

Der Beschluss klingt vernünftig: daneben neu bauen, dann umschalten. Der Fehler steckt im Wort „dann“. Zwei Jahre lang bleibt das Altsystem in Betrieb, und ein System in Betrieb wird geändert, etwa durch eine neue Vorgabe oder einen neuen Lieferanten. Jede Änderung muss im Neubau nachgezogen werden; das Ziel bewegt sich schneller, als der Neubau aufholt.

Dazu kommt: Bis zum Stichtag hat kein Anwender etwas in der Hand, es fehlt also die Korrektur aus dem echten Betrieb. Solche Vorhaben enden deshalb selten mit einem Knall. Sie enden damit, dass dauerhaft zwei Systeme gepflegt werden. Die Ablösewege im Überblick.

Danebenbauen oder Stück für Stück herauslösen

Die Neuentwicklung wird häufiger geplant, das schrittweise Herauslösen häufiger fertig.

Neuentwicklung

Der Neubau auf der grünen Wiese

ein Team baut zwei Jahre neu, ein zweites pflegt das Altsystem weiter
jede Änderung am Altsystem muss nachgezogen werden, und das Ziel bewegt sich mit
am Stichtag muss alles gleichzeitig laufen, auch die undokumentierten Sonderfälle
geht es schief, gibt es nur den Rückzug im Ganzen

Schrittweise

Ein Bereich verlässt das Altsystem

ein fachlicher Bereich zieht um, geht produktiv, der Rest bleibt unangetastet
jeder Schnitt liefert Nutzen, bevor der nächste beginnt
der Monolith schrumpft messbar, an Masken, Tabellen und Nachtläufen
ein misslungener Schnitt kostet einen Bereich, nicht das Haus

Woran man schneidet: an der fachlichen Zuständigkeit

Der erste Reflex ist ein technischer Schnitt: ein Dienst für den Datenbankzugriff, einer für die Berichte, einer für die Oberfläche. Daraus werden Dienste, die einander bei jeder Anfrage brauchen. Sie haben alle Nachteile einer verteilten Anwendung und keinen ihrer Vorteile.

Der tragfähige Schnitt verläuft entlang einer organisatorischen Frage: Wer im Haus entscheidet über diesen Datenbestand? Gibt es genau eine Antwort, ist der Bereich ein Kandidat. Lautet sie „das machen drei Abteilungen gemeinsam“, liegt die Grenze woanders. Bei uns bildet der erste Durchgang deshalb nur den Ist-Stand ab; neu entworfen wird erst im zweiten, aus einem leeren Modell. Die Grundlagen zur Microservice-Architektur stehen auf einer eigenen Seite.

Wer entscheidet über die Daten?

Es muss genau eine Stelle geben, die über den Datenbestand bestimmt. Schreiben drei Abteilungen an dieselben Felder, sitzt der Schnitt falsch.

Wie viel muss der Rest sehen?

Ein Bereich, von dem andere fünf Felder brauchen, lässt sich trennen. Einer, von dem sie fünfzig brauchen, war nie ein eigener Bereich.

Was passiert, wenn er kurz fehlt?

Darf er zehn Minuten ausfallen, ohne dass der Rest steht, ist er ein guter Kandidat.

Lässt er sich einzeln zurückdrehen?

Nur dann taugt der Schnitt. Das ist die praktischste Definition einer Bereichsgrenze.

Wie ein einzelner Schnitt abläuft

Die Schleife, die sich pro Bereich wiederholt

An die Stelle eines Projektplans über zwei Jahre tritt eine Schleife, deren erster Durchlauf der teuerste ist.

Bereich abstecken, Datenhoheit festlegen
Welche Entitäten gehören dazu, welche Felder bleiben beim Altsystem, wer ist ab wann führend? Hier fällt die Architekturentscheidung.
Ergebnis: eine Zuständigkeitsliste
Ist-Stand aufnehmen, Altdaten sichern
Ein Export des Ausschnitts bleibt die Referenz für das Feld-Mapping. Bestandsaufnahme, noch kein Entwurf.
Tage, nicht Wochen
Den Bereich neu modellieren
Entitäten, Felder, Beziehungen, Formulare und Rollen werden entworfen statt abgezeichnet, aber so, dass die Altdaten migrierbar bleiben.
generiert, nicht getippt
Der Bereich wird eine eigene kleine Anwendung
Was herausgelöst wird, landet nicht im nächsten Kapitel einer großen Anwendung, sondern wird eine eigene. Sie teilt sich mit den anderen Anmeldung, Rechte und Erscheinungsbild, verweist auf sie und tauscht Daten mit ihnen aus, sodass es sich im Gebrauch wie ein System anfühlt.
Damit ist der Zuschnitt von eben nicht nur eine Entwurfsfrage: Ein Bereich lässt sich später ändern, neu erzeugen oder abschalten, ohne die anderen anzufassen. Wie das technisch zusammenhängt, steht unter Microservice-Architektur; wie es für den Anwender zusammenwächst, unter einer Oberfläche.
verdrahtet statt verschmolzen
Brücke bauen und lesend live gehen
SOLUTIONS.transformer übernimmt die Bestände und hält sie abgeglichen. Das Altsystem bleibt führend.
erst lesen, dann schreiben
Schreibrichtung umdrehen
Der neue Dienst wird führend, die Brücke spielt Änderungen zurück, solange der Rest sie braucht.
der einzige echte Stichtag
Alten Teil stilllegen oder stehen lassen
Erst nach einer vollen Abrechnungsperiode ohne Rückfall werden Masken, Tabellen und Nachtläufe abgeschaltet.
abschalten heißt abschalten

Die gemeinsame Datenbank hält den Monolithen zusammen

Was einen Monolithen zusammenhält, ist selten der Code. Es ist die eine Datenbank, in der jede Tabelle jede andere sehen kann. Eine Abfrage über sieben Tabellen ist in fünf Minuten geschrieben, und dabei entsteht eine Abhängigkeit, die in fünf Jahren niemand mehr entwirrt. Wer die Dienste trennt, die Datenbank aber gemeinsam lässt, hat nichts gewonnen.

Bei uns gehört jeder Datenbestand genau einem Dienst. Er gibt einzelne Datentypen frei, andere Dienste melden sich dafür an und bekommen sie zugestellt. Niemand greift auf die Datenbank eines anderen zu.

Das kostet dauerhaft etwas: Eine Abfrage über zwei Dienste hinweg gibt es nicht, Auswertungen über Bereichsgrenzen brauchen einen eigenen Weg, und steht ein Dienst still, fehlen dem anderen dessen Daten.

Screenshot SOLUTIONS Microservice Architektur Einbindung

Die Parallelphase ist geplante Arbeit

Solange alt und neu nebeneinanderlaufen, muss für jeden Datenbestand feststehen, welches System führt. Sonst gibt es zwei Wahrheiten, und die Fachabteilung entscheidet täglich neu, welcher sie glaubt.

Die Brücke baut SOLUTIONS.transformer: Quellen anbinden, Felder verbinden, Läufe planen, alles grafisch statt in Skripten. Abgeglichen wird über den fachlichen Schlüssel, ein zweiter Lauf erzeugt also keine Dubletten.

Trifft ein Lauf auf einen ungültigen Datensatz, bricht er ab. Deshalb wird je Bereich getrennt übernommen, statt alles in einem Durchgang.

Wann sich der Umbau lohnt und wann man aufhört

Nicht jeder Monolith gehört zerlegt. Eine überschaubare Anwendung, die läuft und gepflegt wird, wird durch Zerlegung teurer statt billiger: Aus einem Deployment werden fünf, und jede Bereichsgrenze ist eine Schnittstelle, die gebaut und gepflegt werden muss. Deutsche Anbieter veranschlagen je Schnittstelle 3.500 bis 21.000 Euro, laut ihren eigenen Preisangaben mit Stand August 2026.

Der Schritt lohnt sich, wenn mindestens zwei Punkte zutreffen: Bereiche werden in verschiedenen Rhythmen geändert und blockieren sich beim Ausliefern. Ein Bereich soll nach außen erreichbar sein, der Rest ausdrücklich nicht. Ein Bereich hat einen Lastverlauf, der die übrigen mitzieht. Das Wissen liegt bei Leuten, die einander im selben Repository im Weg stehen.

Zuletzt eine Überlegung, die kaum jemand anstellt: Wann hört man auf? Nicht zwingend bei null. Ein Rest, der stabil läuft und niemanden blockiert, darf bleiben. Wer ihn aus Prinzip abreißt, bezahlt für Symmetrie.

Weiterlesen

Häufige Fragen

Woran erkennt man, wo ein Monolith geschnitten werden sollte?

An der fachlichen Zuständigkeit, nicht an der Technik: Für jeden Datenbestand muss es genau eine Stelle geben, die über ihn entscheidet. Schreiben drei Abteilungen an dieselben Felder, verläuft die Grenze woanders.

Wie lange laufen Altsystem und neuer Dienst parallel?

Je Bereich meist einige Wochen: erst geht der neue Dienst lesend live, dann wird die Schreibrichtung umgedreht, dann der alte Teil stillgelegt. Entscheidend ist nicht die Dauer, sondern die Festlegung, welches System führt.

Was passiert mit der gemeinsamen Datenbank, an der alles hängt?

Sie wird aufgeteilt, nicht geteilt. Bei uns gibt der Eigentümer eines Datenbestands seine Modelle frei, abhängige Dienste erhalten sie über den Nachrichtenbus, ohne eigene Datenbankverbindung zur fremden Anwendung.

Was passiert, wenn ein Schritt nicht funktioniert?

Betroffen ist ein Bereich, nicht das Haus. Jeder Dienst wird einzeln versioniert und ausgerollt, der Rücksprung im Code dauert Minuten. In den Daten dauert er länger, deshalb bleibt das Altsystem führend, bis der neue Dienst im Lesebetrieb bestätigt ist.

Muss am Ende der gesamte Monolith verschwinden?

Nein. Ein Rest, der stabil läuft und niemanden blockiert, darf bleiben. Ziel ist eine Landschaft, in der der Altbestand nichts mehr aufhält.

Lohnt sich die Zerlegung immer?

Nein, und das ist die häufigste Fehlentscheidung. Jede Bereichsgrenze ist eine Schnittstelle, die gebaut und gepflegt werden muss. Eine kleine Anwendung, die läuft, wird dadurch teurer.

Stunde mit uns vereinbaren

Eine Stunde per Videokonferenz, kostenlos.