Der Auslöser ist häufig profan: Der Wartungsvertrag für die Server im Keller läuft aus, die Hardware ist abgeschrieben, und die Frage steht im Raum — noch einmal investieren oder in die Cloud? Die Antwort ist seltener eindeutig, als Anbieterprospekte suggerieren. Eine Migration lohnt sich, wenn sie geplant abläuft; überstürzt wird sie teuer. Aus unseren Infrastrukturprojekten hat sich ein Vorgehen in fünf Schritten bewährt, das Risiken früh sichtbar macht und Kosten kalkulierbar hält.
Schritt 1: Inventar und Abhängigkeiten erfassen
Am Anfang steht eine vollständige Bestandsaufnahme: Welche Anwendungen laufen auf welchen Systemen, wer nutzt sie, welche Schnittstellen und Datenflüsse verbinden sie? Gerade die Abhängigkeiten sind entscheidend — die Warenwirtschaft, die nachts Dateien mit der Zeiterfassung austauscht, oder das Etikettendrucksystem, das eine feste IP-Adresse erwartet. Erfahrungsgemäß tauchen bei dieser Aufnahme 20 bis 30 Prozent mehr Systeme auf, als die IT-Dokumentation kennt. Jede Anwendung erhält zudem eine Einstufung: Wie kritisch ist sie für den Betrieb, welche Datenschutzanforderungen gelten, wie viel Ausfallzeit ist tolerierbar? Diese Liste ist das Fundament aller weiteren Entscheidungen.
Schritt 2: Zielbild und Strategie je Anwendung festlegen
Nicht alles gehört in die Cloud, und nicht alles auf demselben Weg. Je Anwendung wird eine Strategie festgelegt: unverändert umziehen (Rehosting), mit moderaten Anpassungen migrieren (Replatforming), durch einen SaaS-Dienst ersetzen — etwa E-Mail oder Dokumentenablage —, neu entwickeln oder bewusst abschalten. Häufig ist die Abschaltliste der erste Gewinn des Projekts: Bei einem Produktionsbetrieb mit 68 inventarisierten Anwendungen wurden elf ersatzlos stillgelegt, weil sie niemand mehr nutzte. Für Systeme mit besonderen Anforderungen — Maschinensteuerungen, latenzkritische Anwendungen, spezielle Compliance-Auflagen — bleibt ein lokaler Rest legitim; das Ergebnis ist dann ein bewusst gewählter Hybridbetrieb, kein Dogma in beide Richtungen.
Schritt 3: Mit einem Piloten Erfahrung aufbauen
Vor der breiten Migration steht ein Pilot: eine Anwendung mit überschaubarer Kritikalität, aber realem Nutzwert — typischerweise ein internes Fachverfahren oder die Testumgebung eines Kernsystems. Am Piloten werden die Bausteine erarbeitet, die später alle Migrationswellen tragen: Netzwerkanbindung und Namensauflösung, Identitäts- und Rechtemanagement, Backup und Wiederherstellung, Überwachung, Kostenkontrolle. Ebenso wichtig ist der organisatorische Ertrag — das IT-Team sammelt Betriebserfahrung, bevor kritische Systeme betroffen sind. Ein Pilot dauert realistisch vier bis acht Wochen und beantwortet die Frage, die kein Konzeptpapier beantworten kann: Funktioniert unser Zielbild im Alltag?
Schritt 4: Migration in Wellen mit Rückwegplan
Die eigentliche Migration erfolgt in Wellen von drei bis sechs Anwendungen, sortiert nach Abhängigkeiten und aufsteigender Kritikalität. Für jede Welle gelten dieselben Regeln: ein Probelauf mit Echtdaten vorab, ein definiertes Umstellungsfenster — meist ein Wochenende —, messbare Abnahmekriterien und ein vorbereiteter Rückweg, falls die Abnahme scheitert. Der Rückwegplan wird fast nie gebraucht, aber seine Existenz verändert das Projekt: Entscheidungen fallen ruhiger, und die Fachabteilungen tragen die Umstellung mit, weil das Risiko begrenzt ist. Zwischen den Wellen liegen bewusst ein bis zwei Wochen Stabilisierung, in denen Erkenntnisse in die nächste Welle einfließen.
Schritt 5: Betrieb, Sicherheit und Kosten aktiv steuern
Mit dem Umzug ist die Arbeit nicht beendet — sie verändert sich. Drei Themen brauchen dauerhafte Aufmerksamkeit. Sicherheit: Zugriffe konsequent über zentrale Identitäten mit Mehrfaktor-Authentifizierung, klare Netzwerksegmentierung, regelmäßige Überprüfung der Berechtigungen. Kosten: Cloud rechnet nach Verbrauch ab — ohne Steuerung wachsen die Ausgaben still. Monatliche Kostenberichte je Anwendung, abgeschaltete Testumgebungen außerhalb der Arbeitszeiten und passend dimensionierte Instanzen senken die laufenden Kosten erfahrungsgemäß um 20 bis 30 Prozent gegenüber dem unbeaufsichtigten Zustand. Und Verantwortung: Es braucht benannte Zuständigkeiten für Plattform, Kosten und Sicherheit — sonst bleibt die Cloud ein Projekt statt ein Betriebsmodell.
Fazit: Reihenfolge schlägt Tempo
Eine Cloud-Migration ist gut beherrschbar, wenn die Reihenfolge stimmt: erst Inventar und Zielbild, dann Pilot, dann Wellen mit Rückwegplan, schließlich ein aktiv gesteuerter Betrieb. Wer diese Schritte einhält, migriert ohne Betriebsunterbrechung und kennt seine Kosten — wer sie überspringt, bezahlt die Abkürzung später. Wie wir Infrastrukturvorhaben von der Analyse bis zum Regelbetrieb begleiten, lesen Sie unter Dienstleistungen. Für eine erste Einschätzung Ihrer Ausgangslage genügt ein kurzes Gespräch — nehmen Sie Kontakt auf.
