Cloud-Migrationsstrategien: Die 6 Rs in der Praxis

Warum “einfach hochladen” nicht funktioniert

Cloud-Migration klingt in der Theorie simpel: On-Prem-Server abschalten, Azure-VM anlegen, Daten rueberkopieren, fertig. In der Praxis scheitert genau dieser naive Ansatz regelmaessig - an falsch dimensionierten VM-Groessen, an Applikationen mit hartcodierten IP-Adressen, an Lizenzmodellen, die in der Cloud anders abgerechnet werden, und an Downtime-Fenstern, die niemand vorher mit dem Fachbereich abgesprochen hat.

Der Unterschied zwischen einer Migration, die reibungslos laeuft, und einer, die zum Wochenend-Notfall wird, liegt fast nie an der Technik allein. Er liegt daran, ob vorher sauber entschieden wurde: Welche Strategie passt zu diesem Workload? Wie sieht die Wellenplanung aus? Und was ist der Plan B, wenn die Migration am Montagmorgen um 6 Uhr nicht so laeuft wie erwartet?

Dieser Artikel geht die komplette Praxis durch: das 6R-Modell als Entscheidungsrahmen, Azure Migrate als Werkzeug fuer Assessment und Durchfuehrung, Wellenplanung, Downtime-Minimierung und ein durchgerechnetes Beispiel fuer den typischen Fall im Schweizer KMU - einen On-Prem-Fileserver oder Applikationsserver, der nach Azure wandert.

Das 6R-Modell: Sechs Wege in die Cloud

Microsoft und die meisten Cloud-Beratungen strukturieren Migrationsentscheidungen entlang von sechs Grundstrategien - den “6 Rs”. Wichtig zu wissen: Microsofts aktuelles Cloud Adoption Framework (CAF) hat das Modell inzwischen auf acht Strategien erweitert (zusaetzlich Rearchitect und Rebuild als eigene Kategorien zwischen Refactor und Repurchase). Fuer die Praxis im KMU reicht das klassische 6R-Modell aber vollkommen aus, weil die Grenzen zwischen “Refactor” und “Rearchitect” in kleineren Umgebungen selten trennscharf sind.

Uebersicht der sechs Strategien

Rehost - der Standardfall im KMU

Rehost ist die haeufigste Strategie bei kleineren Migrationsprojekten, weil sie am wenigsten Risiko und am wenigsten Vorbereitung braucht. Eine VM wird “as-is” nach Azure kopiert: gleiches Betriebssystem, gleiche Anwendungen, gleiche Konfiguration. Der Migrationsaufwand ist gering, dafuer nimmst du technische Schulden 1:1 mit in die Cloud - ein veraltetes Windows Server 2012 R2 bleibt auch in Azure ein veraltetes Windows Server 2012 R2, nur eben mit Azure-Rechnung statt Stromrechnung.

Replatform - der goldene Mittelweg

Replatform bedeutet, dass du die Zielarchitektur leicht aenderst, ohne den Applikationscode grundlegend umzuschreiben. Das klassische Beispiel: SQL Server auf einer VM wird zu Azure SQL Managed Instance. Die Anwendung selbst merkt kaum einen Unterschied (Connection String anpassen reicht oft), aber Patching, Backups und Hochverfuegbarkeit uebernimmt jetzt Azure. Fuer KMU ist das oft das beste Kosten-Nutzen-Verhaeltnis: Man reduziert Betriebsaufwand deutlich, ohne ein monatelanges Refactoring-Projekt zu starten.

Refactor - Code-Anpassung mit echtem Aufwand

Refactoring lohnt sich, wenn eine Applikation Cloud-native Fähigkeiten wirklich braucht: horizontale Skalierung, Container-Orchestrierung, Event-getriebene Architektur. Für ein KMU mit begrenzten Entwicklerressourcen ist das meistens nur bei selbst entwickelten oder aktiv weiterentwickelten Applikationen sinnvoll - nicht bei einer Standard-ERP-Installation eines Drittanbieters, wo du den Code ohnehin nicht anfassen darfst.

Repurchase - Wechsel auf SaaS

Repurchase heisst: Die bestehende Loesung wird nicht migriert, sondern durch eine SaaS-Alternative ersetzt. Der klassische Fall im M365-Kontext ist die Ablösung eines On-Prem-Exchange-Servers durch Exchange Online (siehe Exchange Hybrid Migration). Der technische Migrationsaufwand ist oft überschaubar, der organisatorische Aufwand (Schulung, Prozessanpassung, Datenmigration in ein neues Datenmodell) dafür umso höher.

Retire - der unterschätzte Klassiker

Bevor du überhaupt migrierst, lohnt sich eine ehrliche Bestandsaufnahme: Wie viele Server in deinem Rechenzentrum laufen, weil “die vielleicht noch jemand braucht”? Azure Migrate liefert in der Discovery-Phase häufig Auslastungsdaten, die zeigen, dass ein Server seit Monaten praktisch keine CPU-Last mehr hat. Jeder Server, den du stilllegst statt migrierst, spart dir nicht nur Azure-Kosten, sondern auch Migrationsaufwand.

Retain - bewusst On-Prem bleiben

Manche Workloads bleiben aus guten Gründen vor Ort: regulatorische Vorgaben (z.B. Datenhaltung in der Schweiz für gewisse Branchen), enge Kopplung an lokale Hardware (Maschinensteuerung, Barcode-Scanner mit proprietärem Treiber), oder schlicht eine kürzlich getätigte Hardware-Investition, die erst abgeschrieben werden muss. Retain ist keine Verlegenheitslösung, sondern eine legitime Entscheidung - dokumentiere sie aber mit Begründung und Wiedervorlage-Datum, damit sie nicht zur Dauerlösung wird.

Azure Migrate: Assessment vor der Migration

Bevor du dich für eine Strategie entscheidest, brauchst du belastbare Daten. Genau dafür ist Azure Migrate gedacht - ein kostenloser Azure-Dienst zur Discovery, Bewertung und Durchführung von Migrationen.

Der Discovery-Prozess

Azure Migrate arbeitet mit einer sogenannten Appliance - einer virtuellen Maschine, die du in deiner On-Prem-Umgebung bereitstellst und die Metadaten deiner Server sammelt (CPU, RAM, Disk-IOPS, Netzwerkverkehr, installierte Software). Für VMware- und Hyper-V-Umgebungen läuft das agentenlos über die Virtualisierungsplattform, für physische Server oder andere Hypervisoren brauchst du einen Agenten auf jedem Server.

# Azure Migrate Appliance vorbereiten - Voraussetzungen prüfen (auf der Appliance-VM ausführen)
# Mindestanforderung: 8 vCPU, 32 GB RAM, 80 GB Disk, Windows Server 2022
Test-NetConnection -ComputerName "login.microsoftonline.com" -Port 443
Test-NetConnection -ComputerName "management.azure.com" -Port 443
Test-NetConnection -ComputerName "*.discoverysrv.windowsazure.com" -Port 443

# Beispiel: Registrierungsschlüssel der Appliance mit dem Azure Migrate-Projekt verknüpfen
# (Schlüssel wird beim Erstellen des Migrate-Projekts im Portal generiert)
Set-Location "C:\AzureMigrate"
.\AzureMigrateInstaller.ps1 -Scenario "Server" -SourceEnvironment "VMware"

Nach der Registrierung sammelt die Appliance über mindestens einen Tag, idealerweise 30 Tage Performance-Daten. Diese Zeitspanne ist wichtig: Ein Server, der nur werktags 8-18 Uhr genutzt wird, sieht in einer 24-Stunden-Momentaufnahme ganz anders aus als über einen vollen Monat mit Monatsabschluss-Lastspitzen.

Assessmenttypen

Azure Migrate bietet unterschiedliche Assessment-Typen, je nach Zielarchitektur:

Das Ergebnis eines Azure VM Assessments liefert dir pro Server eine konkrete Empfehlung, z.B. “Standard_D4s_v5, Premium SSD, geschätzt CHF 210/Monat” - inklusive einer Konfidenzbewertung (High/Medium/Low Confidence), die davon abhängt, wie vollständig die gesammelten Performance-Daten sind.

Migrationswellen-Planung

Auch ein kleines KMU mit 15-30 Servern sollte nicht “alles auf einmal” migrieren. Wellenplanung reduziert Risiko, verteilt Aufwand über Zeit und macht Learnings aus frühen Wellen für spätere nutzbar.

Kriterien zur Wellen-Einteilung

1. Abhängigkeiten zuerst kartieren. Nutze Azure Migrate’s Dependency Analysis (basiert auf Netzwerkverkehr zwischen Servern) oder manuell erhobene Anwendungslandkarten, um zu sehen, welche Server miteinander sprechen. Ein Applikationsserver und seine Datenbank gehören in dieselbe Welle.
2. Risikoarme Kandidaten zuerst. Welle 1 sollte aus Servern bestehen, die wenig geschäftskritisch sind und wenig Abhängigkeiten haben - ein interner Testserver oder ein Dateiserver mit überschaubarer Nutzerzahl eignet sich besser als der Produktions-ERP-Server.
3. Geschäftskritische Systeme zuletzt, aber nicht am Ende der Frist. Plane genug Puffer nach der letzten kritischen Welle ein, falls doch Nacharbeiten nötig sind - nicht am letzten Tag vor Vertragsende des alten Rechenzentrums migrieren.
4. Saisonale Geschäftszyklen berücksichtigen. Ein Handelsunternehmen migriert nicht im Dezember, eine Steuerberatungskanzlei nicht im März/April. Frage das Business aktiv nach ruhigen Fenstern.

Beispielhafte Wellenstruktur für ein KMU mit 25 Servern

Downtime-Minimierung

Die Kernfrage jeder Migration: Wie lange steht der Server, während die Daten synchronisiert werden? Azure Migrate arbeitet mit einem zweistufigen Replikationsmodell, das Downtime auf ein Minimum reduziert.

Replikationsphasen

1. Initiale Vollreplikation. Ein kompletter Snapshot der Server-Disks wird nach Azure übertragen. Bei grossen Datenmengen (mehrere TB) kann das je nach Bandbreite Tage dauern - plane das ausreichend im Voraus ein, mindestens 3-4 Tage vor dem eigentlichen Migrationsfenster.
2. Delta-Replikationszyklen. Nach der Vollreplikation überträgt Azure Migrate nur noch die Änderungen (Deltas) in wiederkehrenden Zyklen. Der Server läuft während dieser Phase ganz normal weiter - es gibt keine Downtime.
3. Test-Migration (unbedingt nutzen). Azure Migrate erlaubt eine isolierte Test-Migration in ein separates VNet, ohne den produktiven Replikationszyklus zu unterbrechen. Damit prüfst du Boot-Verhalten, Netzwerkkonnektivität und Anwendungsstart, bevor der echte Cutover ansteht.
4. Finaler Cutover. Erst hier entsteht echte Downtime: Quellserver wird heruntergefahren (damit keine Schreibvorgänge mehr verloren gehen), letzter Delta-Sync läuft, Ziel-VM in Azure wird gestartet.

# Beispiel: DNS-TTL vor der Migration heruntersetzen, damit der Umzug schneller sichtbar wird
# (auf dem internen DNS-Server, mindestens 24h vor dem Cutover ausführen)
Set-DnsServerResourceRecord -ZoneName "firma.local" -OldInputObject $oldRecord -NewInputObject $newRecord

# Nach dem Cutover: IP-Adresse und Hostname auf der neuen Azure-VM prüfen
Get-NetIPConfiguration | Select-Object InterfaceAlias, IPv4Address
Test-Connection -ComputerName "dc01.firma.local" -Count 2

Downtime-Fenster realistisch schätzen

Für einen typischen Fileserver mit 500 GB und einer Applikation ohne komplexe Abhängigkeiten liegt ein realistisches Cutover-Fenster bei 30-90 Minuten: Herunterfahren, letzter Delta-Sync (wenige Minuten dank vorheriger Deltas), VM-Start in Azure, DNS-Umstellung, Funktionstest. Kommuniziere dieses Fenster klar an die Nutzer - inklusive eines Pufferzeitraums, falls der Funktionstest Nacharbeiten aufdeckt.

Rollback-Strategien

Jeder Migrationsplan braucht einen dokumentierten Rollback-Pfad - nicht als Pessimismus, sondern als Grundvoraussetzung, um überhaupt ein Migrationsfenster genehmigt zu bekommen.

Rollback-Optionen je nach Migrationsphase

Die wichtigste Regel: Schalte den Quellserver nicht sofort ab. Halte ihn für mindestens 5-10 Werktage nach erfolgreicher Migration im ausgeschalteten, aber nicht gelöschten Zustand vor - im Idealfall vom Netz getrennt (damit keine IP-Konflikte entstehen), aber startbereit. Das kostet in der Regel nur etwas Stromkosten oder VM-Lizenzkosten, ist aber die günstigste Versicherung, die es gibt.

Rollback-Entscheidungsbaum

Cutover durchgeführt, Probleme erkannt
│
├─ Kritischer Fehler (Anwendung startet nicht, Datenkorruption)?
│   ├─ Ja → Sofort-Rollback: Quellserver reaktivieren, DNS zurück
│   └─ Nein → weiter
│
├─ Performance-Problem (VM zu klein dimensioniert)?
│   ├─ Ja → Kein Rollback nötig, VM-Grösse in Azure hochskalieren
│   └─ Nein → weiter
│
├─ Konnektivitätsproblem (VNet/NSG/DNS)?
│   ├─ Ja → Netzwerkkonfiguration korrigieren, kein Rollback nötig
│   └─ Nein → weiter
│
└─ Unklare/mehrere Ursachen → Rollback einleiten, Root Cause in Ruhe analysieren

Praxisbeispiel: On-Prem-Applikationsserver nach Azure

Ein durchgerechnetes Beispiel aus dem typischen KMU-Alltag: Ein Applikationsserver mit Windows Server 2019, 4 vCPU, 16 GB RAM, 300 GB Datenvolumen, der eine Branchenanwendung samt lokaler SQL-Server-Instanz hostet. Rehost wurde als Strategie gewählt, weil der Softwarehersteller ein Refactoring auf PaaS nicht unterstützt.

Schritt-für-Schritt-Ablauf

1. Discovery. Azure Migrate Appliance sammelt 30 Tage Performance-Daten. Ergebnis: durchschnittlich 35% CPU-Last, Spitzen bis 78% am Monatsende (Fakturierungslauf).
2. Assessment. Basierend auf den Spitzenwerten empfiehlt Azure Migrate Standard_D4s_v5 (4 vCPU, 16 GB RAM) mit Premium SSD - bewusst nicht auf den Durchschnitt, sondern auf die Spitzenlast dimensioniert.
3. Lizenzprüfung. Windows Server 2019 Lizenz wird über Azure Hybrid Benefit weiterverwendet (vorhandene Software Assurance), SQL Server Standard Edition ebenfalls über Hybrid Benefit - das spart gegenüber Pay-as-you-go erheblich.
4. Netzwerk vorbereiten. VNet und Subnetz in Switzerland North anlegen, NSG-Regeln analog zur bestehenden On-Prem-Firewall-Policy definieren (siehe Azure VNet & NSG im Tiefgang).
5. Replikation starten. Agentenlose Replikation über die VMware-Integration, initiale Vollsynchronisation über Nacht und Wochenende.
6. Testmigration. Isolierte Testumgebung in separatem Subnetz, Funktionstest der Branchenanwendung durch den Fachbereich, inklusive eines Testlaufs des Monatsabschlusses mit anonymisierten Testdaten.
7. Cutover-Fenster. Dienstagabend 19:00 Uhr: Quellserver in Wartungsmodus, letzter Delta-Sync, Azure-VM hochfahren, DNS-Eintrag umstellen, Smoke-Test durch IT und einen Key-User.
8. Hypercare-Phase. Fünf Werktage enge Beobachtung (Azure Monitor Alerts auf CPU/Memory/Disk-Latenz), Quellserver bleibt ausgeschaltet, aber vorhanden.
9. Abschluss. Nach erfolgreicher Hypercare-Phase: Quellserver-VM final archivieren oder löschen, Azure Migrate Projekt abschliessen, Dokumentation aktualisieren (siehe IT-Dokumentation & Inventar).

# Beispiel: vereinfachte Bicep-Struktur für die Ziel-VM (Auszug)
resource appServer 'Microsoft.Compute/virtualMachines@2024-07-01' = {
  name: 'vm-appserver-prod'
  location: 'switzerlandnorth'
  properties: {
    hardwareProfile: {
      vmSize: 'Standard_D4s_v5'
    }
    licenseType: 'Windows_Server'
  }
}

// Azure Monitor: CPU-Auslastung der migrierten VM in den ersten 5 Tagen prüfen (Hypercare)
Perf
| where ObjectName == "Processor" and CounterName == "% Processor Time"
| where Computer == "vm-appserver-prod"
| summarize avg(CounterValue), max(CounterValue) by bin(TimeGenerated, 1h)
| order by TimeGenerated desc

Werkzeuge für die Migration

Häufige Fallstricke

• IP-Adressen hartcodiert statt DNS-basiert. Applikationen, die IP-Adressen statt Hostnamen verwenden, brechen nach der Migration, weil sich die IP-Range zwangsläufig ändert. Vor der Migration prüfen und wo möglich auf DNS umstellen.
• Firewall-Regeln vergessen. On-Prem-Firewall-Regeln werden oft über Jahre gewachsen und nicht dokumentiert. Ohne sauberes Audit der bestehenden Regeln fehlen in der neuen NSG-Konfiguration wichtige Freigaben - meist bemerkt man das erst, wenn ein Drittsystem die Verbindung verliert.
• Backup-Strategie nicht mitgedacht. Die Migration selbst ist kein Backup-Konzept. Für die neue Azure-VM muss von Tag eins an ein eigenes Backup-Regime laufen (siehe Backup-Strategie: die 3-2-1-Regel).
• Lizenz-Compliance ignoriert. Manche On-Prem-Softwarelizenzen sind an physische Hardware oder Core-Anzahl gebunden und lassen sich nicht ohne Weiteres in die Cloud übertragen. Vor der Migration beim Hersteller klären.
• Kein dediziertes Rollback-Budget. Rollback braucht Zeit und ggf. zusätzliche Ressourcen (z.B. Parallelbetrieb). Plane das explizit im Projektbudget ein, statt es als “hoffentlich brauchen wir das nicht” zu behandeln.

Weiterlernen

• Select your cloud migration strategies - Cloud Adoption Framework
• Azure Migrate - Übersicht
• Agentless vs. agentenbasierte Migrationsmethoden
• Azure Hybrid Benefit
• Assess VMware servers for migration to Azure VMs
• Azure Site Recovery - Dokumentation

Videos

YouTube