„50.000 VMs und ein bitterer Abschied: Das stille Chaos hinter einem VMware-Exit, den niemand wollte"

Die Migration, um die niemand gebeten hat

Es gibt eine besondere Art von Frustration, die sich einschleicht, wenn eine technische Entscheidung nicht von der Technik selbst getrieben wird, sondern von etwas, das darüber liegt – Lizenzänderungen, Konzernumbrüche oder das, was eine Stimme unverblümt „das Schlimmste, was je passiert ist" nannte. Das ist die Energie hinter einer gewaltigen Migration: rund 1.000 Hosts und 50.000 virtuelle Maschinen, die von VMware auf Hyper-V gedrängt werden. Nicht, weil der Stack versagt hat. Nicht, weil er nicht skalieren konnte. Sondern weil sich der Boden darunter verschoben hat.

Und genau dort beginnt die Spannung. Ein Techniker gibt zu, ein „großer Fan" von VMware zu sein – und gleichzeitig den Auftrag zu haben, es abzubauen. Das ist nicht nur ein technisches Projekt, das ist emotionale Arbeit. Es bedeutet, etwas neu aufzubauen, dem man vertraut hat, und das in einer Größenordnung, in der Fehler nicht nur wehtun – sie hallen nach.

Tools, Skripte und die Illusion von „einfach"

Fragt man in die Runde, kommen die ersten Antworten schnell und selbstbewusst. „Der StarWind V2V Converter ist Ihr bester Freund", sagt jemand. Ein anderer schwört auf backup-basierte Migration mit Veeam und nennt sie „extrem einfach", wenn das Ökosystem bereits vorhanden ist. Auf dem Papier klingt das fast schon sauber – konvertieren, wiederherstellen, booten, fertig.

Doch dann zeigen sich die Risse. Jemand anders weist darauf hin, dass der Prozess nicht mehr so sauber verläuft, sobald man über ein paar Dutzend Maschinen hinausskaliert. Das Entfernen von VMware Tools wird zu einer eigenen kleinen Schlacht. Treiber verhalten sich nicht immer wie erwartet. Versteckte Netzwerkadapter kollidieren mit den IP-Einstellungen. „Man muss das Gateway zweimal setzen", lässt jemand beiläufig fallen, als gehöre das einfach zum Ritual.

Hier zeigt sich ein Muster: Tools versprechen Einfachheit, aber Skalierung legt die Reibung offen. Was bei 25 VMs funktioniert, gerät bei 200 ins Wanken und bricht bei 50.000 komplett ein.

Skalierung verändert alles

Ein Kommentator hält kurz inne, nur um die schiere Größe anzuerkennen: „50.000 VMs … ein ziemlich interessantes Migrationsprojekt. Viel Glück." Das liest sich weniger wie Ermutigung und mehr wie ein stilles Nicken in Richtung des Sturms, der noch bevorsteht.

Eine andere Stimme bringt praktische Erfahrung ein: die Migration von über 200 VMs über mehrere Standorte hinweg in gut einem Monat. Nicht freiwillig. Dieses Detail zählt. Denn erzwungene Zeitpläne lassen keine perfekte Planung zu. Sie erzwingen Kompromisse – parallele Migrationen, provisorische Fixes, Skripte, die „größtenteils funktionieren".

Multiplizieren Sie das jetzt mit 250.

In dieser Größenordnung hören Best Practices auf, ordentliche Checklisten zu sein, und werden zu Überlebenstaktiken. Automatisierung ist keine Option, sondern Pflicht. Cleanup-Skripte sind kein Nice-to-have. Sie machen den Unterschied zwischen einem kontrollierten Rollout und wochenlangem Feuerlöschen nach der Migration.

Drei Lager, drei Realitäten

Auffällig ist, wie gespalten die Perspektiven sind. Nicht im Widerspruch zueinander, aber im Tonfall.

Eine Gruppe ist pragmatisch. Sie konzentriert sich auf Tools, Workflows und Effizienz. „Nutzen Sie diesen Converter." „Führen Sie dieses PowerShell-Skript aus." „So schlimm ist es nicht, wenn man sich vorbereitet." Das sind die Macher, diejenigen, die schon genug Migrationen hinter sich haben, um zu wissen, wo die Minen liegen.

Eine andere Gruppe ist vorsichtig, fast skeptisch. Sie heben die unschönen Seiten hervor – Treiberprobleme, VMware-Reste, Netzwerk-Eigenheiten. Ihr Rat liest sich wie eine Warnung: Unterschätzen Sie die Cleanup-Phase nicht. Die Migration ist nicht abgeschlossen, wenn die VM bootet. Sie ist abgeschlossen, wenn sie sich richtig verhält.

Dann gibt es noch eine leisere dritte Gruppe. Sie bietet keine Tools oder Schritte an. Sie reagiert einfach auf die Größenordnung und den Kontext. „Viel Glück." „Das ist ein riesiges Projekt." Das ist nicht unhilfreich – es ist ehrlich. Manchmal ist die einzig zutreffende Reaktion auf ein so großes Projekt, anzuerkennen, wie schwer es wirklich ist.

Die versteckten Kosten des Abschieds

Es gibt auch eine Unterströmung, die nicht direkt ausgesprochen wird: Der Abschied von einer Plattform, der man vertraut, kostet mehr als nur Lizenzgebühren.

Sie verlieren eingespielte Routinen. Sie verlieren Jahre an Feintuning, Abkürzungen, Instinkten. Plötzlich muss Ihr Team die Grundlagen in einem anderen Ökosystem neu lernen. Selbst wenn Hyper-V leistungsfähig ist – und viele argumentieren, dass es das ist –, ist dieser Übergang nicht umsonst.

Jemand erwähnt bessere Ergebnisse mit den Migrationstools des Windows Admin Center – allerdings mit einem Haken: Man braucht weiterhin vCenter im Spiel. Dieses Detail sagt viel aus. Selbst beim Abschied von VMware stützt man sich während der Übergangsphase noch darauf. Es ist, als würde man aus einem Haus ausziehen, aber die alten Schlüssel brauchen, um die Koffer zu packen.

Und dann gibt es die Kosten im wörtlichen Sinn. Tools wie Zerto werden als „sehr gut, aber wahnsinnig teuer" erwähnt. Der Entscheidungsbaum wird also schnell kompliziert: auf einer Plattform sparen, auf einer anderen ausgeben, Risiko, Zeit und Budget gegeneinander abwägen.

Keine sauberen Enden, nur Kompromisse

Was sich aus alldem ergibt, ist kein klarer „bester Weg" zu migrieren. Es ist eine Sammlung von Kompromissen.

Backup-basierte Migration ist flexibel, kann aber Eigenheiten mit sich bringen. Konvertierungstools sind schnell, brauchen aber Nacharbeit. Native Tools integrieren sich gut, hängen aber oft von bestehender Infrastruktur ab. Jeder Weg löst ein Problem und schafft gleichzeitig ein neues.

Und vielleicht ist das die eigentliche Geschichte dahinter. Nicht die Tools. Nicht die Skripte. Sondern die Realität, dass groß angelegte Infrastrukturentscheidungen selten sauber sind. Sie werden von externem Druck geformt, unter Einschränkungen umgesetzt und von Technikern zusammengehalten, die sich unterwegs alles selbst erarbeiten.

Ein Satz bleibt hängen: „Kein schlechter Prozess … wenn man nicht Tausende hat." Das ist die stille Wahrheit. Im Kleinen fühlt sich alles beherrschbar an. Im Enterprise-Maßstab wird alles zu einem System aus Grenzfällen.

Das ist mehr als eine Migration. Es ist eine Erinnerung daran, dass in der Technik die schwierigsten Probleme nicht immer technischer Natur sind. Es sind die, bei denen die Entscheidung längst gefallen ist – und Sie derjenige sind, der sie zum Laufen bringen muss.