Cloud-Migration für Unternehmen: Planung, Durchführung und Fallstricke

Eine Cloud-Migration verändert mehr als den technischen Speicherort von Anwendungen und Daten. Sie betrifft Geschäftsprozesse, Verantwortlichkeiten, Sicherheitsmodelle, Kostenstrukturen und die tägliche Arbeit der IT. Unternehmen profitieren deshalb vor allem dann, wenn sie die Migration als gesteuertes Transformationsprojekt behandeln und nicht als einmalige Serververlagerung.

Der folgende Leitfaden zeigt, wie eine belastbare Cloud-Strategie entsteht, welche Cloud-Modelle und Migrationsstrategien infrage kommen und wie sich Risiken von der Bestandsaufnahme bis zum laufenden Cloud-Betrieb beherrschen lassen.

Warum sich eine Cloud-Migration strategisch planen lässt

Eine Cloud-Migration lässt sich strategisch planen, indem Geschäftsziele, technische Voraussetzungen, Risiken und erwarteter Nutzen gemeinsam bewertet werden. Die Cloud ist dabei kein Selbstzweck, sondern ein Betriebsmodell, das zu den Anforderungen des Unternehmens passen muss.

Mögliche Ziele sind eine schnellere Bereitstellung neuer Umgebungen, bessere Skalierbarkeit, höhere Ausfallsicherheit oder der Abbau veralteter Rechenzentrumsstrukturen. Auch der Zugang zu Managed Services kann relevant sein. Dem stehen laufende Verbrauchskosten, neue Abhängigkeiten und höhere Anforderungen an Governance und Kompetenzen gegenüber.

Eine sinnvolle Entscheidungslogik folgt dem Prinzip Ziel, Risiko, Wirtschaftlichkeit:

• Ziel: Welches Geschäftsproblem soll gelöst werden, etwa lange Release-Zyklen oder unzureichende Kapazitäten?
• Risiko: Welche Daten, Anwendungen und Prozesse sind kritisch, und welche Ausfallzeit ist vertretbar?
• Wirtschaftlichkeit: Wie verändern sich Investitionen, Betriebskosten, Personalaufwand und Lizenzmodelle?

Eine Cloud-Strategie sollte außerdem festlegen, welche Workloads in die Cloud gehören, welche zunächst unverändert bleiben und welche stillgelegt oder ersetzt werden. Für komplexe oder geschäftskritische Vorhaben kann eine unabhängige Beratung helfen, Annahmen zu prüfen, Zielarchitekturen zu bewerten und interne Teams methodisch zu entlasten.

Bestandsaufnahme und Zielbild definieren

Die Bestandsaufnahme erfasst Anwendungen, Daten, Abhängigkeiten, Geschäftsprozesse und Sicherheitsanforderungen, bevor ein Cloud-Modell ausgewählt wird. Erst dieses Gesamtbild zeigt, welche Workloads technisch und organisatorisch für die Migration geeignet sind.

Ein belastbares Assessment dokumentiert mindestens:

• Applikationslandschaft, Eigentümer, Versionen und technische Lebenszyklen
• Datenarten, Speicherorte, Aufbewahrungsfristen und Datenflüsse
• Schnittstellen, Datenbanken, Identitätsdienste und externe Abhängigkeiten
• Verfügbarkeits-, Performance- und Wiederherstellungsanforderungen
• Datenschutz, Compliance, Schutzbedarf und regulatorische Vorgaben
• Aktuelle Lizenz-, Infrastruktur- und Betriebskosten

Danach wird das Zielbild beschrieben: Netzwerksegmentierung, Identitätsmanagement, Logging, Backup, Berechtigungen, Betriebsprozesse und Verantwortlichkeiten. Beim Cloud-Modell gilt eine einfache Orientierung:

• Public Cloud: sinnvoll bei elastischen Kapazitäten, standardisierten Services und hohem Automatisierungsbedarf; Kostenkontrolle und Datenklassifizierung werden wichtiger.
• Private Cloud: geeignet, wenn hohe Kontrolle, spezielle Sicherheitsanforderungen oder bestehende Investitionen eine Rolle spielen; Skalierung und Betriebsaufwand bleiben stärker beim Unternehmen.
• Hybrid Cloud: passend, wenn bestimmte Systeme oder Daten vorerst lokal bleiben müssen und dennoch Cloud-Ressourcen genutzt werden; die Integration erhöht jedoch die architektonische Komplexität.

Die Auswahl sollte nicht nur nach Anbieterfunktionen erfolgen. Entscheidend sind auch Datenresidenz, Portabilität, Service-Level, Exit-Szenarien und vorhandene Kompetenzen.

Die richtige Migrationsstrategie und Roadmap entwickeln

Die passende Migrationsstrategie hängt von Geschäftswert, technischer Komplexität, Zeitdruck und Modernisierungsziel ab. Rehost, Replatform und Refactor bilden dabei drei zentrale Optionen, die je nach Anwendung auch kombiniert werden können.

Rehost, Replatform oder Refactor?

• Rehost: Die Anwendung wird weitgehend unverändert verschoben. Das reduziert den initialen Aufwand, übernimmt aber bestehende technische Schulden und nutzt Cloud-Vorteile nur begrenzt.
• Replatform: Einzelne Komponenten werden angepasst, etwa Datenbanken oder Laufzeitumgebungen. Das verbessert Betrieb und Skalierung, erfordert aber mehr Tests.
• Refactor: Die Anwendung wird strukturell modernisiert, beispielsweise durch Container, Microservices oder ereignisbasierte Architektur. Das eröffnet langfristig größere Vorteile, verursacht jedoch den höchsten Aufwand und das größte Projektrisiko.

Eine Migrations-Roadmap priorisiert nicht automatisch die technisch einfachsten Systeme. Sinnvoll ist eine Bewertung nach Geschäftskritikalität, Abhängigkeiten, Änderungsaufwand, Sicherheitsrisiko und Lernwert. Ein begrenztes Pilotprojekt sollte repräsentativ sein, aber keinen zentralen Umsatzprozess gefährden.

Die Roadmap kann in Assessment, Landing-Zone-Aufbau, Pilot, Wellenmigration und Optimierung gegliedert werden. Jede Welle benötigt einen Verantwortlichen, messbare Abnahmekriterien, einen Termin für die Rückfallentscheidung und dokumentierte Abhängigkeiten. So entsteht ein kontrollierbarer Lernzyklus statt eines Big Bangs.

Cloud-Migration durchführen: Von der Vorbereitung bis zum Go-live

Eine Cloud-Migration wird sicher durchgeführt, wenn technische Vorbereitung, Tests, Datenübertragung, Rollen und Rückfallplanung vor dem Go-live geklärt sind. Die eigentliche Umschaltung ist nur ein kurzer Abschnitt eines deutlich längeren Betriebsprozesses.

Vor der Migration werden Zielkonten oder Abonnements, Netzwerk, Namensauflösung, Identitätsmanagement, Verschlüsselung, Logging und Berechtigungen eingerichtet. Infrastruktur als Code kann dabei für reproduzierbare Umgebungen sorgen. Gleichzeitig müssen Datenqualität, Backup-Fähigkeit und Abhängigkeiten geprüft werden.

Ein praxistauglicher Ablauf umfasst:

1. Quellsysteme einfrieren oder Änderungen kontrolliert erfassen.
2. Daten initial übertragen und die Vollständigkeit mit Prüfsummen oder fachlichen Kontrollen verifizieren.
3. Anwendung, Schnittstellen, Performance, Sicherheit und Wiederherstellung testen.
4. Fachbereiche in Abnahmetests einbeziehen und Schulungen für Support und Anwender durchführen.
5. Umschaltung in einem definierten Zeitfenster vornehmen und Monitoring intensivieren.
6. Bei festgelegten Schwellenwerten den Rückfallplan auslösen, statt improvisiert weiterzuarbeiten.

Rollen sollten über eine RACI-Zuordnung geklärt werden: Wer führt aus, wer trägt die Verantwortung, wer wird konsultiert und wer informiert? Zusätzlich braucht jede Migration einen Kommunikationsplan. Ein technisch erfolgreicher Go-live ist unzureichend, wenn Helpdesk, Fachabteilung und Notfallorganisation nicht vorbereitet sind.

Sicherheit, Datenschutz und Compliance absichern

Cloud-Sicherheit entsteht durch geteilte Verantwortung: Der Anbieter schützt definierte Teile der Plattform, während das Unternehmen unter anderem Identitäten, Konfigurationen, Daten und Zugriffe verantwortet. Datenschutz und Compliance müssen bereits in der Zielarchitektur berücksichtigt werden.

Zu den grundlegenden Kontrollen gehören:

• Mehr-Faktor-Authentifizierung und rollenbasierte, möglichst kurzlebige Berechtigungen
• Trennung von Entwicklungs-, Test- und Produktionsumgebungen
• Verschlüsselung bei Übertragung und Speicherung sowie sichere Schlüsselverwaltung
• Zentrale Protokollierung, unveränderbare Audit-Logs und regelmäßige Auswertung
• Getestete Backups mit definierten Recovery Point Objectives und Recovery Time Objectives
• Regelmäßige Schwachstellenprüfungen, Patch-Prozesse und Notfallübungen

Für personenbezogene Daten sind unter anderem Zweckbindung, Datenminimierung, Auftragsverarbeitung, Löschfristen und mögliche Drittlandtransfers zu prüfen. Der Anforderungskatalog des Bundesamts für Sicherheit in der Informationstechnik bietet dafür einen anerkannten Orientierungspunkt, ersetzt aber keine individuelle Risikoanalyse.

Governance definiert, wer neue Ressourcen genehmigt, welche Regionen erlaubt sind, wie Secrets behandelt werden und wann Zugriffe entzogen werden. Cloud-Sicherheit ist damit auch eine Frage von Prozessen und Verhalten, nicht nur von Firewall-Regeln.

Typische Fallstricke und wie Unternehmen sie vermeiden

Die häufigsten Fallstricke entstehen durch unvollständige Abhängigkeiten, fehlende Kostenkontrolle, unzureichende Tests und einen zu späten Aufbau von Betriebsprozessen. Unternehmen vermeiden sie mit frühzeitiger Dokumentation, klaren Verantwortlichkeiten und schrittweiser Validierung.

Abhängigkeiten werden unterschätzt

Eine Anwendung wirkt isoliert, nutzt aber möglicherweise versteckte Datenbanken, Batch-Jobs, Zertifikate oder externe Schnittstellen. Das passiert, weil Dokumentation veraltet und Wissen auf einzelne Mitarbeitende verteilt ist. Beim Cutover entstehen dann Fehlfunktionen und Verzögerungen. Abhilfe schaffen Dependency Mapping, Interviews mit Betrieb und Fachbereich sowie ein technischer End-to-End-Test.

Kosten werden nur beim Start betrachtet

Viele Teams kalkulieren Compute und Speicher, übersehen aber Datenübertragung, Lizenzen, Logging, Backups und dauerhaft laufende Ressourcen. Der Grund liegt häufig in einer statischen Budgetplanung für ein dynamisches Verbrauchsmodell. Abweichungen können sich innerhalb weniger Wochen aufbauen. Tags, Budgets, Anomaliealarme, Abschaltregeln und regelmäßige FinOps-Reviews schaffen Transparenz.

Skills und Betrieb kommen zu spät

Eine Migration wird technisch abgeschlossen, obwohl das Team noch keine Erfahrung mit Cloud-Sicherheit, Automatisierung oder Incident-Prozessen hat. Kurzfristig steigt dadurch die Abhängigkeit von externen Spezialisten. Unternehmen sollten Schulungen, Runbooks, Bereitschaftsmodelle und Übergabekriterien bereits vor dem Go-live einplanen. Externe IT-Services sind besonders bei fehlenden Spezialkenntnissen hilfreich, sollten aber Wissen im Unternehmen aufbauen.

Der Vendor Lock-in wird ignoriert

Managed Services verkürzen Entwicklungszeiten, können aber spätere Wechsel erschweren. Wer ausschließlich proprietäre Schnittstellen nutzt, akzeptiert höhere Umstellungskosten und geringere Portabilität. Eine bewusste Gegenmaßnahme sind dokumentierte Exit-Szenarien, standardisierte Datenformate, portable Container dort, wo sie wirtschaftlich sinnvoll sind, und eine regelmäßige Überprüfung kritischer Abhängigkeiten.

Betrieb, Optimierung und kontinuierliche Kontrolle

Nach der Migration beginnt der eigentliche Cloud-Betrieb: Monitoring, Kostenmanagement, Sicherheitskontrollen und kontinuierliche Verbesserung müssen dauerhaft organisiert werden. Eine Anwendung gilt erst dann als erfolgreich migriert, wenn sie stabil, wirtschaftlich und nachvollziehbar betrieben wird.

Monitoring sollte technische und geschäftliche Kennzahlen verbinden. Dazu zählen Verfügbarkeit, Antwortzeiten, Fehlerraten, Ressourcenauslastung, Datenbankzustand und erfolgreiche Geschäftsprozesse. Alarme brauchen klare Schwellenwerte und einen zuständigen Bearbeiter, sonst erzeugen sie nur Geräusche.

FinOps verbindet Finanz-, Fach- und IT-Teams. Monatliche Auswertungen sollten Kosten je Anwendung oder Produkt zeigen, ungenutzte Ressourcen identifizieren und den Verbrauch mit Geschäftswerten vergleichen. Einsparungen durch kleinere Instanzen oder automatische Skalierung dürfen dabei nicht die vereinbarten Performance- und Verfügbarkeitsziele gefährden.

Ein stabiler Betrieb umfasst außerdem Incident-, Problem- und Change-Management, regelmäßige Wiederherstellungstests sowie Sicherheits- und Architektur-Reviews. Nach jeder Migrationswelle sollten Erfahrungen in die nächste Welle einfließen. So wird die Cloud-Migration von einem Projekt zu einer belastbaren Fähigkeit des Unternehmens.

Häufige Fragen zur Cloud-Migration für Unternehmen

Wie lange dauert eine Cloud-Migration für ein Unternehmen?

Die Dauer hängt von Anzahl, Abhängigkeiten und Kritikalität der Workloads ab. Ein begrenzter Pilot kann wenige Wochen beanspruchen, während eine heterogene Applikationslandschaft mehrere Monate oder länger erfordert. Maßgeblich sind Assessment, Testaufwand, Datenschutzprüfung und verfügbare Teams.

Welche Cloud-Migrationsstrategie eignet sich für bestehende Anwendungen?

Rehost eignet sich für geringe Änderungen und schnellen Umzug, Replatform für gezielte technische Verbesserungen und Refactor für langfristige Modernisierung. Die Entscheidung sollte pro Anwendung anhand von Geschäftswert, Risiko, Aufwand und Lebensdauer getroffen werden.

Welche Kosten entstehen bei einer Cloud-Migration?

Zu berücksichtigen sind Beratung, Projektteam, Datenübertragung, Lizenzen, Anpassungen, Tests, Schulungen und mögliche Parallelbetriebe. Hinzu kommen laufende Kosten für Compute, Speicher, Netzwerk, Support, Monitoring und Backups. Eine belastbare Schätzung benötigt daher eine Workload-basierte Kalkulation statt eines pauschalen Prozentsatzes.

Wie lassen sich Datenschutz und Compliance in der Cloud sicherstellen?

Unternehmen benötigen eine Datenklassifizierung, dokumentierte Verantwortlichkeiten, geeignete Verträge, Zugriffskontrollen, Verschlüsselung, Protokollierung und regelmäßige Nachweise. Die konkrete Bewertung hängt von Branche, Datenarten und geltenden Vorschriften ab.

Wann ist eine Hybrid-Cloud-Strategie sinnvoll?

Eine Hybrid Cloud ist sinnvoll, wenn bestimmte Daten, Legacy-Systeme oder regulatorische Anforderungen vorerst lokal bleiben müssen und neue Dienste dennoch aus der Cloud bezogen werden sollen. Sie erhöht jedoch den Integrations- und Betriebsaufwand und sollte deshalb ein bewusstes Zielbild, kein ungeplanter Zwischenzustand sein.