Migrationsleitfaden: Wie du dich ohne Unterbrechungen aus der Anbieterabhängigkeit befreist

Migrationsprojekte scheitern in einer vorhersehbaren Abfolge. Der Umfang der technischen Arbeiten wird festgelegt. Der Zeitplan wird festgelegt. Das Entwicklerteam beginnt mit der Verlagerung der Workloads. Irgendwo in der Mitte tauchen Abhängigkeiten auf, die in der ursprünglichen Bewertung nicht berücksichtigt wurden, die Doppelbetriebsphase überschreitet das dafür vorgesehene Budget, und das Projekt gerät entweder ins Stocken oder wird zu deutlich höheren Kosten als geplant abgeschlossen.

Branchenstudien zeigen immer wieder, dass die Mehrheit der cloud-basierten Migrationsinitiativen das Budget überschreitet, wobei eine unzureichende Bewertung als Hauptursache genannt wird. Der „Flexera 2026 State of the Cloud Report“ rückt die eigentliche Ursache noch deutlicher in den Fokus: „Das Verständnis von Anwendungsabhängigkeiten“ wird von allen Befragten als die größte einzelne Herausforderung bei der Migration genannt (54 %) – noch vor der technischen Machbarkeit (44 %), der Kostenabschätzung (43 %) und der Optimierung nach der Migration (39 %). Abhängigkeiten, die erst während der Durchführung und nicht bereits bei der Bewertung zutage treten, sind die häufigste Ursache für Verzögerungen.

Das verändert die Sichtweise darauf, wie ein Migrationsleitfaden aussehen muss. Die meisten Leitfäden beginnen mit den Tools und der Abfolge der Schritte. Dieser hier beginnt mit den Entscheidungen, die getroffen werden müssen, bevor überhaupt Workloads verschoben werden – denn genau diese Entscheidungen entscheiden darüber, ob das Projekt erfolgreich ist.

Phase 1: Erst prüfen, dann loslegen

Wichtigste Erkenntnis: Ein Migrationsfehler ist ein Planungsfehler, der noch nicht passiert ist. Die in der Bewertungsphase durchgeführte Erfassung von Abhängigkeiten, die Kategorisierung der Workloads und die Entscheidungen zur Zuständigkeit bestimmen fast alles, was danach folgt.

Die Bewertungsphase hat einen einzigen Zweck: ein klares, ehrliches Bild davon zu erstellen, was du verlagerst, wovon es abhängt, was die Verlagerung kosten wird und wer für jede Entscheidung verantwortlich ist. Unternehmen, die diese Phase verkürzen, um den Beginn der technischen Arbeiten zu beschleunigen, stellen immer wieder fest, dass sich die bei der Planung eingesparte Zeit während der Ausführung mit Zinsen auszahlt.

Die Bewertungsarbeit gliedert sich in drei Bereiche:

Bestandsaufnahme und Kategorisierung der Workloads
Bevor eine Migrationsentscheidung getroffen wird, muss jede betroffene Workload anhand des „6-Rs“-Frameworks kategorisiert werden – der branchenüblichen Klassifizierung, die in den Migrations-Frameworks von Gartner und Accenture verwendet wird:

• Retire: Workloads, die nicht mehr aktiv genutzt werden oder deren Weiterführung nicht mehr gerechtfertigt ist. Typischerweise fallen 10 bis 20 % der Unternehmensinfrastruktur in diese Kategorie. Die kostengünstigste Workload für die Migration ist die, die du abschaltest, und die frühzeitige Identifizierung von zu stilllegenden Workloads führt zu sofortigen Kosteneinsparungen, die den Rest der Migration finanzieren.
• Rehost: „Lift-and-Shift“-Workloads mit minimalen Abhängigkeiten und ohne Bedarf an anbieterspezifischen Diensten. Diese lassen sich am schnellsten und mit dem geringsten Risiko migrieren.
• Replatform: Workloads, die geringfügige Anpassungen benötigen, um in einer neuen Umgebung effizient zu laufen, aber keinen kompletten Neuaufbau erfordern.
• Refactor: Workloads, die eine umfassende Neugestaltung der Architektur benötigen, um portabel zu laufen – typischerweise solche, die auf proprietären Anbieterdiensten basieren, für die es anderswo kein direktes Äquivalent gibt.
• Beibehalten: Workloads, die während des Migrationszeitraums aus regulatorischen, technischen oder vertraglichen Gründen beim aktuellen Anbieter verbleiben.
• Neuverhandeln: Workloads, bei denen es in erster Linie um kommerzielle statt um technische Aspekte geht – dabei werden die Konditionen mit dem bestehenden Anbieter neu verhandelt, wobei die nachgewiesene Portabilität als Druckmittel genutzt wird.

Durch diese Kategorisierung werden die Workloads sichtbar, die die größte Komplexität bei der Migration verursachen: jene, die auf proprietären Diensten basieren und für die es beim Zielanbieter kein direktes Äquivalent gibt. Das sind keine Gründe, die Migration aufzugeben; es sind Gründe, sie richtig zu planen.

Abhängigkeitsanalyse
: Dokumentiere für jede Workload, wovon sie abhängt: andere Dienste, Datenspeicher, Netzwerkkonfigurationen, Authentifizierungssysteme – und ob diese Abhängigkeiten Einschränkungen bei der Reihenfolge der Migration mit sich bringen. Workloads mit komplexen Abhängigkeitsketten können nicht einzeln migriert werden; sie werden als Gruppen migriert. Dies erst während der Durchführung statt bereits bei der Bewertung festzustellen, ist eine der häufigsten Ursachen für Verzögerungen bei der Migration – und eine der am leichtesten vermeidbaren.

Zuweisung
von Verantwortlichkeiten Jede betroffene Workload braucht einen namentlich benannten Verantwortlichen, der für die Migrationsentscheidung, die Umstellungskriterien und den Rollback-Plan verantwortlich ist. Das Fehlen klar definierter Verantwortlichkeiten ist einer der Hauptgründe, warum Migrationsprojekte ins Stocken geraten. Verantwortung bedeutet nicht, dass der Verantwortliche die technische Arbeit erledigt. Es bedeutet, dass er für das Ergebnis verantwortlich ist und die Befugnis hat, die Kompromissentscheidungen zu treffen, die die Migration möglicherweise erfordert.

Phase 2: Nach Risiko ordnen, nicht nach Geschwindigkeit

Wichtigste Erkenntnis: Die Reihenfolge der Migration sollte sich nach dem Risikoprofil und der Komplexität der Abhängigkeiten richten, nicht danach, welche Workloads am einfachsten zu verlagern sind. Wenn man zuerst die falsche Workload verlagert, entstehen nachgelagerte Einschränkungen, deren Behebung kostspielig ist.

Der instinktive Ansatz bei den meisten Migrationsprojekten ist, mit „Quick Wins“ zu beginnen: Workloads mit geringer Komplexität, die schnell verlagert werden können und Fortschritte demonstrieren. Dieser Instinkt ist teilweise richtig. Frühe Erfolge stärken das interne Vertrauen und zeigen, dass der Migrationsansatz funktioniert. Aber eine Reihenfolge, die sich ausschließlich an der Geschwindigkeit orientiert, schafft ein spezifisches Problem: Sie schiebt die hochkomplexen Workloads mit vielen Abhängigkeiten bis zum Schluss auf, wenn der Budgetdruck am höchsten und die Toleranz für Verzögerungen am geringsten ist.

Ein risikobasiertes Reihenfolgemodell funktioniert anders:

Beginne mit der Stilllegung
Bevor du irgendwelche Workloads verlagerst, nimm diejenigen außer Betrieb, die gar nicht verlagert werden sollten. Das reduziert den Umfang der Migration, sorgt für sofortige Einsparungen durch wegfallende cloud-Kosten und vereinfacht die Abhängigkeitsübersicht für alles, was danach kommt. Laut dem „Flexera 2026 State of the Cloud Report“. Diese Zahl ist in diesem Jahr zum ersten Mal seit fünf Jahren wieder gestiegen, angetrieben durch die wachsende Kostenkomplexität durch KI und neue Dienste

Verschiebe isolierte Workloads frühzeitig (Rehost)
„Lift-and-Shift“-Migrationen mit minimalen Abhängigkeiten validieren den Migrationsprozess, bauen Teamkompetenzen auf und zeigen den Stakeholdern Fortschritte, ohne nachgelagerte Komplexität zu verursachen. Das sind die passenden ersten Erfolge.

Ordne die Refaktorisierung von Workloads nach Abhängigkeiten, nicht nach Komplexität
an. Die Workloads, die eine Neugestaltung erfordern, sollten danach geordnet werden, was von ihnen abhängt – nicht danach, wie schwer sie zu verlagern sind. Ein stark beanspruchter Dienst, der eine Refaktorisierung erfordert, muss vor den Workloads verlagert werden, die von ihm abhängen – auch wenn es einfacher wäre, diese abhängigen Workloads zuerst zu verlagern.

Plane die Beibehaltung und Neuverhandlungen parallel
Workloads, die während des Migrationszeitraums beim aktuellen Anbieter verbleiben, erfordern zwar keine technischen Arbeiten, aber kommerzielle Entscheidungen. Nutze die Migrationsphase, um die Konditionen für die beibehaltenen Workloads neu zu verhandeln – nutze dabei die nachgewiesene Portabilität als Druckmittel. Die glaubwürdige Fähigkeit zur Migration ist wertvoll, selbst wenn du dich entscheidest, sie nicht auszuüben.

Mach die Multicloud-Bewertung.

Phase 3: Lege die Umstellungskriterien fest, bevor der Parallelbetrieb beginnt

Wichtigste Erkenntnis: Die Doppelbetriebsphase, in der Workloads gleichzeitig sowohl in der Quell- als auch in der Zielumgebung laufen, ist eine finanzielle Belastung, kein Sicherheitsnetz. Jeder Tag ohne definierte Umstellungskriterien ist ein Tag mit unnötigen Ausgaben.

Die am häufigsten unterschätzten Kosten bei Migrationsprojekten sind die Kosten für die Parallelbetriebsphase. Der gleichzeitige Betrieb von Workloads in zwei Umgebungen ist teuer, und die Kosten steigen direkt proportional zur Dauer des Parallelbetriebs. Unternehmen, die in die Parallelbetriebsphase ohne definierte Umstellungskriterien eintreten – also ohne die konkreten, messbaren Bedingungen, die erfüllt sein müssen, bevor die Quellumgebung außer Betrieb genommen wird –, stellen regelmäßig fest, dass sich dieser Zeitraum weit über die ursprüngliche Schätzung hinaus verlängert.

Die Umstellungskriterien müssen vor Beginn des Parallelbetriebs definiert werden, nicht erst währenddessen. Sie sollten Folgendes festlegen:

Schwellenwerte
für die Performance-Gleichheit: Welche Leistungskennzahlen muss die Zielumgebung erfüllen, bevor die Quellumgebung außer Betrieb genommen wird? Definiere diese als konkrete, messbare Werte und nicht als qualitative Einschätzungen.

Überprüfung
der Datenintegrität: Welche Prüfungen bestätigen, dass die Daten in der Zielumgebung vollständig, korrekt und mit der Quellumgebung konsistent sind? Wer ist dafür verantwortlich, diese Prüfungen durchzuführen und das Ergebnis abzusegnen?

Bedingungen
für den Rollback Unter welchen konkreten Umständen wird die Migration auf die Quellumgebung zurückgesetzt? Wie sieht der Rollback-Prozess aus, wer genehmigt ihn und wie lang darf die Rollback-Zeit maximal sein? Diese Bedingungen sollten definiert und getestet werden, bevor sie benötigt werden.

Anforderungen
an die Freigabe durch die Beteiligten Welche Teams müssen die Betriebsbereitschaft bestätigen, bevor die Umstellung erfolgt? Wenn man das im Voraus festlegt, verhindert man, dass die Umstellung von Beteiligten blockiert wird, die nicht in den Planungsprozess einbezogen wurden.

Wenn diese Kriterien nicht vor Beginn des Double-Runs dokumentiert und vereinbart sind, werden Entscheidungen zur Umstellung unter Kostendruck in Echtzeit ausgehandelt – und genau dann ist die Wahrscheinlichkeit am größten, dass sie auf einer falschen Grundlage getroffen werden.

Phase 4: Umgang mit internem Widerstand

Wichtigste Erkenntnis: Die organisatorischen Hindernisse bei der Migration sind besser vorhersehbar als die technischen. Sie bereits in der Planungsphase explizit anzugehen, ist kostengünstiger, als sie während der Umsetzung als Überraschungen bewältigen zu müssen.

Die Teams, die der Migration am ehesten Widerstand leisten, sind nicht diejenigen mit den komplexesten Arbeitsabläufen. Es sind diejenigen, die am wenigsten Klarheit darüber haben, was die Migration für ihre derzeitigen Arbeitsweisen, ihre bestehenden Investitionen in Tools und ihre täglichen operativen Aufgaben bedeutet.

Drei Dinge bauen diesen Widerstand effektiver ab als technische Kommunikation:

Frühzeitige Einbindung in die Kategorisierung
der Workloads Teams, die an der „6 Rs“-Bewertung ihrer eigenen Workloads mitwirken, behindern die daraus resultierenden Migrationsentscheidungen deutlich seltener. Eine Kategorisierung, die den Teams aufgezwungen wird, erzeugt Widerstand. Eine Kategorisierung, die gemeinsam mit den Teams erfolgt, schafft Eigenverantwortung.

Klare Antworten auf die Frage
nach der Autonomie Die häufigste Sorge von Entwicklerteams ist, dass die Migration den Verlust der Kontrolle über ihre Technologieentscheidungen bedeutet. Gehe direkt und konkret darauf ein: Was ändert sich, was bleibt gleich und was gewinnen sie im Gegenzug für das, was sie aufgeben? Vage Zusicherungen bauen den Widerstand nicht ab. Konkrete, ehrliche Antworten zu den Kompromissen hingegen schon.

Sichtbare Verantwortung
der Führungskräfte Migrationen mit namentlich benannten Führungskräften als Sponsoren, die sichtbar für die Ergebnisse verantwortlich sind, schneiden durchweg besser ab als solche, bei denen die Verantwortung diffus verteilt ist. Hier geht es nicht um die Einbindung der Führungskräfte in technische Entscheidungen. Es geht darum, eine namentlich benannte Person zu haben, deren berufliche Verantwortung mit dem Erfolg der Migration verbunden ist.

Die organisatorische Arbeit in den Phasen 1 bis 4 ist das, was Migrationen, die termingerecht und im Rahmen des Budgets abgeschlossen werden, von denen unterscheidet, bei denen das nicht der Fall ist. Die technische Arbeit ist notwendig, aber nicht ausreichend. Eine Migration, die technisch einwandfrei, aber organisatorisch unzureichend vorbereitet ist, wird am ersten wichtigen Entscheidungspunkt ins Stocken geraten – und in einem Migrationsprojekt kommen wichtige Entscheidungspunkte nach einem Zeitplan, der nicht darauf wartet, dass die interne Abstimmung erst einmal nachholt.

Lies dir die Checkliste zur Migrationsdurchführbarkeit durch. 

Häufig gestellte Fragen (FAQ)

Wie lange sollte die Bewertungsphase dauern?
Bei den meisten Unternehmensmigrationen dauert eine gründliche Bewertung vier bis acht Wochen für eine Infrastruktur mittlerer Komplexität. Unternehmen, die diese Phase auf zwei Wochen verkürzen, berichten immer wieder, dass während der Durchführung unentdeckte Abhängigkeiten zutage treten und dem Projekt mehr Zeit kosten, als durch die verkürzte Bewertung eingespart wurde. Die Bewertungsphase ist der kostengünstigste Zeitpunkt, um Komplexität aufzudecken; mit jeder nachfolgenden Phase wird es teurer.

Was ist die richtige Größe für eine erste Migrations-Workload?
Klein genug, um sie innerhalb eines einzigen Sprintzyklus abzuschließen, aber bedeutend genug, um den Migrationsprozess von Anfang bis Ende zu validieren. Das Ziel der ersten Migration ist es, die Tools, den Prozess, das Rollback-Verfahren und die Fähigkeiten des Teams zu testen – nicht, die wichtigste Workload zu verschieben. Eine Rehost-Migration eines Dienstes mit geringer Kritikalität ist in der Regel der richtige Ausgangspunkt.

Wie gehen wir mit Workloads um, die aufgrund vertraglicher Bindungen nicht migriert werden können?
Vertragliche Einschränkungen, darunter Mindestumsatzverpflichtungen, Reservierungen dedizierter Instanzen und langfristige Serviceverträge, sind ein Faktor für die Reihenfolgeplanung, aber kein Hindernis für die Migration. Ordne die Vertragsende-Termine der technischen Workload-Kategorisierung zu und plane die Migrationen so, dass sie sich nach Möglichkeit mit dem Vertragsablauf abstimmen lassen. Nutze in der Zwischenzeit die bei anderen Workloads nachgewiesene Portabilität, um deine Verhandlungsposition für den nächsten Vertragszyklus zu stärken.

Was muss ein Rollback-Plan eigentlich enthalten?
Mindestens: die konkreten Bedingungen, die einen Rollback auslösen, die technischen Schritte, die erforderlich sind, um die Quellumgebung wieder in den betriebsbereiten Zustand zu versetzen, die für die Ausführung dieser Schritte benötigte Zeit sowie die namentlich genannte Person, die befugt ist, die Entscheidung zum Rollback zu treffen. Rollback-Pläne, die nur als Dokumentation existieren, sind weniger nützlich als solche, die vor Beginn des Umstellungsfensters in einer Nicht-Produktionsumgebung getestet wurden.

Wie messen wir den Erfolg einer Migration über die Kosten hinaus?
Kosten sind die sichtbarste Migrationskennzahl, aber nicht immer die aussagekräftigste. Die Kennzahlen, die für ITMMs besonders wichtig sind, sind: die Bereitstellungsgeschwindigkeit der migrierten Workloads im Vergleich zur Ausgangsbasis vor der Migration; die Wiederherstellungszeit bei Störungen in der neuen Umgebung im Vergleich zur alten; der Nachweis der Compliance vor und nach der Migration; sowie die Verhandlungsmacht im nächsten Vertragszyklus mit dem Anbieter. Legt diese Basiswerte fest, bevor die Migration beginnt, damit der Vergleich bei Projektabschluss aussagekräftig ist.