Eine Cloud-Migration umfasst drei voneinander abhängige Ebenen: Infrastruktur, Softwarearchitektur und Organisation. Technisch beginnt sie meist mit Lift and Shift, also dem unveränderten Verlagern einer Anwendung in die Cloud, gefolgt von schrittweisem Refactoring vom Monolith zu Microservices entlang fachlicher Domänenschnitte. Ohne automatisierte CI/CD-Pipelines, Resilienz-Tests und organisatorische Veränderungen scheitert die Migration.
Das Wichtigste in Kürze
- Greenfield-Neuimplementierungen scheitern regelmäßig: Teams, die parallel zum Monolithen ein neues System entwickeln, brechen solche Projekte nach etwa zwei Jahren meist ab.
- Vor jeder Migrationsarbeit muss eine funktionierende CI/CD-Pipeline stehen, nicht danach, denn ohne Automatisierung ist ein System mit vielen Microservices und Datenbanken schlicht nicht wartbar.
- Cloud-Migration verändert Berufsbilder konkret: DBAs verlieren Aufgaben, wenn Oracle durch einen Managed-Service ersetzt wird, und Entwickler, die nur Jar-Dateien liefern, müssen ihren Verantwortungsbereich ausweiten.
- Resilienz-Tests fehlen in klassischen Testsuiten, weil Container-Ausfälle, erhöhte Latenzen und kurze Nichtverfügbarkeiten bei On-Premise-Systemen kaum auftraten, in der Cloud aber zum Normalbetrieb gehören.
Warum Unternehmen in die Cloud gehen
Drei Motive treiben die meisten Cloud-Migrationen: Kostenhoffnung, Flexibilität und der Druck, weil es alle tun. Die ersten beiden sind handfest, das dritte ist ein Hype-Effekt, der seine eigene Dynamik entwickelt.
Bei den Kosten erwarten viele, dass eigene Infrastruktur und das dazugehörige Personal wegfallen. Die Rechnung sieht auf dem Papier gut aus. In der Praxis stellt sich das Bild oft anders dar, weil neue Komplexität an anderer Stelle entsteht.
Flexibilität ist das stärkere Argument. Die großen Hyperscaler betreiben Rechenzentren über den ganzen Planeten. Wer Kunden in Australien ansprechen will, kann das nicht sinnvoll von der Schweiz oder Deutschland aus tun. Diese geografische Reichweite hat kaum eine einzelne Firma in eigener Hand.
Eine VM in der Cloud ist nur ein Rechner, der woanders steht
Technisch betrachtet ist eine virtuelle Maschine in der Cloud zunächst genau das: ein Rechner an einem anderen Ort. Diese nüchterne Sicht hilft, eine verbreitete Illusion zu zerstören, nämlich dass die Cloud die alten Probleme automatisch löst.
Beim Wechsel kommen Probleme zum Vorschein, die lokal schon immer da waren. Security, Zugriffsschutz, Update-Zyklen. Plötzlich wird die Frage relevant, wie oft eine VM gebootet wird oder wie die Day-Two-Operations bei einem Datenbanksystem oder Kubernetes-Cluster aussehen.
Diese Fragen gab es on-premise genauso. Linux-Systeme mussten auch vorher alle zwei Wochen aktualisiert werden. Die Cloud macht diese Pflichten nur sichtbar, weil sie sich nicht mehr im eigenen Rechenzentrum verstecken lassen. Genau das macht eine Migration schwierig, zusammen mit den kulturellen Themen.
Drei Baustellen: Infrastruktur, Architektur, Organisation
Jede Cloud-Migration zerfällt in drei Bereiche, und nur einer davon ist rein technisch.
- Infrastruktur: Der Weg von lokaler zu Cloud-Infrastruktur. Cloud-Anbieter stellen eine API bereit, mit der sich das relativ schnell aufsetzen lässt. Die Managed Services dahinter bringen aber eine eigene Komplexität mit, die das gesamte Vorgehen schwerer macht.
- Architektur: Lang gewachsene Monolithen sind oft schlecht gebaut. Was viele übersehen: Auch ein Monolith kann eine Architektur haben, etwa über saubere Java-Packages. Die Aufgabe besteht darin, solche Monolithen sinnvoll zu zerteilen.
- Organisation: Rund um On-Premise-Datenbanken sind über Jahre Organisationseinheiten entstanden, die nicht mehr zur neuen Welt passen. Hier geht es um Eigenverantwortung und agile Arbeitsweisen.
Wo die Hauptprobleme liegen, ist von Firma zu Firma verschieden. Banken und Versicherungen tragen besonders langlebige Systeme und ebenso langlebige Organisationen mit sich. An der schwächsten Stelle setzt man an.
Wie eine Migration schrittweise abläuft
Der sinnvolle Einstieg heißt Lift and Shift: Du nimmst die bestehende Anwendung, kontainerisierst sie eventuell und startest sie zunächst in einer Cloud-VM. Dieser erste Schritt dient vor allem dazu, Erfahrungen zu sammeln.
Darauf bauen weitere Stufen auf. Beim Re-Hosting wandert der Monolith in die Cloud, was bereits eine angelegte CI/CD-Pipeline voraussetzt. Beim Re-Platforming kommt das Ding in einen Kubernetes-Cluster, und Logging sowie Monitoring laufen über die Dienste des Cloud-Anbieters.
Erst danach folgt das Refactoring. Das ist die eigentliche Architekturfrage, bei der die Struktur verbessert wird, falls man das will. Es gibt durchaus Gründe, diesen letzten Schritt nicht zu gehen.
Vom Monolith zu Microservices: Greenfield scheitert, schrittweises Schneiden trägt
Der Versuch, einen Monolithen mit einem separaten Greenfield-Team komplett neu zu bauen, geht in der Praxis schief. Das Muster ist bekannt: Drei Teams pflegen den Monolithen, ein viertes soll ihn mit sauberen Schnitten neu implementieren. Nach etwa zwei Jahren werden solche Projekte normalerweise abgebrochen.
Der tragfähige Weg führt über den bestehenden Monolithen. Du arbeitest die fachlichen Domänen schrittweise heraus, über mehrere Iterationen verteilt, nicht in einem einzigen Sprint.
Sobald die Interaktionen zwischen den Domänen gering sind, saubere Interfaces stehen und das Datenbankschema getrennt ist, lässt sich eine Domäne herausschneiden und in einen eigenen Container verpacken. Der Schnitt ist fachlich, nicht technisch. Das ist das Grundprinzip von Microservices.
Ein Beispiel aus dem Bankenumfeld ist das Onboarding. Ein Kunde kommt herein, seine Daten werden aufgenommen, erste Produkte werden je nach Investitionssumme und Risikobereitschaft angeboten. Dieser Onboarding-Prozess bildet eine in sich geschlossene Domäne, mit der man anfangen kann.
Die Datenbank ist die härteste Baustelle
Viele Firmen betreiben eine große Oracle-Plattform, und davor sitzen DBAs, die Architekturänderungen oft verhindern. Dieses Thema ist gleichzeitig technisch und organisatorisch.
Eine Oracle-Datenbank lässt sich technisch vielleicht zu einem großen Hyperscaler portieren, aber meist will man das nicht. Genau hier liegt eine der größten Aufgaben jeder Migration.
Eine Datenmigration von einem Datenbanksystem in ein anderes muss sicherstellen, dass die Daten danach noch dieselben sind. Das beginnt bei Zeichensätzen und Feldlängen und reicht weiter. Beim Umstieg von einem alten System auf PostgreSQL wird mit Sicherheit einiges passieren, das auffallen muss, bevor es produktiv wird.
Ohne CI/CD-Pipeline ist ein Microservice-System nicht wartbar
Bevor du irgendetwas migrierst, legst du eine Continuous-Delivery-Pipeline an. Das ist der erste Schritt beim Gang in die Cloud, nicht der letzte.
Ein System aus 40 oder 50 Microservices mit Replikas und darunterliegenden Datenbanken ist ohne Tests und CI/CD-Pipeline gar nicht mehr wartbar. Die Automatisierung muss von Anfang an eingebaut sein.
Wenn man so einen Microservice macht, baut man immer zuerst die CI/CD-Pipeline ein und fängt dann erst an, den Code zu schreiben. Christopher Schmidt
Zur Pipeline gehören Unit-Tests, Komponententests und sauber durchgetestete Microservices. Genau hier tauchen die Fehler auf, die bei einer Datenmigration garantiert kommen. Und auch die Pipeline selbst muss einem Prozess unterliegen. Wer sich vorher kein klares Vorgehen überlegt hat, baut etwas, das ständig wegbricht.
Migration verändert Menschen, nicht nur Maschinen
Eine Cloud-Migration lässt sich nicht als U-Boot-Projekt durchziehen. Wenn ein einzelnes Team beschließt, die lokale IT sei zu langsam, und still in die Cloud wechselt, hält das nicht lange. Wegen der organisatorischen Folgen muss die Geschäftsleitung solche Vorhaben mittragen.
Die klassische Silostruktur passt schlecht in die neue Welt. Ein Infrastruktur-Team, ein Ops-Team, Entwickler, die weder Basis-Images kennen noch Deployment-Manifeste schreiben, weil das Ops übernimmt. Diese Trennung soll aufgelöst werden, und das geht nur über Zielvereinbarungen und Incentives, die man anpasst. Das braucht Zeit.
Konkrete Rollen verändern sich. DBAs sind heute für die Query-Performance verantwortlich und optimieren Abfragen direkt im Datenbanksystem. Mit dem Wechsel auf einen Managed Service wie RDS von AWS sind sie in diesem Maße nicht mehr nötig. Auch Entwickler, deren Selbstverständnis bei “mein Artefakt ist ein Jar, alles andere interessiert mich nicht” endet, müssen sich bewegen.
Gleichzeitig kann in einem komplexen Umfeld nicht jeder alles wissen. Kernkompetenzen müssen in den Teams an einzelnen Stellen verbleiben. Der Anspruch, dass jeder Vollzugriff auf alles Wissen hat, funktioniert nicht.
Resilienz-Tests gehören in jede Cloud-Pipeline
Mit der Cloud kommt eine Testkategorie hinzu, die der klassische Funktionstest nicht abdeckt: Resilienz gegen Latenz und Ausfälle. Funktions-, Unit- und Komponententests hattest du vorher wahrscheinlich schon. Das reicht jetzt nicht mehr.
In einem Cluster sind Container zeitweise nicht da, etwa weil ein Knoten neu gebootet oder gestorben ist. Eine API fällt kurz aus, Latenzen steigen an. Aus einem Monolithen werden eigene Prozesse, verteilt über unterschiedliche Maschinen und teils unterschiedliche Rechenzentren. Damit entstehen Latenzen und Fehlersituationen, die es vorher so nicht gab.
Besonders im Hybrid-Cloud-Szenario wird das spürbar. Liegt ein Teil der Anwendung in der Cloud, während Service- oder Datenbanksysteme on-premise bleiben, läuft die Verbindung über VPNs oder SSL. Die Latenz springt dann etwa von zehn auf hundert Millisekunden. Oft reicht das schon, damit Thread-Pools überlaufen.
Solche Resilienz-Tests gehören in die CI/CD-Pipeline. Wer sie weglässt, wundert sich später, warum Teile der neuen Software regelmäßig abstürzen. Etwas Ähnliches gab es im eigenen Rechenzentrum vielleicht auch, nur hat man es ignoriert oder es kam seltener vor.
Wartungsfenster oder schnelle Reaktion
Managed Services lassen Update-Szenarien in Wartungsfenster verpacken, etwa auf Samstag oder Sonntag. Das klingt bequem, hat aber einen Preis, den du bewusst abwägen musst.
Legst du das Fenster ans Wochenende, kann eine Vulnerability bis dahin online bleiben. Gefixte Sicherheitslücken stehen in den Release Notes, und wer einbrechen will, prüft genau die bekannten Java- oder Linux-Standardprobleme darauf, ob ein System noch verwundbar ist.
Die Empfehlung ist klar: ohne Wartungsfenster arbeiten und schnell deployen. Eine Anwendung, die mit kurzen Ausfällen und höheren Latenzen umgehen kann, braucht das geplante Fenster ohnehin nicht im selben Maß. Damit verschiebt sich die Frage zurück zur Resilienz der Architektur.
Häufig gestellte Fragen
Sparen Unternehmen durch eine Cloud-Migration wirklich Geld?
Nicht zwangsläufig. Drei Motive treiben die meisten Migrationen: Kostenhoffnung, Flexibilität und der Druck, weil es alle tun. Die Kostenrechnung sieht auf dem Papier gut aus, weil eigene Infrastruktur und das dazugehörige Personal wegfallen sollen. In der Praxis entsteht an anderer Stelle neue Komplexität. Das handfestere Argument ist die geografische Reichweite der Hyperscaler: Kunden in Australien lassen sich von Deutschland aus kaum sinnvoll bedienen.
Löst der Umzug in die Cloud bestehende Betriebsprobleme automatisch?
Nein. Eine virtuelle Maschine in der Cloud ist zunächst nur ein Rechner, der woanders steht. Security, Zugriffsschutz und Update-Zyklen bleiben bestehen, sie werden lediglich sichtbar. Plötzlich zählt, wie oft eine VM gebootet wird und wie die Day-Two-Operations für Datenbank oder Kubernetes-Cluster aussehen. Linux-Systeme mussten auch vorher alle zwei Wochen aktualisiert werden, nur ließ sich das im eigenen Rechenzentrum verstecken.
Woran erkennt man, dass sich eine Domäne aus einem Monolithen herausschneiden lässt?
Drei Bedingungen müssen zusammenkommen: geringe Interaktionen zwischen den Domänen, saubere Interfaces und ein getrenntes Datenbankschema. Erst dann lohnt es sich, die Domäne in einen eigenen Container zu verpacken. Der Schnitt erfolgt fachlich, nicht technisch. Ein gutes Einstiegsbeispiel aus dem Bankenumfeld ist das Onboarding: Kundendaten aufnehmen, erste Produkte nach Investitionssumme und Risikobereitschaft anbieten.
Muss die CI/CD-Pipeline vor der eigentlichen Migration stehen?
Ja. Die Continuous-Delivery-Pipeline ist der erste Schritt, nicht der letzte. Ein System aus 40 oder 50 Microservices mit Replikas und darunterliegenden Datenbanken ist ohne Tests und Automatisierung nicht mehr wartbar. Zur Pipeline gehören Unit-Tests, Komponententests und durchgetestete Services. Auch die Pipeline selbst braucht ein festes Vorgehen, sonst bricht das Konstrukt ständig weg.
Warum ist die Datenbank bei einer Migration die härteste Baustelle?
Weil das Thema technisch und organisatorisch zugleich ist. Um große Oracle-Plattformen sind über Jahre Organisationseinheiten gewachsen, und DBAs verhindern Architekturänderungen häufig. Technisch ließe sich eine Oracle-Datenbank portieren, meist will man das aber nicht. Eine Datenmigration muss sicherstellen, dass die Daten danach dieselben sind: Zeichensätze und Feldlängen sind nur der Anfang. Beim Umstieg auf PostgreSQL fällt garantiert etwas auf.
Warum reichen Funktions- und Unit-Tests für Cloud-Anwendungen nicht mehr aus?
Sie decken Resilienz gegen Latenz und Ausfälle nicht ab. In einem Cluster sind Container zeitweise nicht da, weil ein Knoten neu bootet oder gestorben ist, APIs fallen kurz aus. Im Hybrid-Szenario mit VPN oder SSL springt die Latenz von etwa zehn auf hundert Millisekunden, und schon das lässt Thread-Pools überlaufen. Solche Tests gehören in die Pipeline.
Kann ein einzelnes Team eine Cloud-Migration im Alleingang starten?
Als U-Boot-Projekt hält das nicht lange. Wegen der organisatorischen Folgen muss die Geschäftsleitung das Vorhaben mittragen. Die klassische Silostruktur aus Infrastruktur-Team, Ops-Team und Entwicklern, die weder Basis-Images kennen noch Deployment-Manifeste schreiben, passt nicht in die neue Welt. Aufgelöst wird sie nur über angepasste Zielvereinbarungen und Incentives, und das braucht Zeit.
Sind Wartungsfenster am Wochenende eine gute Lösung für Updates?
Sie haben einen Preis: Eine bekannte Vulnerability bleibt bis zum Fenster online. Gefixte Sicherheitslücken stehen in den Release Notes, und Angreifer prüfen genau diese bekannten Java- oder Linux-Standardprobleme durch. Sinnvoller ist es, ohne Wartungsfenster zu arbeiten und schnell zu deployen. Eine Anwendung, die kurze Ausfälle und höhere Latenzen verkraftet, braucht das geplante Fenster ohnehin kaum noch.
