---
title: "Cloud-Transformationsstrategie"
description: "Die vier Transformationsebenen erfolgreicher Cloud-Adoption: Prozesse & Organisation, Menschen & Fähigkeiten, Plattform & Tooling, IT-Systeme & Applikationen."
sidebar:
order: 10
label: "Cloud-Transformationsstrategie"
source_url: "https://framework.stackit.cloud/de/advisory/cloud-vision-and-strategy/cloud-transformation/"
source_file: "docs/de/advisory/cloud-vision-and-strategy/cloud-transformation.mdx"
---
## Was Cloud-Transformation wirklich bedeutet
Cloud-Transformation ist kein Infrastrukturprojekt. Es handelt sich um eine strategische Veränderung über vier eng miteinander verbundene Dimensionen: Organisationsstrukturen und Prozesse müssen sich anpassen, Menschen brauchen neue Fähigkeiten und Arbeitsweisen, Plattformen und Tools müssen aufgebaut werden und das IT-Anwendungsportfolio muss aktiv weiterentwickelt werden. Diese vier Schichten greifen ineinander — eine Transformation, die nur eine Schicht anspricht, bewirkt keine dauerhafte Veränderung.
Der häufigste Fehler ist, die Cloud-Transformation als rein technisches Unterfangen zu betrachten: neue Infrastruktur beschaffen, Anwendungen migrieren, fertig. Das typische Ergebnis ist eine teurere, komplexere IT-Landschaft — mit den gleichen organisatorischen Dysfunktionen, nur in einer neuen Verpackung. Transformation gelingt nur, wenn alle vier Schichten gleichzeitig und koordiniert adressiert werden.
## Ebene 1: Prozesse & Organisation
Cloud-Technologien erfordern angepasste Organisationsstrukturen und Prozesse. Das ist keine Frage der Präferenz — neue Technologien funktionieren in alten Strukturen nicht effektiv. Ein cloud-natives Betriebsmodell erfordert, dass Entscheidungen dezentraler getroffen werden, Verantwortlichkeiten klar verteilt sind und Standardprozesse für die Cloud-Einführung vorhanden sind.
Die wesentlichen Änderungen betreffen Entscheidungs- und Governance-Strukturen. Wer kann welche Cloud-Ressourcen bereitstellen? Wie werden Architekturfragen eskaliert? Welche Teams haben eigenständige Entscheidungshoheit, welche Entscheidungen müssen zentral freigegeben werden? Diese Fragen müssen beantwortet werden, bevor die erste produktive Anwendung in die Cloud geht — nicht danach.
Betriebs- und Sicherheitsprozesse müssen für die Cloud-Realität neu gestaltet werden: Deployment-Prozesse, Incident Management, Change Control und Kapazitätsplanung stellen in Cloud-Umgebungen andere Anforderungen als in einer On-Premises-Infrastruktur. Diese Prozesse nicht anzupassen bedeutet, Cloud-Infrastruktur mit einem On-Premises-Denken zu betreiben — mit entsprechenden Reibungsverlusten.
Die klare Zuordnung von Verantwortlichkeiten ist der zentrale Governance-Hebel. Cloud-Betrieb ohne klare Eigentumsverhältnisse schafft Lücken in Sicherheit, Kostenkontrolle und Compliance. Das RACI-Modell des Cloud-Betriebsmodells definiert diese Verantwortlichkeiten verbindlich.
Definition von Entscheidungsrechten, Eskalationspfaden und Freigabeprozessen für
Cloud-Ressourcen. Der CCoE ist das zentrale Governance-Organ — er setzt Standards und überwacht
deren Einhaltung, ohne operative Aufgaben von Plattform-Teams zu übernehmen.
Anpassung von Deployment-, Incident- und Change-Prozessen für Cloud-Umgebungen. Automatisierung
ersetzt manuelle Prozesse dort, wo sie die Skalierbarkeit oder Konsistenz gefährden.
Standardisierte Vorgehensweise bei Cloud-Architektur-Entscheidungen und klare
Eigentumszuordnung für alle Cloud-Ressourcen. Kein Workload ohne benannten verantwortlichen
Eigentümer.
## Ebene 2: Menschen & Fähigkeiten
Cloud-Technologien erfordern neue Fähigkeiten und neue Arbeitsweisen. Dies ist die kritischste und am häufigsten unterschätzte Transformationsebene. Technologie kann gekauft werden — Fähigkeiten müssen aufgebaut werden. Und Capability Development braucht Zeit, Investitionen und Geduld.
Die zentralen Kompetenzfelder sind Cloud Engineering, Platform Engineering und DevOps. Cloud Engineers verstehen die Prinzipien und Services von Cloud-Plattformen und können Workloads bedarfsgerecht gestalten. Platform Engineers bauen und betreiben die interne Plattform, auf der Anwendungsteams entwickeln. DevOps-Praktiken überbrücken die klassische Trennung zwischen Entwicklung und Betrieb und ermöglichen kürzere Lieferzyklen.
Ein besonders wichtiger Kulturwandel ist die zunehmende Verantwortung im Team. In cloud-nativen Organisationen tragen Entwicklungsteams die Verantwortung für den gesamten Lebenszyklus ihrer Applikationen — von der Entwicklung über das Deployment bis hin zum Betrieb. Diese „You build it, you run it“-Kultur erfordert neue Fähigkeiten, aber auch organisationales Vertrauen und eine entsprechende Autonomie.
Cross-funktionale Teams sind das organisatorische Vehikel für diese Transformation. Wenn Entwicklung, Betrieb, Sicherheit und Architektur in gemeinsamen Teams arbeiten, entstehen schnellere Entscheidungen, bessere Lösungen und weniger Reibungsverluste an Schnittstellen.
Die Investition in Menschen ist keine weiche Maßnahme, sondern die Voraussetzung dafür, dass alle anderen Transformationsebenen wirksam werden. Eine Organisation, die Cloud-Infrastruktur kauft, ohne in Cloud-Fähigkeiten zu investieren, kauft Komplexität ohne Befähigung.
## Ebene 3: Plattform & Tooling
Die Plattform-Schicht ist die technologische Grundlage der Transformation. Sie besteht aus der Cloud-Plattformarchitektur (Landing Zone), standardisierter Infrastruktur und Plattformdiensten, Automatisierungsmöglichkeiten und zentralen Diensten für Sicherheit, Protokollierung und Überwachung.
Die Landing Zone ist kein einzelner Server oder ein einfaches Netzwerksegment, sondern die Gesamtheit aller vorkonfigurierten, governance-konformen Cloud-Umgebungen, in denen Workloads bereitgestellt werden. Eine gut gestaltete Landing Zone macht Compliance zum Standard: Teams landen in einer Umgebung, die bereits korrekt konfiguriert ist, anstatt in einem leeren Canvas, in dem alles manuell eingerichtet werden muss.
Standardisierte Services reduzieren Doppelungen und steigern die Qualität. Wenn jedes Anwendungsteam seine eigene Protokollierung, Identitätsverwaltung und Netzwerksegmentierung erfinden muss, entsteht eine zersplitterte Landschaft mit uneinheitlichen Sicherheitsstufen. Zentrale Plattformdienste lösen dieses Problem: Teams konsumieren vorgefertigte Bausteine und konzentrieren sich auf die Anwendungslogik.
Automatisierung ist das Funktionsprinzip der Plattform-Schicht. Infrastructure Provisioning, Deployment-Pipelines, Security Scans und Compliance Checks laufen automatisch ab — nicht weil Automatisierung ein Selbstzweck ist, sondern weil manuelle Prozesse nicht mit der Geschwindigkeit und Skalierbarkeit von Cloud-Umgebungen mithalten können.
## Ebene 4: IT-Systeme & Applikationen
Die vierte Transformationsschicht umfasst das gesamte Anwendungsportfolio der Organisation. Sie wird durch zwei grundsätzlich unterschiedliche Ansätze adressiert, die oft parallel und mit unterschiedlichen Teams verfolgt werden.
**Die Migration bestehender Systeme (Brownfield)** bezeichnet die Verlagerung bestehender Anwendungen in die Cloud. Es gibt kein universelles Rezept: Das Migrationsmuster hängt von der Architektur der Anwendung, ihren Abhängigkeiten, dem operativen Aufwand und dem Geschäftswert ab. Eine strukturierte Portfoliobewertung — oft auch als „6R-Rahmenwerk“ (Rehost, Replatform, Refactor, Repurchase, Retire, Retain) bezeichnet — hilft, die richtige Vorgehensweise für den jeweiligen Anwendungsfall zu finden.
**Die Entwicklung neuer Applikationen (Greenfield)** bietet die Möglichkeit, von Beginn an cloud-native zu bauen. Hier können alle Cloud-Vorteile genutzt werden: Managed Services, Automated Deployment, horizontale Skalierbarkeit, Infrastructure as Code. Greenfield-Projekte sind gleichzeitig die besten Lernlabore für die Organisation — Teams bauen Fähigkeiten auf, die später bei der Modernisierung von Brownfield-Anwendungen verwendet werden können.
Portfolio-Priorisierung ist eine strategische Entscheidung: Welche Anwendungen werden zuerst migriert oder modernisiert? Typischerweise handelt es sich hierbei um Anwendungen mit hoher Betriebslast, auslaufendem Support oder hohem Potenzial für cloud-native Optimierung — nicht unbedingt die kritischsten Produktivsysteme.
## Das Zusammenspiel der vier Schichten
1. **Zuerst Governance etablieren:** Bevor Workloads bereitgestellt werden, müssen Entscheidungsstrukturen, Verantwortlichkeiten und Kernprozesse definiert werden. Governance nachträglich einzuführen ist um ein Vielfaches teurer.
2. **Plattform und Skills parallel aufbauen:** Die Landing Zone und die ersten Cloud-Kompetenzen werden gemeinsam entwickelt — Teams lernen auf der realen Plattform, und die Plattform wird durch reale User Experiences verbessert.
3. **Start mit Greenfield-Projekten:** Neue Anwendungen auf der Cloud-Plattform geben der Organisation echte Erfahrungen mit cloud-nativen Mustern, bevor komplexe Migrationen in Angriff genommen werden.
4. **Brownfield systematisch adressieren:** Das Applikationsportfolio wird nach klaren Kriterien priorisiert und Schritt für Schritt migriert — mit vordefinierten Erfolgsmaßstäben und Exit-Kriterien pro Phase.
Die vier Transformationsebenen stellen keine sequenzielle Checkliste dar — sie werden iterativ und parallel adressiert. Was sich ändert, ist die Intensität: In frühen Phasen dominieren Governance und Plattform-Building. In späteren Phasen dominieren Capability Expansion und Portfolio-Migration.