Zum Inhalt gehen

Wie übersteht man eine Lift & Shift Cloud Migration?

Stanimir Dimitrov, Malgorzata Ilczyk
12 Aug 2022

Cloud Migration per Lift & Shift klingt einfach: Server ziehen aus der alten Infrastruktur um in die neue. Was könnte dabei schon schief gehen? Alles! Der Umzug läuft glatter, wenn man die häufigsten Fehler kennt und sie vermeidet.

Cloud-Migration per Lift & Shift ist im Grunde ganz simpel: Man zieht Server und Applikationen von der alten Infrastruktur in eine neue um. Was kann denn dabei schief gehen? Die kurze Antwort lautet: Alles! Die Fehlermuster aber wiederholen sich – und sind damit vermeidbar. Dabei hilft auch die Einrichtung eines speziellen Migration Defect Management Teams.

Der Umzug in die Cloud steht bei jedem Unternehmen als strategische Notwendigkeit auf der Agenda – außer er ist längst erfolgt. Allerdings gleicht die Cloud-Migration stärker dem Erlebnis eines Bauherrn als dem Umzug in die nächste Altbauwohnung: Das neue Haus muss erst geplant, gebaut und fertig sein, bevor er die alte Mietwohnung verlässt. Überraschungen sind einkalkuliert – und doch dauert schnell alles sehr viel länger als geplant. Mietkosten türmen sich auf Hausrechnungen, die Anspannung steigt und alle warten auf die neuen Räume, das Mehr an Platz, die Flexibilität für Gäste.

Ähnlich ist es bei der Migration aus dem alten Rechenzentrum in die Cloud. Bei der am häufigsten eingesetzten Methode Lift & Shift werden die Server einer Applikation aus der bestehenden Infrastruktur (CMO = Current Mode of Operation) kopiert und in eine neue (FMO = Future Mode of Operation) integriert. Das klingt einfach, doch fraglich ist normalerweise nicht, ob alle Anwendungen nach der Migration funktionieren, sondern wie viele es nicht tun. Zahlreiche Schwierigkeiten können auftreten – und viele folgen eigentlich bekannten Mustern. Sie ziehen die Migrationsdauer unnötig in die Länge, steigern die Kosten und lassen das ganze Unternehmen länger auf die erwarteten Cloud-Vorteile warten.

Lift & Shift ist für große Legacy-Migrationsszenarien mit tausenden Servern und Applikationen der einfachste und kosteneffizienteste Ansatz. Da er sich skalieren lässt, können auch umfangreiche Migrationsprojekte in einem überschaubaren Zeitraum abgeschlossen und die Vorzüge der Cloud zügig realisiert werden: die Flexibilität der Public Cloud für neue Technologien mit modernen IT-Architekturen zu nutzen etwa, eine schnellere Time-to-Market oder Energie, Kosten und CO2 einzusparen.

Fehlermuster wiederholen sich

Erfahrene Migrationsteams kennen die häufigsten Fehlerquellen und halten sie von Beginn an im Blick, denn die Identifikation und Dokumentation von Fehlermustern spielt im Verlauf eines Migrationsprojektes eine zentrale Rolle. So kann das Team Präventivmaßnahmen entwickeln und implementieren, um Fehlermuster frühestmöglich eingrenzen oder aushebeln. Die meisten dieser Muster beruhen auf Faktoren wie Technologie, Migrationsansatz oder -werkzeug, Netzwerkzone oder Abhängigkeiten von anderen Systemen. Die folgende Tabelle beschreibt für einige der häufigsten Fehlermuster die Ursachen und was Migrationsteams präventiv dagegen tun können:

FehlermusterUrsacheVorbeugende Maßnahmen
Benutzung eines neuen externen Proxy-Server im FMODie Anwendungen sind nicht in der Lage den neuen externen Proxy zu verwenden, wenn sie externe Systeme/Dienste über das Internet aufrufen.Erstellung eines PoC, um sicherzustellen, dass die Anwendungen in der Lage sind, den FMO External Proxy zu verwenden. Idealerweise werden die Anwendungen so konfiguriert, dass sie den FMO External Proxy bereits vor der Migration (in CMO) nutzen.
Middleware / Application Services stehen nicht zur VerfügungMiddleware / Application Services wurden nach der Migration nicht oder nicht in der richtigen Reihenfolge gestartet. Überprüfung und Aktualisierung der Applikationsdokumentation.Post-Migration erfolgt der Start aller benötigten Services/ Dienste gemäß der Dokumentation in der richtigen Reihenfolge 
Fehlerhafte oder fehlende Load-Balancer-KonfigurationDie Load-Balancer-Konfiguration im FMO entspricht nicht der Umgebungsänderungen (bspw. Re-IP) nach der Migration.Sorgfältige Überprüfung aller benötigten Änderungen, die die Migration verursacht (bspw. re-IP) und Implementierung im FMO.
Der Netzwerkverkehr wird durch Firewalls im FMO blockiert.Fehlende Firewall-RegelnNach der Analyse aller bestehenden Firewall-Regeln im CMO werden die für das FMO identifiziert und dort implementiert. Wichtig ist es dabei, neue Server-IPs sowie Veränderungen der Netzwerkarchitektur (unterschiedliche Netzwerkzonen, Sicherheitsmechanismen on premise vs. public cloud etc.) zu berücksichtigen.
Fehlerhafte DNS-Einträge (Domain Name System)DNS-Einträge wurden nicht aktualisiert, nachdem migrierte Server neue IPs zugewiesen bekommen haben.Beim Lift & Shift Ansatz wird häufig ein re-IP durchgeführt. DNS-Einträge müssen dementsprechend aktualisiert werden, sodass sie auf die IP-Adressen im FMO und nicht auf die im CMO verweisen.
Festcodierte IPs im Quellcode oder in KonfigurationsdateienDas ist ein Anti-Pattern, das leider von einigen Software-Entwicklern verwendet wird. Durch das re-IP sind die migrierten Server unter den CMO IP-Adressen nicht mehr erreichbar.Quellcode und Konfigurationsdateien sollten nach fest codierten IPs durchsucht und durch FQDNs (Fully Qualified Domain Names) ersetzt werden.
An MAC/IP-Adressen gebundene SoftwarelizenzenEine Änderung der MAC/IP-Adresse während der Migration führt dazu, dass ein Softwarelizenzschlüssel auf einem Rechner ungültig wird.Überprüfung aller Softwarelizenzen und ggf. Generierung neuer Lizenzschlüssel.
Migrierte Server/Applikationen können nicht mit anderen Systemen kommunizieren.Netzwerk-Konnektivität zu anderen Rechenzentren, public Cloud Subscriptions und entfernten Standorten (z. B. Offices, Fabrikanlagen) fehlt.Überprüfung und Herstellung der Netzwerkkonnektivität zwischen der Ziel-Netzwerkzone der Anwendung und allen abhängigen Systemen an anderen Standorten.
Performance-ProblemeUnzureichende CPU, Arbeitsspeicher oder Speicherplatz nach der Migration.Verkleinerung (Downsizing) der VMs zur Kostenoptimierung sollte erst nach einer umfassenden Analyse der CPU-, Arbeitsspeicher- oder Speichernutzung stattfinden. Es ist empfehlenswert die Möglichkeiten der Cloud Hypervisor zur Optimierung zu nutzen (z. B. Azure Storage Disk Cache). Vor der Migration sollte außerdem eine „Performance Baseline“ festgelegt werden.
Zu hohe Netzwerklatenz und zu niedriger ‑durchsatzAbhängige Systeme befinden sich noch im CMO.Analyse der Abhängigkeiten einer Anwendung sowie potenzieller Netzwerklatenzen und Durchsatzprobleme, die durch die „geteilte“ Migration verursacht werden (d. h. nicht alle voneinander abhängigen Anwendungen befinden sich im FMO oder können auf einmal migriert werden). Falls erforderlich, muss die Migrationsplanung angepasst werden.

Schlüssel zum Erfolg

Um diese und weitere Fehlerquellen möglichst schnell abstellen zu können, schlagen wir eine Vorgehensweise mit 3 Komponenten vor: einem Cloud Operating Modell, Agilität und kontinuierlicher Verbesserung. Die Anzahl der Iterationen sollte sich an Dauer und Umfang des Migrationsprojektes orientieren – mit einer Iterationslänge von jeweils zwei bis vier Wochen. So kann das Migrationsteam während des gesamten Transformationsprojektes neue Erkenntnisse kontinuierlich und zügig im Prozess verankern. Kürzere Iterationslängen führen zu übermäßig häufigen, zeitintensiven Abstimmungsterminen. Längere Iterationen dagegen können die Umsetzung der Verbesserungsmaßnahmen zu stark verzögern.

Cloud Operating Model

Nach einer Migration befinden sich die Anwendungen im FMO. In der Regel handelt es sich um ein anderes Betriebsmodell als beim CMO. Deswegen sollten die neuen organisatorischen, betrieblichen und wirtschaftlichen Richtlinien gut verstanden und berücksichtigt werden. Das Ergebnis der Migration einer Applikation sollte eine Lösung sein, die dem Cloud-Betriebsmodell entspricht. Damit können die Vorteile einer public Cloud optimal genutzt werden. Ausnahmen sollte der Kunde offiziell als gewünscht bestätigen.

Agilität

Ein großes Migrationsvorhaben involviert tausende Applikationen, die auf einer Vielzahl von Technologien basieren. Aus diesem Grund sollte die Teamstruktur flexibel gehalten werden. Um ein komplexes System nach einer Migration rechtzeitig und effizient wieder zum Laufen zu bringen, können bei Bedarf schnell Task Forces gebildet werden, die über die erforderlichen Technologiekenntnisse verfügen. Hinzu kommt, dass Anwendungen, die dieselben Technologien verwenden, nach der Migration in der Regel die gleichen Probleme aufweisen wie zuvor. So kann die jeweilige Task Force effizient Anwendungsprobleme behandeln, denen dasselbe Fehlermuster zugrunde liegt. Zu beachten ist, dass auch Experten außerhalb des Migration Defect Management Teams (z. B. Drittanbieter) Teil der Task Forces sein können. Sobald die Grundursache und die Lösung identifiziert worden sind, kann das Migrationsteam die Lösung wiederverwenden.

Kontinuierliche Verbesserung

Cloud Migrationsprojekte sind sehr komplex, fehleranfällig und haben in der Regel eine lange Laufzeit. Die IT jedes Unternehmens ist anders. Umso wichtiger ist eine Learning-by-doing-Vorgehensweise. Diese ermöglicht das Erlernen von Fähigkeiten, die im konkreten Projekt für den Erfolg entscheidend sind. Was hat gut geklappt? Wo gab es Probleme? Sind meine Migrationsprozesse effizient genug? Wenn die bei der Behebung von Anwendungsmigrationsfehlern gewonnenen Erkenntnisse in die kontinuierliche Verbesserung der Migrationsprozesse einfließen und die ermittelten Präventivmaßnahmen mit allen Beteiligten (Migrationsarchitekten, Anwendungsteams, Supportteams usw.) geteilt werden, lässt sich vermeiden, dass bei den bevorstehenden Migrationen dieselben Probleme erneut auftreten.

Personeller Erfolgsfaktor: das Migration Defect Management Team

Darüber hinaus ist es auf der organisatorischen Ebene sinnvoll, ein sogenanntes Migration Defect Management Team aufzustellen, das während des gesamten Projekts als Single Point of Contact gegenüber allen anderen Parteien (Kunde, Migrationsteams, Applikationsteams und Drittanbieter) fungiert. Es hält dem übrigen Migrationsteam den Rücken frei, sammelt zentral das gesamte Wissen über die auftretenden Applikationsmigrationsfehler und

  • identifiziert und dokumentiert gemeinsame Muster und deren Lösungen
  • definiert Präventivmaßnahmen und teilt diese mit interessierten Parteien, insbesondere mit den Migrations- und Anwendungsteams
  • dient als übergeordnetes Team im Rahmen des Transformationsprojektes, unabhängig von den verwendeten Technologien.

Die Hauptkomponenten für eine zeiteffiziente Problemlösung sind CMO-, FMO- und Anwendungswissen. Daher soll das Migration Defect Management Team ein umfassendes Verständnis sowohl der CMO- als auch der FMO-Umgebung und Zugriff auf die Anwendungsdokumentation haben. So kann dieses Team das Gesamtbild überblicken. Es versteht

  • wie die Anwendung in CMO funktioniert hat
  • wie die Anwendung in FMO funktionieren soll
  • welche Abhängigkeiten zwischen der Anwendung und den anderen Systemen bestehen

und kann Migrationsprobleme so effizient lösen.

Lift & Shift-Migrationen sind ein Prozess, der eine umfassende Vorbereitung und sorgfältige Ausführung erfordert. Um den Kosten- und Zeitaufwand gering zu halten und dem Business die Cloud-Vorteile möglichst schnell zur Verfügung stellen zu können, sollten die 3 Komponenten Cloud Operating Modell, Agilität und kontinuierlicher Verbesserung im Vorgehen berücksichtigt werden. Ein gut vorbereitetes und organisiertes Migration Defect Management Team kann den Ablauf eines jeden Lift & Shift Cloud Migration Programms darüber hinaus sehr viel reibungsloser gestalten.

Autor*innen

Stanimir Dimitrov

Enterprise/Cloud Architecture

Malgorzata Ilczyk

Data Architecture

    Blog-Updates per Mail?

    Abonnieren Sie unseren Newsletter und erhalten Sie alle zwei Monate eine Auswahl der besten Blogartikel.