Die Migration Hunderter Legacy-Anwendungen von VMs zu AWS gelingt, wenn Sie sie wie eine Fertigungslinie führen statt wie Hunderte Einzelprojekte: jede App inventarisieren und einordnen, je App zwischen Upgrade und Neubau entscheiden und den Bestand in Blöcke aufteilen, die kleine Teams verantworten. Ein gemeinsames Anwendungsgerüst, getestete Schritte für Umstellung und Rollback und Runbooks, denen jedes Team folgen kann, halten die Qualität stabil, während das Volumen wächst.
Beginnen Sie mit einem Inventar, das zeigt, was jede App wirklich braucht
Bevor irgendjemand AWS anfasst, listen Sie jede Anwendung auf, die auf den alten VMs läuft, und erfassen Sie die Fakten, die den Migrationsaufwand bestimmen. Eine gemeinsame Tabelle reicht zunächst. Wichtig ist, dass jede App eine Zeile, einen Verantwortlichen und dieselben Spalten hat.
Ordnen Sie dann jede App einem von wenigen Pfaden zu, etwa Upgrade, Neubau und Stilllegung. So können die Teams nach Pfad planen, statt jede App von Grund auf neu zu diskutieren.
- Laufzeitumgebung und Framework-Version, mit Markierung für alles, was sein Supportende erreicht hat
- Datenbanken, Dateifreigaben und geplante Jobs, von denen die App abhängt
- Ein- und ausgehende Integrationen, einschließlich fest codierter Hostnamen und IP-Adressen
- Authentifizierungsmethode und alle auf der VM gespeicherten Secrets
- Fachlich Verantwortliche, Nutzungsintensität und akzeptables Ausfallfenster
Entscheiden Sie je App zwischen Upgrade und Neubau, nicht einmal für das ganze Programm
Keine einzelne Strategie passt zu Hunderten von Apps. Manche brauchen nur ein Framework-Upgrade, eine ausgelagerte Konfiguration und ein neues Deployment-Ziel. Andere enthalten so viel toten Code oder verworrene Strukturen, dass ein Neubau auf sauberer Basis schneller geht als eine Reparatur.
Entscheiden Sie anhand schriftlicher Kriterien, damit verschiedene Teams zur selben Antwort kommen. Eine nützliche Regel: Wenn der Umzug der App auf das Standardgerüst ohnehin bedeutet, die meisten Controller und den Datenzugriff neu zu schreiben, bauen Sie sie neu. Lässt sich die Geschäftslogik weitgehend unverändert übernehmen, machen Sie ein Upgrade.
Das Programm von Crédit Agricole, das 600+ interne Anwendungen von alten VMs zu AWS brachte, nutzte beide Wege. Die Apps wurden auf dem internen CodeIgniter-Gerüst der Bank neu aufgesetzt, manche per Upgrade, manche von Grund auf neu gebaut.
- Upgrade, wenn der Code lesbar, sein Verhalten klar und der Abstand zur aktuellen Framework-Version klein ist
- Neubau, wenn Geschäftslogik überall mit der Darstellung vermischt ist oder die App von entfernten Sprachfunktionen abhängt
- Stilllegung, wenn die Nutzung nahe null liegt und die fachlich Verantwortlichen zustimmen, denn die günstigste Migration ist die, die Sie auslassen
Teilen Sie den Bestand in Blöcke und geben Sie jeden Block einem Team
In dieser Größenordnung wird ein einzelnes zentrales Team zum Engpass. Bei der Aufteilung in Blöcke erhält ein kleines Team eine Gruppe zusammenhängender Apps und verantwortet sie von der Analyse bis zur Umstellung.
Bilden Sie Blöcke nach gemeinsamen Abhängigkeiten, nicht alphabetisch. Apps, die sich eine Datenbank teilen oder einander aufrufen, sollten zusammen umziehen, sonst wiederholt sich dieselbe Integrationsarbeit in mehreren Teams.
Blöcke machen den Fortschritt auch messbar. Jedes Team meldet für jede App dieselben Status, etwa analysiert, migriert, getestet, umgestellt und stillgelegt, und das Programm-Board ist die Summe dieser Status. Das Programm von Crédit Agricole lief auf diese Weise, und SDK Enterprises hat als Teil des Programmteams 50+ seiner Anwendungsmigrationen umgesetzt.
Bauen Sie ein Standardgerüst und bringen Sie jede App darauf
Ein Standard-Anwendungsgerüst macht aus Hunderten Migrationen einen wiederholbaren Prozess. Es legt die Entscheidungen fest, die nicht für jede App neu getroffen werden sollten: Verzeichnisstruktur, Konfiguration über Umgebungsvariablen, Log-Format, Health Checks, Anknüpfungspunkte für die Authentifizierung und die Deployment-Pipeline.
Jede migrierte App unterscheidet sich dann nur noch in ihrer Geschäftslogik. Reviewer wissen, wo sie suchen müssen, der Betrieb erhält einheitliche Logs und Alarme, und eine Korrektur am Gerüst erreicht jede App, die darauf aufbaut.
Halten Sie das Gerüst klein und versioniert. Wächst es zu einem eigenen Framework heran, fangen die Teams an, es zu umgehen.
Planen Sie Umstellung und Rollback vor der ersten Migration
Jede App braucht einen Umstellungsplan, der festhält, wie der Traffic umzieht, wie die Daten umziehen und wie man zurückkommt. Entscheiden Sie das, bevor die erste App umzieht. Wer einen Rollback mitten in einem Vorfall improvisiert, verspielt als Migrationsprogramm das Vertrauen der Fachbereiche.
- Freeze-Fenster: Vereinbaren Sie mit den fachlich Verantwortlichen, ab wann auf der alten VM keine Änderungen mehr erfolgen
- Datensynchronisation: Migrieren Sie die Daten vorab und führen Sie im Umstellungsfenster eine letzte Delta-Synchronisation durch
- Traffic-Umschaltung: Ändern Sie DNS oder das Routing des Load Balancers, mit niedrigen DNS-TTLs, die Tage vorher gesetzt werden
- Smoke-Tests: eine kurze, skriptgesteuerte Prüfung von Login, wichtigen Screens und Integrationen direkt nach der Umschaltung
- Rollback-Auslöser: eine benannte Person und schriftliche Bedingungen für das Zurückschalten
- Alte VM behalten: Stoppen Sie sie, aber löschen Sie sie erst, wenn die App eine vereinbarte Zeit lang fehlerfrei auf AWS gelaufen ist
Schreiben Sie Runbooks, denen jedes Team vom ersten Tag an folgen kann
Ein Runbook ist die Checkliste für einen wiederholbaren Vorgang: eine App vorbereiten, sie umstellen, sie zurückrollen, die VM stilllegen. Schreiben Sie jedes einmal, testen Sie es an den ersten Apps und aktualisieren Sie es jedes Mal, wenn ein Team von etwas überrascht wird.
Gute Runbooks nennen Befehle, Verantwortliche und erwartete Ergebnisse, keine Absichten. „Prüfen, ob die App funktioniert“ ist kein Schritt. „Als Testnutzer anmelden und bestätigen, dass das Dashboard die Kontodaten lädt“ ist einer.
Runbooks sorgen auch dafür, dass Entwickler, die mitten im Programm dazukommen, schnell produktiv werden. Ein Spezialist, der in Woche sechs einsteigt, sollte nach einer einzigen gemeinsamen Session anhand der Dokumente eine App umstellen können.
Wo ein externes Team in einer großen Migration hilft
Große Programme brauchen oft für einen festgelegten Zeitraum zusätzliche Kapazität, ohne die Kontrolle abzugeben. Wir übernehmen Migrationsblöcke innerhalb größerer Programme und arbeiten dabei mit dem Gerüst, den Runbooks und den Tools des Kunden, mit unseren Entwicklern und geprüften freiberuflichen Spezialisten unter einem Vertrag.
Das Wichtigste in Kürze
- Inventarisieren und klassifizieren Sie jede App, bevor Sie auch nur eine migrieren, damit sich die Arbeit nach Pfaden planen lässt.
- Wählen Sie je App zwischen Upgrade, Neubau und Stilllegung, mit schriftlichen Kriterien, die jedes Team gleich anwendet.
- Teilen Sie den Bestand in Blöcke zusammenhängender Apps, die jeweils ein kleines Team von Anfang bis Ende verantwortet.
- Ein kleines, versioniertes Anwendungsgerüst macht Hunderte Migrationen einheitlich und prüfbar.
- Stellen Sie nie eine App um ohne getesteten Rollback-Weg und ohne dass die alte VM noch verfügbar ist.
FAQ
Wie lange dauert die Migration Hunderter Anwendungen zu AWS?
Das hängt von der Zahl der Apps ab, vom Anteil, der neu gebaut werden muss, von der Zahl paralleler Teams und von den Umstellungsfenstern, die das Geschäft akzeptiert. Schätzen Sie nach der Klassifizierung: Messen Sie die Dauer einiger Apps aus jedem Pfad, multiplizieren Sie mit der Größe jedes Pfads und teilen Sie durch die Teamkapazität.
Legacy-Apps erst per Lift-and-Shift umziehen und später modernisieren?
Lift-and-Shift ist am schnellsten, wenn eine App bereits auf einer unterstützten Laufzeitumgebung läuft und das Ziel ist, ein Rechenzentrum zu verlassen. Bei Apps auf Laufzeitumgebungen am Supportende trägt ein unveränderter Umzug die alten Risiken auf die neue Plattform, sodass ein Upgrade oder Neubau während des Umzugs insgesamt oft günstiger ist.
Was ist eine Migration mit Aufteilung in Blöcke?
Dabei wird ein großer Anwendungsbestand in Gruppen zusammenhängender Apps aufgeteilt, und jede Gruppe geht an ein Team, das sie von der Analyse bis zur Umstellung verantwortet. Das beseitigt den zentralen Engpass und macht den Fortschritt über viele Teams hinweg leicht nachvollziehbar.