Cloud-Migration: Kosten, Risiken und Zeitplan realistisch planen

Cloud-Migration steht auf der Agenda vieler mittelständischer IT-Abteilungen. Die Versprechen sind bekannt: niedrigere Betriebskosten, höhere Skalierbarkeit, modernere Entwicklungsplattformen. Die Realität ist differenzierter. Projekte, die auf drei Monate geschätzt wurden, dauern oft ein Jahr. Kostenersparnisse stellen sich nicht automatisch ein.

Und wer Legacy-Systeme in die Cloud verschiebt ohne sie zu modernisieren, bekommt dieselben Probleme mit höherer Rechnung. Dieser Beitrag gibt eine realistische Einordnung – für Entscheider, die auf Fakten statt Versprechen setzen.

Was Cloud-Migration wirklich bedeutet: Die sieben Strategien

Kurz: Nicht alle Cloud-Migrationen sind gleich.

Nicht alle Cloud-Migrationen sind gleich. McKinsey und Gartner beschreiben sieben grundlegende Strategien (die „7 R's"), die sehr unterschiedliche Aufwände und Risiken mit sich bringen:

Strategie	Beschreibung	Aufwand	Nutzen
Retire	Anwendung abschalten	Minimal	Kostenersparnis durch Wegfall
Retain	On-Premise belassen	Minimal	Keine Veränderung
Rehost (Lift & Shift)	VM in Cloud verschieben	Niedrig	Betriebsflexibilität
Relocate	Container in Cloud verschieben	Niedrig–Mittel	Portabilität
Repurchase	Durch SaaS-Lösung ersetzen	Mittel	Modernisierung
Replatform	Mit kleinen Anpassungen in Cloud	Mittel–Hoch	Teilmodernisierung
Refactor/Re-architect	Für Cloud neu entwickeln	Hoch	Volle Cloud-Vorteile

Die häufigste Anfängerfehlannahme: „Wir migrieren in die Cloud" meint oft Rehost – aber verspricht die Vorteile von Refactor. Das ist der Ausgangspunkt vieler enttäuschter Cloud-Projekte.

Was eine Cloud-Migration wirklich kostet

Kurz: Die Kostenkalkulation einer Cloud-Migration hat zwei Seiten: Migrationskosten und laufende Cloud-Betriebskosten.

Die Kostenkalkulation einer Cloud-Migration hat zwei Seiten: Migrationskosten und laufende Cloud-Betriebskosten.

Einmalige Migrationskosten:

Kostenblock	Treiber
Planung und Assessment	Inventarisierung, Abhängigkeitsanalyse, Zielarchitektur
Technische Migration	Rehosting, Replatforming oder Refactoring je Anwendung
Testing	Funktions-, Integrations-, Last- und Sicherheitstests
Datenmigration	Volumen, Format, Qualitätsbereinigung
Schulung	IT-Team, Entwickler, Endanwender
Parallelbetrieb	Kosten für altes + neues System während der Übergabe
Unvorhergesehenes	Erfahrungswert: 20–30 % Puffer einplanen

Orientierungswerte für den Mittelstand:

• Rehost von 5–10 VMs: 20.000–60.000 €
• Replatforming einer mittleren Anwendung: 50.000–150.000 €
• Vollständige Re-Architektur einer Business-Anwendung: 150.000–500.000 €+

Laufende Cloud-Kosten: Die häufigste Fehlkalkulation

Viele Unternehmen vergleichen On-Premise-Abschreibungen mit Cloud-Verbrauchskosten.

Das ist falsch.

Vergleichen Sie den Total Cost of Ownership – inklusive Strom, Kühlung, Wartung, Raum, Hardware-Erneuerung, IT-Personal für On-Premise vs.

Cloud-Verbrauch, Support-Verträge, egress-Kosten (Daten aus der Cloud herausbewegen) und Lizenzanpassungen.

Cloud kann günstiger sein – aber nicht automatisch. Wer eine on-premise-Anwendung als Lift-&-Shift in die Cloud schiebt und weiterläuft wie bisher, zahlt typisch 20–40 % mehr als on-premise.

Versteckte Risiken, die Projekte scheitern lassen

Kurz: Unbekannte Abhängigkeiten.

Unbekannte Abhängigkeiten. In gewachsenen IT-Landschaften gibt es mehr undokumentierte Verbindungen zwischen Systemen als irgend jemand vermutet. Eine Abhängigkeitsanalyse vor der Migration ist keine Kür, sondern Pflicht.

Legacy-Systeme ohne API. Ältere Anwendungen, die direkt auf Datenbankebene kommunizieren oder proprietäre Protokolle nutzen, lassen sich nicht einfach in die Cloud verschieben. Legacy-Modernisierung ist oft ein notwendiger Parallelpfad.

Datenmigration unterschätzt. Große Datenmengen, schlechte Datenqualität und komplexe Transformationen machen Datenmigration zur oft unterschätzten Disziplin. Wer mit „wir kopieren die Datenbank" rechnet, unterschätzt die Bereinigung, Validierung und Rekonstruktion von Relationen.

Compliance und Datenschutz. Wo liegen die Cloud-Regionen? Welche personenbezogenen Daten werden gespeichert? DSGVO-Anforderungen, Betriebsvereinbarungen und Branchenregulierung müssen vor der Migration geklärt sein – nicht danach.

Netzwerk-Latenz. Anwendungen, die on-premise mit lokaler Datenbank sehr schnell reagierten, können nach Cloud-Migration durch Netzwerklatenzen merklich langsamer werden – besonders bei hohem DB-Traffic.

Lock-in-Risiko. Wer tief in proprietäre Cloud-Dienste eines Anbieters (AWS, Azure, GCP) investiert, schränkt spätere Wechselmöglichkeiten ein. Portabilitätsstrategie von Anfang an mitdenken.

Realistischer Zeitplan: Was wann passiert

Kurz: Ein typischer Cloud-Migrationszeitplan für ein mittelständisches Unternehmen mit 10–30 Anwendungen:

Ein typischer Cloud-Migrationszeitplan für ein mittelständisches Unternehmen mit 10–30 Anwendungen:

Phase 1: Assessment (4–8 Wochen)

• Anwendungsinventar
• Abhängigkeitsanalyse
• Kostenmodellierung (on-premise vs. Cloud)
• Zielarchitektur je Anwendung (Strategie: Rehost / Replatform / Refactor)
• Migrationspriorisierung

Phase 2: Pilotmigration (4–8 Wochen)

• 1–2 unkritische Anwendungen migrieren
• Prozesse und Tools etablieren
• Team schulen
• Erfahrungen für den Hauptrollout nutzen

Phase 3: Hauptmigration (3–12 Monate)

• Priorisierte Anwendungen in Wellen migrieren
• Parallelbetrieb und Abnahmetests
• Altsysteme abschalten

Phase 4: Optimierung (laufend)

• Kosten optimieren (Rightsizing, Reserved Instances)
• Monitoring und Alerting verfeinern
• Sicherheitsarchitektur stärken

Gesamtprojekt für einen typischen Mittelständler: 8–18 Monate, realistisch eher am oberen Ende wenn Legacy-Systeme betroffen sind.

Cloud-Migration und Softwareentwicklung

Kurz: Wer im Zuge einer Cloud-Migration auch Anwendungen modernisiert oder neue entwickelt, sollte die Projekte koordinieren – nicht als separate Silos.

Wer im Zuge einer Cloud-Migration auch Anwendungen modernisiert oder neue entwickelt, sollte die Projekte koordinieren – nicht als separate Silos. Individuelle Softwareentwicklung cloud-native zu gestalten (Container, Microservices, Infrastructure-as-Code) zahlt sich langfristig aus, kostet aber initial mehr.

Neue Schnittstellen-Entwicklung ist oft notwendig, um on-premise-Systeme, die parallel weiterlaufen, mit cloud-basierten Anwendungen zu verbinden. Diese Integrationsschicht wird häufig unterschätzt.

Fazit

Kurz: Cloud-Migration lohnt – wenn sie mit realistischem Aufwand, klarer Strategie und passendem Timing geplant wird.

Cloud-Migration lohnt – wenn sie mit realistischem Aufwand, klarer Strategie und passendem Timing geplant wird.

Lift-&-Shift ist der schnellste Weg in die Cloud, bringt aber die wenigsten Vorteile.

Re-Architektur ist aufwändig, liefert aber langfristig die größten Einsparungen und Flexibilitätsgewinne.

Unser Team begleitet Cloud-Migrationsprojekte von der Hosting- und Cloud-Beratung über die technische Umsetzung bis zur Cloud-Migration – mit dem Anspruch, dass am Ende nicht nur die Systeme in der Cloud laufen, sondern der Betrieb effizienter ist als vorher.

Häufig gestellte Fragen (FAQ)

Kurz: Welcher Cloud-Anbieter ist der richtige für den deutschen Mittelstand?

Welcher Cloud-Anbieter ist der richtige für den deutschen Mittelstand?

AWS, Azure und GCP bieten alle deutsche Rechenzentren.

Entscheidend sind: bestehende Microsoft-Lizenzierung (spricht für Azure), vorhandene Entwickler-Expertise, spezifische Dienste und Compliance-Anforderungen.

Es gibt keine universell richtige Antwort.

Muss man komplett in die Cloud, oder gibt es Alternativen? Hybrid-Cloud-Architekturen – Teil on-premise, Teil Cloud – sind für viele Mittelständler die pragmatische Lösung. Nicht alles muss in die Cloud, nur was davon profitiert.

Was ist mit DSGVO und Cloud? Alle drei großen Cloud-Anbieter haben EU-Datenschutzgarantien (SCC, Data Processing Agreements) und EU-Regionen. Bei besonders sensiblen Daten kann ein deutsches Rechenzentrum oder eine souveräne Cloud-Option (z.B. GAIA-X-kompatible Anbieter) sinnvoll sein.

Können wir während der Migration weiterarbeiten? Ja – mit Parallelbetrieb und phasenweisem Umzug. Ein Big-Bang-Wechsel (alles auf einmal) ist für produktive Systeme fast immer zu riskant. Schrittweise Migration mit Fallback-Option ist Standard.