Cloud-Migration planen: Checkliste für den Umzug

Warum eine strukturierte Cloud-Migration entscheidend ist

Die Verlockung ist groß: schnell ein paar Server in die Cloud verschieben, Kosten sparen, fertig. Die Realität sieht anders aus. Laut Gartner scheitern rund 30 Prozent aller Cloud-Migrationsprojekte oder überschreiten Budget und Zeitrahmen massiv. Der häufigste Grund ist nicht mangelnde Technologie, sondern fehlende Planung.

Eine Cloud-Migration betrifft nicht nur die IT-Abteilung. Sie verändert Betriebsprozesse, Sicherheitsarchitekturen, Lizenzmodelle und die Art, wie Teams zusammenarbeiten. Wer ohne strukturierten Plan migriert, riskiert Ausfallzeiten, Datenverluste, explodierende Kosten und frustrierte Mitarbeiter.

Dieser Leitfaden gliedert die Cloud-Migration in fünf aufeinander aufbauende Phasen. Jede Phase enthält eine konkrete Checkliste mit den Aufgaben, die Sie abarbeiten müssen, bevor Sie zur nächsten Phase übergehen. So behalten Sie den Überblick, auch wenn das Projekt komplex wird.

Phase 1: Assessment - Die Bestandsaufnahme

Bevor Sie irgendetwas migrieren, müssen Sie wissen, was Sie haben. Das klingt trivial, ist in der Praxis aber die anspruchsvollste Phase. Viele Unternehmen haben keinen vollständigen Überblick über ihre IT-Landschaft - insbesondere bei gewachsenen Infrastrukturen mit Schatten-IT, Legacy-Systemen und undokumentierten Abhängigkeiten.

Anwendungsinventar erstellen

Erfassen Sie jede Anwendung, jeden Server und jeden Dienst, der in Ihrem Rechenzentrum läuft. Dazu gehören nicht nur die offensichtlichen Produktivsysteme, sondern auch Testumgebungen, interne Tools, Batch-Jobs und Datenbanken. Nutzen Sie Discovery-Tools wie Azure Migrate, AWS Application Discovery Service oder Open-Source-Alternativen wie RackTables, um automatisiert zu inventarisieren.

Abhängigkeiten kartieren

Welche Anwendung spricht mit welcher Datenbank? Welcher Dienst hängt von welchem API-Endpunkt ab? Dependency Mapping ist kritisch, weil Sie sonst beim Cutover feststellen, dass ein migrierter Service einen noch nicht migrierten Dienst im lokalen Rechenzentrum braucht. Tools wie ServiceNow Discovery oder Application Dependency Mapping helfen, diese Verflechtungen sichtbar zu machen.

Kosten analysieren

Ermitteln Sie die Total Cost of Ownership (TCO) Ihrer aktuellen Infrastruktur. Dazu zählen Hardware-Abschreibungen, Strom, Kühlung, Raummiete, Personalkosten für Administration, Lizenzkosten und Wartungsverträge. Nur mit einer ehrlichen Baseline können Sie die Cloud-Kosten realistisch vergleichen. Vorsicht vor dem häufigen Fehler, nur die Hosting-Kosten zu vergleichen und den Betriebsaufwand zu ignorieren.

Phase 2: Strategie - Die 6 Rs der Cloud-Migration

Nicht jede Anwendung gehört in die Cloud, und nicht jede Cloud-Migration bedeutet dasselbe. Das Modell der 6 Rs bietet einen bewährten Rahmen, um für jede Anwendung die passende Migrationsstrategie zu wählen. Jede Strategie hat unterschiedliche Auswirkungen auf Kosten, Zeitaufwand und Nutzen.

Rehost (Lift and Shift)

Die Anwendung wird eins zu eins in die Cloud verschoben, ohne Änderungen am Code oder der Architektur. Ein On-Premise-Server wird zur virtuellen Maschine in der Cloud. Das geht schnell und ist risikoarm, schöpft aber die Cloud-Vorteile nicht voll aus. Ideal für schnelle Migrationen oder wenn die Anwendung bald abgelöst wird.

Replatform (Lift, Tinker and Shift)

Kleinere Anpassungen, um Cloud-Dienste zu nutzen, ohne die Kernarchitektur zu ändern. Beispiel: Eine Anwendung auf eine verwaltete Datenbank umstellen statt eine eigene Datenbank-VM zu betreiben. Guter Kompromiss zwischen Geschwindigkeit und Cloud-Optimierung.

Refactor (Re-Architect)

Die Anwendung wird grundlegend umgebaut, um Cloud-native Technologien wie Container, Serverless oder Microservices zu nutzen. Aufwändig und teuer, aber langfristig die beste Skalierbarkeit und Kosteneffizienz. Sinnvoll für strategisch wichtige Anwendungen mit langer Lebensdauer.

Repurchase (Drop and Shop)

Die bestehende Lösung wird durch ein SaaS-Produkt ersetzt. Statt einen eigenen Exchange-Server zu migrieren, wechseln Sie zu Microsoft 365. Eliminiert Betriebsaufwand komplett, erfordert aber Datenmigration und Anpassung der Prozesse.

Retain (Revisit)

Die Anwendung bleibt vorerst On-Premise. Gründe können technische Einschränkungen, regulatorische Anforderungen oder laufende Verträge sein. Wichtig: Retain ist eine bewusste Entscheidung, kein Aufschub.

Retire (Decommission)

Die Anwendung wird abgeschaltet. Beim Assessment stellt sich häufig heraus, dass 10 bis 20 Prozent der Anwendungen nicht mehr genutzt werden oder redundant sind. Jede abgeschaltete Anwendung spart Lizenz- und Betriebskosten.

Strategie	Aufwand	Dauer	Cloud-Nutzen	Typischer Einsatz
Rehost	Gering	Tage-Wochen	Niedrig	Legacy-Systeme, schnelle Migration
Replatform	Mittel	Wochen-Monate	Mittel	Datenbanken, Middleware
Refactor	Hoch	Monate	Hoch	Strategische Kernanwendungen
Repurchase	Mittel	Wochen-Monate	Hoch	E-Mail, CRM, ERP
Retain	Keiner	-	Keiner	Regulatorik, Spezial-Hardware
Retire	Gering	Tage	Indirekt	Ungenutzte, redundante Systeme

Phase 3: Planung - Migrationswellen und Reihenfolge

Alles gleichzeitig migrieren ist keine Option. Stattdessen teilen Sie die Migration in Wellen auf. Jede Welle umfasst eine Gruppe von Anwendungen, die zusammen migriert werden können, weil sie voneinander abhängen oder weil die Reihenfolge logisch ist.

Migrationswellen definieren

Beginnen Sie mit einfachen, unkritischen Anwendungen in Welle 1. Das Team sammelt Erfahrung, Prozesse werden eingespielt und Fehler haben geringe Auswirkungen. Erst wenn die erste Welle erfolgreich abgeschlossen ist, folgen komplexere Systeme. Typisch sind drei bis sechs Wellen über einen Zeitraum von sechs bis achtzehn Monaten.

Reihenfolge festlegen

Die Reihenfolge ergibt sich aus den Abhängigkeiten. Wenn Anwendung A von Datenbank B abhängt, muss B vor oder gleichzeitig mit A migriert werden. Berücksichtigen Sie auch Business-Zyklen: Migrieren Sie nicht das ERP-System während des Jahresabschlusses und nicht den Webshop vor dem Weihnachtsgeschäft.

Rollback-Strategie planen

Für jede Migrationswelle brauchen Sie einen Plan B. Was passiert, wenn die migrierte Anwendung in der Cloud nicht funktioniert? Können Sie schnell auf die On-Premise-Umgebung zurückfallen? Definieren Sie klare Rollback-Kriterien und testen Sie den Rollback-Prozess vor dem Cutover.

Phase 4: Migration - Durchführung und Cutover

Jetzt wird es ernst. Die eigentliche Migration folgt dem Plan aus Phase 3, Welle für Welle. Der Cutover - der Moment, in dem der produktive Betrieb von On-Premise auf die Cloud umgestellt wird - ist der kritischste Punkt. Hier entscheidet sich, ob die Planung gut war.

Testmigration durchführen

Bevor Sie produktive Daten anfassen, führen Sie für jede Welle eine vollständige Testmigration durch. Migrieren Sie in eine Testumgebung, prüfen Sie die Funktionalität und messen Sie die Dauer. Nur wenn die Testmigration erfolgreich ist, geben Sie die produktive Migration frei.

Datenmigration planen

Die Datenmigration ist oft der zeitkritischste Teil. Bei großen Datenmengen kann eine Offline-Migration per physischem Datenträger (AWS Snowball, Azure Data Box) schneller sein als die Übertragung über das Netzwerk. Planen Sie die Synchronisation der Daten, die sich während der Migration ändern, über Delta-Sync oder Change Data Capture.

Cutover-Fenster festlegen

Der Cutover muss in einem Wartungsfenster stattfinden, in dem die Anwendung nicht produktiv genutzt wird - typischerweise am Wochenende oder in den Nachtstunden. Kommunizieren Sie das Fenster rechtzeitig an alle Beteiligten. Definieren Sie den Point of No Return: Ab welchem Zeitpunkt wird nicht mehr zurückgerollt, sondern in der neuen Umgebung stabilisiert?

Phase 5: Optimierung - Nach der Migration

Die Migration ist abgeschlossen, die Systeme laufen in der Cloud. Jetzt beginnt die Phase, die viele Unternehmen vernachlässigen: die Optimierung. Die initialen Cloud-Konfigurationen sind selten optimal. Erst nach einigen Wochen Produktivbetrieb zeigt sich, wo Ressourcen überdimensioniert oder unterdimensioniert sind.

Right-Sizing durchführen

Die meisten Unternehmen provisionieren Cloud-Ressourcen zunächst grosszügig, um Risiken zu minimieren. Nach vier bis sechs Wochen zeigen die Monitoring-Daten, welche Instanzen zu groß dimensioniert sind. Durch Right-Sizing - das Anpassen der Instanzgrössen an den tatsächlichen Bedarf - lassen sich typischerweise 20 bis 40 Prozent der Compute-Kosten einsparen.

Reserved Instances und Savings Plans

Wenn klar ist, welche Ressourcen langfristig benötigt werden, können Reserved Instances (1 oder 3 Jahre Vertragsbindung) die Kosten um 30 bis 72 Prozent senken. Azure bietet Reserved VM Instances, AWS hat Savings Plans und Spot Instances für flexible Workloads.

Alte Umgebung dekommissionieren

Vergessen Sie nicht, die alte On-Premise-Umgebung nach der Stabilisierungsphase abzuschalten. Parallel laufende Umgebungen verursachen doppelte Kosten. Definieren Sie eine Frist - typischerweise 30 bis 90 Tage nach dem Cutover - nach der die alte Umgebung endgültig abgeschaltet wird.

Die 5 häufigsten Fehler bei Cloud-Migrationen

Aus hunderten durchgeführten Migrationsprojekten kristallisieren sich immer wieder dieselben Fehler heraus. Wer sie kennt, kann sie vermeiden.

1. Lift and Shift als Dauerlösung

Rehost ist ein guter erster Schritt, aber kein Endzustand. Wer seine On-Premise-Architektur eins zu eins in der Cloud abbildet, zahlt oft mehr als vorher - ohne die Vorteile von Auto-Scaling, Managed Services oder Serverless zu nutzen. Planen Sie nach dem initialen Rehost eine schrittweise Modernisierung ein.

2. Kosten unterschätzen

Die Cloud ist nicht automatisch günstiger. Ohne aktives Kostenmanagement können die monatlichen Rechnungen schnell explodieren. Vergessene Testumgebungen, überdimensionierte Instanzen und ungenutzte Speicher-Volumes summieren sich. Implementieren Sie von Tag eins an Cost Tagging, Budgetalarme und regelmässige Kostenreviews.

3. Sicherheit nachlagern

Security muss von Anfang an Teil der Cloud-Architektur sein, nicht nachträglich draufgeschraubt. Shared Responsibility Model verstehen, Identity and Access Management korrekt aufsetzen, Netzwerksegmentierung in der Cloud planen und Verschlüsselung für Daten at rest und in transit aktivieren - das alles muss vor der ersten produktiven Migration stehen.

4. Kein Skill-Aufbau im Team

Cloud-Infrastruktur erfordert andere Kompetenzen als klassische On-Premise-Administration. Wenn das Team nicht geschult wird, entstehen Fehlkonfigurationen, Sicherheitslücken und ineffiziente Architekturen. Investieren Sie parallel zur Migration in Cloud-Schulungen und Zertifizierungen.

5. Big-Bang-Migration statt Wellen

Alles auf einmal migrieren maximiert das Risiko. Wenn etwas schiefgeht, ist alles betroffen. Ein wellenbasierter Ansatz erlaubt es, aus Fehlern zu lernen, Prozesse zu verbessern und das Risiko zu streuen. Die erste Welle ist immer ein Lernprojekt - behandeln Sie sie auch so.

Kosten und Zeitrahmen realistisch einschätzen

Die häufigste Frage vor einer Cloud-Migration: Was kostet es und wie lange dauert es? Eine pauschale Antwort gibt es nicht, aber die folgende Tabelle bietet eine Orientierung für typische Mittelstandsprojekte:

Projektgrösse	Anzahl Systeme	Dauer	Projektkosten ca.
Klein	5-15 Server	2-4 Monate	15.000-40.000 EUR
Mittel	15-50 Server	4-9 Monate	40.000-120.000 EUR
Groß	50-200 Server	9-18 Monate	120.000-400.000 EUR
Enterprise	200+ Server	12-24 Monate	Ab 400.000 EUR

Diese Kosten umfassen Beratung, Planung, Durchführung und initiale Optimierung. Nicht enthalten sind die laufenden Cloud-Betriebskosten, die je nach Nutzung monatlich anfallen. Die Projektkosten amortisieren sich bei den meisten Unternehmen innerhalb von 18 bis 36 Monaten durch reduzierte Betriebskosten, höhere Skalierbarkeit und weniger ungeplante Ausfälle.

On-Premise, Hybrid oder Full Cloud?

Nicht jedes Unternehmen muss vollständig in die Cloud. Die richtige Antwort hängt von Ihrer spezifischen Situation ab. Drei Modelle stehen zur Wahl:

Full Cloud

Alle Systeme laufen in der Cloud. Kein eigenes Rechenzentrum mehr. Ideal für Unternehmen ohne Spezial-Hardware, mit variablen Workloads und dem Wunsch nach maximaler Flexibilität. Voraussetzung: zuverlässige Internetanbindung und Cloud-Kompetenzen im Team.

Hybrid Cloud

Teile der Infrastruktur bleiben On-Premise, andere laufen in der Cloud. Der häufigste Ansatz im Mittelstand. Sensible Daten oder latenzempfindliche Anwendungen bleiben lokal, während Standardworkloads, Backups und Entwicklungsumgebungen in die Cloud wandern. Erfordert eine sichere Verbindung zwischen beiden Welten.

On-Premise mit Cloud-Erweiterung

Das eigene Rechenzentrum bleibt das Hauptsystem. Die Cloud wird punktuell genutzt - für Disaster Recovery, Burst-Kapazitäten oder spezifische SaaS-Dienste. Der konservativste Ansatz mit dem geringsten Veränderungsaufwand, aber auch dem geringsten Cloud-Nutzen.

Kriterium	Full Cloud	Hybrid	On-Premise+
Flexibilität	Sehr hoch	Hoch	Mittel
Datensouveränität	Eingeschränkt	Wählbar	Vollständig
Initialkosten	Hoch (Migration)	Mittel	Gering
Betriebskosten	Variabel	Gemischt	Fix + variabel
Komplexität	Mittel	Hoch	Gering
Skalierung	Sofort	Cloud-Anteil sofort	Hardware-abhängig

Fazit: Planung schlägt Geschwindigkeit

Eine erfolgreiche Cloud-Migration ist kein Sprint, sondern ein Marathon mit klarem Streckenplan. Die fünf Phasen - Assessment, Strategie, Planung, Migration und Optimierung - bilden das Grundgerüst für jeden Migrationserfolg. Überspringen Sie keine Phase, auch wenn der Druck groß ist, schnell Ergebnisse zu liefern.

Die wichtigsten Erfolgsfaktoren im Überblick: Investieren Sie ausreichend Zeit in das Assessment, damit Sie wissen, was Sie migrieren. Wählen Sie für jede Anwendung die richtige R-Strategie. Migrieren Sie in Wellen, nicht als Big Bang. Planen Sie Rollbacks für jede Welle. Und vergessen Sie die Optimierung nach der Migration nicht.

Mit der richtigen Planung wird die Cloud-Migration vom Risikoprojekt zum strategischen Vorteil. Ihr Unternehmen gewinnt Flexibilität, Skalierbarkeit und - bei korrekter Umsetzung - auch Kosteneffizienz. Der erste Schritt: Nehmen Sie sich die Checklisten aus diesem Artikel und starten Sie mit dem Assessment.