Definition: Was ist Azure-Migration?
Azure-Migration bezeichnet den planvollen Transfer von Workloads, Anwendungen und Daten aus On-Premises- oder anderen Cloud-Umgebungen in Microsoft Azure. Der Prozess folgt dem Microsoft-Modell Plan–Prepare–Execute–Evaluate–Decommission und gliedert sich in klar definierte Phasen: Bestandsaufnahme, Bewertung, Migration, Validierung und Abschaltung der Altsysteme.
Zentrale Steuerungsinstanz ist Azure Migrate – ein kostenfreier Hub, der Discovery, Assessment, Migration und Optimierung unter einer Oberfläche bündelt. Seit 2025/2026 ergänzt ein KI-gestützter Copilot-Migrations-Agent die Werkzeugkette und führt Teams schrittweise durch den gesamten Lebenszyklus. Ziel ist ein betriebssicherer, kostentransparenter Cloud-Betrieb bei minimaler Downtime. Strukturierte Migrationswellen mit Testläufen und Rollback-Optionen reduzieren das Risiko, während das Cloud Adoption Framework organisationale Vorlagen für Landing-Zone-Design, Skills-Check und Akzeptanzplan liefert.
Modern Cloud Infrastructure
Zukunftssichere IT-Infrastruktur für Ihr Unternehmen
Wie funktioniert Azure-Migration? – Die 9 Schritte im Überblick
Der Migrationsprozess folgt neun aufeinander aufbauenden Phasen. Zunächst erfasst die Bestandsaufnahme (Discovery) alle Assets und Abhängigkeiten – agentlos, per Appliance oder über den Collector für air-gapped Umgebungen. Darauf baut die Bewertung & Business Case auf: Sizing, Zielmodellwahl zwischen IaaS und PaaS sowie TCO/ROI-Rechnung liefern die Entscheidungsgrundlage. Die Migrationsplanung & Landing-Zone-Design orientiert sich am Cloud Adoption Framework mit Readiness-Check, Governance-Vorlagen und Skills-Analyse.
Ein Pilot validiert Werkzeuge und Rollback-Pläne unter Realbedingungen. Anschließend rollen wellenbasierte Produktionsmigrationen per Replikation und Live-Sync – Near-Zero-Downtime durch parallelen Betrieb. Der geplante Cutover & Go-Live erfolgt erst nach Stakeholder-Freigabe und erfolgreicher Testvalidierung. Nach dem Umzug folgt Post-Migration-Optimierung: FinOps-getriebenes Right-Sizing, Reservierungsmanagement und Lizenzoptimierung. Governance, Security-Baselines & Policy-as-Code härtet die Umgebung dauerhaft. Den Abschluss bildet das Decommissioning der Altsysteme samt Continuous-Improvement-Schleife. Jede Phase liefert messbare Artefakte für die nächste; der Execute-Leitfaden fasst Validierung, Stakeholder-Einbindung und operative Übergabe zusammen.
Schritt 1: Bestandsaufnahme (Discovery) – Vollständigkeit herstellen
Die Discovery erfasst sämtliche Server, Datenbanken, Anwendungen und Netzwerkabhängigkeiten automatisiert. Microsoft stellt dafür drei Wege bereit: die Azure Migrate Appliance für agentlose Inventarisierung von VMware-, Hyper-V- und physischen Umgebungen, agentenbasiertes Scannen für granulare Metriken und den Collector für air-gapped Rechenzentre ohne Internetzugang. Das Ergebnis ist eine aktuelle CMDB-Grundlage samt Abhängigkeitskarte (Dependency Visualization), die spätere Wellenplanung und Risikobewertung erst ermöglicht.
Ohne lückenlose Discovery bleiben Shadow-IT und verdeckte Abhängigkeiten die häufigsten Ursachen für Cutover-Verzögerungen. Ein häufiges Muster: Applikationen teilen sich Datenbanken oder nutzen gemeinsame Dateifreigaben, die in keiner Dokumentation auftauchen. Die Abhängigkeitsanalyse deckt solche Verbindungen auf, bevor Migrationswellen definiert werden. Azure Migrate konsolidiert die Daten im zentralen Hub und liefert damit die Entscheidungsgrundlage für Sizing, Zielmodell (IaaS versus PaaS) und Lizenzoptimierung im nachfolgenden Assessment.
Die Appliance wird als OVA/VAE importiert, per PowerShell konfiguriert und verbindet sich über einen verwalteten Identitätskontext mit dem Azure-Migrate-Projekt. Für air-gapped Umgebungen exportiert der Collector die Inventardaten als JSON, die anschließend hochgeladen werden. Beide Wege schreiben in dieselbe Datenbasis, sodass heterogene Landschaften einheitlich bewertbar bleiben. Die Dokumentation beschreibt die Voraussetzungen für vCenter-Berechtigungen, Firewall-Regeln und die Dimensionierung der Appliance-VM.
Schritt 2: Bewertung & Business Case (Assessment) – Wirtschaftlichkeit belegen
Im Assessment ordnet Azure Migrate jede ermittelte Workload einem passenden Zielmodell zu: Virtual Machines, Azure SQL, Azure Kubernetes Service oder App Service. Das Tool dimensioniert die Ressourcen per Right-Sizing neu – basierend auf tatsächlicher Auslastung, nicht auf überdimensionierter On-Premises-Hardware. Anschließend rechnet es die Azure-Preise (Pay-as-you-go, Reserved Instances und Azure Hybrid Benefit) gegen die aktuellen Betriebskosten auf. Lizenzoptimierung für Windows Server und SQL Server fließt direkt in die Kalkulation ein.
Die integrierte TCO/ROI-Berechnung liefert ein quantifiziertes Ergebnis: Investitionshöhe, laufende Kosten, Amortisationszeit und Einsparpotenzial über drei bis fünf Jahre. Stakeholder erhalten damit eine datenbasierte Entscheidungsgrundlage für Budgetfreigaben. Das Assessment zeigt zudem Abhängigkeiten zwischen Anwendungen, identifiziert Kandidaten für Rehost, Replatform oder Refactor und bewertet Migrationsrisiken nach Komplexität und Geschäftskritikalität.
Das Ergebnis ist ein belastbarer Business Case, der nicht nur Kosten vergleicht, sondern auch operative Vorteile wie Skalierbarkeit, Patch-Management und Sicherheitsupdates quantifiziert. Damit lässt sich die Migration gegenüber Fachbereichen und Controlling argumentativ absichern – vor dem ersten Testlauf in der Zielumgebung.
Schritt 3: Migrationsplanung & Landing Zone – Das Fundament legen
Auf Basis der Assessment-Daten entsteht nun der konkrete Migrationsplan. Er gliedert den Umzug in Wellen: Ein Pilot mit geringem Risiko macht den Anfang, gefolgt von nicht-kritischen Workloads, bevor geschäftskritische Systeme an der Reihe sind. Für jede Welle legt der Plan Zeitfenster, Rollback-Kriterien und klare Verantwortlichkeiten fest. Parallel dazu wird die Landing Zone nach CAF-Prinzipien bereitgestellt. Sie schafft die organisatorische und technische Basis: Management Groups für Governance-Hierarchien, Policy-Sets für Compliance-Standards, eine Hub-Spoke-Netzwerktopologie für sichere Konnektivität, die Integration der Identitätsinfrastruktur sowie eine Monitoring-Baseline für Observability ab Tag eins.
Ein zentrales Artefakt ist der Migrationsakzeptanzplan (Migration Acceptance Plan). Er definiert messbare Abnahmekriterien für jede Welle – von Performance-Schwellenwerten über Applikationsverfügbarkeit bis hin zu Sicherheitskonfigurationen. Nur wenn diese Kriterien erfüllt sind, erfolgt der Cutover in die nächste Phase. Die offizielle Migrationsdokumentation empfiehlt, Testmigrationen als verbindlichen Bestandteil jeder Welle einzuplanen, um Abhängigkeiten unter Realbedingungen zu validieren. So lassen sich Überraschungen beim produktiven Umschalten vermeiden und der Rollback bleibt beherrschbar. Wer diese Planungsdisziplin vernachlässigt, riskiert spätere Nacharbeiten, die teurer sind als die initiale Sorgfalt.
Schritt 4: Pilot-Migration & Testvalidierung – Risiko kontrollieren
Eine repräsentative, niedrigkritische Workload wandert zuerst in eine isolierte Subscription. Der Testlauf misst RTO und RPO, vergleicht Performance-Baselines und führt automatisierte Applikationstests durch. Rollback-Prozeduren werden unter Realbedingungen geübt, bevor die nächste Welle startet.
Der KI-gestützte Copilot-Migrations-Agent in Azure Migrate orchestriert 1st- und 3rd-Party-Toolketten und liefert zentrale Sichtbarkeit über alle Migrationsphasen hinweg. Er koordiniert Replikation, Validierung und Cutover in einem Dashboard, sodass Abweichungen sofort auffallen.
Erst nach formaler Migration Acceptance – dokumentiert durch Stakeholder-Sign-off – folgt die nächste Welle. Microsoft empfiehlt, die Pilotphase bewusst eng zu fassen: ein Server, eine Datenbank, ein klares Zeitfenster. Das begrenzt den Blast-Radius und schafft Vertrauen in das Vorgehensmodell. Ein Community-Beitrag fasst die Praxisregeln für diesen Schritt zusammen: Testmigration starten, Ergebnisse validieren, dann skalieren.
Schritt 5: Wellenbasierte Produktionsmigration – Near-Zero-Downtime erreichen
Produktionsworkloads ziehen in priorisierten Wellen um. Azure Migrate repliziert per Agent oder Appliance kontinuierlich im laufenden Betrieb – Änderungen fließen inkrementell nach. Der parallele Betrieb On-Premises und in Azure bleibt so lange erhalten, bis das Staging validiert ist.
Der Cutover erfolgt geplant: Nach Final Sync und DNS-Switch reduziert sich die Downtime auf Minuten. Ein Rollback bleibt bis zur endgültigen Freigabe möglich. Die Wellengröße leitet sich aus dem Abhängigkeitsgraphen und den verfügbaren Change-Fenstern ab – eng gekoppelte Systeme migrieren gemeinsam, unabhängige parallel.
Das Cloud Adoption Framework empfiehlt, jede Welle mit einem definierten Validierungsset abzuschließen: Funktionstests, Performance-Baselines, Sicherheits-Policies. Erst wenn alle Kriterien grün sind, folgt die nächste Welle. So bleibt das Risiko beherrschbar, selbst bei großen Landschaften mit hunderten VMs und Datenbanken.
Schritt 6: Cutover & Go-Live – Der kontrollierte Umstieg
Der finale Cutover folgt strikt einem vorab freigegebenen Runbook. Kernstück ist der letzte synchronisierte Replikationszyklus, danach erfolgt die DNS-Umschaltung auf die Azure-Endpunkte. Unmittelbar darauf prüfen automatisierte Smoke-Tests die kritischen Applikationspfade – Datenbankverfügbarkeit, Authentifizierungsflüsse, externe Schnittstellen. Erst nach positivem Stakeholder-Sign-Off gilt die Migration als abgeschlossen. Das Cloud Adoption Framework empfiehlt für diese Phase ein dediziertes War-Room-Setup mit vordefinierten Eskalationspfaden.
Azure Migrate zeigt den Migrationsstatus pro Asset in Echtzeit an. Der KI-gestützte Copilot-Agent orchestriert abhängige Schritte: Datenbank-Failover vor Anwendungsstart, Cache-Warmup vor Traffic-Umschaltung, Zertifikats-Rollover im passenden Zeitfenster. Weicht ein Schritt vom Soll ab, greift der definierte Rollback-Trigger automatisch – die On-Premises-Umgebung bleibt bis zur endgültigen Bestätigung im Readiness-Zustand.
Nach Go-Live beginnt die 24/7-Hypercare-Phase. Monitoring-Regeln werden schärfer, Alert-Schwellen niedriger, On-Call-Besetzung verstärkt. Ziel: Auffälligkeiten in den ersten 48 bis 72 Stunden erkennen und beheben, bevor sie Nutzerimpact erzeugen. Parallel läuft das Decommissioning der Alt-Systeme nach definierter Karenzzeit.
Schritt 7: Post-Migration-Optimierung & FinOps – Kosten im Griff behalten
Nach dem Go-Live beginnt die eigentliche Kostenarbeit. Azure Cost Management liefert die Datengrundlage, FinOps-Praktiken machen Ausgaben steuerbar. Teams setzen Tagging-Policies durch, damit jeder Ressource ein Kostenstellen-Owner zugeordnet ist. Budget-Alerts feuern frühzeitig, bevor Limits reißen. Showback-Modelle schaffen Transparenz, Chargeback-Modelle lenken Verhalten – je nach Reifegrad der Organisation.
Modern Cloud Desktop
Flexibles Arbeiten von überall – sicher und effizient
Technisch dominieren drei Hebel: Right-Sizing passt VM-Größen an tatsächliche Metriken an, nicht an konservative On-Prem-Schätzungen. Reservierte Instanzen und Savings Plans decken stabile Baselines ab – bis zu 72 Prozent Ersparnis gegenüber Pay-as-you-go. Speicher-Tiering verschiebt kalte Daten in Cool- oder Cold-Tiers, Archive-Tier für Compliance-Archive. Idle-Ressourcen – verwaiste Disks, unbelegte Public IPs, gestoppte, aber nicht deallokierte VMs – werden per Policy automatisch bereinigt.
Der KI-Copilot in Azure Migrate analysiert laufend Telemetrie und schlägt konkrete Maßnahmen vor: VM-Series-Wechsel bei geänderten Workload-Profilen, Migration von IaaS auf PaaS (etwa Azure SQL Managed Instance), Konsolidierung unterausgelasteter Instanzen. Die Vorschläge landen direkt im Optimierungs-Dashboard von Azure Migrate, wo Teams sie mit einem Klick validieren und ausrollen. Microsofts Migrations-Portal bündelt diese FinOps-Funktionen, während das What’s-New-Feed neue Optimierungs-Regeln und PaaS-Zielpfade dokumentiert. So bleibt die Cloud-Landschaft ökonomisch wie technisch fit.
Schritt 8: Governance, Security & Policy-as-Code – Compliance automatisieren
Governance wird in Azure über Policy-as-Code durchgesetzt. Azure Policy prüft Tagging-Konventionen, erlaubte Regionen und VM-SKUs sowie Security-Baselines – etwa die Aktivierung von Microsoft Defender for Cloud und Azure Firewall. Netzwerk-Segmentierung und Privileged Identity Management ergänzen den Schutz sensibler Workloads.
Landing-Zone-Policies liegen versioniert in Git-Repositorien. Über GitOps-Rollout werden sie auf neue Subscriptions vererbt, sodass jede Umgebung vom Start an den Zielzustand erfüllt. Drift-Detection meldet Abweichungen automatisiert; Compliance-Reports liefern Auditoren lückenlose Nachweise – audit-ready by design.
Das Cloud Adoption Framework empfiehlt, Governance nicht nachträglich aufzusetzen, sondern parallel zur Migration zu etablieren. So vermeiden Teams Schatten-IT und Kostenexplosionen durch nicht getaggte Ressourcen. Policy-Initiativen bündeln verwandte Regeln – etwa „PCI-DSS“ oder „ISO 27001“ – und wenden sie konsistent auf Management-Gruppen an. Regelmäßige Reviews der Policy-Compliance sichern den dauerhaften Zielzustand auch bei wachsender Cloud-Fläche.
Schritt 9: Decommissioning & Continuous Improvement – Altlasten abbauen
Nach erfolgreicher Validierung und Ablauf der Fallback-Frist beginnt das planvolle Stilllegen der On-Premises-Umgebungen. Zunächst steht die datenschutzkonforme Vernichtung aller Datenträger nach geltenden Compliance-Vorgaben an – sowohl für physische Medien als auch für virtuelle Snapshots in der Alt-Umgebung. Hardware wird entweder über zertifizierte Remarketing-Kanäle weiterverkauft oder gemäß ElektroG recycelt. Parallel laufen Lizenz-Rückgaben bei Microsoft und Drittanbietern sowie die Kündigung von Colocation-Verträgen, Support-Agreements und Wartungsverträgen für die stillgelegten Systeme. Ein strukturierter Asset-Check stellt sicher, dass keine verwaisten Ressourcen weiter Kosten verursachen.
Das Projektteam dokumentiert Lessons Learned strukturiert: technische Stolpersteine, Organisationslücken, Kostenabweichungen. Diese Erkenntnisse fließen direkt in das Cloud Adoption Framework ein und schärfen das Operating Model für nachfolgende Migrationswellen. Für den Dauerbetrieb nutzt das Team Azure Advisor, Well-Architected Reviews und den Copilot-Migrations-Agenten, um kontinuierlich Empfehlungen zu Kosten, Sicherheit, Performance und Reliability zu erhalten. Ergänzend sorgen Policy-as-Code und FinOps-Praktiken dafür, dass Abweichungen vom Zielzustand automatisiert erkannt und korrigiert werden. So wird aus der einmaligen Migration ein iterativer Verbesserungszyklus, der die Cloud-Landschaft dauerhaft effizient und compliant hält.
Beispiele aus der Praxis – Drei typische Migrationsszenarien
Ein mittelständisches Unternehmen konsolidiert sein Rechenzentrum. 300 virtuelle Maschinen – Windows, Linux, SQL Server – wandern per Lift-and-Shift in vier Wellen über zwölf Wochen nach Azure. Die Azure Migrate Appliance entdeckt Abhängigkeiten automatisch, das Assessment quantifiziert die Einsparung: 32 Prozent geringere Gesamtkosten gegenüber dem Weiterbetrieb on-premises.
Ein Independent Software Vendor modernisiert seinen .NET-Monolithen. Statt reiner VM-Migration wählt das Team den Pfad zu Azure Kubernetes Service (AKS) mit Container Apps. Das Assessment empfiehlt das PaaS-Zielmodell, ein Pilot validiert die CI/CD-Pipeline und zeigt, wie sich Deployments von Tagen auf Minuten verkürzen lassen. Die Migrationslösungen für Webanwendungen liefern dafür Referenzarchitekturen und Automatisierung.
Ein Kunde betreibt SQL Server 2012 und Windows Server 2012 R2 jenseits des Mainstream-Supports. Über Azure Dedicated Host mit Extended Security Updates (ESU) bleiben die Workloads kompliant in der Cloud, während die schrittweise Modernisierung vorbereitet wird. So vermeidet das Unternehmen Bußgeldrisiken und gewinnt Zeit für Refactoring ohne Betriebsunterbrechung.
