Lift-and-Shift oder Refactoring? 7 Kriterien für die Azure-Migration

Stand: November 2026

Einleitung: Die Frage, die jede Migration stellt

Der Mietvertrag für das Rechenzentrum läuft aus. Die Hardware erreicht End-of-Life. Der Druck steigt, Workloads in die Cloud zu bringen – und zwar schnell. Genau hier stellt sich die zentrale Frage: Lift-and-Shift oder Refactoring? Ein reiner 1:1-Umzug auf Azure Virtual Machines (Rehosting) verspricht Geschwindigkeit. Eine cloud-native Modernisierung (Refactoring) verspricht langfristige Effizienz. Beides stimmt – und beides greift zu kurz, wenn es als pauschale Entscheidung für die gesamte Applikationslandschaft verkauft wird.

Microsofts 6-Rs-Framework macht deutlich: Migration ist kein Entweder-oder. Rehost, Replatform, Refactor, Repurchase, Retire, Retain – jede Strategie passt zu bestimmten Workloads. Der Cloud Adoption Framework empfiehlt daher eine workload-spezifische Bewertung statt eines Generalverdachts.

In den folgenden sieben Kriterien leiten wir Sie durch die Entscheidung. Sie lernen, woran Sie harten Zeitdruck erkennen, wie technische Schulden die Wahl beeinflussen und warum Team-Skills oft wichtiger sind als Architekturdiagramme. Am Ende steht keine binäre Antwort, sondern ein Migrationsplan, der jede Anwendung dort abholt, wo sie heute steht – und dorthin bringt, wo sie morgen Wert schafft.

Bevor du startest: 3 Klärungsfragen

Drei Antworten entscheiden, ob der Migrationspfad überhaupt verhandelbar ist. Erst wenn sie stehen, lohnt der Blick in die Kriterien-Matrix.

1. Gibt es ein hartes Exit-Datum?

Mietvertragsende, Hardware-EOL oder Lizenzablauf zwingen zum Tempo. Wer in sechs Wochen raus muss, hat keine Wahl: Lift-and-Shift ist der einzige realistische Pfad. Ohne externen Druck gewinnt Refactoring an Spielraum. Ein harter Stichtag schiebt die Entscheidung oft allein auf die Rehost-Seite – auch wenn die Folgekosten steigen. Cigen bestätigt, dass Exit-Druck die häufigste Ursache für reine Rehost-Projekte ist.

2. Wie verteilt sich das Budget auf CAPEX und OPEX?

Lift-and-Shift schont das Initialbudget (geringer Engineering-Aufwand), hebt aber die laufenden Betriebskosten an, weil On-Prem-Architekturen Cloud-Elastizität nicht nutzen. Refactoring verlangt Investitionen in Entwicklung und Tests, senkt dafür langfristig die OPEX durch Autoscaling, Managed Services und Rechte-Sizing. Kläre vorab: Welcher Topf ist gefüllt, welcher gedrosselt?

3. Welchen Cloud-Reifegrad hat das Team?

Container, PaaS, Serverless – wenn niemand davon produktiv gearbeitet hat, scheitert Refactoring an der Lernkurve. Ein Team, das nur VMs kennt, liefert schneller stabile Rehost-Ergebnisse. Crucial Logics beschreibt das als Sequenzierungsproblem: Erst migrieren, dann Skills aufbauen, anschließend modernisieren. Die ehrliche Bestandsaufnahme der Kompetenzen verhindert teure Fehlstarts.

Die 7 Auswahlkriterien für Ihre Migrationsstrategie

Microsofts Cloud Adoption Framework und die Beratungspraxis zeigen: Keine Workload passt in ein einziges Schema. Jede Anwendung erfordert eine eigene Bewertung entlang sieben Entscheidungshebel. Azure Migrate liefert dafür das Datenfundament – automatisierte Inventarisierung, Abhängigkeitsanalyse und Kostenprognose.

• Zeitdruck / Data-Center-Exit (harte Deadlines vs. Spielraum)
• Budgetrahmen (CAPEX-schonender Einstieg vs. OPEX-Optimierung)
• Applikationskomplexität & Abhängigkeiten (Monolith vs. modulare Architektur)
• Technischer Schuldenberg (stabil laufend vs. beherrschbar modernisierbar)
• Business-Kritikalität & Skalierungsbedarf (intern/konstant vs. kundenfern/spiky)
• Team-Skills & Kapazität (VM-Know-how vs. Cloud-Native-Expertise)
• Compliance & Data Sovereignty (schnelle Regionswahl vs. zertifizierte PaaS)

Die nachfolgenden Abschnitte beleuchten jedes Kriterium mit Definition, Relevanz und konkreten Prüfschritten.

1. Zeitdruck & Data-Center-Exit

Harte Deadlines geben den Takt vor. Ein auslaufender Mietvertrag, Hardware am EOL oder der Ablauf kritischer Lizenzen zwingen zum Handeln. In solchen Szenarien bleibt oft nur ein schmaler Korridor zwischen Entscheidung und Produktion.

Lift-and-Shift lässt sich in Wochen realisieren, während Refactoring typischerweise Monate bis Jahre bindet. Diese Differenz entscheidet über Machbarkeit. Wer den Exit-Termin kennt, kann den verbleibenden Zeitraum gegen den geschätzten Migrationsaufwand rechnen – inklusive Puffer für Tests, Abnahme und Rollback-Szenarien.

Ein konkretes Faustmaß: Liegen weniger als sechs Monate bis zum Stichtag, spricht alles für Rehost als ersten Schritt. Die Anwendung läuft dann in Azure, der Vertrag ist gerettet, und das Team gewinnt Zeit für spätere Modernisierung. Cigen bestätigt, dass reine Rehost-Projekte regelmäßig innerhalb weniger Wochen abschließen, während architektonische Umbauten deutlich längere Horizonte benötigen.

Zugleich warnt Netrix davor, Zeitdruck als Dauerargument für Lift-and-Shift zu missbrauchen. Wer ohne Not auf Refactoring verzichtet, zahlt langfristig höhere Betriebskosten und verpasst Cloud-native Vorteile. Die saubere Lösung: Exit-Datum festlegen, Puffer einplanen, dann entscheiden – nicht umgekehrt.

2. Budget: CAPEX vs. OPEX

Lift-and-Shift schont das Investitionsbudget. Die Migration auf virtuelle Maschinen gelingt ohne Code-Änderungen, sodass Engineering-Kosten minimal bleiben. Doch dieser Vorteil kehrt sich im Betrieb um: On-Premise-Architekturen nutzen die Elastizität der Cloud nicht. Ressourcen laufen rund um die Uhr dimensioniert für Lastspitzen – die sogenannte Lift-and-Shift Penalty treibt die monatlichen Betriebskosten nach oben.

Refactoring dreht das Kostenprofil um. Der Einstieg erfordert substantielles Entwicklungsbudget für Architekturumbau, Containerisierung und PaaS-Migration. Dafür sinken die laufenden Ausgaben: Autoscaling passt Kapazität an tatsächliche Last an, Managed Services reduzieren Administrationsaufwand, und Lizenzmodelle lassen sich optimieren – etwa durch Azure Hybrid Benefit oder Serverless-Abrechnung.

Die Entscheidung verlangt ein TCO-Modell über drei bis fünf Jahre. Erfassen Sie initiale Migrationskosten, laufende VM-Preise, PaaS-Gebühren, Personalaufwand für Betrieb und Weiterentwicklung. Prüfen Sie, ob CAPEX für den Refactoring-Start verfügbar ist oder ob OPEX-Spielraum die Rehost-Variante erzwingt. Berechnen Sie den Break-even-Punkt: Ab wann amortisieren sich die höheren Initialinvestitionen durch niedrigere Betriebskosten? Ein Vergleich beider Ansätze zeigt, dass Workloads mit stark schwankender Last schneller vom Refactoring profitieren als konstant ausgelastete Systeme.

3. Applikations-Komplexität & Abhängigkeiten

Monolithische Legacy-Anwendungen mit undokumentierten Dependencies, Third-Party-Komponenten oder hardcodierten IPs bilden die größte Hürde für Refactoring. Wer den Code nicht vollständig versteht, riskiert bei jedem Eingriff Produktionsausfälle. Hohe Komplexität plus unbekannte Abhängigkeiten gleich hohes Risiko – diese Gleichung zwingt oft zum Lift-and-Shift.

Die Analyse beginnt mit Dependency Mapping über Azure Migrate. Application Insights und Service Map visualisieren Laufzeitbeziehungen zwischen Diensten, Datenbanken und externen Schnittstellen. Ergänzend prüfen Teams, ob Third-Party-Hersteller Cloud-Versionen ihrer Komponenten anbieten und unter welchen Lizenzbedingungen diese betrieben werden dürfen. Fehlt diese Information, bleibt die Anwendung eine „Black Box“.

• Inventarisieren Sie alle Laufzeitabhängigkeiten automatisiert – manuelle Listen sind unvollständig.
• Klassifizieren Sie Abhängigkeiten: intern (steuerbar), Third-Party (Verhandlungsmasse), Hardcoded (Refactoring-Blocker).
• Bewerten Sie Testabdeckung: Ohne automatisierte Regressionstests ist Refactoring ein Blindflug.

Eine technische Tiefeanalyse zeigt: Je mehr „Tribal Knowledge“ den Betrieb trägt, desto stärker spricht das für Rehosting als ersten Schritt. Die Migration kauft Zeit, die Architektur لاحقًا gezielt zu entflechten – Workload für Workload, nicht im Big Bang.

4. Technischer Schuldenberg

Technischer Schuldenberg entscheidet oft über den Migrationspfad. Veraltete Frameworks, fehlende Tests und Spaghetti-Code kennzeichnen hohe Schulden. Wer sie ignoriert, zahlt in der Cloud doppelt: Lift-and-Shift konserviert die Altlasten auf virtuellen Maschinen, während Refactoring zum Risiko wird, weil jede Code-Änderung Seiteneffekte triggert.

Ein Code-Health-Assessment mit Tools wie SonarQube oder CAST liefert die nötige Basis. Daraus lässt sich der Refactoring-Aufwand in Personentagen schätzen und gegen das Risiko eines instabilen Betriebs abwägen. Laut Crucial Logics bewährt sich bei kritischen Systemen oft ein zweistufiger Ansatz: erst Rehost für schnellen Data-Center-Exit, danach schrittweise Entschuldung nach Business-Priorität. Brewed in the Cloud bestätigt, dass hybride Sequenzierung State-of-the-Art ist – Lift-and-Shift kauft Zeit, Refactoring kauft Effizienz. Teams sollten den Schuldenberg also nicht als Blockierer sehen, sondern als Steuerungsgröße für die Migrationsreihenfolge. Eine priorisierte Rückführungsliste schafft Transparenz und verhindert, dass technische Altlasten die Cloud-Kosten dauerhaft treiben.

5. Business-Kritikalität & Skalierungsbedarf

Umsatzrelevante, kundennahe Systeme – E-Commerce-Plattformen, Self-Service-Portale, Buchungsstrecken – weisen typischerweise spitze, kaum vorhersagbare Lastprofile auf. Interne Tools wie ERP-Backends oder Dokumentenarchive laufen dagegen oft mit konstanter, planbarer Auslastung. Diese Unterscheidung steuert die Migrationsstrategie maßgeblich: Customer-facing Workloads profitieren überproportional von cloud-nativer Elastizität, automatischem Failover und schneller Feature-Velocity, die PaaS- und Serverless-Dienste liefern.

Die Prüfung erfolgt in drei Schritten. Erstens: Business Value Scoring – wie stark trägt die Applikation direkt zu Umsatz, Kundenzufriedenheit oder regulatorischer Compliance bei? Zweitens: Lastprofil analysieren – zeigen Monitoring-Daten (CPU, Requests, DB-Connections) ein „spiky“-Muster mit Spitzen, die das 5- bis 10-fache des Medians erreichen? Drittens: SLA-Anforderungen prüfen – fordern Verträge 99,95 % Verfügbarkeit oder Millisekunden-Latenzen bei Lastspitzen? Liegen hoher Business Value und hohe Variabilität vor, sollte Replatforming oder Refactoring priorisiert werden. Ein reines Rehosting auf VMs belässt die Skalierungslogik in der Anwendung und verpasst die operative Entlastung durch Azure Scale Sets, App Service oder AKS.

Praxisberichte bestätigen: Wer spitzenlastgetriebene Systeme erst per Lift-and-Shift verschiebt, zahlt später doppelt – einmal für überdimensionierte VMs, einmal für die nachträgliche Modernisierung. Analysen typischer Fallstricke zeigen, dass frühes Assessment der Lastprofile die teuersten Nacharbeiten vermeidet. Ergänzend liefert ein Überblick zu Migrationswerkzeugen Entscheidungshilfen, welche Azure-Services welches Skalierungsverhalten nativ abdecken.

6. Team-Skills & Kapazität

Das interne Know-how entscheidet oft über Erfolg oder Misserfolg einer Modernisierung. Fehlende Erfahrung mit DevOps-Pipelines, AKS, PaaS-Diensten wie App Service oder Azure SQL sowie Infrastructure-as-Code (Bicep, Terraform) führt regelmäßig zu Verzögerungen – nicht die Technologie selbst. Eine ehrliche Bestandsaufnahme verhindert Überraschungen mitten im Projekt.

Erstellen Sie eine Skills-Matrix für alle beteiligten Rollen: Entwickler, Betrieb, Sicherheit, Architektur. Bewerten Sie Kompetenzen in Container-Orchestrierung, Cloud-nativen Patterns (Retry, Circuit Breaker, Observability) und automatisierter Bereitstellung. Quantifizieren Sie den Schulungsbedarf in Personentagen und kalkulieren Sie Puffer für Lernkurven ein.

Wenn das Team klein ist und Cloud-Erfahrung fehlt, bietet sich ein gestaffelter Einstieg an: Erst Lift-and-Shift auf VMs, parallel Managed Services (Azure SQL Managed Instance, App Service) nutzen, um operative Routine zu gewinnen. Externe Begleitung durch Microsoft-Partner oder Managed-Service-Provider schließt die Lücke, ohne dauerhaft Abhängigkeiten zu schaffen. Ein Community-Bericht aus der Praxis zeigt, wie stark Unterschätzung des internen Aufwands Realisierungszeiträume sprengt.

Entscheidend: Planen Sie Kapazität für den Betrieb ab Tag eins ein. Refactoring ohne eigenes DevOps-Fundament erzeugt technischen Schuldenberg in der Cloud – teurer als on-premises.

7. Compliance & Data Sovereignty

Regulatorische Vorgaben bestimmen oft den Migrationspfad. Die DSGVO, BSI-KRITIS-Anforderungen und branchenspezifische Regularien verlangen zertifizierte Rechenzentren sowie nachvollziehbare Datenflüsse. Wer personenbezogene Daten verarbeitet, muss gemäß Art. 37 DSGVO einen Datenschutzbeauftragten benennen, sobald 20 Personen ständig mit der automatisierten Verarbeitung beschäftigt sind – eine Schwelle, die viele mittelständische IT-Landschaften bereits erreicht.

Ein Lift-and-Shift in eine zertifizierte Azure-Region (z. B. Germany West Central) ist häufig der schnellste Weg, Compliance-Nachweise zu erbringen. Die physische Verortung der VMs in einem auditierten Rechenzentrum erfüllt Data-Residency-Anforderungen unmittelbar. Anders verhält es sich bei PaaS-Diensten: Jeder Service – von Azure SQL Managed Instance bis App Service – muss einzeln auf dessen Zertifizierungsstand und regionale Verfügbarkeit geprüft werden.

Der Prüfpfad: Compliance-Katalog erstellen (welche Nachweise fordert der Prüfer?), Azure Compliance Manager nutzen, um Microsoft-Zertifikate (ISO 27001, SOC, C5) gegen eigene Anforderungen abzugleichen, Data Residency über Azure Policy erzwingen. Bei akutem Handlungsbedarf – etwa auslaufender Rechenzentrumsvertrag – bietet sich Rehost in die zertifizierte Region an; die PaaS-Migration folgt anschließend als gezielte Modernisierung.

Ein Distributor wie ALSO bündelt entsprechende Migrationspakete und unterstützt bei der Nachweisführung gegenüber Auditoren. Wichtig: Die Verantwortung für die rechtliche Würdigung bleibt beim Datenverantwortlichen – Microsoft liefert die zertifizierte Infrastruktur, der Kunde konfiguriert sie konform.

Fazit & nächste Schritte: Sequenzierung statt Binärentscheidung

Die sieben Kriterien liefern ein Entscheidungsraster pro Workload – nicht für die gesamte Landschaft. State-of-the-Art ist eine hybride Sequenzierung: Erst Lift-and-Shift für schnellen Data-Center-Exit und Stabilisierung, danach priorisierte Modernisierung der Business-kritischen Systeme durch Replatforming oder Refactoring. Wer alles auf einmal refaktoriert, blockiert Kapazitäten und verzögert den Nutzen. Wer alles nur repliziert, zahlt dauerhaft die „Lift-and-Shift-Penalty“ bei Betriebskosten und verpasster Elastizität.

Konkrete nächste Schritte lauten: (1) Azure Migrate Assessment starten – automatisierte Inventarisierung, Abhängigkeitsanalyse und Kostenprognose schaffen die Faktenbasis. (2) 6-Rs-Bewertung pro Workload durchführen – das Microsoft-Framework (Rehost, Replatform, Refactor, Repurchase, Retire, Retain) zwingt zur expliziten Entscheidung je Anwendung. (3) Migrationswellen planen – nach Business Value, Risiko und Teamkapazität priorisieren; Quick Wins zuerst, komplexe Refactoring-Projekte in späteren Wellen. (4) Governance & Cost Management etablieren – Policies, Tagging, Budgets und Monitoring vor der ersten Welle definieren, nicht nachträglich.

Methodischen Rahmen bietet der Microsoft Cloud Adoption Framework: Strategy, Plan, Ready, Adopt, Govern. Er übersetzt die technische Entscheidung in einen organisatorischen Prozess, der Stakeholder einbindet und technische Schulden nicht nur migriert, sondern gezielt abbaut. Die Sequenzierung kauft Zeit für den Exit und Effizienz für den Betrieb – beides nacheinander, nicht gleichzeitig.