Das 6-Rs-Migrationsframework

Das 6-Rs-Migrationsframework ist ein strukturierter Ansatz, um festzulegen, wie jede lokale Workload in die Cloud überführt werden soll. Microsoft und die gesamte Branche verwenden diese sechs Strategien — auch Migrationsmuster genannt —, um Portfolioentscheidungen effizient und konsistent zu treffen. Statt einen einheitlichen Ansatz auf alle Anwendungen anzuwenden, bewerten Architekten jede Anwendung einzeln und ordnen ihr das am besten geeignete R zu.

Rehost (Lift and Shift) bedeutet, eine Workload ohne Codeänderungen nach Azure zu verschieben. Sie übernehmen das vorhandene VM-Image oder die Anwendungsbinärdatei und führen sie auf Azure-IaaS aus. Dies ist die schnellste Strategie und wird typischerweise für schwer zu ändernde Legacyanwendungen oder für Organisationen mit engen Migrationsfristen verwendet. Die Replikations-Engine von Azure Migrate automatisiert das Rehosting der meisten Windows- und Linux-VMs.

Replatform (auch Lift, Tinker, and Shift genannt) umfasst kleinere Optimierungen während der Migration, ohne die Kernarchitektur zu ändern. Beispiele sind die Migration einer selbst verwalteten MySQL-Datenbank von einer VM zu Azure Database for MySQL oder der Ersatz eines selbst gehosteten SMTP-Relays durch Azure Communication Services. Sie profitieren von den Vorteilen verwalteter Dienste — Patching, Sicherungen und Skalierung —, ohne die Anwendungslogik neu schreiben zu müssen.

Rearchitect (oder Refactor) bedeutet, die Architektur einer Anwendung grundlegend zu ändern, um cloudnative Funktionen zu nutzen. Eine monolithische .NET-Anwendung kann beispielsweise in Microservices aufgeteilt werden, die auf Azure Container Apps bereitgestellt werden, oder ein auf Cron-Jobs basierendes Batchsystem kann als Azure Functions neu implementiert werden. Rearchitecting bietet langfristig die größten Vorteile bei Skalierbarkeit und Kosten, erfordert jedoch die höchsten Investitionen.

Rebuild bedeutet, die bestehende Anwendung vollständig aufzugeben und eine neue cloudnative Lösung zu entwickeln. Diese Strategie wird gewählt, wenn die Legacyanwendung zu teuer in der Wartung ist, einen Technologie-Stack am Ende seines Lebenszyklus verwendet oder selbst nach einer Migration die geschäftlichen Anforderungen nicht erfüllen kann. Rebuild bietet den größtmöglichen cloudnativen Vorteil, hat jedoch die längste Zeit bis zum Nutzen. Azure-PaaS- und serverlose Dienste wie Azure App Service, Azure Functions und Cosmos DB sind häufige Zielplattformen.

Replace bedeutet, eine bestehende lokale Anwendung durch ein kommerziell verfügbares SaaS-Produkt zu ersetzen, das gleichwertige oder bessere Funktionen bietet. Beispiele sind der Ersatz eines lokalen CRM-Systems durch Dynamics 365 oder eines veralteten Dateiservers durch SharePoint Online. Replace macht die Verwaltung der Infrastruktur vollständig überflüssig. Der Nachteil sind geringere Anpassungsmöglichkeiten sowie ein potenziell erheblicher Aufwand für Datenmigration und Änderungsmanagement.

Retire ist die einfachste Strategie: Sie ermitteln Anwendungen, die nicht mehr verwendet werden, redundant oder durch andere Systeme ersetzt worden sind, und nehmen sie außer Betrieb, anstatt sie zu migrieren. Die mit Azure Migrate erfassten Ermittlungsdaten zeigen häufig, dass ein erheblicher Anteil (manchmal 20–30 %) der lokalen Server nur sehr gering ausgelastet ist oder keine aktiven Benutzer hat. Durch die Außerbetriebnahme dieser Anwendungen verringern sich der Migrationsumfang, die Lizenzkosten und die betriebliche Komplexität.

Für die Auswahl des passenden R müssen Sie bei jeder Anwendung vier Faktoren analysieren: geschäftliche Kritikalität, technische Komplexität, Migrationszeitplan und Gesamtbetriebskosten. Ein einfaches Webfrontend ohne Integrationsabhängigkeiten ist ein guter Kandidat für Rehost. Eine Anwendung mit Hunderten gespeicherter Prozeduren und benutzerdefinierten Datenbankfunktionen benötigt möglicherweise Rearchitect oder Rebuild. Interne Tools mit geringem Wert sind besonders geeignete Kandidaten für Retire oder Replace.

Azure Migrate stellt eine Funktion namens Business Case bereit, die auf Grundlage von Auslastungsdaten, Lizenzen und Azure-Preisen automatisch eine Migrationsstrategie für ermittelte Server vorschlägt. Sie gruppiert Workloads in die Kategorien Rehost, Replatform und End-of-Support und schafft damit eine gute Ausgangsbasis für die 6-Rs-Klassifizierung. Sie können jede Empfehlung überschreiben und vor der Finalisierung des Migrationsplans zusätzlichen geschäftlichen Kontext angeben.

Sobald jeder Anwendung ein R zugewiesen wurde, gruppieren Sie sie in Migrationswellen. Kandidaten mit geringem Risiko für Rehost bilden typischerweise die erste Welle, um das Vertrauen des Teams und die Vertrautheit mit den Tools zu stärken. Rearchitect- und Rebuild-Projekte laufen in parallelen Arbeitsströmen mit längeren Zeitplänen. Abhängigkeiten zwischen Anwendungen — beispielsweise zwischen einer Webschicht und einer gemeinsam genutzten Datenbank — müssen berücksichtigt werden, damit zusammengehörige Anwendungen gemeinsam oder in der richtigen Reihenfolge migriert werden.

Die 6 Rs sind auf die Phase Adopt des Cloud Adoption Framework von Microsoft abgestimmt. Das CAF stellt Vorlagen für die Planung von Wellen, RACI-Matrizen und Fragebögen zur Workloadbewertung bereit, mit denen die 6 Rs im Unternehmensmaßstab umgesetzt werden. Die während der Phase Ready eingerichteten Governance-Leitplanken — Landing Zones, Richtlinien und Identität — müssen vor Beginn der Migrationswellen vorhanden sein, damit migrierte Workloads vom ersten Tag an in einer konformen Umgebung bereitgestellt werden.

Testen Sie Ihr Verständnis der Konzepte aus Microsoft Azure Fundamentals (AZ-900), die in dieser Lektion behandelt wurden.

In dieser Lektion haben Sie gelernt: Das 6-Rs-Framework (Rehost, Replatform, Rearchitect, Rebuild, Replace, Retire) stellt ein Vokabular für Migrationsentscheidungen bereit, jedes R weist einen anderen Kompromiss zwischen Kosten und Geschwindigkeit auf, und der Business Case von Azure Migrate kann auf Grundlage von Auslastungsdaten automatisch Strategien vorschlagen. Als Nächstes sehen wir uns an, wie Azure Migrate lokale Server ermittelt und bewertet.