Cloud-Migration: die 6-Phasen-Strategie, die über Erfolg entscheidet

Die Migration in die Cloud — oder auf eine moderne On-Prem-Plattform wie Proxmox — ist selten ein technisches Problem. Sie scheitert fast immer an mangelnder Vorbereitung. Nach über 15 Jahren IT und dutzenden Migrationen sind es immer dieselben sechs Phasen, die den Unterschied machen. Wer sie überspringt, zahlt später mit Ausfällen, Nachtschichten und Budgetüberschreitungen. Die folgende Struktur hat sich sowohl bei Umzügen in die öffentliche Cloud als auch beim Aufbau einer eigenen, souveränen Plattform bewährt. Im Mittelstand kommt ein weiterer Faktor hinzu: Migrationen laufen hier selten im stillen Kämmerlein, sondern müssen den laufenden Betrieb stören — Planung und Kommunikation werden so mindestens so wichtig wie die Technologie.

Phase 1: Assessment & Planung

Der häufigste Fehler ist unzureichende Vorbereitung. Eine gründliche Bestandsaufnahme ist Pflicht:

Abhängigkeits-Kartierung — vollständige Kartierung aller Systemabhängigkeiten
Leistungs-Baseline — aktuelle Leistungsmetriken dokumentieren
Kostenanalyse (TCO) — TCO-Vergleich zwischen Bestand und Ziel
Sicherheits- und Compliance-Prüfung — Compliance- und Sicherheitsanforderungen

Gerade das Dependency Mapping wird oft unterschätzt: Eine scheinbar nebensächliche Schnittstelle, die nachts Daten liefert, kann die gesamte Kette blockieren, wenn sie im neuen Umfeld fehlt.

Phase 2: Architektur-Design

Cloud-native heißt umdenken. Monolithen werden entkoppelt, Zustand wird externalisiert, Skalierung wird horizontal gedacht.

# Service-Grenzen sauber schneiden
services:
  api:      { replicas: 3, stateless: true }
  worker:   { replicas: 2, queue: redis }
  storage:  { type: object, backend: minio }

Wer den Zustand konsequent aus den Diensten herauszieht, gewinnt etwas Entscheidendes: Services lassen sich austauschen, skalieren und neu starten, ohne dass Daten verloren gehen. Genau diese Eigenschaft trägt eine Migration im laufenden Betrieb.

Phase 3–6: Migrieren, testen, umschalten, optimieren

Migrate — in kleinen, rückrollbaren Schritten, niemals "Big Bang".
Validate — Last- und Failover-Tests gegen die Baseline.
Cutover — Umschalten mit Rollback-Pfad, idealerweise per Proxy-Switch.
Optimize — Kosten, Skalierung und Monitoring im laufenden Betrieb nachschärfen.

Die Reihenfolge ist nicht verhandelbar. Wer „migrieren" und „validieren" zusammenzieht, um Zeit zu sparen, holt sich die fehlenden Tests spätestens beim ersten Vorfall zurück — dann eben unter Druck.

Wo Migrationen typischerweise scheitern

Die wiederkehrenden Stolpersteine sind kaum technisch, sondern organisatorisch: unklare Verantwortlichkeiten, unterschätzte Datenmengen, vergessen gegangene Cronjobs oder externe Systeme, die nur in der Produktion sichtbar werden. Eine weitere klassische Falle ist die unterschätzte Netzwerkabhängigkeit — Latenzen zwischen ehemalig zusammenliegenden Diensten verändern das Antwortzeitverhalten plötzlich spürbar. Frühzeitig gemessene Baselines und ein klarer Kommunikationsplan zwischen Fachbereich und IT minimieren diese Risiken. Ein festes Go/No-Go-Meeting verhindert Entscheidungen in letzter Minute unter Zeitdruck.

Hochverfügbarkeit ist kein Add-on

Wer es ernst meint, plant Ausfallsicherheit von Anfang an ein: redundante Knoten, repliziertes Storage (etwa mit LINBIT DRBD/LINSTOR) und ein Monitoring, das Probleme meldet, bevor der Kunde sie merkt. Wer diese Themen erst nach dem Go-Live nachholt, zahlt sie teuer — mit Ausfällen, die in der Planung billig gewesen wären.

Eine gute Migration erkennt man daran, dass niemand sie bemerkt hat.