Wie würdest du die Migration einer On-Premises-Anwendung in die Cloud planen?

Erst Inventar und Bewertung, dann eine Behandlung pro Komponente statt einer Strategie für alles: rehosten, was stabil ist, replatformen, wo ein Managed Service Aufwand wegnimmt, refactoren nur da, wo es sich klar auszahlt, und alles ausmustern, was niemand nutzt. Sortier nach Risiko und fang mit etwas Unkritischem an, um die Pipeline zu beweisen. Plan Datenmigration und Cutover sorgfältig, denn dort liegt die echte Downtime, und halt einen Rollback-Pfad bereit.

Die erste Phase ist Discovery, und sie dauert immer länger, als irgendjemand einplant. Was läuft, was redet mit was, wie die tatsächliche Auslastung aussieht, wem es gehört und welche Lizenz- und Compliance-Zwänge es gibt. Daraus fällt eine Entscheidung pro Komponente statt einer Strategie für die ganze Landschaft. Stabile Dinge, die funktionieren, werden mit minimaler Änderung rehostet, denn der Wert liegt darin, aus dem Rechenzentrum rauszukommen, nicht im Umschreiben. Dinge, bei denen ein Managed Service einen Haufen Betriebsarbeit wegnimmt, meistens Datenbanken und Queues, werden replatformt. Refactoring hebe ich mir für Komponenten auf, bei denen es einen echten Business Case gibt, denn es ist die langsamste und riskanteste Option. Und erstaunlich viel wird ausgemustert, denn jede Landschaft hat Server, die seit Jahren niemand mehr braucht. Dann Sortierung nach Risiko: zuerst ein interner Service mit wenig Traffic, damit wir Netzwerk, Pipeline und Runbook dort üben, wo Fehler billig sind. Daten sind der harte Teil, also vorab kontinuierlich replizieren, parallel fahren und das On-Premises-System nach dem Cutover noch ein paar Wochen live und rollbackfähig halten.