Cloud-Migration: 10 Fehler, die KMU immer noch machen

Die meisten Cloud-Migrationen scheitern nicht. Sie enttäuschen — und das ist schwerer zu erkennen und schwerer zu korrigieren.

Die Systeme laufen. Die Abschaltung des alten Rechenzentrums war erfolgreich. Trotzdem ist die Rechnung höher als geplant, die Entwicklung nicht schneller, und die Frage nach dem Nutzen bleibt unbeantwortet.

Zehn Fehler, die dafür verantwortlich sind. Die ersten drei erklären die meisten Fälle.

1. Die Bewertungsphase wird übersprungen

Die Migration beginnt mit einer Liste von Servern statt mit einer Liste von Arbeitslasten. Das ist nicht dasselbe.

Eine brauchbare Bewertung beantwortet pro Anwendung: Wer nutzt sie, wie oft, mit welchem Lastprofil? Welche Daten verarbeitet sie und welchen Schutzbedarf haben diese? Wovon hängt sie ab, und was hängt von ihr ab? Was kostet ein Ausfall pro Stunde?

Ohne diese Antworten wird jede Arbeitslast gleich behandelt — und eine Anwendung, die einmal im Quartal läuft, erhält dieselbe Ausstattung wie eine, die das Tagesgeschäft trägt.

2. Datenschutz wird nachgelagert

Wer revDSG/nDSG und DSGVO erst nach der Architekturentscheidung betrachtet, baut Umgebungen, die später verschoben werden müssen.

Die Fragen gehören an den Anfang: In welcher Region liegen die Daten? Wer kann aus welchem Land darauf zugreifen — auch im Support? Welche Unterauftragsverarbeiter sind beteiligt? Wie lange werden Protokolldaten aufbewahrt, und ist das dokumentiert?

Besonders die Zugriffsfrage wird unterschätzt. Ein Schweizer Speicherort mit weltweitem Administrationszugriff erfüllt die Erwartung nicht, die ein Kunde mit «Daten in der Schweiz» verbindet.

3. Die Gesamtkosten werden unterschätzt

Verglichen wird meist Rechenleistung gegen Rechenleistung. Auf der Rechnung stehen dann Posten, die in der Schätzung fehlten:

• Datentransfer zwischen Zonen, Regionen und nach aussen
• Speicher-Snapshots, die nie aufgeräumt werden
• Verwaltete Dienste, die bequemer und teurer sind als die selbstbetriebene Variante
• Lizenzen, die in der Cloud anders bepreist werden als im eigenen Rechenzentrum
• Der Aufwand für den Betrieb, der nicht verschwindet, sondern sich verlagert

4. «Lift and Shift» wird als Ziel behandelt

Eine unveränderte Übernahme ist ein legitimer erster Schritt — und ein schlechter Endzustand. Sie überträgt die bisherige Dimensionierung, die bisherigen Abhängigkeiten und die bisherigen Wartungsfenster in eine Umgebung, in der Sie pro Stunde zahlen.

Der Nutzen entsteht im zweiten Schritt: Dimensionierung an die reale Last anpassen, Zustand aus den Anwendungsservern herauslösen, Umgebungen automatisiert erstellen. Wird dieser Schritt nicht budgetiert, findet er nicht statt.

5. Sicherheit wird als Abschlussprüfung behandelt

Die Verantwortungsteilung wird häufig missverstanden. Der Anbieter sichert die Infrastruktur. Konfiguration, Identitäten, Netzwerkregeln und Daten bleiben bei Ihnen — und dort entstehen die meisten Vorfälle.

Die wiederkehrenden Befunde: zu weit gefasste Berechtigungen, weil eng gefasste anfangs Arbeit machten. Öffentlich erreichbare Speicher, die es nie sein sollten. Zugangsdaten in Repositories. Deaktivierte Protokollierung, weil sie Kosten verursacht.

6. Die Menschen werden nicht mitgenommen

Ein Betriebsteam, das zehn Jahre Server administriert hat, arbeitet nach der Migration anders. Ohne Schulung und ohne Zeit zum Üben entstehen Umgehungslösungen: manuelle Eingriffe an der Automatisierung vorbei, Konfigurationen, die nur eine Person versteht, Dokumentation, die nie entsteht.

Das ist kein Personalthema. Es ist ein Planungsthema — und es gehört in den Projektplan, nicht in die Zeit danach.

7. Das falsche Modell oder der falsche Anbieter

Multi-Cloud klingt nach Unabhängigkeit und bedeutet in der Praxis doppelten Betriebsaufwand. Für die meisten KMU ist ein Anbieter mit einem dokumentierten Ausstiegspfad die bessere Wahl als zwei Anbieter mit halber Kompetenz in beiden.

Umgekehrt gibt es gute Gründe für eine hybride Aufstellung: regulatorische Auflagen, Anwendungen mit besonderen Latenzanforderungen, Hardware-Abschreibungen, die noch laufen. Die Entscheidung sollte begründet sein, nicht standardmässig.

8. Zu wenig getestet

Getestet wird meist, ob die Anwendung startet. Nicht getestet wird, was tatsächlich schiefgeht: Verhalten unter Last, Wiederherstellung aus dem Backup, Ausfall einer Verfügbarkeitszone, Rückfall auf die alte Umgebung.

Der Rückfallplan ist der am häufigsten fehlende. Er muss geprüft sein, bevor er gebraucht wird — sonst ist er eine Annahme.

9. Schwache Wiederherstellungsplanung

«Die Cloud hat Backups» ist kein Wiederherstellungskonzept. Ein Konzept nennt zwei Zahlen pro Anwendung: wie viel Datenverlust akzeptabel ist und wie lange die Wiederherstellung dauern darf.

Diese Zahlen kommen aus dem Geschäft, nicht aus der IT. Und sie sind wertlos, solange die Wiederherstellung nicht mindestens einmal geübt wurde.

10. Nach der Migration wird nicht optimiert

Der letzte und teuerste Fehler. Das Projekt endet mit dem Go-live, das Team wird aufgelöst, und die Umgebung bleibt in dem Zustand, in dem sie am Umzugstag war.

Die Einsparung entsteht aber genau danach — in der Anpassung der Dimensionierung, im Abschalten ungenutzter Umgebungen, im Aufräumen verwaister Ressourcen, in reservierten Kapazitäten für stabile Lasten.

Geplant gehört das als eigener Abschnitt mit eigenem Budget und einer benannten verantwortlichen Person.

Was das zusammengenommen bedeutet

Neun dieser zehn Fehler haben dieselbe Ursache: Die Migration wurde als Umzug geplant und nicht als Veränderung der Betriebsweise.

Ein Umzug ist am Zieltag fertig. Eine Veränderung der Betriebsweise hat einen Vorher-Wert, eine Messgrösse und einen Abschnitt nach dem Go-live. Der Unterschied kostet in der Planung wenig und entscheidet über das Ergebnis.

Vertiefend dazu: Cloud-ROI in der Schweiz geht auf die Kostenseite im Detail ein. Wie wir Migrationen begleiten, steht unter Cloud und DevOps.

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