Inhaltsverzeichnis
Warum ein Cloud Migration Readiness Assessment?
Die Verlockung ist groß: Cloud-Anbieter versprechen Kostenersparnis, Skalierbarkeit und Innovation auf Knopfdruck. Doch die Realität sieht oft anders aus. Laut Gartner scheitern rund 30 % aller Cloud-Migrationsprojekte an mangelnder Vorbereitung — nicht an der Technologie selbst. Unternehmen, die ohne strukturiertes Assessment in die Migration starten, erleben regelmäßig Budgetüberschreitungen von 50 % und mehr.
Ein Cloud Migration Readiness Assessment ist kein bürokratischer Overhead, sondern eine strategische Investition. Es beantwortet die zentrale Frage: Ist Ihre Organisation — technisch, organisatorisch und prozessual — bereit für den Betrieb in der Cloud? Die Antwort darauf entscheidet, ob Ihre Migration ein Erfolg wird oder ein teures Experiment bleibt.
Die häufigsten Ursachen für gescheiterte Migrationen sind dabei erschreckend vorhersehbar: fehlende Kostentransparenz, unterschätzte Abhängigkeiten zwischen Systemen, mangelnde Cloud-Kompetenz im Team und unklare Verantwortlichkeiten. All diese Risiken lassen sich durch ein systematisches Assessment frühzeitig identifizieren und adressieren.
In der Praxis zeigt sich immer wieder dasselbe Muster: Unternehmen migrieren ihre ersten Workloads erfolgreich in die Cloud, feiern den vermeintlichen Erfolg — und stellen sechs Monate später fest, dass die monatlichen Cloud-Kosten das Dreifache des ursprünglichen On-Premises-Betriebs betragen. Der Grund? Sie haben zwar Server verschoben, aber weder ihre Architektur angepasst noch ihre Betriebsprozesse modernisiert. Ein Readiness Assessment hätte diese Diskrepanz aufgedeckt, bevor die erste Ressource provisioniert wurde.
30 % aller Cloud-Migrationen scheitern an mangelnder Vorbereitung. Ein strukturiertes Assessment reduziert dieses Risiko um bis zu 70 %.
Die 6R-Strategie: Migrationspfade verstehen
Bevor Sie einzelne Workloads bewerten, müssen Sie verstehen, welche Migrationspfade überhaupt zur Verfügung stehen. Das von Gartner etablierte 6R-Modell bietet einen bewährten Rahmen, um für jede Anwendung die richtige Strategie zu bestimmen. Nicht jede Anwendung gehört in die Cloud — und nicht jede muss komplett neu gebaut werden.
Die Wahl des richtigen Migrationspfads hat massive Auswirkungen auf Kosten, Timeline und Risiko. Ein Rehost einer Legacy-Anwendung kann in wenigen Wochen abgeschlossen sein, liefert aber kaum Cloud-Vorteile. Ein vollständiges Refactoring hingegen dauert Monate, ermöglicht aber langfristig deutlich niedrigere Betriebskosten und höhere Agilität. Die Kunst liegt darin, für jede Anwendung die richtige Balance zu finden.
- 1Rehost (Lift & Shift): Die schnellste Variante — Anwendungen werden 1:1 auf Cloud-VMs verschoben. Ideal für Datacenter-Konsolidierungen und als erster Schritt, wenn die Zeitvorgabe eng ist. Nachteil: Kaum Cloud-native Vorteile, potentiell höhere Kosten durch Overprovisioning.
- 2Replatform (Lift, Tinker & Shift): Kleine Optimierungen während der Migration — etwa der Wechsel von einer selbstverwalteten Datenbank zu einem Managed Service wie RDS oder Cloud SQL. Gutes Aufwand-Nutzen-Verhältnis bei moderatem Risiko.
- 3Repurchase (Drop & Shop): Ablösung einer bestehenden Anwendung durch eine SaaS-Lösung. Typisches Beispiel: Ein selbst betriebener E-Mail-Server wird durch Microsoft 365 ersetzt. Sinnvoll bei Commodity-Anwendungen, die keinen Wettbewerbsvorteil bieten.
- 4Refactor (Re-Architect): Die Anwendung wird für die Cloud neu architektiert — Microservices, Container, Serverless. Höchster Aufwand, aber auch höchster langfristiger Nutzen. Empfehlenswert für strategisch wichtige Anwendungen mit langer Lebensdauer.
- 5Retire: Abschalten von Anwendungen, die nicht mehr benötigt werden. In der Praxis finden sich bei einem Assessment erstaunlich viele Systeme, die niemand mehr aktiv nutzt, aber weiterhin Infrastrukturkosten verursachen. Die Migration ist der ideale Zeitpunkt für diese Bereinigung.
- 6Retain: Bewusste Entscheidung, bestimmte Workloads vorerst On-Premises zu belassen. Das kann regulatorische Gründe haben, an fehlender Cloud-Unterstützung liegen oder schlicht daran, dass der Business Case für eine Migration nicht gegeben ist.
15 Fragen für Ihre Cloud-Readiness
Die folgenden 15 Fragen bilden das Herzstück jedes Cloud Migration Readiness Assessments. Sie sind in fünf Dimensionen gegliedert, die gemeinsam ein vollständiges Bild Ihrer Migrationsfähigkeit zeichnen. Beantworten Sie jede Frage ehrlich — Schönfärberei rächt sich spätestens in der Umsetzung.
Jede Frage enthält Hinweise darauf, was eine gute Antwort auszeichnet und wo typische Fallstricke lauern. Nutzen Sie die Bewertung als Diskussionsgrundlage mit Ihrem Führungsteam, nicht als einsame Selbsteinschätzung der IT-Abteilung.
Strategie & Business Case (Fragen 1–3)
Frage 1: Was sind Ihre konkreten Geschäftstreiber für die Cloud-Migration? — Eine Cloud-Migration braucht einen klaren Business Case jenseits von „Alle machen das jetzt". Legitime Treiber sind Kostenoptimierung, Skalierbarkeit für wachsendes Geschäft, Innovationsbeschleunigung oder die Ablösung veralteter Infrastruktur. Wenn Ihr einziger Treiber „der CTO hat es auf einer Konferenz gehört" ist, sollten Sie innehalten. Die besten Migrationen werden von messbaren Geschäftszielen getrieben: 30 % kürzere Time-to-Market, 40 % Reduktion der Infrastrukturkosten oder 99,99 % Verfügbarkeit für geschäftskritische Systeme.
Frage 2: Haben Sie eine vollständige Total Cost of Ownership (TCO) Analyse durchgeführt? — Die TCO-Analyse ist der häufigste Schwachpunkt in Cloud-Businesscases. Viele Unternehmen vergleichen lediglich die Serverkosten — On-Premises-Hardware versus Cloud-VMs. Dabei werden versteckte Kosten systematisch übersehen: Datenübertragungsgebühren (Egress), Kosten für Logging und Monitoring, Premium-Support-Verträge, Schulungsaufwand und der Produktivitätsverlust während der Migration. Eine ehrliche TCO-Analyse umfasst mindestens 3 Jahre und berücksichtigt sowohl direkte als auch indirekte Kosten. Erst dann zeigt sich, ob die Cloud tatsächlich günstiger ist — oder ob der Mehrwert in anderen Bereichen liegt.
Frage 3: Wie sieht Ihre Migrations-Timeline aus — und ist sie realistisch? — „Wir wollen in sechs Monaten komplett in der Cloud sein" ist ein Satz, den wir als Berater regelmäßig hören — und der fast immer zu Enttäuschungen führt. Eine realistische Timeline berücksichtigt nicht nur die technische Migration, sondern auch Change Management, Schulungen, Testphasen und den parallelen Betrieb beider Umgebungen. Für mittelständische Unternehmen mit 20–50 Anwendungen ist eine Migrations-Timeline von 12–18 Monaten realistisch. Große Enterprises mit hunderten Anwendungen und komplexen Abhängigkeiten sollten 2–3 Jahre einplanen.
Technische Bereitschaft (Fragen 4–6)
Frage 4: Kennen Sie Ihre aktuelle IT-Landschaft vollständig? — Sie können nur migrieren, was Sie kennen. Klingt trivial, ist es aber nicht. In vielen Unternehmen existieren Shadow-IT-Systeme, undokumentierte Datenbankverbindungen und Legacy-Anwendungen, deren Verantwortlicher längst das Unternehmen verlassen hat. Ein vollständiges Application Portfolio Assessment — inklusive aller Abhängigkeiten, Datenflüsse und Integrationen — ist die unverzichtbare Grundlage jeder Migration. Tools wie AWS Migration Hub, Azure Migrate oder unabhängige Discovery-Tools helfen bei der automatisierten Erfassung.
Frage 5: Welche Workloads sind cloud-ready — und welche nicht? — Nicht jede Anwendung lässt sich problemlos in die Cloud verschieben. Mainframe-Anwendungen, Software mit hardwaregebundenen Lizenzen oder Systeme mit extremen Latenzanforderungen sind typische Kandidaten, die besondere Aufmerksamkeit erfordern. Bewerten Sie jeden Workload nach Kriterien wie: Zustandslosigkeit (stateless vs. stateful), Lizenzmodell (BYOL-fähig?), Abhängigkeit von spezifischer Hardware, Performance-Anforderungen und Datensensitivität. Diese Bewertung liefert die Grundlage für die 6R-Zuordnung.
Frage 6: Kennen Sie alle Abhängigkeiten zwischen Ihren Systemen? — Die unterschätzteste Dimension jeder Cloud-Migration sind die Abhängigkeiten. Eine Anwendung funktioniert selten isoliert — sie kommuniziert mit Datenbanken, API-Gateways, Message Queues, Shared Filesystems und anderen Anwendungen. Wenn Sie System A in die Cloud migrieren, aber System B (von dem A Daten bezieht) On-Premises bleibt, entsteht eine Hybrid-Situation mit Latenzproblemen und Komplexität. Dependency Mapping — idealerweise tool-gestützt und über mehrere Wochen hinweg erfasst — ist unverzichtbar.
Sicherheit & Compliance (Fragen 7–9)
Frage 7: Welche Compliance-Anforderungen gelten für Ihre Daten und Anwendungen? — Regulatorische Anforderungen können eine Cloud-Migration erheblich einschränken oder bestimmte Architekturentscheidungen erzwingen. DSGVO, BDSG, branchenspezifische Regulierung (BaFin, KRITIS, HIPAA) und vertragliche Verpflichtungen gegenüber Kunden definieren den Rahmen. Klären Sie frühzeitig: Welche Daten dürfen in die Cloud? Welche Cloud-Regionen sind zulässig? Gibt es Aufbewahrungspflichten, die bestimmte Storage-Klassen erfordern? Welche Zertifizierungen muss der Cloud-Anbieter vorweisen?
Frage 8: Wie gehen Sie mit Datensouveränität und Datenresidenz um? — Die Frage, wo Ihre Daten physisch gespeichert werden, ist keine rein technische — sie ist eine rechtliche und strategische. Für europäische Unternehmen gelten mit DSGVO und dem Schrems-II-Urteil strenge Vorgaben. AWS, Azure und GCP bieten alle Rechenzentren in Frankfurt und anderen EU-Standorten, aber nicht jeder Service ist in jeder Region verfügbar. Prüfen Sie für jeden Workload: Reicht eine EU-Region? Muss es Deutschland sein? Gibt es Daten, die On-Premises bleiben müssen? Sovereign Cloud Angebote wie die T-Systems Sovereign Cloud powered by Google Cloud adressieren dieses Thema explizit.
Frage 9: Wie sieht Ihre aktuelle Security Baseline aus? — Bevor Sie über Cloud-Security sprechen, müssen Sie Ihre aktuelle Security Baseline kennen. Viele Unternehmen projizieren Sicherheitserwartungen an die Cloud, die sie On-Premises nie erreicht haben. Dokumentieren Sie: Wie funktioniert Ihr Identity & Access Management heute? Wie werden Geheimnisse (Credentials, API Keys) verwaltet? Welche Verschlüsselungsstandards gelten? Wie sehen Ihre Incident-Response-Prozesse aus? Das Shared Responsibility Model der Cloud bedeutet, dass der Anbieter die Infrastruktur sichert — aber für die Konfiguration Ihrer Ressourcen sind Sie selbst verantwortlich. Fehlkonfigurationen in IAM-Policies oder offene S3-Buckets sind die häufigste Ursache für Cloud-Sicherheitsvorfälle.
Organisation & Skills (Fragen 10–12)
Frage 10: Verfügt Ihr Team über ausreichende Cloud-Kompetenzen? — Technologie ist nur so gut wie die Menschen, die sie bedienen. Eine ehrliche Skill-Gap-Analyse ist oft der unangenehme Teil des Assessments — aber der wichtigste. Bewerten Sie Ihr Team nach: Erfahrung mit Infrastructure-as-Code (Terraform, CloudFormation), Container-Orchestrierung (Kubernetes, ECS), Cloud-Networking (VPCs, Peering, Transit Gateway), Cloud-Security (IAM, Security Groups, KMS) und Cloud-nativer Entwicklung (Serverless, Managed Services). Identifizieren Sie nicht nur Wissenslücken, sondern auch Engpässe: Wenn nur eine Person im Team Terraform beherrscht, ist das ein Single Point of Failure.
Frage 11: Wer ist für die Migration verantwortlich — und hat diese Person Entscheidungsbefugnis? — Cloud-Migrationen scheitern selten an technischen Problemen und häufig an organisatorischen. Ohne einen dedizierten Migrationsverantwortlichen mit klarer Entscheidungsbefugnis und ausreichend Budget versanden Projekte in endlosen Abstimmungsschleifen. Der ideale Migrations-Owner sitzt an der Schnittstelle zwischen IT und Business, hat Zugriff auf das C-Level und kann cross-funktionale Teams koordinieren. In größeren Organisationen empfiehlt sich ein Cloud Center of Excellence (CCoE), das Best Practices definiert, Governance-Frameworks etabliert und interne Teams befähigt.
Frage 12: Welcher Schulungsbedarf besteht — und wie werden Sie ihn decken? — Die Transformation zu Cloud-basiertem Betrieb erfordert nicht nur neue technische Skills, sondern ein fundamentales Umdenken in der Art, wie IT betrieben wird. Provisioning in Minuten statt Wochen, Pay-per-Use statt Capacity Planning, Infrastructure-as-Code statt Ticket-basierter Änderungen. Planen Sie dedizierte Schulungsbudgets ein — sowohl für Cloud-Provider-Zertifizierungen (AWS Solutions Architect, Azure Administrator) als auch für interne Workshops, Pair Programming und Hands-on Labs. Eine Faustregel: Rechnen Sie mit 10–15 % des Migrationsbudgets für Schulung und Enablement.
Betrieb & Governance (Fragen 13–15)
Frage 13: Wie werden Sie Ihre Cloud-Kosten überwachen und steuern? — Cloud-Kosten sind variabel, granular und — wenn unkontrolliert — explosiv. Ohne ein strukturiertes FinOps-Framework werden Sie innerhalb weniger Monate feststellen, dass Ihre Cloud-Rechnung deutlich über den Prognosen liegt. Implementieren Sie von Tag eins: Tagging-Standards für alle Ressourcen, Budget-Alarme auf Projekt- und Team-Ebene, automatisiertes Rightsizing für Over-Provisioned Instanzen und regelmäßige Cost Reviews. Tools wie AWS Cost Explorer, Azure Cost Management oder Third-Party-Lösungen wie Spot.io und Infracost unterstützen Sie dabei. Die Erfahrung zeigt: Unternehmen, die FinOps von Anfang an implementieren, sparen im Durchschnitt 25–35 % gegenüber Unternehmen, die das Thema erst nach der Migration adressieren.
Frage 14: Wie sieht Ihre Backup- und Disaster-Recovery-Strategie in der Cloud aus? — „Die Cloud ist doch redundant" — dieser Irrglaube hat schon viele Unternehmen teuer zu stehen bekommen. Ja, Cloud-Provider bieten hochverfügbare Infrastruktur. Aber Datenverlust durch versehentliches Löschen, Ransomware oder Konfigurationsfehler ist auch in der Cloud möglich. Definieren Sie für jeden Workload: RPO (Recovery Point Objective) und RTO (Recovery Time Objective), Backup-Frequenz und Aufbewahrungsdauer, Cross-Region oder Cross-Account Backup-Strategie, regelmäßige Disaster-Recovery-Tests. Services wie AWS Backup, Azure Site Recovery oder Veeam für Multi-Cloud decken die technische Seite ab — aber die Strategie müssen Sie selbst definieren.
Frage 15: Wie werden Sie Multi-Cloud und Hybrid-Szenarien steuern? — Die Realität der meisten Unternehmen ist nicht „eine Cloud", sondern ein Mix aus AWS, Azure, Google Cloud, SaaS-Anwendungen und On-Premises-Restbeständen. Diese Heterogenität erfordert eine klare Governance: Wer entscheidet, welcher Workload auf welchem Provider läuft? Wie stellen Sie konsistente Security Policies über alle Umgebungen sicher? Wie vermeiden Sie Vendor Lock-in bei gleichzeitiger Nutzung provider-spezifischer Managed Services? Definieren Sie klare Guardrails, setzen Sie auf Infrastructure-as-Code für Portabilität und investieren Sie in eine Cloud Management Platform, die Ihnen eine einheitliche Sicht über alle Umgebungen bietet.
Cloud Migration Readiness Matrix
Die folgende Matrix gibt Ihnen eine schnelle Orientierung, wie Sie Ihre Readiness in jeder Dimension bewerten können. Nutzen Sie sie als Diskussionsgrundlage in Ihrem Migrations-Team. Seien Sie ehrlich bei der Bewertung — jede gelbe oder rote Bewertung ist eine Chance zur Verbesserung, kein Makel.
Ziel ist nicht, in jeder Dimension sofort „Grün" zu sein. Viele Unternehmen starten ihre Migration bewusst mit einer Mischung aus grünen und gelben Bewertungen — entscheidend ist, dass rote Bereiche vor der Migration adressiert werden.
| Bereich | Ready (Grün) | Teilweise Ready (Gelb) | Nicht Ready (Rot) |
|---|---|---|---|
| Strategie & Business Case | Klare Geschäftsziele definiert, TCO-Analyse abgeschlossen, realistische Timeline | Geschäftsziele vorhanden aber unscharf, TCO nur teilweise kalkuliert | Keine klaren Ziele, Migration rein technisch getrieben, keine TCO-Analyse |
| Technische Bereitschaft | Vollständiges Application Portfolio, Abhängigkeiten kartiert, 6R-Zuordnung abgeschlossen | Application Portfolio teilweise erfasst, einige Abhängigkeiten unklar | Keine Übersicht über IT-Landschaft, Shadow IT, keine Dependency-Analyse |
| Sicherheit & Compliance | Compliance-Anforderungen dokumentiert, Security Baseline definiert, Shared Responsibility verstanden | Compliance-Anforderungen bekannt aber nicht vollständig dokumentiert | Keine Compliance-Analyse, keine Security Baseline, Shared Responsibility unklar |
| Organisation & Skills | Cloud-Skills im Team, dedizierter Migrations-Owner, Schulungsplan vorhanden | Einige Cloud-Skills vorhanden, Owner benannt aber nicht freigestellt | Keine Cloud-Kompetenz, kein Owner, kein Schulungsbudget |
| Betrieb & Governance | FinOps etabliert, DR-Strategie definiert, Multi-Cloud-Governance vorhanden | Erste FinOps-Ansätze, DR-Strategie in Arbeit | Keine Kostenkontrolle geplant, kein DR-Konzept, keine Governance |
Die häufigsten Fehler bei der Cloud Migration
Aus hunderten begleiteter Migrationsprojekte haben sich klare Muster herauskristallisiert. Die folgenden Fehler sehen wir immer wieder — und sie sind alle vermeidbar, wenn man sie kennt.
- 1Lift & Shift als Dauerlösung: Viele Unternehmen migrieren per Rehost und belassen es dabei. Was als schneller erster Schritt gedacht war, wird zum Dauerzustand. Die Folge: Höhere Kosten als On-Premises bei gleichzeitig fehlenden Cloud-Vorteilen. Planen Sie von Anfang an eine Modernisierungs-Roadmap nach dem initialen Rehost.
- 2Cloud-Kosten unterschätzen: Die monatliche Rechnung besteht nicht nur aus Compute und Storage. Datenübertragungskosten, Logging, Monitoring, Premium-Support und inaktive Ressourcen summieren sich schnell. Implementieren Sie FinOps vor der ersten Provisionierung, nicht danach.
- 3Security als Nachgedanken: „Das machen wir nach der Migration" — ein Satz, der regelmäßig zu Sicherheitsvorfällen führt. Cloud-Security muss von Tag eins integriert sein: Least-Privilege IAM, Verschlüsselung at rest und in transit, Network Segmentation und automatisiertes Compliance-Monitoring.
- 4Fehlende Schulung: Teams, die ohne ausreichende Cloud-Kenntnisse migrieren, machen teure Fehler. Überdimensionierte Instanzen, falsch konfigurierte Security Groups, fehlende Backups — all das ist die Folge von mangelndem Know-how. Investieren Sie in Schulung, bevor Sie in Cloud-Infrastruktur investieren.
- 5Kein Exit-Plan: Vendor Lock-in ist ein reales Risiko. Wer ausschließlich auf proprietäre Services eines Anbieters setzt, hat später erhebliche Switching-Kosten. Definieren Sie eine Exit-Strategie — nicht weil Sie den Anbieter wechseln wollen, sondern weil die Option dazu Ihre Verhandlungsposition stärkt.
- 6Big-Bang statt Wellen-Migration: Der Versuch, alle Systeme gleichzeitig zu migrieren, überfordert jede Organisation. Erfolgreiche Migrationen arbeiten in Wellen: Zuerst weniger kritische Workloads als Proof-of-Concept, dann schrittweise kritischere Systeme. Jede Welle liefert Erkenntnisse für die nächste.
- 7Kein Rückfall-Plan: Was passiert, wenn die Migration eines kritischen Systems fehlschlägt? Ohne definierten Rollback-Plan stehen Sie vor der Wahl zwischen einem nicht funktionierenden Cloud-System und einem bereits abgeschalteten On-Premises-System. Für jeden migrierten Workload muss ein getesteter Rollback-Plan existieren.
- 8Organisatorische Veränderung ignorieren: Cloud verändert nicht nur die Technologie, sondern die gesamte IT-Organisation. Operations wird zu DevOps, Capacity Planning wird zu FinOps, Ticket-basierte Änderungen werden zu Self-Service. Wer diese kulturelle Transformation ignoriert, wird die technische Migration nicht nachhaltig umsetzen können.
Nächste Schritte: Vom Assessment zur Roadmap
Ein Assessment ist nur so wertvoll wie die Maßnahmen, die daraus abgeleitet werden. Die folgenden Schritte überführen Ihre Readiness-Bewertung in eine konkrete Migrations-Roadmap.
Beginnen Sie mit der Priorisierung: Welche roten Bereiche aus der Readiness Matrix sind Showstopper? Diese müssen adressiert werden, bevor die erste Migration startet. Typische Showstopper sind fehlende Compliance-Klärung, mangelnde Skills im Kernteam und ein nicht vorhandener Business Case.
Definieren Sie Migrationswellen: Gruppieren Sie Ihre Anwendungen in 3–5 Wellen, beginnend mit Low-Risk, High-Value Workloads. Die erste Welle dient als Pilotprojekt — hier sammeln Sie Erfahrung, validieren Ihre Prozesse und bauen Vertrauen auf. Jede folgende Welle wird effizienter, weil Sie aus den vorherigen gelernt haben.
Erstellen Sie eine Landing Zone: Bevor der erste Workload migriert wird, muss Ihre Cloud-Umgebung bereit sein. Eine Landing Zone umfasst: Account-Struktur (Multi-Account oder Single Account mit Projekttrennung), Netzwerk-Design (VPC-Layout, Connectivity zu On-Premises), Identity-Federation (SSO, Rollen, Policies), Logging und Monitoring (Central Logging, Alerting) sowie Security-Guardrails (SCPs, Azure Policies). Services wie AWS Control Tower oder Azure Landing Zones beschleunigen diesen Aufbau.
Etablieren Sie ein Governance-Framework: Definieren Sie klare Regeln für Cloud-Nutzung — von Naming Conventions über Tagging-Standards bis hin zu Change-Management-Prozessen. Dieses Framework wächst mit Ihrer Cloud-Reife und verhindert, dass die Cloud-Umgebung zum Wildwuchs wird.
Planen Sie den Parallelbetrieb: Während der Migration betreiben Sie temporär zwei Umgebungen. Planen Sie die Kosten dafür ein — und definieren Sie klare Kriterien, wann On-Premises-Systeme abgeschaltet werden. Ein typischer Parallelbetrieb dauert 3–6 Monate pro Migrationswelle.
Fazit
Eine Cloud-Migration ist kein IT-Projekt — es ist eine Unternehmenstransformation. Technologie ist dabei nur ein Teil der Gleichung. Strategie, Organisation, Skills, Security und Governance müssen gleichermaßen berücksichtigt werden.
Die 15 Fragen in diesem Assessment decken die kritischsten Dimensionen ab. Wenn Sie mehr als fünf davon nicht mit Zuversicht beantworten können, ist Ihre Organisation noch nicht bereit für eine Migration — und das ist völlig in Ordnung. Besser jetzt Lücken identifizieren als sie mitten in der Migration schmerzhaft zu entdecken.
Nutzen Sie die Readiness Matrix als Ausgangspunkt, erstellen Sie einen realistischen Plan zur Schließung der identifizierten Gaps und starten Sie Ihre Migration erst dann, wenn Sie in allen fünf Dimensionen mindestens „Gelb" erreicht haben. Eine gut vorbereitete Migration dauert vielleicht länger in der Planungsphase — liefert aber schneller Ergebnisse in der Umsetzung.
Cloud-Migration ist kein Sprint, sondern ein Marathon. Und wie bei jedem Marathon gilt: Die Vorbereitung entscheidet über den Erfolg.
Quellen & Referenzen
Die in diesem Artikel referenzierten Cloud-Strategien und Best Practices basieren auf den folgenden Quellen:
- AWS Well-Architected Framework: https://aws.amazon.com/architecture/well-architected/
- Azure Cloud Adoption Framework: https://azure.microsoft.com/en-us/solutions/cloud-enablement/cloud-adoption-framework
- Gartner 6R Migration Model: https://www.gartner.com/en/documents/3873016
- AWS Migration Hub: https://aws.amazon.com/migration-hub/
- FinOps Foundation: https://www.finops.org/
Die wichtigsten Erkenntnisse
- 30 % aller Cloud-Migrationen scheitern an mangelnder Vorbereitung — ein strukturiertes Readiness Assessment ist keine Option, sondern Pflicht.
- Nicht jeder Workload gehört in die Cloud. Die 6R-Strategie hilft, für jede Anwendung den richtigen Migrationspfad zu bestimmen.
- Cloud-Kosten werden systematisch unterschätzt. Eine ehrliche TCO-Analyse über mindestens 3 Jahre ist die Basis jedes Business Case.
- Skills sind der häufigste Engpass. Investieren Sie 10–15 % des Migrationsbudgets in Schulung und Enablement.
- Migrieren Sie in Wellen, nicht als Big Bang. Jede Welle liefert Erkenntnisse, die die nächste effizienter machen.
- Governance und FinOps müssen vor der ersten Migration stehen — nicht als Nachgedanke nach der ersten überraschend hohen Cloud-Rechnung.
Passende Assessment-Templates
Häufig gestellte Fragen
Die Dauer hängt stark von Umfang und Komplexität ab. Für ein mittelständisches Unternehmen mit 20–50 Anwendungen sollten Sie 12–18 Monate einplanen — von der initialen Assessment-Phase bis zum vollständigen Betrieb in der Cloud. Große Enterprises mit mehreren hundert Anwendungen, komplexen Legacy-Systemen und strengen Compliance-Anforderungen benötigen typischerweise 2–3 Jahre. Wichtig: Diese Zeiträume umfassen nicht nur die technische Migration, sondern auch Vorbereitung, Schulung, Testing und die Stabilisierungsphase nach der Migration. Der häufigste Fehler ist, nur die reine Migrationszeit zu kalkulieren und den Aufwand für Vorbereitung und Nachbereitung zu ignorieren. Eine Pilotmigration einzelner Workloads kann allerdings bereits nach 4–8 Wochen abgeschlossen sein.
Eine seriöse Kostenschätzung ohne Kenntnis Ihrer spezifischen Umgebung ist nicht möglich — aber typische Größenordnungen lassen sich benennen. Für ein mittelständisches Unternehmen liegen die reinen Migrationskosten (Beratung, Tools, Parallelbetrieb) bei 100.000–500.000 Euro. Hinzu kommen laufende Cloud-Kosten, die je nach Optimierungsgrad 20–40 % über oder unter den bisherigen On-Premises-Kosten liegen können. Entscheidend ist die Gesamtbetrachtung: Neben den direkten Kosten müssen Sie Schulungsaufwand, Produktivitätsverlust während der Umstellung, Anpassung von Prozessen und eventuell notwendige Refactoring-Aufwände einkalkulieren. Unternehmen, die ein FinOps-Framework von Anfang an implementieren, sparen langfristig 25–35 % gegenüber Unternehmen ohne strukturiertes Kostenmanagement.
Die Antwort „es kommt darauf an" ist unbefriedigend, aber ehrlich. AWS hat das breiteste Service-Portfolio und die größte Community — ideal für Unternehmen mit vielfältigen technischen Anforderungen. Azure ist die natürliche Wahl für Microsoft-zentrierte Organisationen (Active Directory, Office 365, .NET) und bietet hervorragende Hybrid-Cloud-Integration. Google Cloud punktet bei Data Analytics, Machine Learning und Kubernetes-nativen Workloads. In der Praxis nutzen viele Unternehmen mehr als einen Anbieter. Entscheidender als der Anbieter selbst sind Faktoren wie: vorhandene Skills im Team, bestehende Lizenzverträge, spezifische Service-Anforderungen und die Verfügbarkeit von Rechenzentren in den für Sie relevanten Regionen. Vermeiden Sie dogmatische Entscheidungen — wählen Sie pragmatisch basierend auf Ihren konkreten Anforderungen.
Technisch ja, praktisch nur mit erheblichem Aufwand. Eine Repatriation — die Rückmigration von der Cloud zurück On-Premises — ist möglich, aber kostspielig und komplex. Die Kosten liegen oft über den ursprünglichen Migrationskosten, da Sie erneut Hardware beschaffen, Rechenzentrumskapazität aufbauen und Ihre Teams für den On-Premises-Betrieb umschulen müssen. Laut Studien haben etwa 10–15 % der Unternehmen einzelne Workloads zurückmigriert — meist aufgrund unerwarteter Kosten oder Compliance-Anforderungen. Der beste Schutz gegen Repatriation ist ein gründliches Readiness Assessment vor der Migration. Wenn Sie dennoch einen Exit-Plan benötigen: Setzen Sie auf offene Standards (Container, Kubernetes), vermeiden Sie übermäßige Nutzung proprietärer Services und dokumentieren Sie Ihre Architektur sorgfältig.
Lift-and-Shift (Rehost) bedeutet, eine Anwendung 1:1 auf Cloud-Infrastruktur zu verschieben — die Anwendung selbst wird nicht verändert. Statt auf einem physischen Server im eigenen Rechenzentrum läuft sie auf einer virtuellen Maschine in der Cloud. Das ist schnell, günstig und risikoarm — nutzt aber kaum Cloud-Vorteile. Cloud-Native hingegen bedeutet, eine Anwendung so zu architektieren, dass sie die Stärken der Cloud voll ausschöpft: Microservices, Container, Serverless Computing, Managed Databases, Auto-Scaling. Cloud-native Anwendungen sind elastischer, kosteneffizienter und resilienter — erfordern aber erheblich mehr Entwicklungsaufwand. In der Praxis empfehlen wir einen stufenweisen Ansatz: Erst per Lift-and-Shift in die Cloud migrieren, dann schrittweise Richtung Cloud-Native modernisieren. So vermeiden Sie Big-Bang-Risiken und können in jeder Phase Mehrwert nachweisen.
Nicht zwingend, aber in den meisten Fällen empfehlenswert — besonders wenn es Ihre erste große Cloud-Migration ist. Externe Berater bringen zwei Dinge mit, die intern oft fehlen: Erfahrung aus dutzenden vergleichbaren Projekten und einen unvoreingenommenen Blick auf Ihre Organisation. Sie erkennen Fallstricke, die Ihr internes Team mangels Erfahrung übersieht, und können bewährte Frameworks und Tools mitbringen, die den Prozess beschleunigen. Allerdings sollte die Migration nicht vollständig an externe Berater delegiert werden. Ihr internes Team muss die Cloud-Umgebung nach der Migration eigenständig betreiben können. Der ideale Ansatz ist ein Knowledge-Transfer-Modell: Externe Berater leiten die Planung und die ersten Migrationswellen, während sie gleichzeitig Ihr internes Team aufbauen und befähigen. Ab Welle 2 oder 3 übernimmt Ihr Team die Führung — die Berater stehen nur noch beratend zur Seite.