Ein Migrationsvorschlag kann vollständig wirken, wenn er Server und Zielumgebung aufführt. Die schwierigeren Fragen betreffen die Arbeit, die diese Server unterstützen. Können Mitarbeitende weiterhin Aufträge bearbeiten? Wann läuft ein geplanter Export? Wer prüft die Datensätze nach der Übertragung? Ein Cloud-Migrationsplan sollte Infrastrukturentscheidungen mit diesen Alltagsaufgaben verbinden. Die folgende Reihenfolge macht aus einem umfassenden Umzug überprüfbare Arbeit.
Auf dieser Seite
Die betriebliche Verbesserung definieren
Ersetzen Sie „in die Cloud umziehen“ durch einen überprüfbaren Grund. Vielleicht hängen Releases von einem manuell konfigurierten Server ab, oder eine Spitzenzeit erfordert Kapazität, die die aktuelle Umgebung nicht bietet. Erfassen Sie das heutige Verhalten, bevor Sie die Zielumgebung spezifizieren. Ohne diese Ausgangsbasis ist schwer erkennbar, ob der Umzug das ursprüngliche Problem gelöst oder nur seinen Ort verändert hat.
- Benennen Sie den betroffenen Ablauf und die verantwortliche Person.
- Beschreiben Sie eine beobachtbare Verbesserung, etwa einen wiederholbaren Bereitstellungsprozess.
- Listen Sie die Grenzen auf, die bei der Migration einzuhalten sind.
Die Verbindungen jedes Workloads abbilden
Listen Sie für jede Anwendung Datenbank, Dateispeicher, geplante Jobs, externe Dienste und Zugriffsanforderungen auf. Lassen Sie die Übersicht von den Betriebsverantwortlichen prüfen. Ein nächtlicher Bericht oder eine Lieferantenanbindung wird in einer Serverinventur leicht übersehen. Markieren Sie, welche Abhängigkeiten gemeinsam umziehen müssen und welche Verbindungen während eines schrittweisen Übergangs bestehen bleiben können.
Den Migrationsansatz pro Anwendung wählen
Beispielentscheidung: Ein Kundenportal nutzt eine unterstützte Laufzeitumgebung, teilt aber eine Datenbank mit einer älteren Buchhaltungsanwendung. Das Portal zuerst zu verschieben ist möglicherweise nur sinnvoll, wenn die verbleibende Datenbankverbindung die vereinbarten Zugriffs- und Leistungsanforderungen erfüllt. Andernfalls sollten die verbundenen Workloads gemeinsam umziehen oder die Abhängigkeit zuerst aufgelöst werden. Vergleichen Sie direkten Umzug, gezielte Änderungen und Neuentwicklung anhand des Bedarfs dieser Anwendung. Nicht die gesamte Systemlandschaft benötigt denselben Ansatz.
Den Betrieb der neuen Umgebung gestalten
Weisen Sie Zuständigkeiten für Zugriffe, Bereitstellungen, Warnmeldungen, Backups und Kostenprüfungen zu. Schätzen Sie den Bedarf anhand verfügbarer Nutzungsdaten, einschließlich ruhigerer Zeiten und Spitzen. Prüfen Sie, wie sich die Schätzung bei wachsendem Speicherbedarf oder Datentransfers zwischen Diensten verändert. Eine hilfreiche Kostendiskussion legt Annahmen und die Überwachung nach dem Start offen, statt die erste Schätzung als feste Betriebsrechnung zu behandeln.
- Wer darf Produktionseinstellungen ändern?
- Wer reagiert, wenn ein Job fehlschlägt?
- Wie wird die Wiederherstellung aus Backups geprüft?
Die Rollback-Entscheidung vor der Umschaltung festlegen
Vereinbaren Sie für das Beispielportal, wie das Team Anmeldung, Auftragserfassung und Datensatzanzahl prüft, bevor die neue Umgebung freigegeben wird. Definieren Sie, welche Fehler die Umstellung stoppen und wer darüber entscheidet. Können Nutzer nach der Umschaltung neue Datensätze anlegen, reicht es nicht, den Verkehr zurück zum alten Server zu leiten: Für diese Datensätze braucht es einen vereinbarten Umgang. Proben Sie die Abfolge und auch den Punkt, ab dem ein Rollback zusätzliche Datenarbeit erfordert.
Die Migration mit Betriebsprüfungen abschließen
Prüfen Sie nach dem Umzug Abläufe, geplante Aufgaben, Warnmeldungen und Nutzungsmuster anhand der vereinbarten Ausgangsbasis. Weisen Sie offenen Problemen Verantwortliche zu. Nehmen Sie die alte Umgebung erst außer Betrieb, nachdem das Team seine Übergangsprüfungen abgeschlossen und entschieden hat, welche Daten oder Konfigurationen erhalten bleiben müssen. Halten Sie Anwendungsübersicht und Wiederherstellungsanweisungen für die künftigen Betriebsverantwortlichen verfügbar.