Cloud-Migration: Lift & Shift vs. Refactoring

Jede Cloud-Migrationsdiskussion gelangt irgendwann an dieselbe Weggabelung: Soll man das Vorhandene verschieben oder neu aufbauen? Die kurze Antwort lautet, dass beide Strategien gültig sind – und die meisten Organisationen im Verlauf ihrer Cloud-Journey beide an unterschiedlichen Stellen einsetzen. Der Fehler liegt darin, eine Strategie undifferenziert auf alles anzuwenden, ohne zu verstehen, was jede in Zeit, Geld und Komplexität kostet.

Dieser Leitfaden erklärt, wie jeder Ansatz funktioniert, wann er sinnvoll ist und wie Sie die Entscheidung für Ihre spezifischen Workloads treffen. Wir behandeln auch die Anforderungen an den Datenspeicherort, die für Unternehmen unter deutschem und EU-Recht relevant sind – denn wo Ihre Daten liegen, ist hier keine rein technische Frage.

Was Lift & Shift in der Praxis bedeutet

Lift and Shift – auch Rehosting genannt – bedeutet, eine virtuelle Maschine oder einen Server-Workload mit minimalen Änderungen in die Cloud zu verschieben. Sie schreiben die Anwendung nicht neu, ändern nicht wie sie Daten speichert und überdenken die Architektur nicht. Sie nehmen den Server und stellen ihn in ein anderes Gebäude – nur dass dieses Gebäude ein Microsoft- oder AWS-Rechenzentrum ist.

Azure Migrate ist das primäre Werkzeug dafür im Microsoft-Ökosystem. Es inventarisiert Ihre On-Premise-Server, bewertet deren Kompatibilität und übernimmt die Replikation der VM-Festplatten nach Azure. Eine Migration, die früher wochenlange manuelle Arbeit erforderte, wird auf Tage verkürzt. Unser Managed Cloud-Team führt diesen Prozess end-to-end für DACH-Unternehmen durch.

Das Geschäftsargument ist Geschwindigkeit und Risikoreduzierung. Wenn Ihr Unternehmen sich einem Hardware-Erneuerungszyklus nähert und die bestehenden Server in die Jahre gekommen sind, ermöglicht Lift & Shift den vollständigen Ausstieg aus der physischen Infrastruktur ohne eine einzige Zeile Anwendungscode neu zu schreiben. Für ein deutsches Mittelstandsunternehmen, das DATEV, ein individuelles ERP und verschiedene Legacy-Windows-Server-Workloads betreibt, ist das oft der einzig realistische Weg in einem 12-Monats-Fenster.

Die versteckten Kosten

Lift & Shift ist schnell zu starten, aber oft teuer im Betrieb. Eine virtuelle Maschine, die für Spitzenlast auf einem physischen Server dimensioniert wurde, läuft 24 Stunden am Tag in der Cloud und wird entsprechend abgerechnet. Ein On-Premise-SQL-Server, der einmalig angeschafft wurde, kostet nun jeden Monat Geld. Viele Organisationen, die ohne Optimierung migrieren, stellen fest, dass ihre Cloud-Rechnung in den ersten sechs Monaten höher als erwartet ist – was Druck erzeugt, die Ressourcen mit Cloud-Kostenoptimierung anzupassen und die Modernisierungsarbeit trotzdem zu beginnen.

Was Refactoring bedeutet – und warum es sich lohnt

Refactoring bedeutet, Ihre Anwendung zu modifizieren, um Cloud-native Services zu nutzen. Anstatt eine SQL-Server-VM zu betreiben, migrieren Sie zu Azure SQL Database. Anstatt einen Fileserver als VM zu hosten, verschieben Sie Dokumente zu SharePoint oder Azure Blob Storage. Anstatt eines dedizierten Anwendungsservers erwägen Sie Azure App Service oder Container.

Der Unterschied bei den Betriebskosten ist erheblich. Azure SQL Database skaliert automatisch, Sie zahlen nur für die tatsächlich genutzte Compute-Kapazität, und Hochverfügbarkeit ist integriert. Eine SQL-Server-VM, die 24/7 für moderaten Datenverkehr läuft, ist fast immer teurer als ein gut konfigurierter Managed-Database-Service bei vergleichbarer Leistung.

Der Nachteil ist Zeit und Risiko. Refactoring erfordert Entwicklungsarbeit, gründliche Tests und sorgfältige Cutover-Planung. Für eine geschäftskritische Branchenanwendung mit begrenzter interner Dokumentation kann dieser Aufwand erheblich sein.

Ein Entscheidungsrahmen: Welche Workloads wohin

Statt eine Strategie für alles zu wählen, besteht der praktische Ansatz darin, jeden Workload zu kategorisieren. Hier ist ein Rahmen, der im DACH-Kontext gut funktioniert:

Datenspeicherort: Der DSGVO-Faktor

Für Unternehmen in Deutschland, Österreich und der Schweiz ist Cloud-Migration keine reine Kosten- und Leistungsentscheidung. Die Frage, wo Ihre Daten physisch gespeichert werden, ist unter DSGVO, Schweizer DSG und österreichischem DSG relevant. Personenbezogene Kundendaten, Mitarbeiterdaten und Finanzinformationen unterliegen strengen Anforderungen.

Microsoft Azure bietet dedizierte deutsche Rechenzentrumsregionen – Germany West Central (Frankfurt) und Germany North (Berlin). Die Wahl dieser Regionen für Workloads, die personenbezogene Daten verarbeiten, stellt sicher, dass Ihre Daten innerhalb der EU verbleiben und EU-Datenschutzrecht gilt – ohne Rückgriff auf Übertragungsmechanismen wie Standardvertragsklauseln.

Das BSI hat Cloud-Computing-Leitlinien im Rahmen von C5 (Cloud Computing Compliance Criteria Catalogue) veröffentlicht. Microsoft Azure hält eine C5-Attestierung, was bedeutet, dass unabhängige Prüfer verifiziert haben, dass Azures Sicherheitskontrollen den BSI-Standards entsprechen. Die BSI-C5-Attestierung hat mehr Gewicht, als viele annehmen — besonders bei Verhandlungen über Cyberversicherungen. Versicherer fragen zunehmend direkt danach, und wer sie vorlegen kann, verkürzt dieses Gespräch erheblich.

Ein praktischer Hinweis: Datenspeicherort ist nicht dasselbe wie Datensouveränität. Speicherort bedeutet, dass die Daten in Deutschland gespeichert werden. Souveränität bedeutet, dass keine Instanz außerhalb Deutschlands den Zugriff erzwingen kann. Microsofts EU-Datengrenzen-Zusage adressiert Ersteres, aber nicht in allen Fällen Letzteres. Organisationen mit besonders sensiblen Daten – Anwaltskanzleien, Gesundheitswesen, Finanzdienstleistungen – sollten diese Unterscheidung sorgfältig prüfen.

Der Migrationszeitplan: Was Sie erwarten können

Eine realistische Migration für ein Unternehmen mit 20–50 Mitarbeitern läuft typischerweise in vier Phasen:

1. Inventarisierung und Assessment (2–3 Wochen): Jeden Server, jede Anwendung und jede Abhängigkeit erfassen. Azure Migrate erstellt einen Bereitschaftsbericht und eine Kostenschätzung. Diese Phase deckt oft vergessene Server und Anwendungen auf, die niemand seit Jahren angefasst hat.
2. Proof of Concept (1–2 Wochen): Migration eines unkritischen Workloads – meist ein Entwicklungsserver oder internes Tool – zur Validierung von Konnektivität, Sicherheit und Leistung. Probleme werden in einer risikoarmen Umgebung behoben.
3. Migrations-Wellen (4–12 Wochen je nach Komplexität): Workloads werden in Batches nach Abhängigkeit migriert. E-Mail und Collaboration-Tools kommen zuerst, wenn sie On-Premise sind. Branchenanwendungen folgen. Die Datenmigration läuft parallel, wo möglich.
4. Optimierung (Laufend): VMs richtig dimensionieren, Azure Cost Management-Alarme einrichten, On-Premise-Hardware stilllegen. Die meisten Cloud-Kosteneinsparungen werden nicht bei der Migration realisiert, sondern in den darauffolgenden Monaten.