Kosteneffiziente Cloud-Migration in fünf Schritten

Die meisten Migrationsratgeber sind für Konzerne geschrieben, die ein eigenes Cloud-Team und ein mehrjähriges Budget haben. KMU in der Schweiz, in Deutschland und in Österreich haben beides nicht. Sie haben eine bestehende Landschaft, ein kleines Team mit Tagesgeschäft und eine Geschäftsleitung, die eine Zahl möchte.

Dies ist die Fassung, die zu diesen Rahmenbedingungen passt: fünf Schritte in fester Reihenfolge, jeder mit einem vorzeigbaren Ergebnis.

Erst die Strecke kennen, dann die Reise planen

Ein Grundsatz liegt allen fünf Schritten zugrunde. Eine Migration ist kein Technikprojekt mit nachträglicher Begründung — sie ist eine Geschäftsveränderung, die zufällig über Technik geliefert wird.

Dieser Unterschied bestimmt, was «fertig» heisst. Ein Technikprojekt ist fertig, wenn die Arbeitslasten am neuen Ort laufen. Eine Geschäftsveränderung ist fertig, wenn sich Kosten, Geschwindigkeit oder Risikolage messbar verschoben haben. Nur die zweite Fassung übersteht die Frage «Was haben wir dafür bekommen?».

Fünf Hürden, an denen KMU-Migrationen scheitern

Sie gehören vor die Schritte, weil jeder Schritt eine davon entschärft:

1. Die Vernetzung wird unterschätzt. Die nicht dokumentierte Abhängigkeit zeigt sich beim Umschalten.
2. Kostenüberschreitungen kommen nach dem Go-live, nicht während des Projekts — wenn das Team bereits aufgelöst ist.
3. Regulatorische Komplexität, die allgemeine Ratgeber überspringen und die ein Schweizer oder deutsches Unternehmen nicht überspringen kann.
4. Eine Kompetenzlücke mitten im Projekt, meist bei Netzwerk, Identitäten oder Infrastructure as Code.
5. Nach dem Go-live fehlt die Verantwortung, und die Umgebung friert im Zustand des Umzugstags ein.

Schritt 1 — Bewerten und Zahlen erzeugen

Kein Inventar von Servern. Ein Inventar von Arbeitslasten, jeweils mit den Angaben, die den Umzug bestimmen:

• Wer nutzt sie, wie oft, und wie sieht das Lastprofil über ein Jahr aus?
• Welche Daten liegen darin, und welchen Schutzbedarf haben diese?
• Wovon hängt sie ab, und was hängt von ihr ab?
• Was kostet eine Stunde Ausfall?
• Was kostet sie heute — Abschreibung, Housing, Lizenzen und die Betriebsstunden, die sie bindet?

Die letzte Zeile wird am häufigsten ausgelassen, und ohne sie lässt sich nie beantworten, ob sich die Migration gelohnt hat. Ein Vorher-Wert lässt sich nachträglich nicht rekonstruieren — er muss entstehen, bevor sich etwas bewegt.

Ergebnis dieses Schritts: eine Liste von Arbeitslasten mit je einer Entscheidung — stilllegen, behalten, umziehen, anpassen, umbauen, ersetzen.

Stilllegen ist die wertvollste und am meisten übersehene Entscheidung. In den meisten Landschaften gibt es Systeme, die seit Jahren niemand nutzt. Sie zu finden ist der günstigste Gewinn des ganzen Vorhabens.

Schritt 2 — Nach Geschäftswirkung reihen

Der Reflex ist, mit der einfachsten Arbeitslast zu beginnen. Das fühlt sich produktiv an und bewegt nichts.

Reihen Sie stattdessen nach Wirkung und Risiko zugleich: etwas, das für das Geschäft zählt, dessen Ausfall aber verkraftbar ist. Das ergibt eine erste Welle mit echtem Ergebnis und eine sichere Generalprobe des Vorgehens.

Zwei Regeln halten die Reihenfolge ehrlich:

• Nichts Reguliertes zuerst. Das Vorgehen soll erprobt sein, bevor die Arbeitslast mit der Compliance-Last umzieht.
• Eng gekoppelte Systeme ziehen gemeinsam um. Eine Abhängigkeit über Wellen zu trennen bedeutet eine temporäre Integration, die Sie wegwerfen — dieser Aufwand gehört in den Plan, sonst findet die Trennung nicht statt.

Schritt 3 — Landing Zone bauen und belegen

Die Landing Zone ist die Umgebung, in der alles landet: Netzwerkaufbau, Identitäts- und Berechtigungsmodell, Protokollierung, Überwachung, Sicherung, Kostenkennzeichnung und die Leitplanken, die ein Abdriften verhindern.

Dieser Schritt wird unter Zeitdruck am häufigsten verkürzt — und er bestimmt, wie die nächsten drei Jahre aussehen. Aus einer schwachen Landing Zone stammen die wiederkehrenden Probleme: zu weit gefasste Berechtigungen, öffentlich erreichbarer Speicher, abgeschaltete Protokollierung aus Kostengründen, Kosten, die niemand zuordnen kann.

Zwei Punkte gehören hier geklärt, beide regulatorisch:

• Datenstandort UND Datenzugriff. Speicherung in einer Schweizer oder EU-Region beantwortet nicht, wer von wo darauf zugreift — einschliesslich des Supports Ihres Anbieters. Nach revDSG/nDSG und DSGVO ist die Zugriffsfrage die geprüfte.
• Ein dokumentierter Ausstiegspfad. Für FINMA-beaufsichtigte Unternehmen ist das eine Anforderung, keine Vorsichtsmassnahme.

Klären Sie hier auch die Kostenzuordnung. Kennzeichnen Sie ab Tag eins nach Team oder Produkt. Eine Rechnung an «IT» gibt niemandem einen Anreiz zur Senkung, und eine Kennzeichnung nachträglich über eine laufende Landschaft zu legen ist mühsame Arbeit.

Schritt 4 — In Wellen migrieren, mit erprobtem Rückweg

Jede Welle durchläuft dieselbe Schleife: migrieren, gegen den Ausgangswert aus Schritt 1 prüfen, wo möglich parallel betreiben, dann umschalten.

Übersprungen wird meist der Rückweg. Ein Rückfallplan, der nie ausgeführt wurde, ist eine Annahme und kein Plan. Prüfen Sie ihn in der ersten Welle, wenn der Einsatz am geringsten ist.

Was pro Welle zu prüfen ist — über «es startet» hinaus:

• Verhalten unter realistischer Last, nicht unter Rauchtest-Last
• Wiederherstellung aus der Sicherung, tatsächlich durchgeführt
• Ausfall einer Verfügbarkeitszone
• Der Rückfall selbst

Schritt 5 — Optimieren, mit benannter Verantwortung

Die Einsparung entsteht nicht durch die Migration. Sie entsteht durch das, was danach angepasst wird: Dimensionierung an die reale Nutzung, Abschalten von Nicht-Produktionsumgebungen ausserhalb der Arbeitszeiten, Aufräumen verwaister Volumes und Snapshots, reservierte Kapazität für stabile Lasten.

Nichts davon geschieht, wenn das Vorhaben mit dem Go-live endet und das Team sich auflöst. Dieser Schritt braucht daher von Anfang an drei Dinge im Plan: eigenes Budget, eigenen Zeitraum und eine benannte Person — kein Gremium —, die monatlich über Abweichungen berichtet.

Wie sich das als Zahl zeigt

Eine so geplante Migration zeigt ihren Ertrag meist an drei Stellen statt an einer: Infrastrukturkosten nach dem Optimierungsschritt, zurückgewonnene Engineering-Zeit aus manueller Umgebungsarbeit und die Zeit bis zu einer Änderung für das Geschäft.

Der dritte Punkt ist meist der grösste und der am seltensten gemessene. Sinkt die Bereitstellung einer Testumgebung von drei Tagen auf zwei Stunden, verändert das, was sich das Geschäft überhaupt zutraut — und dieser Effekt steht auf keiner Infrastrukturrechnung.

Weiterführend

• Cloud-Migration: 10 Fehler, die KMU immer noch machen — die Fehlerbilder, die jeder Schritt oben verhindern soll
• Cloud-ROI in der Schweiz: 5 Lehren für ICT-Leitung — die Kostenseite im Detail
• Cloud & DevOps — wie wir solche Vorhaben begleiten

Wenn Sie eine Migration vor sich haben oder eine hinter sich, die nicht liefert, was sie sollte — vereinbaren Sie ein Gespräch. Unverbindlich.