Cloud-Migration Schritt für Schritt: So gelingt der Wechsel ohne Ausfälle

Cloud-Migrationen scheitern selten an der Wolke. Sie scheitern an undokumentierten Abhängigkeiten, die erst nach dem Umzug auffallen. An Datenmigrationsproblemen, die im Test nicht aufgetreten sind. An fehlenden Rollback-Plänen, wenn etwas schiefgeht. Und an unrealistischen Zeitplänen, die keinen Puffer für die unvermeidlichen Überraschungen lassen.

Dieser Beitrag ist eine ehrliche Schritt-für-Schritt-Anleitung – nicht die Verkaufsbroschüre.

Vorbereitung: Bevor die Migration beginnt

Anwendungsinventar erstellen

Listen Sie alle Anwendungen, Dienste und Datenbanken auf, die potenziell migriert werden sollen. Für jede Anwendung:

• Technologie-Stack (OS, Runtime, Datenbank, Middleware)
• Abhängigkeiten zu anderen Systemen (APIs, Datenbanken, File-Shares)
• Datenvolumen und Wachstumsrate
• Verfügbarkeitsanforderungen und Wartungsfenster
• Compliance-Anforderungen (DSGVO, Branchenregulierung)
• Aktueller Betreiber und Verantwortlicher

Abhängigkeitsanalyse

Das ist der Schritt, den viele überspringen – und dann bereuen. Tools wie AWS Application Discovery Service, Azure Migrate oder Infrastruktur-Monitoring-Tools (Zabbix, Prometheus) können Netzwerkverbindungen zwischen Systemen kartieren. Was Sie finden wird mehr sein als erwartet.

Suchen Sie explizit nach: hardcodierten IP-Adressen (die sich bei der Migration ändern), Dateifreigaben, die andere Systeme nutzen, zeitgesteuerten Jobs (Cron, Task Scheduler), die auf andere Systeme zugreifen, Druckerfreigaben, Samba-Shares und anderen Netzwerkdiensten.

Migrationsreihenfolge planen

Nicht alle Anwendungen gleichzeitig. Abhängigkeiten bestimmen die Reihenfolge: Zuerst die Systeme, von denen andere abhängig sind (z.B. Active Directory, Datenbankserver), dann die abhängigen Anwendungen.

Kategorisieren Sie Anwendungen nach Kritikalität:

• Kritisch (Produktionsausfall bei Fehler) → Zuletzt, mit maximaler Vorbereitung
• Wichtig (erhebliche Beeinträchtigung) → Mittelphase
• Unkritisch (Test-, Entwicklungsumgebungen) → Zuerst, als Übungsfeld

Cloud-Umgebung vorbereiten

Bevor die erste Anwendung migriert wird:

• Cloud-Account aufsetzen, Billing-Alerts konfigurieren
• Netzwerkarchitektur definieren (VPC, Subnetze, Sicherheitsgruppen)
• Identitäts- und Zugriffsmanagement aufsetzen (IAM)
• Monitoring und Logging konfigurieren (CloudWatch, Azure Monitor, Stackdriver)
• VPN- oder Direct-Connect-Verbindung zur On-Premise-Umgebung aufbauen
• Namensauflösung (DNS) zwischen on-premise und Cloud planen

Schritt 1: Pilotmigration

Warum ein Pilot?

Der Pilot reduziert Risiken durch Lernen an einem unkritischen System. Was im Pilot schiefgeht, geht nicht im Produktivsystem schief.

Welche Anwendung als Pilot?

• Niedrige Kritikalität (kein Produktionsausfall bei Ausfall)
• Repräsentative Komplexität (nicht das einfachste System, sonst lernt man nichts)
• Typischer Tech-Stack des Unternehmens
• Bekannte und vollständig dokumentierte Abhängigkeiten

Was im Pilot zu lernen ist:

• Wie funktioniert der Migrationsprozess technisch?
• Wie lange dauert tatsächlich was?
• Welche unerwarteten Abhängigkeiten tauchen auf?
• Wie funktioniert das Monitoring in der Cloud?
• Welche Performanceunterschiede gibt es?

Pilot-Ergebnisse dokumentieren und in die Planung der Hauptmigration einfließen lassen. Nicht überspringen.

Schritt 2: Datenmigration planen

Kurz: Datenmigration ist komplex genug für ein eigenes Kapitel.

Datenmigration ist komplex genug für ein eigenes Kapitel. Typische Fehler:

Datenmenge unterschätzt. Wer erst beim Live-Test merkt, dass 5 TB Daten über eine 100-Mbit-Leitung 4 Tage brauchen, hat ein Problem. Bandbreite und Übertragungszeit vorab berechnen.

Datenqualität nicht geprüft. Was on-premise „funktioniert hat", kann in der Migration Fehler offenbaren: doppelte Primärschlüssel, inkonsistente Referenzen, fehlerhafte Datumsformate. Datenqualitätscheck vor der Migration.

Inkrementelle Migration nicht geplant. Bei großen Datenmengen: Bulk-Migration zuerst (Tage vor dem Go-live), dann inkrementelle Synchronisation der Änderungen bis zum Schnitt.

Migrationsstrategie je Datenbanktyp:

• Relationale DBs: Dump-and-Restore für kleine DBs, Replikations-basierte Migration für große DBs ohne langen Ausfall
• Dateisysteme: rsync-basierte inkrementelle Synchronisation
• Object Storage (S3, Blob): parallele Multi-Thread-Übertragung mit Checksummenvalidierung

Schritt 3: Rollback-Strategie definieren

Kurz: Vor jedem Migrations-Schritt: Was ist der Rollback-Plan, wenn es schiefgeht?

Vor jedem Migrations-Schritt: Was ist der Rollback-Plan, wenn es schiefgeht?

Für Rehost-Migrationen:

• On-Premise-System läuft weiter bis nach dem Abnahmetest in der Cloud
• Beim Go-live: DNS-Umschaltung statt IP-Wechsel (ermöglicht schnelles Zurückschalten)
• DNS-TTL vor der Migration auf niedrigen Wert setzen (5–10 Minuten)
• Backup der Datenbankstände unmittelbar vor der Umschaltung

Rollback-Zeitfenster festlegen: Wie lange kann die Cloud-Umgebung beobachtet werden, bevor der Rollback-Zeitpunkt abläuft? Typisch: 24–72 Stunden für kritische Systeme.

Rollback-Test durchführen: Den Rollback-Prozess vor dem echten Go-live einmal im Staging durchspielen.

Schritt 4: Go-live und Monitoring

Kurz: Wartungsfenster wählen: Migrationen kritischer Systeme: außerhalb der Geschäftszeiten, mit Bereitschaft aller Beteiligten.

Wartungsfenster wählen: Migrationen kritischer Systeme: außerhalb der Geschäftszeiten, mit Bereitschaft aller Beteiligten. Nicht freitags abends (Wochenende als Puffer ist verlockend – aber Hilfe ist dann schwerer erreichbar). Besser: Dienstag oder Mittwoch.

Kommunikationsplan:

• Interne Kommunikation: IT-Team, Fachbereiche, Geschäftsführung
• Externe Kommunikation falls nötig: Kunden, Lieferanten mit systemischer Anbindung
• Wer entscheidet über Rollback?

Monitoring nach Go-live:

• Systemmetriken: CPU, Memory, Disk, Netzwerk
• Anwendungsmetriken: Antwortzeiten, Fehlerrate, Transaktionsdurchsatz
• Log-Monitoring: Fehlermeldungen, unerwartete Ausnahmen
• Vergleich mit Baseline-Werten aus der On-Premise-Umgebung

Hypercare-Phase: Mindestens 2 Wochen nach Go-live erhöhte Aufmerksamkeit. Erst dann ist das System stabil genug, um on-premise als Fallback abzuschalten.

Schritt 5: Optimierung nach der Migration

Kurz: Die Migration ist nicht das Ende.

Die Migration ist nicht das Ende. In den ersten Monaten nach der Migration:

Kosten-Optimierung:

• Rightsizing: Sind die gewählten Cloud-Instanzgrößen korrekt? Überprovisioniert oder zu klein?
• Reserved Instances / Savings Plans: Für stabile Workloads erhebliche Rabatte (bis zu 40–60 %)
• Ungenutzte Ressourcen identifizieren und abschalten (verwaiste Snapshots, unused Volumes)

Sicherheitsoptimierung:

• Security Groups und Firewall-Regeln auf Minimum reduzieren
• Verschlüsselung für Storage und Datenübertragung prüfen
• IAM-Rollen und -Policies nach Least-Privilege-Prinzip anpassen
• IT-Sicherheits-Review der Cloud-Umgebung

Performance-Optimierung:

• CDN für statische Assets aktivieren
• Datenbankabfragen und Indexes überprüfen (Cloud-Metriken zeigen neue Muster)
• Caching-Layer (Redis, Memcached) wo sinnvoll einsetzen

Fazit

Kurz: Eine Cloud-Migration ohne Ausfälle ist möglich – mit ausreichender Vorbereitung, einem Pilotprojekt, einer klaren Rollback-Strategie und einem realistischen Zeitplan.

Eine Cloud-Migration ohne Ausfälle ist möglich – mit ausreichender Vorbereitung, einem Pilotprojekt, einer klaren Rollback-Strategie und einem realistischen Zeitplan.

Die Schritte sind bekannt; das Problem ist die Versuchung, sie zu überspringen, um schneller fertig zu sein.

Das rächt sich fast immer.

Unser Team begleitet Cloud-Migrationsprojekte mit Erfahrung aus realen Mittelstandsprojekten – von der Abhängigkeitsanalyse bis zum Post-Migration-Monitoring.

Häufig gestellte Fragen (FAQ)

Kurz: Wie lange sollte die On-Premise-Umgebung nach der Migration noch laufen?

Wie lange sollte die On-Premise-Umgebung nach der Migration noch laufen? Mindestens 4–6 Wochen nach erfolgreichem Go-live für kritische Systeme. Erst dann abschalten, wenn alle Funktionen in der Cloud bestätigt sind und keine Rollback-Option mehr benötigt wird.

Was tun, wenn ein Rollback nötig ist? DNS-Umschaltung zurück, falls die Anwendung per Hostnamen adressiert wird. Datenbank-Synchronisation zurückführen (Deltaänderungen, die in der Cloud entstanden sind). Ursache analysieren, bevor erneut migriert wird.

Welche Tools helfen bei der Cloud-Migration?

AWS: Application Migration Service (MGN), Database Migration Service (DMS).

Azure: Azure Migrate.

GCP: Migrate to Virtual Machines.

Cloud-unabhängig: Carbonite Migrate, Zerto.

Für Datenbankmigrationen: AWS Schema Conversion Tool, Azure Database Migration Service.

Müssen wir für die Migration einen Change-Freeze einhalten? Empfehlenswert: Kein Major-Release kurz vor oder nach einer Migration. Änderungen erhöhen die Komplexität. Mindestens zwei Wochen vor dem Migrations-Go-live ein Code-Freeze für die betroffenen Systeme.