Blog

Cloud-Migration ist weit mehr als ein technischer Wechsel. Im Interview erklärt Anja Kammer, warum Strategie, Organisation und Architektur zusammengedacht werden müssen – und wie eine erfolgreiche Migration in der Praxis gelingt.

Cloud-Migration wird oft als rein technisches Thema betrachtet – du betonst aber auch Organisation und Architektur. Warum ist es so wichtig, diese Aspekte gemeinsam zu denken?

Weil eine Cloud-Migration eben nicht nur ein Technologiewechsel ist. Natürlich spielen Themen wie Cloud-Plattformen, Container oder Orchestrierung eine wichtige Rolle. Aber damit allein ist noch keine erfolgreiche Migration geschafft. Entscheidend ist auch, ob die Architektur zur neuen Betriebsumgebung passt und ob die Organisation in der Lage ist, mit dieser Veränderung umzugehen.

Cloud-Umgebungen sind dynamisch, verteilt und in vieler Hinsicht deutlich volatiler als klassische Infrastrukturen. Dafür braucht es Architekturen, die auf Resilienz, Skalierbarkeit und Entkopplung ausgelegt sind. Wenn ich nur bestehende Strukturen in eine neue technische Umgebung hebe, ohne diese Fragen zu berücksichtigen, nehme ich viele alte Probleme einfach mit.

Genauso wichtig ist die organisatorische Seite. Migrationen scheitern in der Praxis nicht selten weniger an der Technologie als an fehlenden Zuständigkeiten, an unklaren Prozessen oder daran, dass die nötige Cloud-Native-Kultur nicht entsteht. Neue Technologien bringen neue Anforderungen an Teams, Verantwortlichkeiten und Zusammenarbeit mit sich. Dazu kommen Themen wie Training, Compliance, Datenschutz oder auch veränderte Machtverhältnisse zwischen Rollen und Abteilungen.

Deshalb sollte man Cloud-Migration als sozio-technisches Veränderungsvorhaben verstehen. Technik, Architektur und Organisation greifen hier unmittelbar ineinander –und nur wenn diese drei Ebenen zusammen gedacht werden, kann Migration nachhaltig funktionieren.

Viele Unternehmen starten eine Cloud-Migration, ohne eine klare Strategie zu haben. Was sind aus deiner Sicht die wichtigsten Elemente einer guten Planungsphase?

Eine gute Planungsphase beginnt aus meiner Sicht immer damit, die Ausgangslage wirklich zu verstehen. Das klingt banal, wird aber in der Praxis oft unterschätzt. Man sollte nicht nur auf das Gesamtsystem schauen, sondern möglichst jede Anwendung, jedes Modul und jede relevante Komponente einzeln betrachten. Dabei ist zum Beispiel die Frage wichtig, ob sensible Daten verarbeitet werden und welche regulatorischen Anforderungen daraus folgen.

Dabei geht es darum, Transparenz zu schaffen: Welche Anwendungen gibt es überhaupt, welche Datenbanken, welche Infrastruktur, welche Schnittstellen und welche Abhängigkeiten? Ebenso wichtig sind Anforderungen an Performance, Sicherheit und Compliance. Am Ende sollte ein möglichst belastbares Bild des Systems stehen.

Danach muss die Migration in den größeren Kontext eingeordnet werden. Eine Cloud-Strategie entsteht nicht im luftleeren Raum, sondern hängt von der allgemeinen IT-Strategie und den Unternehmenszielen ab. Vielleicht gibt es bereits technologische Leitplanken, etwa die Ablösung bestimmter Produkte oder Plattformen. Entsprechend sollten auch die richtigen Rollen eingebunden sein – von IT und Betrieb über Architektur und Projektmanagement bis hin zu Fachbereichen, Compliance oder Finance.

Erst auf dieser Basis lassen sich Anwendungen sinnvoll bewerten und priorisieren: nach Kosten, Nutzen, Risiko und Komplexität. Daraus ergeben sich dann Pilotkandidaten und eine sinnvolle Reihenfolge. Anschließend kann für jede Anwendung oder Komponente ein passender Migrationspfad festgelegt werden. Das Ergebnis ist im Idealfall kein scheinpräziser Masterplan, sondern ein realistischer Überblick über Phasen, Meilensteine und Abhängigkeiten.

Du sprichst von Themen wie Risiken, Voraussetzungen und Migrationswellen. Wie gelingt es in der Praxis, daraus einen wirklich belastbaren Migrationsplan zu entwickeln?

In der Praxis hat es sich bewährt, nicht mit einem Big Bang zu starten, sondern zunächst nur wenige Pilotkomponenten auszuwählen. Für diese Komponenten kann man genauer herausarbeiten, welche Schritte notwendig sind, welche Risiken bestehen und welche Voraussetzungen zuerst erfüllt sein müssen. Wichtig ist dabei auch, die Auswahl nachvollziehbar zu machen und die Argumente zu dokumentieren.

Für einzelne Komponenten sollte man dann die wesentlichen Phasen und Tätigkeiten skizzieren. Das muss am Anfang nicht bis ins letzte Detail ausdefiniert sein. Aber kritische Meilensteine, Abhängigkeiten und mögliche Blocker müssen sichtbar werden. Gerade Abhängigkeiten sind oft harte Planungsfaktoren. Wenn zum Beispiel eine Datenbankmigration vorgesehen ist, kann das bedeuten, dass bestimmte technische Altlasten vorher aufgelöst werden müssen.

Außerdem hilft ein schrittweises Vorgehen, Risiken zu begrenzen. Wenn eine umfassende Modernisierung zu aufwendig oder zu kontrovers ist, kann zunächst ein Replatforming (nach den 6 R’s) oder ein anderer Zwischenschritt sinnvoll sein, bevor ein größerer Umbau gemacht wird. Solche gestuften Wege machen einen Plan oft realistischer. Aus den Einzelplänen entsteht dann nach und nach eine Roadmap mit Migrationswellen, in der sich Abhängigkeiten, kritische Meilensteine und zeitliche Prioritäten besser einordnen lassen.

Die „6 R’s“ sind ein bekanntes Modell für Cloud-Migrationen. Wie können Teams dieses Konzept sinnvoll einsetzen, ohne es nur schematisch anzuwenden?

Die 6 R’s sind aus meiner Sicht vor allem ein guter Strukturierungsrahmen. Sie helfen Teams dabei, mögliche Migrationsoptionen systematisch zu betrachten und die Diskussion zu strukturieren. Problematisch wird es dann, wenn man das Modell wie ein starres Schema behandelt.

Wichtig ist vor allem, nicht für ein komplettes System pauschal eine einzige Strategie festzulegen. In der Praxis ist es fast immer sinnvoller, pro Anwendung oder sogar pro Komponente zu entscheiden. Unterschiedliche Teile eines Systems haben oft sehr unterschiedliche Anforderungen, Risiken und Potenziale.

Die 6 R’s liefern also nicht die Antwort selbst, sondern eher die richtigen Kategorien, um die passende Antwort zu entwickeln. Entscheidend ist die Begründung: Welche Ziele verfolgen wir, welche Randbedingungen gelten, welche Risiken akzeptieren wir, und wo lohnt sich welcher Aufwand? Genau an dieser Stelle wird das Modell wertvoll, weil es Trade-offs sichtbar macht – etwa zwischen Geschwindigkeit und Perfektion oder zwischen kurzfristiger Entlastung und langfristiger Modernisierung.

Wenn ein Unternehmen heute vor der Entscheidung steht, bestehende Systeme zu optimieren, neu zu entwickeln oder komplett zu ersetzen: Welche Faktoren sollten dabei besonders berücksichtigt werden?

Am Anfang sollte immer die Frage stehen, welches Ziel eigentlich verfolgt wird. Geht es um mehr Flexibilität, um Internationalisierung, um Automatisierung, um schnellere Bereitstellung neuer Funktionen oder um den Ersatz auslaufender Technologien? Ohne dieses Zielbild bleibt die Diskussion über Optimierung, Neuentwicklung oder Austausch schnell zu abstrakt.

Daneben gibt es oft harte Rahmenbedingungen, die die Entscheidung stark beeinflussen. Das können regulatorische Vorgaben sein, Anforderungen an Datenresidenz, vertragliche Fristen oder strategische technologische Vorgaben. Auch die wirtschaftliche Perspektive ist zentral: Welche Kosten entstehen, welcher Nutzen ist realistisch, und welches Risiko ist mit den jeweiligen Optionen verbunden?

Technisch spielt die Cloud-Readiness der bestehenden Systeme natürlich ebenfalls eine große Rolle. Manche Anwendungen lassen sich relativ unkompliziert anpassen, andere sind stark von Alttechnologien geprägt. Je nach Ausgangslage kann ein Rehost, ein Replatforming oder ein stärkeres Refactoring sinnvoll sein. Gerade bei sensiblen Daten steigt in der Public-Cloud oft der Aufwand, weil Sicherheits- und Compliance-Fragen sehr viel genauer betrachtet werden.

Und schließlich darf man die Organisation nicht ausblenden. Die beste technische Zielarchitektur hilft wenig, wenn im Unternehmen die nötigen Fähigkeiten, Verantwortlichkeiten oder Betriebsmodelle fehlen. Deshalb sollten immer auch vorhandenes Wissen und die Bereitschaft zu neuen Formen von Ownership und Zusammenarbeit in die Entscheidung einfließen.

Welche typischen Fehler siehst du bei Cloud-Migrationen immer wieder? Was würdest du Teams raten, um diese von Anfang an zu vermeiden?

Ein häufiger Fehler ist, dass Unternehmen zu schnell loslaufen. Die Entscheidung für „wir gehen in die Cloud“ ist dann schon gefallen, aber die eigentliche Strategiearbeit wurde noch gar nicht gemacht. Dadurch startet man mit viel Aktivität, aber wenig Orientierung. Mein Rat wäre deshalb immer: erst Transparenz schaffen, dann bewerten und priorisieren, und erst danach konkrete Migrationspfade festlegen.

Ein zweiter typischer Fehler ist, die Migration ausschließlich als Technikthema zu behandeln. Dabei werden organisatorische Auswirkungen, neue Rollen, Lernaufwände oder auch Compliance-Fragen zu spät berücksichtigt. Das rächt sich fast immer. Wer hier früh die relevanten Beteiligten einbindet und die Veränderung als gemeinsames Thema versteht, schafft deutlich bessere Voraussetzungen.

Ebenso problematisch ist der Versuch, einen einheitlichen Migrationspfad für ein komplettes System festzulegen. In der Praxis funktioniert das selten gut. Sinnvoller ist es, differenziert pro Komponente zu entscheiden, mit Pilotkandidaten zu starten und aus den ersten Schritten gezielt zu lernen.

Und schließlich sehe ich oft einen Perfektionsanspruch, der den gesamten Prozess lähmt. Nicht jede Anwendung muss sofort vollständig cloud-native neu gedacht werden. Oft ist ein pragmatischer Zwischenschritt die bessere Lösung, wenn dadurch Risiken reduziert und Fortschritte überhaupt erst möglich werden. Entscheidend ist, Abhängigkeiten früh sichtbar zu machen, sensible Daten ernst zu nehmen und die Migration als lernenden, iterativen Prozess zu gestalten.

Mehr zum Thema gibt es beim Software Architecture Forum 2026: Dort zeigt Anja Kammer in ihrer Session, wie sich Cloud-Migration strategisch planen und erfolgreich umsetzen lässt.

Über die Sprecherin:

Anja Kammer ist Senior Consultant bei INNOQ und begleitet Unternehmen auf ihrem Weg in die Cloud. Neben der Beratung zu Entwicklungsprozessen und -plattformen entwickelt sie Cloud-native Webanwendungen in cross-funktionalen Teams. Zudem ist sie akkreditierte Trainerin und Co-Kuratorin für das iSAQB Advanced-Level-Modul CLOUDINFRA.