Wie lange dauert eine Cloud-Migration wirklich?

Eine pauschale Antwort auf die Frage „wie lange dauert cloud migration?“ wäre unseriös. Eine einzelne, klar abgegrenzte Anwendung kann in wenigen Wochen produktiv in die Cloud umziehen. Die Modernisierung einer geschäftskritischen Plattform mit Schnittstellen, Datenbeständen, Compliance-Vorgaben und hohen Verfügbarkeitsanforderungen braucht dagegen häufig mehrere Monate. Entscheidend ist nicht allein die Menge der Server. Architektur, Daten, Abhängigkeiten und der gewünschte Betriebsreifegrad bestimmen den Kalender.

Für mittelständische Unternehmen ist dabei ein Punkt besonders relevant: Eine Migration ist erst abgeschlossen, wenn die Anwendung unter Last stabil läuft, überwacht wird, wiederholbar ausgerollt werden kann und Kosten sowie Verantwortlichkeiten geklärt sind. Wer nur Infrastruktur verschiebt, verlagert oft bestehende Betriebsprobleme in eine neue Umgebung.

Wie lange dauert eine Cloud-Migration typischerweise?

Als belastbare Orientierung gelten drei Zeiträume. Ein überschaubares System mit wenigen Komponenten, geringer Datenmenge und klaren Abhängigkeiten lässt sich oft innerhalb von vier bis acht Wochen migrieren. Für eine zentrale Fachanwendung oder einen E-Commerce-Stack mit mehreren Umgebungen, externen Schnittstellen und Datenmigration sind eher drei bis sechs Monate realistisch. Bei gewachsenen Plattformlandschaften mit mehreren Anwendungen, regulatorischen Anforderungen und einer schrittweisen Modernisierung kann das Programm sechs bis zwölf Monate oder länger dauern.

Diese Spannen sind keine Projektzusage. Sie zeigen aber, warum die Frage „Wann sind wir in der Cloud?“ präziser gestellt werden muss: Soll eine Anwendung zunächst unverändert auf neuer Infrastruktur laufen? Soll sie containerisiert werden? Werden Deployment-Prozesse, Security-Prüfungen, Monitoring und Disaster Recovery gleich mit aufgebaut? Jede dieser Entscheidungen verändert Dauer, Risiko und späteren Nutzen.

Die sechs Phasen, die den Zeitplan prägen

1. Bestandsaufnahme und Zielbild

Am Anfang steht keine Zielplattform, sondern Transparenz. Welche Anwendungen sind geschäftskritisch? Welche Daten fließen zwischen Systemen? Wo liegen technische Schulden, manuelle Betriebsabläufe oder Single Points of Failure? Gerade in langjährig gewachsenen IT-Landschaften sind Abhängigkeiten selten vollständig dokumentiert.

Für eine fokussierte Anwendung reichen dafür häufig zwei bis vier Wochen. Bei einem Portfolio aus vielen Systemen kann die Analyse deutlich länger dauern. Diese Zeit zu kürzen, wirkt zunächst effizient, führt aber oft zu Überraschungen während Test oder Cutover. Ein sauberer Application Assessment reduziert genau dieses Risiko und schafft eine belastbare Priorisierung.

2. Cloud Foundation und Betriebsmodell

Bevor produktive Workloads umziehen, benötigt die Zielumgebung klare Leitplanken: Netzwerksegmentierung, Identitäts- und Berechtigungskonzepte, Verschlüsselung, Backup, Logging, Monitoring, Kostenkontrollen und Verantwortlichkeiten. Auch Entwicklungs-, Test- und Produktionsumgebungen sollten von Beginn an vorgesehen sein.

Eine schlanke Cloud Foundation lässt sich in zwei bis sechs Wochen etablieren. Bei komplexen Netzwerkvorgaben, hybrider Anbindung oder erhöhten Compliance-Anforderungen dauert sie länger. Der Aufwand zahlt sich aus: Teams vermeiden Sonderlösungen pro Anwendung, Sicherheitsvorgaben werden automatisierbar und neue Services kommen schneller in eine kontrollierte Betriebsumgebung.

3. Migrationsstrategie pro Anwendung

Nicht jede Anwendung braucht dieselbe Behandlung. Ein Lift-and-Shift kann sinnvoll sein, wenn Hardware ersetzt werden muss und Zeitdruck besteht. Er liefert schnellen Fortschritt, beseitigt aber nicht automatisch langsame Releases oder einen hohen Betriebsaufwand. Replatforming nutzt verwaltete Cloud-Dienste, ohne die Anwendung vollständig umzubauen. Refactoring geht weiter und passt Architektur sowie Code etwa für Container, ereignisbasierte Verarbeitung oder skalierbare APIs an.

Die Strategie entscheidet maßgeblich über die Dauer. Eine schnelle Verlagerung kann nach wenigen Wochen produktiv sein. Eine gezielte Modernisierung braucht mehr Vorlauf, schafft aber oft bessere Verfügbarkeit, kürzere Release-Zyklen und eine nachvollziehbarere Kostenstruktur. Der richtige Weg hängt vom Geschäftswert, dem Risikoprofil und der erwarteten Lebensdauer der Anwendung ab.

4. Automatisierung, Security und Observability

Manuelle Infrastrukturkonfiguration ist ein häufiger Grund dafür, dass Migrationen stocken oder nach dem Go-live instabil werden. Infrastructure as Code, automatisierte CI/CD-Pipelines und reproduzierbare Container-Images verkürzen nicht nur die Umsetzung. Sie machen Änderungen prüfbar und erlauben es, Umgebungen konsistent aufzubauen.

Parallel müssen Sicherheitsprüfungen und Betriebsdaten integriert werden. Dazu gehören Secret Management, Rechte nach dem Least-Privilege-Prinzip, Schwachstellenprüfungen, zentrale Logs, Metriken und Alarmierungen. Für eine einzelne Anwendung kann diese Phase zwei bis vier Wochen beanspruchen. Werden grundlegende Standards erstmals geschaffen, ist sie eher ein Baustein der Cloud Foundation. Sie zu verschieben bedeutet meist, spätere Nacharbeiten unter Produktionsdruck zu bezahlen.

5. Datenmigration und Integrationstests

Daten sind oft der eigentliche Engpass. Große Datenbanken, geringe Wartungsfenster, inkonsistente Datenqualität oder Anforderungen an die Nachvollziehbarkeit verlängern die Migration stärker als die Bereitstellung von Compute-Ressourcen. Häufig ist ein einmaliger Export nicht möglich. Dann wird zunächst repliziert, anschließend werden Differenzen synchronisiert und erst zum Cutover ein kurzes Schreibfenster eingeplant.

Mindestens ebenso kritisch sind Schnittstellen. Zahlungsanbieter, ERP, Identity Provider, Logistiksysteme oder Partner-APIs müssen in realistischen Szenarien getestet werden. Ein erfolgreicher technischer Deployment-Test sagt noch nicht, ob ein Geschäftsprozess vollständig funktioniert. Je nach Integrationsdichte dauert diese Phase zwei Wochen bis mehrere Monate.

6. Cutover, Stabilisierung und Übergabe in den Betrieb

Der produktive Umzug braucht einen klaren Ablauf: Kommunikationsplan, Freigabekriterien, Backout-Szenario, Verantwortliche und ein definiertes Wartungsfenster. Bei gut vorbereiteten Anwendungen kann der eigentliche Cutover nur Stunden dauern. Die Stabilisierung danach benötigt dennoch Aufmerksamkeit, weil Lastprofile, reale Nutzerwege und externe Abhängigkeiten erst jetzt vollständig sichtbar werden.

Ein verantwortungsvoller Übergang endet nicht mit dem ersten erfolgreichen Login. Das Betriebsteam braucht Dashboards, Alarmierungswege, Runbooks und geregelte Incident-Prozesse. Wird der Betrieb von Anfang an mitgeplant, sinken Ausfallrisiken und die Plattform wird nicht zum neuen Sonderfall im Unternehmen.

Was Cloud-Migrationen verzögert

Die größten Verzögerungen entstehen selten durch die Cloud-Plattform selbst. Häufig bremsen unbekannte Abhängigkeiten, fehlende Testdaten, unklare fachliche Freigaben oder Entscheidungen, die zu spät getroffen werden. Auch ein zu großer Migrationsumfang ist problematisch: Wer alle Systeme gleichzeitig bewegen will, bindet Fachbereiche und Technikteams über Monate in einem Hochrisikoprojekt.

Ein weiterer Faktor sind unrealistische Verfügbarkeitsvorgaben. Wenn es kein akzeptiertes Wartungsfenster gibt, müssen Datenreplikation, paralleler Betrieb und Umschaltmechanismen aufwendiger geplant werden. Das ist bei geschäftskritischen Anwendungen richtig - sollte aber als bewusste Investition behandelt werden, nicht als nachträgliche Zusatzanforderung.

Schließlich verlängert eine Migration sich, wenn Zuständigkeiten offen bleiben. Cloud Provider, internes IT-Team, Entwicklung und externe Partner müssen wissen, wer Architekturentscheidungen trifft, Releases freigibt und im Störungsfall handelt. Ein Engineering-Partner wie devRocks verbindet diese Ebenen, damit Architektur, Automatisierung und produktiver Betrieb nicht nacheinander, sondern abgestimmt entstehen.

So wird der Zeitplan belastbar statt optimistisch

Ein guter Migrationsplan arbeitet in Wellen. Zuerst eignet sich eine Anwendung, die sichtbar Nutzen bringt, aber kein unnötiges Geschäftsrisiko erzeugt. Das Team validiert damit die Cloud Foundation, Pipelines, Monitoring und den Freigabeprozess. Die Erkenntnisse fließen in die nächste Welle ein, statt für jedes System bei null anzufangen.

Wichtig sind messbare Exit-Kriterien je Phase: Infrastruktur per Code reproduzierbar, Backups getestet, Performance unter erwarteter Last geprüft, Sicherheitsvorgaben erfüllt und Betriebsverantwortung geklärt. Damit wird Fortschritt nicht nach Folien oder abgeschlossenen Tickets bewertet, sondern nach tatsächlicher Produktionsreife.

Auch FinOps gehört früh auf den Plan. Kosten entstehen nicht erst nach dem Go-live. Ungenutzte Ressourcen, überdimensionierte Datenbanken oder fehlende Budgets werden bei später Korrektur teuer und organisatorisch mühsam. Kosten-Tags, Budgets und Verbrauchstransparenz sollten daher Teil der ersten produktiven Standards sein.

Die richtige Frage lautet deshalb nicht nur, wie schnell die erste Anwendung in die Cloud kommt. Entscheidend ist, wie schnell Ihr Unternehmen danach sicher, wiederholbar und wirtschaftlich weitere Produkte ausliefern kann. Genau daran sollte sich der Zeitplan messen lassen.