Über die VM-Migration hinaus: Was kommt nach dem Lift-and-Shift?

Ich habe dieses Gespräch dutzende Male mit Infrastrukturteams geführt. Das Unternehmen hat gerade eine VM-Migration von einem Legacy-Hypervisor abgeschlossen oder befindet sich gerade in dieser Phase. Der schwierige Teil ist fast geschafft. So denken sie zumindest.

Hier ist der Punkt, über den die meisten nicht sprechen: Die Migration an sich ist der einfache Teil. Das ist taktisch. Sie hat einen klaren Anfang, eine klare Mitte und ein klares Ende. Was danach kommt, die Modernisierung Ihrer Infrastruktur, das ist die Umgebung, in der die eigentliche Arbeit stattfindet, und ehrlich gesagt, auch der größte Mehrwert.

Die Veränderungen in den Branchen, die diese Migrationen vorantreiben, stellen eine strategische Chance für die moderne Infrastruktur dar. Angesichts der Aspekte Lizenzeffizienz, Kostenoptimierung und Anbieterflexibilität entscheiden sich viele Unternehmen in einem noch nie dagewesenen Tempo für Red Hat OpenShift Virtualization. Seit Anfang 2024 ist die Kundenakzeptanz um 178 % gestiegen. Während sich viele Diskussionen nur auf die Migration konzentrieren, liegt der wahre Wert in der Innovation, die nach der Migration stattfindet.

Die Migration ist nicht das Endziel, sondern der Ausgangspunkt für zukunftsorientierte Organisationen. Bei dieser Umstellung geht es nicht nur darum, vergangene Herausforderungen zu lösen, sondern auch darum eine Basis zu schaffen, auf der Sie die Funktionen einer modernen, einheitlichen und zukunftssicheren Anwendungsplattform in vollem Umfang nutzen können.

So sieht diese umfassendere Roadmap in der Praxis aus.

Phase 1: Ordnung im Linux-Bereich schaffen

Nach der Migration sollten Sie die unkontrollierte Ausbreitung Ihres Betriebssystems bewerten. Die meisten Unternehmen verfügen über eine Mischung aus Distributionen, Versionen und Supportverträgen, die sich über Jahre des internen Wachstums angesammelt haben und nicht durch bewusste Auswahl. Um es klarzustellen: Als Open Source-Unternehmen möchten wir Ihnen nicht sagen, dass Monokulturen immer die Lösung sind. Heterogenität hat reale Vorteile. Sie kann gemeinsame Fehlermodi reduzieren und den Wirkungsradius einer einzelnen Fehlerklasse begrenzen. Ein Teil dieser Vielfalt ist beabsichtigt und vertretbar.

In großen Unternehmen ist vieles davon jedoch nicht beabsichtigt. Das sind technische Schulden. Es handelt sich um die Ubuntu-Instanz, die 2019 für ein Projekt erstellt wurde und auf der jetzt etwas Wichtiges ausgeführt wird. Es ist das CentOS-System, das nach der Ankündigung des End-of-Life (EOL) niemand gepatcht hat. Es ist das Windows XP-System, von dem niemand so genau weiß, was es tut, das aber bei einem Ausfall Probleme verursacht.

Sobald Sie die Hypervisor-Schicht standardisiert haben, ist der nächste logische Schritt, sich mit den Guest-Betriebssystemen zu befassen. Der Einsatz von Red Hat Enterprise Linux (RHEL) zusammen mit Red Hat OpenShift bietet Ihnen ein konsistenteres Betriebsmodell – einheitliches Patching, kohärente Supportpfade und Durchsetzung von Richtlinien, die in Ihrer gesamten Umgebung funktionieren. Die Umfrage von Red Hat zu den Global Tech Trends 2024 ergab, dass 45 % der Unternehmen die Modernisierung ihres Anwendungs-Stacks ganz oben auf der Liste sehen. Die Modernisierungsinitiativen, die tatsächlich funktionierten, folgten dem gleichen Prinzip: unnötige Vielfalt der Betriebssysteme beseitigen und an Systemen mit einem gültigen Business Case festhalten.

Phase 2: Die neue Plattform nicht mehr wie die alte verwalten

Das ist der Fehler, den wir am häufigsten sehen. Die Teams führen eine Migration durch und verwalten dann die neue Umgebung genauso wie die alte. Dieselben manuellen Prozesse. Dieselben ticketgesteuerten Patching-Zyklen. Dieselben Ad-hoc-Änderungen über eine Konsole.

Die Umgebung nach der Migration ist ein Neuanfang. Es ist wahrscheinlich die beste Gelegenheit für Sie, Ihre Automatisierungsgeschichte richtig umzusetzen.

Mit Red Hat Ansible Automation Platform können Teams den Arbeitsaufwand für das Rollout manueller Aufgaben von Wochen auf Stunden reduzieren. Sobald die Playbooks vorhanden sind, erfolgen Provisionierung, Patching und Compliance automatisch.

Wenn Ihr Team bereits in GitOps-Bereich arbeitet, können Sie mit Red Hat Advanced Cluster Management for Kubernetes dieselbe Disziplin auf die Virtualisierung übertragen. Richtlinien werden zu Code, der in Git gespeichert wird. Kein konsolengesteuertes Driften mehr. Das bedeutet strengere Kontrollen von Abweichungen, schnellere Rollouts und vorhersehbarere Day-2-Operationen.

Die praktische Wahrheit lautet: Automatisierung ist kein „Nice to Have“ auf dem Weg zur Modernisierung. Denn nur sie macht die späteren Phasen erst möglich.

Phase 3: Workloads dort ausführen, wo sie hingehören

Nicht jede Workload sollte für immer eine virtuelle Maschine (VM) bleiben. Einige davon eignen sich nativ für Containerisierung. Ziel ist jedoch nicht die Containerisierung von allen Inhalten. Ziel ist es, die einzelnen Workloads dort auszuführen, wo es am sinnvollsten ist.

Mit OpenShift können Sie VMs und Container auf derselben Plattform verwalten, sodass Sie sich nicht zwischen „Lift-and-Shift für alles“ und „alles cloudnativ umschreiben“ entscheiden müssen. Diese falsche Wahlmöglichkeit hat in der gesamten Branche bereits enorme Mengen an Geld und Zeit verschwendet. PNC Bank ist ein gutes Beispiel für ein pragmatisches Vorgehen. Das Unternehmen führte neue Standards ein und verkürzte die Lieferzeit von 8 Wochen auf ein Ziel von 10 Tagen.

In dieser Phase geraten viele Teams ins Stocken. Die Technologie ist nicht der schwierige Teil. Der schwierige Teil besteht darin, herauszufinden, welche Workloads wann und in welcher Reihenfolge verschoben werden. Die Unterstützung durch jemanden mit entsprechender Erfahrung kann den Unterschied zwischen einem Modernisierungszyklus von 6 oder 13 Monaten ausmachen. Forrester-Studien bestätigen dies. Ein Unternehmen verkürzte mit erfahrener Unterstützung die Bereitstellung und VM-Migration von OpenShift von 13 auf 7 Monate.

Phase 4: Über KI nachdenken, bevor es notwendig wird

Das ist das Besondere an KI: Niemand hat sie erfolgreich auf einer Infrastruktur eingeführt, die vorher schon ein einziges Chaos war. Laut Gartner® werden sich die weltweiten Ausgaben für KI in 2026 auf 2,5 Billionen USD belaufen.

Damit ist nicht gemeint, dass Sie KI planen müssen, bevor Sie die Migration abgeschlossen haben. Aber die Teams, die dies erfolgreich umgesetzt haben, verfügten über eine saubere, automatisierte Infrastruktur als Basis. KI-Workloads sind anspruchsvoll, wenn es um Computing, Storage und Observability geht. Sie lösen dieses Problem lieber auf einer standardisierten Kubernetes-nativen Plattform, als es aus jahrelangem organischem Wachstum zu entwirren.

Migration bewegt Sie. Modernisierung transformiert Sie.

Durch die Migration verlassen Sie eine Plattform, auf der Sie nicht bleiben wollten. Durch die Modernisierung entsteht eine Plattform, die Sie tatsächlich benötigen. Dabei handelt es sich um grundlegend verschiedene Dinge. Und in der Lücke dazwischen liegen die eigentliche Arbeit (und der wahre Wert).

Pressemitteilung von Gartner: Laut Gartner werden die weltweiten Ausgaben für KI im Jahr 2026 insgesamt 2,5 Billionen USD betragen, 15. Januar 2026

GARTNER ist eine Marke von Gartner, Inc. und/oder seinen verbundenen Unternehmen.