Cloud-Migration ohne Blindflug: Eine Strategie für den Mittelstand

Die Ausgangslage

Viele mittelständische Unternehmen stehen vor der gleichen Frage: Wie kommen wir in die Cloud, ohne den laufenden Betrieb zu gefährden? Die Antwort ist selten ein Big-Bang-Ansatz und fast nie “einfach alles zu AWS schieben”.

Eine erfolgreiche Cloud-Migration beginnt mit Strategie. Die Infrastruktur kommt danach.

Die 6 R’s der Cloud-Migration

Jede Anwendung im Portfolio verdient eine individuelle Bewertung. Das bewährte Framework der 6 R’s hilft bei der Einordnung:

Rehost (Lift & Shift): 1:1 in die Cloud verschieben, minimaler Aufwand
Replatform: Kleine Anpassungen für Cloud-Vorteile (z.B. Managed Database statt Self-Hosted)
Refactor: Architektur modernisieren, Cloud-native umbauen
Repurchase: Durch SaaS-Lösung ersetzen
Retain: Bewusst on-premise belassen
Retire: Abschalten, weil nicht mehr benötigt

Der häufigste Fehler

Teams neigen dazu, alles als Rehost zu planen. Das ist kurzfristig einfacher, aber langfristig teurer, weil Cloud-Kosten ohne Optimierung schnell explodieren. Wer die Gelegenheit für ein Refactor sinnvoll nutzen will, sollte vorher ehrlich entscheiden, ob der Schnitt von Monolith zu Microservices wirklich passt.

Kosten: Die unsichtbare Gefahr

Cloud-Kosten sind anders als On-Premise-Kosten. Statt fixer Investitionen zahlt man verbrauchsabhängig. Das klingt flexibel, wird aber zum Problem, wenn niemand den Verbrauch überwacht.

Cost Governance von Tag 1

Drei Maßnahmen, die sich sofort auszahlen:

Tagging-Strategie: Jede Ressource bekommt Tags für Team, Projekt und Umgebung. Ohne Tags keine Kostenzuordnung.
Budget-Alerts: Automatische Benachrichtigungen bei 50%, 80% und 100% des Budgets. Kein Team sollte überrascht werden.
Reserved Instances: Für vorhersehbare Workloads bis zu 60% günstiger als On-Demand.

Sicherheit und Compliance

Im DACH-Raum ist Datenschutz kein Feature, sondern Pflicht. Das hat Konsequenzen für die Cloud-Architektur:

Datenresidenz: Personenbezogene Daten müssen in der EU bleiben. AWS eu-central-1 (Frankfurt) oder Azure Germany West Central sind die offensichtlichen Choices.
Verschlüsselung: At rest und in transit, idealerweise mit eigenen Schlüsseln (BYOK).
Zugriffskontrolle: Least Privilege als Standard, regelmäßige Access Reviews.

Der Migrations-Fahrplan

Eine realistische Timeline für ein mittelständisches Unternehmen mit 20–50 Anwendungen:

Monat 1–2: Assessment

Anwendungsinventar erstellen
Abhängigkeiten dokumentieren
Jede Anwendung einem der 6 R’s zuordnen

Monat 3–4: Foundation

Landing Zone aufbauen (Netzwerk, IAM, Logging)
CI/CD-Pipeline für Infrastructure as Code
Erste nicht-kritische Anwendung migrieren

Monat 5–8: Migration Waves

Anwendungen in Wellen migrieren, gruppiert nach Abhängigkeiten
Parallelbetrieb mit Fallback-Option
Performance-Tests nach jeder Welle

Monat 9–10: Optimierung

Rightsizing der Ressourcen basierend auf echten Nutzungsdaten
Automatisierung von Scaling-Policies
Dokumentation und Wissenstransfer

Fazit

Cloud-Migration ist kein IT-Projekt. Es ist eine Transformation, die Strategie, Governance und Change Management erfordert. Der Schlüssel ist ein iterativer Ansatz: klein anfangen, lernen, skalieren.

Wir begleiten Unternehmen durch den gesamten Prozess. Lassen Sie uns sprechen →

Häufige Fragen

Wie lange dauert eine Cloud-Migration?

Für ein mittelständisches Unternehmen mit 20-50 Anwendungen rechnet man mit neun bis zwölf Monaten. Das Assessment braucht zwei Monate, die Foundation zwei weitere, dann folgen Migration Waves über vier Monate und schließlich zwei Monate Optimierung. Größere Portfolios erfordern längere Timelines.

Welche Anwendungen sollte man zuerst migrieren?

Nicht-kritische Anwendungen mit wenigen Abhängigkeiten sind die besten Kandidaten für den Anfang. Sie ermöglichen schnelle Lerneffekte und Erfolgserlebnisse. Anschließend migriert man in Wellen nach Abhängigkeitsgruppen, nicht nach kritikalität.

Was kostet eine Cloud-Migration?

Die Kosten setzen sich aus Planung, Durchführung und ersten Monaten Cloud-Betrieb zusammen. Rehost-Projekte sind günstiger, Refactor- und Repurchase-Varianten teurer. Erfahrungsgemäß rechnet sich eine Migration durch niedrigere IT-Betriebskosten innerhalb von zwei bis drei Jahren.

Wie minimiert man das Risiko bei einer Migration?

Parallelbetrieb mit Fallback-Option ist der Schlüssel. Außerdem solide Testing nach jeder Welle, klare Rollback-Pläne und regelmäßige Performance-Messungen. Ein iterativer Wellensatz ist sicherer als ein großer Bang-Ansatz.