Die unbequeme Wahrheit: Die meisten Migrationen scheitern nicht an Technologie, sondern an Komplexität.

Wenn über Cloud-Migrationen gesprochen wird, dominieren oft technologische Schlagworte die Diskussion: Microservices, Kubernetes, PostgreSQL, AWS oder FinOps. Doch die eigentliche Herausforderung liegt selten in der Einführung neuer Technologien. Sie liegt darin, geschäftskritische Systeme zu modernisieren, ohne dabei die Stabilität eines laufenden Unternehmens zu gefährden.

Genau dort trennt sich Infrastrukturmodernisierung von echter Transformation.

Ein besonders eindrucksvolles Beispiel liefert die Modernisierung einer zentralen Unternehmensplattform, die über Jahre auf einer monolithischen Oracle-Architektur gewachsen war. Das System unterstützte rund 100 weltweit verteilte Redakteurinnen und Redakteure und war gleichzeitig mit etwa 20 internen und externen Schnittstellenpartnern verbunden. Eine Plattform, deren Ausfall unmittelbare Auswirkungen auf operative Geschäftsprozesse gehabt hätte. Ziel war daher nicht einfach die Verlagerung von Workloads in die AWS-Cloud. Die eigentliche Ambition bestand darin, die technologische Grundlage des Systems grundlegend neu auszurichten und gleichzeitig den laufenden Betrieb vollständig aufrechtzuerhalten.

Transformation unter Volllast: Warum die schwierigsten Projekte niemals auf der grünen Wiese entstehen

Was solche Vorhaben anspruchsvoll macht: Die technische Ausgangslage bleibt während des Projekts selten stabil. Während die neue Plattform entstand, wurde die bestehende Anwendung weiterhin aktiv weiterentwickelt. Das Projektteam musste daher nicht nur migrieren, sondern parallel neue Anforderungen auf der Altplattform umsetzen. Diese Situation findet sich in vielen Transformationsprogrammen wieder und wird dennoch häufig unterschätzt. Die größte Komplexität entsteht oft nicht durch die Zielarchitektur, sondern durch den Umstand, dass Vergangenheit und Zukunft über Monate parallel betrieben und entwickelt werden müssen.

Der Monolith war nie das Problem – fehlende Entkopplung schon

Vor diesem Hintergrund wurde die bestehende monolithische Anwendung schrittweise in eine moderne Service-Landschaft überführt. Rund 70 Java-basierte Services wurden identifiziert, extrahiert oder neu zugeschnitten und für den Betrieb in einer Kubernetes-basierten Umgebung vorbereitet. Dabei ging es nicht um die mechanische Zerlegung eines Monolithen. Der eigentliche Wert entstand durch die Neudefinition von Verantwortlichkeiten, die Entkopplung fachlicher Domänen und die Schaffung klarer Betriebsgrenzen.

Microservices sind kein Selbstzweck. Sie entfalten ihren Nutzen erst dann, wenn sie organisatorische und fachliche Komplexität reduzieren, anstatt sie lediglich zu verteilen. Zu viele Modernisierungsprogramme verwechseln technische Modularisierung mit echter Architekturarbeit. Das Ergebnis sind dann verteilte Monolithen statt moderner Plattformen. Der entscheidende Erfolgsfaktor liegt daher nicht in der Anzahl der Services, sondern in der Qualität ihrer fachlichen Schnitte.

Daten sind der eigentliche Mount Everest jeder Cloud-Migration

Noch deutlicher zeigt sich die wahre Dimension solcher Transformationsprogramme beim Thema Daten. Viele Unternehmen investieren enorme Energie in die Modernisierung ihrer Applikationslandschaft und behandeln die Datenmigration als technischen Nebenaspekt. In der Praxis verhält es sich häufig genau umgekehrt. Die kritische Erfolgsgröße liegt in der Datenebene.

In diesem Projekt mussten mehr als 700 Tabellen mit rund 100 Millionen Datensätzen vollständig und verlustfrei von Oracle nach PostgreSQL migriert werden. Hinzu kam ein komplexes Domänenmodell mit zahlreichen Abhängigkeiten und Join-Konstruktionen über mehr als zehn Tabellen hinweg. Eine solche Migration ist keine technische Routineaufgabe. Sie erfordert tiefes Prozessverständnis, detailliertes Wissen über Geschäftsregeln und eine präzise Validierung jeder einzelnen Datenbewegung. AWS DMS unterstützte die eigentliche Übertragung, gleichzeitig wurden jedoch zusätzliche Validierungswerkzeuge entwickelt, um die Datenqualität jederzeit nachweisen zu können. Parallel dazu erfolgte die Migration von rund einer Million Dateien von einem NAS-System nach Amazon S3.

Oracle verlassen heißt nicht einfach PostgreSQL einführen

Besonders anspruchsvoll wurde die Transformation durch die Unterschiede zwischen Oracle und PostgreSQL. Datenbankprozeduren, Trigger und Funktionen mussten vollständig auf die PostgreSQL-Semantik übertragen werden. Entscheidend war dabei nicht die Syntaxübersetzung, sondern das veränderte Transaktionsverhalten. Während Oracle in bestimmten Szenarien toleranter agiert, erzwingt PostgreSQL konsequent Atomicität.

Genau dieser Unterschied machte ein umfassendes Redesign zahlreicher Queries und Batch-Prozesse notwendig. Die eigentliche Modernisierung fand nicht auf Infrastruktur-, sondern auf Logik- und Datenebene statt. Gleichzeitig zeigte sich ein weiterer Aspekt, der in vielen Cloud-Programmen unterschätzt wird: Nicht jede Funktion arbeitet nach einer Migration automatisch mit identischer Performance weiter. Da Oracle in bestimmten Bereichen performanter war, mussten SQL-Statements refaktoriert, Indizes optimiert und umfangreiche Performance-Tests durchgeführt werden. Genau an diesem Punkt scheitern viele vermeintlich einfache Datenbankmigrationen.

Unsichtbar, aber geschäftskritisch: Warum ETL-Prozesse über Erfolg oder Scheitern entscheiden

Ein ähnlich unterschätzter Bereich sind ETL- und Integrationslandschaften. Sie bilden in vielen Unternehmen das operative Nervensystem zwischen Fachprozessen und Datenplattformen. Solange sie funktionieren, werden sie kaum wahrgenommen. Sobald sie ausfallen, kommt jedoch häufig die gesamte Prozesskette ins Stocken.

Rund zehn Informatica-Workflows mit mehr als 400 Mappings mussten an die neue Datenbankstruktur und das veränderte Transaktionsmodell angepasst werden. Solche Anpassungen wirken von außen oft unspektakulär, entscheiden aber maßgeblich darüber, ob Geschäftsprozesse nach einer Transformation weiterhin zuverlässig funktionieren. Die Modernisierung einer Plattform endet nicht an den Systemgrenzen der Kernanwendung. Sie umfasst sämtliche Datenströme, Integrationen und Betriebsprozesse, die über Jahre entstanden sind. Wer diese Abhängigkeiten unterschätzt, unterschätzt das eigentliche Projekt.

Der Mut zum Big Bang: Warum risikoarm manchmal riskanter ist

Bemerkenswert ist auch die gewählte Migrationsstrategie. Während viele Organisationen versuchen, Risiken durch lange Parallelbetriebsphasen zu minimieren, entstehen dadurch häufig neue Risiken: doppelte Komplexität, steigende Kosten und dauerhaft fragmentierte Architekturlandschaften.

In diesem Fall fiel die Entscheidung bewusst für einen Big-Bang-Go-Live. Ein solcher Ansatz gilt heute fast schon als unmodern. Tatsächlich ist er jedoch keineswegs per Definition risikoreicher als eine schrittweise Migration. Voraussetzung ist eine außergewöhnlich hohe Vorbereitungsqualität. Der Rollout- und Rollback-Plan wurde mehrfach getestet. Sämtliche 20 Schnittstellenpartner wurden eng eingebunden. Delta-Replikationen, Abschaltung der Altsysteme, Aktivierung der Zielplattform und umfangreiche Funktionstests wurden minutiös vorbereitet. Das Ergebnis war eine Umschaltung ohne spürbare Unterbrechung des Geschäftsbetriebs. Noch wichtiger: Das vorbereitete Rollback musste nie aktiviert werden.

Der wahre Go-Live beginnt erst nach dem Go-Live

Der eigentliche Erfolg einer Transformation zeigt sich nicht am Go-Live-Wochenende, sondern in den Wochen danach. Erst dann wird sichtbar, ob Architekturentscheidungen tragfähig waren, Daten korrekt migriert wurden und Betriebsprozesse tatsächlich funktionieren.

Deshalb verdient die Hypercare-Phase besondere Aufmerksamkeit. Über einen Monat hinweg wurden Performance, Transaktionsverhalten und Betriebsprozesse intensiv überwacht. Die Unterschiede zwischen Oracle und PostgreSQL machten gezielte Optimierungen erforderlich. Durch konsequente Analyse und Anpassung gelang es, die Performance der modernisierten Plattform auf dem Niveau der Vorgängerumgebung zu halten, obwohl die technische Grundlage vollständig verändert worden war. Gleichzeitig wurde die Betriebsdokumentation an die neue Architektur angepasst und damit die Grundlage für einen langfristig stabilen Betrieb geschaffen. Hypercare war damit nicht nur eine Unterstützungsphase, sondern ein wesentlicher Bestandteil des Transformationsprogramms.

FinOps ist kein Kostenreporting – sondern Architekturdisziplin

Ebenso interessant ist die Rolle von FinOps. In vielen Cloud-Projekten wird Kostenoptimierung erst diskutiert, wenn die erste unerwartet hohe Rechnung eintrifft. Erfolgreiche Transformationen integrieren wirtschaftliche Überlegungen dagegen von Beginn an in die Architektur.

Die Ausgestaltung von S3-Speicherklassen, die Dimensionierung von RDS-Instanzen, Kubernetes-Scaling und Monitoring wurden von Anfang an unter Kosten- und Effizienzgesichtspunkten geplant. Cloud-Native bedeutet nicht automatisch wirtschaftlich. Erst die Verbindung aus technischer Skalierbarkeit und finanzieller Transparenz schafft nachhaltigen Mehrwert. FinOps ist deshalb keine nachgelagerte Controlling-Aufgabe, sondern eine Architekturkompetenz. Wer Skalierbarkeit plant, muss gleichzeitig Wirtschaftlichkeit gestalten.

Die wichtigste Erkenntnis: Migration bewegt Systeme, Transformation verändert Unternehmen

Die zentrale Erkenntnis aus diesem Transformationsprogramm lautet: Erfolgreiche Cloud-Modernisierung ist keine Infrastrukturinitiative. Sie ist ein Zusammenspiel aus Architektur, Daten, Organisation, Betriebsmodell und Wirtschaftlichkeit. Wer lediglich Systeme verschiebt, erhält am Ende eine modernisierte Altlast. Wer jedoch die Datenbasis erneuert, Integrationen konsequent modernisiert, Betriebsprozesse hinterfragt und organisatorische Komplexität reduziert, schafft eine Plattform, die den Anforderungen der kommenden Jahre tatsächlich gewachsen ist. Die eigentliche Herausforderung einer Transformation besteht nicht darin, neue Technologien einzuführen. Sie besteht darin, bestehende Komplexität kontrolliert in eine zukunftsfähige Struktur zu überführen.

Fazit: Erfolgreich war nicht die Technologie – sondern wie das Team umgegangen ist mit der Komplexität

Die Migration von einem Oracle-Monolithen zu einer AWS-basierten Microservices-Plattform mit PostgreSQL, rund 70 Services, über 700 migrierten Tabellen, 100 Millionen Datensätzen, einer Million migrierter Dateien und mehr als 400 angepassten ETL-Mappings zeigt eindrucksvoll, dass selbst hochkomplexe Unternehmenssysteme erfolgreich transformiert werden können. Die Umsetzung erfolgte durch ein Team von 15 Expertinnen und Experten innerhalb von zehn Monaten bei gleichzeitig laufender Weiterentwicklung des Bestandssystems.

Entscheidend war dabei nicht die Technologie allein. Entscheidend war die Fähigkeit, technische, organisatorische und fachliche Komplexität gleichzeitig zu beherrschen. Die verlustfreie Datenmigration, die Anpassung der ETL-Landschaft, die sorgfältig geplante Big-Bang-Umstellung, ein belastbarer Rollback-Ansatz, eine konsequente Hypercare-Phase und die frühe Integration von FinOps-Prinzipien waren keine Nebenthemen. Sie waren die eigentlichen Erfolgsfaktoren.

Genau das macht den Unterschied zwischen einer Migration und echter Transformation.