Von Monolith zu Microservices: Erfolgreiche Cloud-Migration und IT-Transformation

KAPITEL 1: EINLEITUNG UND GRUNDLAGEN

‍
Die gleichzeitige Transformation einer monolithischen Anwendung in eine Microservices-
Architektur und die parallele Migration in die Cloud gehören zu den anspruchsvollsten und
zugleich chancenreichsten Projekten in der modernen IT. Monolithische Systeme sind über
viele Jahre gewachsen, oft eng mit historischen Prozessen verknüpft und bilden die
Grundlage für eine Vielzahl geschäftskritischer Funktionen. Doch sie werden immer
schwerfälliger, wenn neue Anforderungen entstehen oder schnellere Reaktionszeiten
erforderlich sind. Microservices, auf der anderen Seite, sind klein, spezialisiert und
unabhängig voneinander entwickelbar. Sie ermöglichen eine schnellere Weiterentwicklung
und eine passgenaue Skalierung einzelner Teilfunktionen. Doch bei der Umstellung von
einem monolithischen Konstrukt in eine verteilte Service-Landschaft steigen sofort die
Komplexität und die Anforderungen an die Koordination verschiedener Teams und
Technologien. Wenn dann auch noch eine Cloud-Migration hinzukommt, die für Infrastruktur,
Betrieb und Skalierung eine ganz neue Grundlage schafft, muss jedes Unternehmen sich
bewusst sein, dass hier ein tiefgreifender Veränderungsprozess stattfindet.
Bevor man in die Umsetzung geht, empfiehlt es sich, eine Zielarchitektur auf hohem
Abstraktionsniveau zu definieren, die das Zusammenspiel der künftigen Microservices sowie
die grobe Struktur in der Cloud festlegt. Sobald diese Zielarchitektur skizziert ist, werden in
einem Lastenheft alle fachlichen Anforderungen und Prozesse dokumentiert, die das neue

System erfüllen muss. Die so festgelegte Zielarchitektur wird im nächsten Schritt
heruntergebrochen auf ein Pflichtenheft, in dem die konkreten technischen
Umsetzungsideen und Bausteine festgehalten sind. Darauf aufbauend werden schließlich
die einzelnen Umsetzungskonzepte erstellt, aus denen man User Storys ableitet, die das
Entwicklungsteam anschließend Schritt für Schritt umsetzt.

‍
Die entscheidende Frage lautet, wie man mit einer solch tiefgreifenden Umstellung umgehen
sollte, damit die Risiken überschaubar bleiben und man gleichzeitig genug Spielraum für
notwendige Lernschleifen hat. Denn bei einem gewachsenen Monolithen, der seit Jahren
verschiedene Abteilungen bedient, existieren oftmals unzählige Verflechtungen, die sich erst
im Zuge der tatsächlichen Umsetzung zeigen. Darüber hinaus kommt hinzu, dass viele
Unternehmen den Schritt in die Cloud nicht nur als reine Infrastrukturverlagerung sehen,
sondern gleichsam eine Modernisierungskampagne anstoßen möchten, die langfristig für
höhere Flexibilität und Agilität sorgt. Ein sorgfältig geplanter Ansatz, der sowohl die
Anforderungsaufnahme in einem gewissen Umfang vorwegnimmt als auch frühzeitige
Experimentier- und Testphasen vorsieht, ist deshalb ein logischer Weg, um die Komplexität
in beherrschbare Teilabschnitte zu zerlegen.

‍
KAPITEL 2: DIE HERAUSFORDERUNG DER PARALLELEN TRANSFORMATION

‍
Beim Aufbrechen eines Monolithen kommt es häufig zu der Frage, in welcher Reihenfolge
man einzelne Module oder Funktionen in eigenständige Microservices auslagert. Nicht
selten ist die Software historisch so gewachsen, dass bestimmte Komponenten eng
miteinander verwoben sind und gemeinsame Datenbanken, Konfigurationen oder
Schnittstellen nutzen. Will man all dies im großen Stil umstrukturieren und gleichzeitig in die
Cloud bringen, steigt das Risiko, dass man das Projekt zu umfassend anlegt und im
schlimmsten Fall den Überblick verliert. Daher hat es sich in vielen Unternehmen bewährt,
mit einem iterativen Vorgehen zu arbeiten. Man analysiert zunächst die Domänen, die am
meisten von einer Microservices-Architektur profitieren würden, extrahiert die
entsprechenden Funktionen aus dem Monolithen und baut diese nach modernen Standards
in einer separaten Umgebung auf. Parallel dazu wird geklärt, wie genau die Cloud-
Infrastruktur aussehen soll, welche Dienste man nutzen möchte und wie der künftige Betrieb
organisiert wird.

‍
In der Realität lässt sich diese Strukturierung oft nicht so eindeutig trennen, da die
Umstellung auf Microservices bereits viele technologische Fragen aufwirft, die man besser in
einer Cloud-nahen Umgebung beantwortet. Auf der anderen Seite will man in der Cloud-
Migration noch nicht alle Anwendungen verschieben, solange man nicht weiß, wie die neue
Architektur aussehen wird. Genau hier entsteht die Idee der parallelen Test- und Pre-
Production-Umgebungen, in denen man frühzeitig sowohl Technologieexperimente als auch
Teilauslagerungen des Monolithen durchführen kann. Die Testumgebung dient dabei als
erste Distanz. Hier können Units und Abhängigeiten getestet werden. Sobald ein gewisses
Qualitätsniveau erreicht wird geht es mit der Pre-Prod Umgebung weiter. Die Pre Prod
Umgebung ist als eine Art simulierter Echtbetrieb zu verstehen. Dort werden anonymisierte
Echt daten getestet, da dies nochmal einen großen Unterschied ausmachen kann. So haben
Unternehmen die Möglichkeit, bereits erste Services unter realistischen Bedingungen zu
erproben, ohne den produktiven Betrieb zu gefährden oder in einem großen Big-Bang-
Ansatz sämtliche Risiken auf einen Schlag zu nehmen.

‍
KAPITEL 3: VOM MONOLITH ZUM MICROSERVICE

‍
Der Kern dieser Transformation besteht darin, ein meist großes, komplexes und eng

geknüpftes Softwaregebilde in einzelne kleine Services zu zerlegen, die jeweils eine klar
definierte Aufgabe erfüllen. Dabei ist es essenziell, dass diese Services weitestgehend
unabhängig voneinander agieren können. Eine monolithische Anwendung greift oft auf eine
einzige, gemeinsame Datenbank zu, sodass der Datenaustausch implizit erfolgt und
Änderungen in einer Stelle unbemerkt andere Stellen beeinflussen können. In einer
Microservices-Landschaft definiert man im Idealfall für jeden Service entweder eine eigene
Datenbank oder zumindest abgetrennte Schemas, sodass die Zuständigkeiten klar
abgegrenzt sind. Dies erfordert jedoch ein gründliches Umdenken in der Architektur, denn
jede Entkopplung kann bedeuten, dass bisher interne Funktionen nun über APIs oder
Events kommunizieren müssen.

‍
Wer diesen Schritt mit einer Cloud-Migration verbindet, muss zusätzlich überlegen, wie die
Infrastruktur für die neuen Services aussieht. Viele Teams entscheiden sich, Container-
Plattformen zu nutzen, weil sich Microservices darin elegant paketieren und isoliert betreiben
lassen. Andere setzen auf serverlose Angebote ihrer Cloud-Anbieter, um sich noch stärker
auf den Code und weniger auf den Betrieb zu konzentrieren. In jedem Fall ist das Risiko,
etwas übersehen zu haben, hoch. Deshalb empfiehlt es sich, relativ früh eine einfache
Testumgebung in der Cloud einzurichten, in der man erste Services oder Prototypen
einrichtet und beobachtet, wie gut diese mit den ausgewählten Technologien harmonieren.
Manche Unternehmen entdecken in dieser Phase bereits, dass bestimmte Datenflüsse so
eng miteinander verwoben sind, dass eine Auslagerung in Microservices nur unter
erheblichen strukturellen Anpassungen funktionieren würde. Andere stellen fest, dass sie
vielleicht auf ein ganz anderes Datenbankmodell wechseln müssen, um wirklich in einer
Microservices-Welt profitieren zu können. Gerade hier sind iterative Lernzyklen enorm
hilfreich, da man mit jedem kleinen Teilschritt besser versteht, was als Nächstes ansteht,
welche weiteren Anforderungen definiert werden müssen und wo man die Planung eventuell
korrigieren sollte.

‍
KAPITEL 4: CLOUD-MIGRATION ALS KATALYSATOR

‍
Die Cloud ist für viele Unternehmen nicht mehr nur ein virtueller Ersatz für das eigene
Rechenzentrum, sondern ein Innovationsmotor, der ihnen ermöglicht, auf fortschrittliche
Technologien zuzugreifen, ohne riesige Infrastrukturprojekte zu stemmen. Wer seine neu
entstandenen Microservices direkt in die Cloud integriert, kann meist von skalierbaren
Ressourcen, automatisierten CI/CD-Pipelines und komfortablem Monitoring profitieren. Doch
genau in dieser Phase tauchen oftmals Fragen zu Sicherheit, Compliance oder
Kostenkontrolle auf, die man klar regeln muss.

‍
Es empfiehlt sich, eine Pre-Production-Umgebung zu definieren, die möglichst nah an die
produktiven Anforderungen heranreicht und echte oder zumindest repräsentative Daten
enthält. Dadurch kann man abschätzen, wie das System unter Last reagiert und ob man
Eventualitäten wie Netzwerkausfälle, Dateninkonsistenzen oder regionale
Verfügbarkeitsanforderungen bedacht hat. In dieser Staging-Phase lassen sich Fehler, die
im Umgang mit Echtdaten auftreten, strukturiert dokumentieren. Die Praxis zeigt, dass hier
Defects eingestellt werden, die alle Beteiligten gemeinsam analysieren.

Das betrifft Entwicklerinnen und Entwickler, die den Code verantworten, Testerinnen und Tester, die
den Systembetrieb überprüfen, Konzeptionsexperten, die für die fachliche Integration
zuständig sind, und nicht zuletzt den Fachbereich selbst, der am Ende beurteilen muss, ob
die neue Lösung tatsächlich die Geschäftsprozesse korrekt abbildet. Durch dieses
Zusammenspiel kann die Software schnell nachjustiert werden, und das Team versteht
immer besser, welche Anpassungen an der Gesamtarchitektur notwendig sind. Dieser

Prozess steigert nicht nur die technische Qualität und senkt das Risiko, sondern sorgt auch
dafür, dass die Anwendung tatsächlich praxistauglich ist, da alle Fachexperten rechtzeitig
einbezogen werden.

‍
KAPITEL 5: PROJEKTORGANISATION, DEFECT-MANAGEMENT UND FAZIT

‍
Die parallele Entwicklung von Microservices und die gleichzeitige Migration in die Cloud
erfordern eine gründlich geplante Projektorganisation, die idealerweise auf agilen oder
hybriden Prinzipien basiert. In einem agilen Setting können Anforderungen dank der
ausführlichen Entiwcklungskonzepte in User Stories festhalten, während das Team im
Hintergrund bereits die ersten Komponenten vorbereitet. Manche Aspekte wie
Datenschnittstellen, Sicherheitskonzepte oder die Konfigurationsmethoden für den Cloud-
Betrieb werden parallel weiter ausgearbeitet, sodass es zu jeder Zeit möglich ist, erste
Services in einer Test- oder Pre-Production-Umgebung zu integrieren. So entsteht eine
lernende Organisation, die sicherstellt, dass niemand auf monatelange Vorarbeiten wartet,
sondern sich das System organisch weiterentwickelt.

‍
Gerade das Defect-Management spielt dabei eine Schlüsselrolle. Werden in der Testphase
oder in der Pre-Production-Umgebung Fehler entdeckt, sollten diese umgehend in einem
zentralen System erfasst und priorisiert werden. Das Team nimmt sich dann die Zeit, den
Fehler zu analysieren, herauszufinden, ob die Ursache in der Architektur, im Code oder in
der Konfiguration liegt, und setzt entsprechende Gegenmaßnahmen um. Auf diese Weise
lernt jeder Teil des Projektteams kontinuierlich dazu, weshalb diese iterative Schleife nicht
als notwendiges Übel, sondern als Chance zu verstehen ist.

‍
Neben einer klaren Defect-Management-Strategie ist zudem ein professionelles
Änderungsmanagement unverzichtbar. Gerade in Projekten, bei denen Anforderungen und
Technologien gleichermaßen im Fluss sind, müssen alle Anpassungen sauber dokumentiert
und intern kommuniziert werden. Ein etabliertes Änderungsmanagement stellt sicher, dass
weder Überraschungen im Tagesgeschäft noch Reibungsverluste zwischen Fachbereichen
und Technik auftreten. Nur wenn alle Stakeholder den Überblick behalten, kann eine
Microservices-Transformation mitsamt Cloud-Migration reibungslos gelingen.

‍
Fazit

‍
Obwohl die parallele Transformation von Monolith zu Microservices und die Migration in die
Cloud sehr aufwendig wirkt, ist sie langfristig die konsequenteste Methode, um Komplexität
zu entwirren und eine robuste, skalierbare Infrastruktur zu schaffen. Natürlich entstehen
durch den Betrieb einer separaten Test- und Pre-Production-Umgebung zunächst höhere
Kosten und mehr Ressourcenbedarf. Doch gerade diese strukturierten Vorstufen verhindern
ein Chaos, in dem eine übereilte Umstellung womöglich zeit- und kostenintensive
Rückschläge auslösen würde. Wer auf Sicherheit und Praxis setzt, indem er Stück für Stück
lernt und Anpassungen vornimmt, findet Gefallen an dieser methodischen
Herangehensweise. So lässt sich mit hoher Wahrscheinlichkeit vermeiden, dass eine
Transformation in einen unkontrollierten Umbau mündet, der Geld und Zeit verschlingt.
Letztlich gewinnen alle Beteiligten durch die gewonnene Klarheit und können das Projekt
fokussiert zu Ende führen, ohne sich in endlosen Nacharbeiten zu verlieren. Schritt für
Schritt lässt sich so eine neue IT-Landschaft erschaffen, die das Unternehmen
zukunftssicher aufstellt.

‍
Sie planen, Ihre IT-Landschaft von Grund auf zu modernisieren und möchten sicherstellen,
dass der Wechsel zu Microservices und in die Cloud reibungslos gelingt? Ich unterstütze Sie
gerne dabei, ein passendes Zielarchitekturbild zu entwerfen, die Lasten- und Pflichtenhefte
auszuarbeiten und Entwicklungskonzepte zu erstellen. Als Product Owner überführe ich
diese Konzepte in konkrete User Storys, manage die Entwicklung und Tests sowie die

Business-Analyse und kümmere mich um das Defect-Management von der Testphase bis
hin zum Fachbereich. So können wir gemeinsam sicherstellen, dass Ihr Go-Live möglichst
problemlos und erfolgreich verläuft. Nehmen Sie jetzt Kontakt auf, um Ihre Transformation
ins Rollen zu bringen.

‍