Migration & Strategie

Cloud-Migration planen: von der Bestandsaufnahme bis zur ersten Welle

Migrationen scheitern selten an der Technik, sondern an einem Anwendungsinventar, das Abhängigkeiten nicht kennt, und an einer ersten Welle, die zu groß geschnitten war. Wer mit unkritischen Anwendungen beginnt, jede Welle mit einem getesteten Rückweg versieht und die Landing Zone vor der ersten Nutzlast baut, kommt planbar durch. Der teuerste Fehler ist die Reihenfolge, nicht das Werkzeug.

5 Kapitel mit allen Befehlen
Team plant eine Infrastruktur-Migration vor Notizwand und Architekturdiagramm
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

Woran Migrationen tatsächlich scheitern

Fast jede gescheiterte Migration hat dieselbe Vorgeschichte: Das Anwendungsinventar stammt aus einer Tabelle, die jemand vor zwei Jahren gepflegt hat. Darin stehen Namen, Verantwortliche und vielleicht die Serveranzahl. Nicht darin stehen die Dinge, die den Umzug bestimmen: welcher Dienst mit welchem spricht, wie viele Daten täglich fließen, welche feste IP-Adresse in einer fremden Firewall eingetragen ist und welches Fachverfahren an einem Lizenzserver hängt. Diese Abhängigkeiten tauchen dann in der Nacht des Umzugs auf, wenn niemand mehr Zeit hat, sie zu klären.

Der zweite Klassiker ist der Zuschnitt der ersten Welle. Weil das Projekt Wirkung zeigen soll, wird die wichtigste Anwendung zuerst genommen. Damit trifft das Team seine ersten Fehler an dem System mit der geringsten Toleranz. Die richtige Reihenfolge ist umgekehrt: Die erste Welle dient dem Lernen. Sie besteht aus Anwendungen, deren Ausfall für einen halben Tag verkraftbar ist, deren Abhängigkeiten überschaubar sind und deren Fachbereich mitzieht. Was das Team dabei lernt, spart in Welle drei mehr Zeit, als die zwei Wochen Vorlauf gekostet haben.

Der dritte Punkt ist die Kostenseite. Während einer Migration zahlst du doppelt: Das alte System läuft weiter, das neue auch, und der Datenabgleich zwischen beiden kostet zusätzlich Datenverkehr. Wer das nicht einplant, gerät nach der zweiten Welle unter Druck, das alte Rechenzentrum schneller abzuschalten als geplant, und genau dann fällt der Rückweg weg. Plane den Doppelbetrieb je Welle bewusst ein, mit Anfang und Ende, und mach das Abschalten der Altumgebung zu einem eigenen, terminierten Schritt.

Miniatur-Szene: alter Serverschrank links, leuchtende Cloud rechts, dazwischen eine Brücke mit Kisten

Von der Inventur bis zur letzten Welle

  1. 01 Anwendungen und Abhängigkeiten am laufenden System erfassen
  2. 02 Zielbild festlegen und die Landing Zone aufbauen
  3. 03 Je Anwendung einen der sieben Wege entscheiden
  4. 04 Wellen schneiden, klein anfangen, Rückweg testen
  5. 05 Testdurchlauf fahren, dann kontrolliert umschalten
  6. 06 Doppelbetrieb terminiert beenden und Altumgebung abschalten
Was du mitnimmst

Ein Vorgehen in fünf Etappen

Die Reihenfolge ist der eigentliche Inhalt einer Migrationsplanung. Wer Etappen tauscht, spart nichts, sondern verschiebt Arbeit in eine Phase, in der sie teurer ist.

Inventar mit Zahlen statt mit Namen

Erfasse je Anwendung: beteiligte Server, Betriebssysteme, Datenmenge, tägliche Änderungsrate, Lastprofil über den Tag, offene Verbindungen zu anderen Systemen, feste Adressen in fremden Regelwerken und den Support-Status des Herstellers. Erhebe die Verbindungen automatisiert am laufenden System, nicht aus der Dokumentation. Genau diese Liste bestimmt später Wellenzuschnitt und Aufwand.

Zielbild und Landing Zone vor der ersten Nutzlast

Kontenstruktur, Netzsegmentierung, Anbindung an das eigene Rechenzentrum, Identitäten, Protokollierung, Verschlüsselung und Kostenzuordnung gehören fertig, bevor die erste produktive Anwendung umzieht. Wer das später nachzieht, baut jede migrierte Anwendung zweimal. Die Leitplanken kommen dabei aus Richtlinien und Kontogrenzen, nicht aus Dokumenten, die niemand liest.

Je Anwendung einen Weg festlegen

Sieben Wege stehen zur Auswahl: abschalten, behalten, verlagern, umziehen, anpassen, ersetzen, neu bauen. Die Entscheidung fällt je Anwendung anhand von Restlaufzeit, Herstellerunterstützung, Änderungsbedarf und verfügbarem Wissen im Team. Ein reiner Umzug ist die schnellste Variante und erzeugt die höchsten Betriebskosten, ein Neubau ist umgekehrt.

Wellen schneiden statt Stichtag setzen

Eine Welle bündelt Anwendungen, die miteinander sprechen, und umfasst höchstens so viel, wie das Team in einem Wartungsfenster zurückrollen kann. Jede Welle bekommt einen Testdurchlauf ohne Umschaltung, ein definiertes Abbruchkriterium und ein Ende des Doppelbetriebs mit Datum. Ein einziger großer Stichtag ist die riskanteste aller Varianten.

Betriebsmodell und Kostensteuerung von Anfang an

Kennzeichnung aller Ressourcen, Budgets je Welle und ein monatlicher Blick auf die Kostenaufteilung gehören in die erste Woche und nicht in das Nachfolgeprojekt. Ebenso das Betriebsmodell: Wer patcht, wer hat Rufbereitschaft, wer darf Ressourcen anlegen. Ohne diese Antworten entsteht eine Umgebung, die niemand vollständig kennt.

Tutorial

Vom Anwendungsinventar bis zur abgeschlossenen ersten Welle

Der teuerste Fehler in einer Migration ist die Reihenfolge und nicht das Werkzeug: Wer die Landing Zone erst nach der ersten Nutzlast baut, fasst jede migrierte Anwendung ein zweites Mal an. Die fünf Etappen stehen deshalb genau so, wie sie im Projekt anfallen, also erfassen, entscheiden, Fundament bauen, testen und umschalten, danach aufräumen und rechnen. Die Beispiele zeigen AWS und Azure nebeneinander, und alle Befehle lesen zuerst nur, ohne etwas zu verändern.

01

Schritt 1: Inventar und Abhängigkeiten am laufenden System erfassen

Die Dokumentation beschreibt, wie es gedacht war. Der Netzverkehr beschreibt, wie es ist. Nimm beides auf, aber entscheide nach dem zweiten.

Verbindungen zwischen den Systemen aufnehmen
# Bestehende Verbindungen ueber alle Hosts einsammeln, mehrfach ueber den Tag
while read -r host; do
  ssh "$host" 'ss -Htnp state established' \
    | awk -v h="$host" '{print h, $3, $4}'
done < hosts.txt >> verbindungen.txt

# Wer spricht mit wem? Das sind die Kandidaten fuer eine gemeinsame Welle
awk '{print $1, $3}' verbindungen.txt | sort | uniq -c | sort -rn | head -40

# Datenmenge je Server als Grundlage fuer die Uebertragungsdauer
while read -r host; do
  ssh "$host" 'df -B1 --output=source,used,target -x tmpfs -x devtmpfs'
done < hosts.txt > datenmengen.txt

Erhebe die Verbindungen über mindestens eine volle Woche, inklusive Monatsende und Nachtläufen. Die Abhängigkeit, die dich später aufhält, taucht typischerweise genau einmal im Monat auf: der Abgleich mit dem Lohnsystem, der Bericht an die Bank, der nächtliche Lizenzcheck.

Erhobene Daten in die Bewertungswerkzeuge der Anbieter geben
# AWS: erfasste Server importieren und auswerten
aws discovery start-import-task --name inventar-2026 \
  --import-url s3://migration-inventar/server-2026-07.csv
aws discovery list-configurations --configuration-type SERVER --max-results 100
aws discovery describe-configurations --configuration-ids <id-liste>

# Azure: Bewertung laeuft ueber Azure Migrate, Ergebnis danach pruefen
az resource list --resource-type Microsoft.Migrate/assessmentProjects -o table

Die Bewertungswerkzeuge liefern eine Empfehlung für Instanzgröße und Kosten. Nimm sie als Ausgangspunkt und nicht als Ergebnis, denn gerechnet wird mit dem gemessenen Spitzenwert, und damit fallen die Empfehlungen regelmäßig zu groß aus.

02

Schritt 2: Je Anwendung einen Weg festlegen

Die Entscheidung fällt nicht für das Rechenzentrum, sondern je Anwendung. Sieben Wege, ein Ergebnis pro Zeile im Inventar, schriftlich begründet.

Die sieben Wege und wann sie passen

WegWann er passtWas er kostet
AbschaltenAnwendung wird faktisch nicht mehr genutzt, Daten sind archivierbarfast nichts, spart sofort Betriebskosten und Migrationsaufwand
BehaltenAnwendung endet ohnehin bald oder darf das Haus nicht verlassennichts im Projekt, aber die Altumgebung bleibt länger bestehen
VerlagernVirtualisierungsschicht soll unverändert bleiben, etwa bei VMware-Landschaftengering im Projekt, dauerhaft höhere Plattformkosten
UmziehenStandardserver ohne Änderungsbedarf, schneller Abzug aus dem Rechenzentrumgeringster Projektaufwand, höchste laufende Kosten
AnpassenDatenbank oder Middleware kann durch einen verwalteten Dienst ersetzt werdenmittlerer Aufwand, spürbar weniger Betriebslast danach
ErsetzenFür die Fachaufgabe existiert ein passendes Standardprodukt als DienstProjektaufwand liegt in Datenübernahme und Prozessen, nicht in der Technik
Neu bauenAnwendung ist strategisch, Änderungsrate hoch, Altcode bremst spürbarhöchster Aufwand, niedrigste laufende Kosten und größte Flexibilität

In der Praxis landen in den meisten Häusern siebzig bis achtzig Prozent der Anwendungen beim Umziehen oder Anpassen. Das ist kein Versagen, sondern eine vernünftige Reihenfolge: Erst den Abzug aus dem Rechenzentrum sichern, danach modernisieren, wo es sich rechnet. Wichtig ist nur, dass die Entscheidung bewusst fällt und mit einem Termin für die Nacharbeit versehen wird, sonst bleibt der Umzug für immer der Endzustand. Die Abwägung zwischen schnellem Umzug und Neubau haben wir unter Lift and Shift oder Neubau im Detail aufgeschrieben.

03

Schritt 3: Landing Zone und Leitplanken bauen

Bevor die erste produktive Anwendung umzieht, steht das Fundament: Kontenstruktur, Regionsbindung, Identitäten, Protokollierung und Kostenzuordnung. Leitplanken gehören in die Plattform, nicht in eine Richtlinie im Intranet.

Regionen und Dienste in beiden Welten begrenzen
# AWS: Regionsbindung als Service Control Policy auf der Organisationseinheit
aws organizations create-policy --type SERVICE_CONTROL_POLICY \
  --name nur-eu --description "Nur eu-central-1 und eu-west-1" \
  --content file://scp-regionen.json
aws organizations attach-policy --policy-id p-beispiel --target-id ou-beispiel

# Azure: dieselbe Leitplanke als Richtlinie auf der Verwaltungsgruppe
az policy assignment create --name nur-eu \
  --scope /providers/Microsoft.Management/managementGroups/mg-produktiv \
  --policy e56962a6-4747-49cd-b67b-bf8b01975c4c \
  --params '{"listOfAllowedLocations":{"value":["germanywestcentral","westeurope"]}}'

# Kostenzuordnung erzwingen, sonst weiss spaeter niemand, wem was gehoert
az policy assignment create --name pflicht-kostenstelle \
  --scope /providers/Microsoft.Management/managementGroups/mg-produktiv \
  --policy 871b6d14-10aa-478d-b590-94f262ecfa99 \
  --params '{"tagName":{"value":"kostenstelle"}}'

Die Regionsbindung ist die wirksamste einzelne Leitplanke. Sie verhindert nicht nur ungewollte Datenabflüsse in andere Rechtsräume, sondern auch die häufigste Ursache verstreuter Ressourcen: eine Konsole, die beim nächsten Anmelden in einer anderen Region öffnet.

04

Schritt 4: Die erste Welle testen und umschalten

Jede Welle hat zwei Termine: den Testdurchlauf ohne Auswirkung auf den Betrieb und die eigentliche Umschaltung. Der Testdurchlauf ist nicht optional, er ist der Grund, warum die Umschaltung funktioniert.

Replikation prüfen, Testdurchlauf fahren, dann umschalten
# Stand der Replikation je Server, bevor irgendetwas passiert
aws mgn describe-source-servers --query \
  'items[].{Name:sourceProperties.identificationHints.hostname,
            Stand:dataReplicationInfo.dataReplicationState}'

# Testdurchlauf: startet Testinstanzen, Produktion laeuft unberuehrt weiter
aws mgn start-test --source-server-ids s-0123456789abcdef0

# Erst nach erfolgreichem Test und Freigabe des Fachbereichs
aws mgn start-cutover --source-server-ids s-0123456789abcdef0

# Abschluss: beendet die Replikation und gibt die Ressourcen frei
aws mgn finalize-cutover --source-server-id s-0123456789abcdef0

Zwischen Testdurchlauf und Umschaltung gehört die fachliche Abnahme, nicht nur ein technischer Erreichbarkeitstest. Der Fachbereich prüft echte Vorgänge: einen Auftrag anlegen, einen Bericht erzeugen, einen Druckjob absetzen. Genau dort tauchen fehlende Firewall-Freigaben und vergessene Schnittstellen auf.

Freigabekriterien einer Welle

  • Rückweg beschrieben, terminiert und mindestens einmal geprobtEin Rückweg, der nur auf Papier existiert, ist im Ernstfall keiner. Unter Zeitdruck entscheidet die Frage, ob jemand die Schritte schon einmal gemacht hat.
  • Sicherung in der Zielumgebung eingerichtet und eine Wiederherstellung getestetNach dem Umschalten ist die Altumgebung nur noch begrenzt aktuell. Ohne getestete Wiederherstellung hast du für die neue Umgebung gar keinen Wiederanlaufpunkt.
  • Überwachung und Alarmierung greifen vor der Umschaltung, nicht danachDie ersten Stunden nach dem Umzug erzeugen die meisten Auffälligkeiten. Wer die Überwachung nachzieht, verpasst genau das Zeitfenster, in dem sie am meisten wert wäre.
  • Feste Adressen in fremden Regelwerken vorher geändert und bestätigtFirewalls von Partnern, Banken und Behörden führen IP-Adressen in Freigabelisten. Deren Änderung dauert Tage und liegt nicht in deiner Hand.
  • Ende des Doppelbetriebs mit Datum vereinbartOhne Termin läuft die Altumgebung weiter, du zahlst dauerhaft doppelt und niemand traut sich mehr, den Stecker zu ziehen.
  • Abbruchkriterium und Entscheider für den Abbruch benanntMitten in der Nacht entsteht sonst eine Diskussion statt einer Entscheidung, und der Rückweg schließt sich, während geredet wird.
05

Schritt 5: Nachlauf, Kosten und der offene Rückweg

Nach der Umschaltung beginnt der Teil, den Projektpläne gern weglassen: rechnen, richtig dimensionieren und den Doppelbetrieb tatsächlich beenden.

Kosten je Welle sichtbar machen
# Kosten nach Dienst und nach der Kennzeichnung der Welle aufschluesseln
aws ce get-cost-and-usage --time-period Start=2026-07-01,End=2026-08-01 \
  --granularity MONTHLY --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=SERVICE Type=TAG,Key=welle

# Zu gross gewaehlte Instanzen finden, das ist der groesste Einzelposten
aws ce get-rightsizing-recommendation --service AmazonEC2

# Azure: dieselbe Sicht ueber alle Abonnements
az costmanagement query --type ActualCost --timeframe MonthToDate \
  --scope /subscriptions/<id> \
  --dataset-grouping name=ResourceType type=Dimension

Warte mit dem Anpassen der Instanzgrößen mindestens vier Wochen nach der Umschaltung. Vorher kennst du das Lastprofil in der neuen Umgebung nicht, und ein zu klein gewählter Server im ersten Monatsabschluss kostet mehr Vertrauen, als er an Geld spart.

Halte den Rückweg auch nach dem Projekt bewusst offen. Das heißt nicht, die Altumgebung ewig zu behalten, sondern zu wissen, in welchem Format deine Daten vorliegen, wie du sie herausbekommst und was das kostet. Der EU Data Act stärkt hier deine Position deutlich, weil er Anbieter zur Unterstützung beim Wechsel verpflichtet und die Entgelte dafür begrenzt. Was daraus konkret folgt, steht unter EU Data Act und Cloud-Wechsel. Und wenn du am Ende zu dem Schluss kommst, dass ein Teil der Last besser im eigenen Haus bleibt, ist das ein legitimes Ergebnis der Planung und kein Rückschritt.

Wissen prüfen

Teste dich und finde deinen Weg

Bevor du einen Kurs buchst, lohnt sich eine ehrliche Standortbestimmung. Die Tests sind kostenlos und ohne Anmeldung.

Gut zu wissen

Häufige Fragen zu Cloud-Migration und Architektur

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt
Wie lange dauert eine Cloud-Migration?
Für ein mittelständisches Rechenzentrum mit rund hundert Servern und dreißig Anwendungen ist ein Zeitraum von neun bis achtzehn Monaten realistisch, gerechnet vom Projektstart bis zum Abschalten der Altumgebung. Davon entfallen etwa drei Monate auf Inventar und Zielbild, zwei bis drei auf die Landing Zone und der Rest auf die Wellen. Die einzelne Welle dauert selten länger als vier Wochen. Verlängert wird ein solches Projekt fast immer durch drei Dinge: die Vorlaufzeit der Netzanbindung, Abhängigkeiten zu Fremdsystemen und Fachbereiche, die keine Zeit für die Abnahme haben.
Womit fange ich an, wenn noch gar nichts vorbereitet ist?
Mit dem Inventar, und zwar mit dem gemessenen statt dem dokumentierten. Lass über zwei bis vier Wochen die bestehenden Netzverbindungen aufzeichnen und stelle daneben die Datenmengen und Änderungsraten. Diese Erhebung kostet wenig, läuft parallel zu allem anderen und beantwortet später die entscheidenden Fragen zum Wellenzuschnitt. Erst danach lohnt sich die Diskussion über Anbieter und Zielarchitektur. Wer umgekehrt vorgeht, entscheidet über Zielbilder, ohne zu wissen, was überhaupt umziehen soll.
Sollen wir zuerst migrieren oder zuerst modernisieren?
In den meisten Fällen zuerst migrieren, dann modernisieren, und zwar aus einem einfachen Grund: Beides gleichzeitig zu tun bedeutet, bei einem Fehler nicht zu wissen, ob die neue Plattform oder der neue Code die Ursache ist. Der reine Umzug ist schnell und riskoarm, verursacht dafür höhere laufende Kosten. Genau die sind dann das Argument für die anschließende Modernisierung, und das Team hat inzwischen Erfahrung mit der Plattform. Ausnahme sind Anwendungen, die ohnehin neu gebaut werden sollen. Sie ziehen gar nicht erst um.
Was muss das Team können, bevor die erste produktive Anwendung umzieht?
Drei Dinge müssen sitzen: Netz und Identitäten in der Zielumgebung, Sicherung und Wiederherstellung, sowie Kostenzuordnung und Alarmierung. Alles Weitere lässt sich unterwegs lernen, diese drei nicht, weil sie im Störungsfall gebraucht werden. Konkret heißt das mindestens eine Person je Bereich, die den Weg schon einmal ohne Anleitung gegangen ist. Plane Schulungen deshalb vor die erste Welle und nicht parallel dazu. Wissen, das zeitgleich mit dem produktiven Umzug aufgebaut wird, ist im entscheidenden Moment noch nicht belastbar.
Wird es in der Cloud günstiger?
Ein reiner Umzug ohne Anpassung wird in aller Regel teurer als der Betrieb im eigenen Rechenzentrum, weil du die bisherige Auslastung eins zu eins in ein Modell überträgst, das nach Nutzung abrechnet. Günstiger wird es durch drei Hebel: richtige Dimensionierung nach echter Last, Abschalten in Randzeiten und der Wechsel zu verwalteten Diensten, bei denen der Betriebsaufwand entfällt. Diese Hebel greifen erst nach der Migration. Wer die Wirtschaftlichkeit im ersten Monat nach dem Umzug misst, misst die schlechteste Zahl des gesamten Vorhabens.

Zuletzt geprüft am 26. Juli 2026.

Das sagen Teilnehmer

Echte Stimmen aus unseren IT-Kursen

Erwartungen wurden erfüllt. Angekündigte Themen in hinreichender Tiefe bearbeitet. Zudem gutes Zeitmanagement.
Rückmeldung aus dem Kurs „Source Code Management und CI / CD (DO4)“
Qualitativ sehr guter Kurs. Ruhiger und wertschätzender Umgang. Keine Informationsüberlastung.
Rückmeldung aus dem Kurs „Ansible Kompaktkurs“
Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Cloud-Programm den passenden Kurs oder Lernpfad zu finden.

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

Nächster Schritt

Das Vorgehen einmal vollständig durchspielen

Migrating to AWS und AWS Migration Essentials führen genau diesen Weg von der Bewertung des Bestands über den Wellenzuschnitt bis zur Umschaltung, mit den Werkzeugen, die du danach im Projekt einsetzt. Für das Zielbild ergänzen Architecting on AWS und der Azure-Architekturkurs AZ-305 die Entwurfsseite. Alle Kurse laufen Live-Online oder in Präsenz, auf Wunsch als Inhouse-Termin mit eurem eigenen Inventar als Übungsgrundlage.