# Cloud Migration Strategy: Die 6 Säulen des Umzugs

TL;DR / Management Summary Eine Cloud-Migration ist kein reiner Kopiervorgang. Ohne Strategie importieren Sie nur lokale Probleme in ein teureres Rechenzentrum. Wir nutzen das 6 Rs Modell, um für jeden Server zu entscheiden: Behalten, Löschen oder Migrieren? Ein Senior Admin plant die Migration in Wellen, beginnt mit unkritischen Testsystemen und nutzt Tools wie AWS Migration Hub oder Azure Migrate, um die Kompatibilität vorab zu prüfen.

# 1. Die ‘6 Rs’ der Migration

Die strategische Entscheidung.

Für jedes System in Proxmox müssen Sie entscheiden:

Rehost (Lift & Shift): VM 1:1 in die Cloud schieben. (Schnell, aber teuer).
Replatform: Kleine Optimierung (z.B. Wechsel von lokalem SQL zu Managed Azure SQL).
Refactor: Applikation neu schreiben für Cloud-Native (Serverless). (Beste Effizienz, hohe Kosten).
Repurchase: Wechsel zu einer SaaS-Lösung (z.B. Salesforce statt CRM-VM).
Retain (Behalten): Bleibt in der Private Cloud (Proxmox), z.B. wegen Latenz oder Compliance.
Retire (Löschen): Das System wird nicht mehr gebraucht. (Beste Kostensenkung!).

# 2. Der Phasen-Plan

Sicher umziehen.

# Phase 1: Assessment (Bestandsaufnahme)

Scannen Sie Ihr lokales Netz.

Aktion: Welche VMs haben welche Abhängigkeiten? (Wer spricht mit wem?).
Tool: netstat Analysen oder Azure Migrate Agenten.

# Phase 2: Pilot-Welle

Migrieren Sie 2-3 unkritische Dienste (z.B. Wiki oder Test-DB).

Lerneffekt: Passt die VPN-Bandbreite? Funktionieren die Firewall-Regeln in der Cloud?

# Phase 3: Massen-Migration

Verschieben von Applikations-Stacks in logischen Gruppen.

# 3. Deep Dive: Daten-Migration (Large Scale)

Terabytes bewegen.

Das Netzwerk ist oft der Flaschenhals.

Methode A: Online-Sync via VPN/ExpressRoute (für kleine Mengen).
Methode B: Physischer Datentransport. Nutzen Sie AWS Snowball oder Azure Data Box.
- Ablauf: Provider schickt ein gepanzertes NAS -> Sie kopieren Ihre VHDXs lokal darauf -> Postversand zum Cloud-RZ -> Daten erscheinen im Bucket.

# 4. Day-2 Operations: Finalisierung & Cutover

Den Stecker lokal ziehen.

Der kritischste Moment: Der Schwenk der User.

Strategie: Nutzen Sie DNS-TTL Senkung (Artikel 739) 24 Stunden vor dem Umzug.
Vorgang: Lokale VM stoppen -> Letzte Daten-Synchronisation (Delta) -> DNS auf neue Cloud-IP ändern -> Test.

# 5. Troubleshooting & “War Stories”

Wenn die Cloud-Migration scheitert.

# Top 3 Fehlerbilder

Symptom: Applikation ist extrem langsam nach der Migration.
- Ursache: Die Datenbank wurde migriert, der App-Server blieb aber On-Premise. (Latency Gap).
- Lösung: Migrieren Sie immer den gesamten Stack zusammen.
Symptom: “Incompatible VM configuration”.
- Ursache: UEFI/BIOS Mismatch oder zu große virtuelle Disks (> 2 TB).
- Fix: Konvertieren Sie die Images vorab mit Tools wie qemu-img (Artikel 668).
Symptom: Kosten verdoppeln sich.
- Ursache: Überprovisionierte Instanzen (“Sicherheitspuffer” aus Proxmox-Welt in die Cloud übernommen).

# “War Story”: Die “Vergessene” Datenbank-Latenz

Ein Admin migrierte ein Warenwirtschaftssystem nach AWS. Er nutzte “Lift & Shift”. Das Ereignis: Der Seitenaufruf dauerte statt 1 Sekunde plötzlich 15 Sekunden. Die Ursache: Die Applikation machte für jede Seite hunderte kleine SQL-Abfragen. In seinem lokalen 10G Netz war die Latenz < 1ms. In der Cloud (obwohl der SQL-Server in der gleichen Region stand) lag die Latenz bei 2-3ms. Die Summe der Verzögerungen machte die App unbenutzbar. Lehre: Testen Sie die “Chattiness” Ihrer Applikationen. Manche Software ist nicht für Cloud-Infrastrukturen geeignet, ohne den Code zu optimieren (Refactor).

# 6. Monitoring & Reporting

Migrations-Fortschritt.

# Migration Dashboard

Verfolgen Sie den Status:

VMs remaining On-Prem.
Data Transfer Progress.
Post-Migration Performance Check.

# 7. Fazit & Empfehlung

Migration ist kein Ziel, sondern eine Reise.

Empfehlung: Nutzen Sie den “Replatform”-Ansatz als Standard. Es bietet den besten ROI zwischen Aufwand und Nutzen.
Wichtig: Sorgen Sie für eine saubere Rückzugs-Strategie (Rollback). Wenn der Test nach dem Cutover fehlschlägt, müssen Sie innerhalb von 5 Minuten wieder auf der lokalen Proxmox-VM online sein können.

# Anhang: Checkliste für den Cutover-Tag

[ ] Backup am Quell-System abgeschlossen?
[ ] DNS TTL auf 60 Sekunden?
[ ] Firewall-Regeln am Zielort getestet?
[ ] Datenbank-Konsistenz geprüft?
[ ] Support-Hotlines der Cloud-Provider griffbereit?