T-Mobile USA macht den VMware-Exit zum Stresstest für Firmen-IT: Zehntausende virtuelle Maschinen sollen aus einer Broadcom/VMware-Umgebung heraus, während parallel um Support für bestehende Dauerlizenzen gestritten wird. Für deutsche Unternehmen ist das kein ferner US-Sonderfall, sondern eine unbequeme Frage: Wüsste Ihre IT morgen, welche VMs wirklich umziehbar sind?
Der Fall trifft einen Nerv, weil VMware in Rechenzentren, Behörden, Industrie, Handel und bei Managed-Service-Providern oft zur unsichtbaren Grundplatte des Betriebs geworden ist. Solange alles läuft, wirkt Virtualisierung neutral. Sobald Support, Lizenzmodell oder Vertragsfrist Druck machen, entscheidet sich, ob aus einer Plattform ein Käfig geworden ist.
Das Wichtigste in 30 Sekunden
- Anlass: T-Mobile USA migriert nach aktuellen Fachberichten zehntausende VMware-VMs und streitet mit Broadcom um Support für bestehende Dauerlizenzen.
- Größenordnung: Genannt werden rund 1.000 Applikationen; als technische Kontextzahl stehen außerdem 303.000 Cores im Raum.
- Risiko: Ein VMware-Exit betrifft nicht nur VM-Dateien, sondern Compute, Storage, Netzwerk, Identitäten, Monitoring, Backup, Automatisierung, Verträge und Betriebsabläufe.
- Wer handeln sollte: IT-Teams in Konzernen, Mittelstand, öffentlicher Hand, Rechenzentren und Managed Services sollten ihre Wechseloptionen kennen, bevor Vertragsfristen den Takt vorgeben.
- Nutzen dieses How-tos: Sie bekommen sieben Checks, mit denen Sie Ihre VMware-Umgebung prüfen, ohne vorschnell einen neuen Anbieter zum Gewinner zu erklären.
T-Mobile, Broadcom und VMware: Warum der Fall jetzt für Europas IT zählt
VMware vSphere, ESXi und vCenter haben über Jahre eine stille Erfolgsgeschichte geschrieben. Unternehmen konnten physische Server besser auslasten, Systeme schneller bereitstellen, Cluster zentral verwalten und Ausfälle leichter abfedern. Genau deshalb hängen heute oft nicht nur einzelne Anwendungen daran, sondern ganze Betriebsmodelle.
Der Konflikt zwischen T-Mobile USA und Broadcom legt offen, was viele IT-Abteilungen ungern testen: Portabilität ist mehr als ein Exportknopf. Wenn eine kritische Applikation aus drei VMs, zwei Datenbanken, festen IP-Adressen, alten Treibern, einem Lizenzserver und einem nächtlichen Batch-Job besteht, wird Migration schnell Detektivarbeit.
Für Europa heißt das nicht, dass jede Vertragslage identisch wäre. Es heißt aber: Wer erst beim nächsten Renewal über Alternativen spricht, startet zu spät. Dann fehlen Inventar, Abhängigkeiten, Testfenster, Budget, Skills und oft auch die Zustimmung der Fachbereiche.
VMware, vSphere, ESXi, vCenter und VM: die Begriffe kurz erklärt
ESXi ist der Hypervisor, also die Software auf einem physischen Server, die mehrere virtuelle Maschinen betreibt. vSphere bezeichnet die Plattform rund um diese Virtualisierung. vCenter ist die zentrale Verwaltung für Hosts, Cluster, VMs, Rollen, Ressourcen und viele Betriebsroutinen.
Eine virtuelle Maschine ist ein Software-Computer mit virtueller CPU, Arbeitsspeicher, Festplatte und Netzwerkkarte. Sie unterscheidet sich von einem Container, der stärker das Betriebssystem teilt und häufig enger mit modernen Deployment-Prozessen verbunden ist. Bare Metal meint dagegen den direkten Betrieb auf physischer Hardware. Cloud-Instanzen ähneln aus Nutzersicht oft VMs, hängen aber an Netzwerken, Identitäten, Diensten und Abrechnungsmodellen des jeweiligen Cloud-Anbieters.
Ein VMware-Exit heißt deshalb nicht: VM-Datei kopieren, anderswo einschalten, fertig. Umziehen müssen auch Datenpfade, Firewallregeln, DNS, Identitäten, Monitoring, Backup, Automatisierung, Patching und Verantwortlichkeiten.
Voraussetzungen: Was Sie vor dem VMware-Exit-Check brauchen
- Zugriff auf vCenter sowie Host- und Clusterinformationen
- Liste aller virtuellen Maschinen mit Betriebssystem, Ressourcenzuweisung, Storage, Netzwerken und Tags
- Applikationsinventar, auch wenn es zunächst lückenhaft ist
- Vertrags- und Supportunterlagen zu VMware, Hardware, Datenbanken und Enterprise-Software
- Backup- und Restore-Dokumentation
- Monitoring- und Incident-Runbooks
- Ansprechpartner aus Betrieb, Netzwerk, Security, Fachbereichen, Einkauf und Legal
7 VMware-Exit-Checks: So prüfen Sie Ihre virtuelle Infrastruktur
-
Inventar erstellen: Hosts, Cluster, VMs, Cores und Applikationen erfassen
Aktion: Exportieren Sie aus vCenter eine vollständige Liste aller Hosts, Cluster, Datastores, virtuellen Maschinen, vCPU-Zuweisungen, RAM-Werte, Netzwerke, Snapshots und Templates. Ergänzen Sie, welche Applikation auf welcher VM läuft.
Ergebnis: Sie sehen nicht nur, wie viele VMs existieren, sondern welche Systeme geschäftlich relevant sind. Die reine VM-Zahl hilft wenig, wenn niemand weiß, welche Maschinen zusammen einen Bestellprozess, ein Laborgerät oder eine Filialkasse betreiben.
-
Verträge prüfen: Dauerlizenz, Abo, Wartung und Support trennen
Aktion: Unterscheiden Sie sauber zwischen Besitz- oder Nutzungsrechten, Wartung, Support und Update-Zugang. Dauerlizenzen können im Betrieb wenig nützen, wenn kein Support, keine Patches oder keine kompatiblen Betriebsbedingungen mehr verfügbar sind.
Ergebnis: Einkauf, Legal und IT sprechen über dieselbe Sache. Technisch kann eine VM portabel sein, während Datenbank-, Applikations- oder Supportverträge den Umzug ausbremsen.
-
Abhängigkeiten finden: Die riskante VM läuft selten allein
Aktion: Erfassen Sie Datenbankverbindungen, Schnittstellen, feste IP-Adressen, DNS-Namen, VLANs, Firewallregeln, Load Balancer, Lizenzserver, Batch-Jobs und nächtliche Datentransfers. Nutzen Sie Monitoringdaten, Logs und Gespräche mit Fachbereichen.
Ergebnis: Sie erkennen Ketten statt Einzelserver. Aus Sicht eines Ingenieurs ist die gefährlichste VM selten die größte. Es ist die schlecht dokumentierte VM mit alten Treibern, hart codierten IPs und niemandem, der noch weiß, warum sie nachts um 2 Uhr mit drei anderen Systemen spricht.
-
Workloads sortieren: zuerst lernen, nicht zuerst riskieren
Aktion: Bewerten Sie Workloads nach Kritikalität, Komplexität, Lizenzrisiko und Migrationsaufwand. Beginnen Sie nicht mit dem wichtigsten System, aber auch nicht mit einer belanglosen Test-VM, aus der niemand etwas lernt.
Ergebnis: Sie bekommen Migrationswellen: einfache Kandidaten für frühe Tests, heikle Systeme für spätere Planung, Systeme für Ersatz oder Stilllegung und Workloads, die zunächst auf VMware bleiben müssen.
-
Zielplattform wählen: anderer Hypervisor, Private Cloud, Public Cloud oder Umbau
Aktion: Vergleichen Sie Kategorien statt Markennamen. Ein anderer Hypervisor kann nahe am bestehenden Betriebsmodell bleiben. Public Cloud verändert Netzwerk, Identitäten, Kostenmodell und Betrieb. Kubernetes oder OpenShift helfen nur, wenn Anwendungen dafür geeignet sind. Re-Architecture ist der größte Eingriff, kann aber alte technische Schulden abbauen.
Ergebnis: Sie vermeiden die Scheinlösung, nur den Hypervisor auszutauschen und alle Altlasten mitzunehmen. Ein VMware-Exit kann kurzfristige Lizenzoptimierung sein – oder der Start eines größeren Plattformumbaus. Beides sollte nicht in einem Projektplan verschwimmen.
-
Pilot-Migration planen: Booten reicht nicht
Aktion: Wählen Sie eine kleine, aber echte Applikationsgruppe. Definieren Sie Messpunkte: Startzeit, Performance, Netzwerkpfade, Backup, Restore, Monitoring, Security-Checks, Patchprozess, Betriebsübergabe und Rollback.
Ergebnis: Der Pilot beweist nicht nur, dass eine VM startet. Er zeigt, ob die Anwendung unter Last funktioniert, ob Alarme ankommen, ob ein Restore gelingt und ob das Betriebsteam sie am Montagmorgen betreuen kann.
-
Cutover und Rollback vorbereiten: ohne Rückweg ist es kein Plan
Aktion: Planen Sie Umschaltfenster, Datenkonsistenz, Kommunikationswege, Rückfalloptionen und Verantwortlichkeiten. Dokumentieren Sie, wann ein Rollback noch möglich ist und wann nicht mehr.
Ergebnis: Die Migration hängt nicht an einer Person und nicht an einem heroischen Wochenende. Sie haben einen Ablauf, Zuständigkeiten und eine klare Grenze, ab der abgebrochen wird.
Priorisierungsmatrix: Welche VMware-Workloads zuerst dran sind
| Workload-Typ | Typisches Risiko | Gute erste Aktion |
|---|---|---|
| Nicht kritische interne Tools | Geringe Geschäftsfolgen, aber oft mäßige Dokumentation | Als Lernpilot nutzen, Monitoring und Restore mitprüfen |
| Datenbanknahe Anwendungen | Performance, Lizenzbindung, Datenkonsistenz | Lizenzmodell und Lastprofil vor jeder Migration klären |
| Legacy-Systeme | Alte Treiber, alte Betriebssysteme, fehlender Herstellersupport | Erst Ersatz, Stilllegung oder Isolierung bewerten |
| Kritische Kunden- oder Produktionssysteme | Ausfallzeit, Abhängigkeiten, schweres Rollback | Spät migrieren, nur nach bewiesenem Pilot und Restore-Test |
Lift-and-shift, Re-Platforming, Re-Architecture: welche Migration passt?
| Option | Was passiert? | Wann sinnvoll? |
|---|---|---|
| Lift-and-shift | VM wird möglichst unverändert auf eine andere Plattform übertragen | Wenn Zeit knapp ist und die Anwendung stabil läuft |
| Re-Platforming | Die Anwendung bleibt ähnlich, nutzt aber neue Plattformdienste oder Betriebsabläufe | Wenn Betrieb, Backup oder Skalierung modernisiert werden sollen |
| Re-Architecture | Die Anwendung wird grundlegend umgebaut | Wenn Altlasten den Weiterbetrieb ohnehin blockieren |
| Stilllegen | System wird abgeschaltet oder durch vorhandene Funktionen ersetzt | Wenn niemand mehr sauber begründen kann, warum die VM läuft |
Typische Fehler: Was VMware-Exits unnötig riskant macht
- VM-Zahlen mit Applikationsklarheit verwechseln: Tausend gut dokumentierte VMs können einfacher sein als fünfzig alte Systeme ohne Besitzer.
- Backup mit Disaster Recovery verwechseln: Eine Kopie ist erst dann wertvoll, wenn die Wiederherstellung getestet wurde.
- Netzwerk unterschätzen: VLANs, Firewallregeln, DNS, feste IPs und Ost-West-Traffic entscheiden oft über Erfolg oder Ausfall.
- Lizenzen zu spät ansehen: Datenbanken und Enterprise-Software können an Cores, Hosts, Cluster oder Virtualisierungstechniken gebunden sein.
- Skills ignorieren: Ein neues Portal ersetzt keine jahrelang eingeübten vCenter-Routinen, Patchprozesse und Incident-Runbooks.
- Big Bang planen: Vertragsdruck verführt zu großen Schnitten. Besser sind Wellen, die messbar lernen und Rückwege behalten.
Ergebnisprüfung: Woran Sie echte VMware-Exit-Fähigkeit erkennen
Eine Umgebung ist nicht exit-fähig, nur weil ein Migrationswerkzeug eine VM konvertieren kann. Sie ist erst dann vorbereitet, wenn sechs Nachweise vorliegen:
- Inventar und Applikationszuordnung sind für die wichtigsten Systeme tragfähig.
- Abhängigkeiten über Netzwerk, Datenbanken, Identitäten und Lizenzserver sind dokumentiert.
- Verträge, Supportansprüche und Lizenzbedingungen sind bewertet.
- Ein Pilot hat Performance, Monitoring, Backup, Restore und Security-Checks bestanden.
- Betriebsteams können die Zielplattform im Alltag betreuen.
- Cutover und Rollback sind schriftlich geplant und geprobt.
Meine Einschätzung: Der T-Mobile-Fall ist kein Sonderfall, den nur Telekommunikationsriesen verstehen müssen. Er ist ein Stresstest für eine Gewohnheit: Virtualisierung wurde in vielen Unternehmen als neutrale Basisschicht behandelt. Sobald Lizenzmodell, Support oder Anbieterstrategie kippen, zeigt sich, ob diese Schicht wirklich austauschbar ist – oder ob sie längst zum Betriebssystem des gesamten Rechenzentrums geworden ist.
FAQ: Was IT-Leiter, Admins und Geschäftsführung jetzt wissen wollen
Muss jedes Unternehmen jetzt aus VMware aussteigen?
Nein. Der sinnvolle erste Schritt ist kein Ausstieg, sondern Transparenz. Wer Kosten, Support, Lizenzlage und Abhängigkeiten kennt, kann Verlängerung, Optimierung oder Migration nüchtern vergleichen.
Was ist der Unterschied zwischen VMware-Exit und normaler VM-Migration?
Eine normale Migration bewegt einzelne Systeme. Ein Exit verändert die Plattform darunter: Betrieb, Support, Tools, Verträge, Backup, Monitoring und Skills.
Welche Daten brauche ich für ein erstes Exit-Assessment?
Mindestens Host- und Clusterliste, VM-Inventar, Applikationszuordnung, Netzwerke, Storage, Backup-Status, Lizenzunterlagen und Ansprechpartner der Fachbereiche.
Kann ich VMware-VMs einfach in eine Public Cloud verschieben?
Technisch gibt es Migrationspfade für VMware-VMs in Cloud-Umgebungen. Praktisch müssen Netzwerk, Identitäten, Storage, Lizenzen, Performance, Kostenmodell und Betrieb neu bewertet werden.
Wie groß sollte ein Pilotprojekt sein?
Klein genug, um kontrollierbar zu bleiben, aber echt genug, um zu lernen. Eine einzelne belanglose Test-VM beweist wenig. Besser ist eine kleine Applikationsgruppe mit Datenfluss, Monitoring, Backup und klarer Betriebsverantwortung.
Wann ist Re-Platforming sinnvoller als Lift-and-shift?
Wenn eine Anwendung ohnehin modernisiert werden muss, wenn alte Betriebsabläufe teuer sind oder wenn die Zielplattform andere Stärken bietet. Lift-and-shift spart Zeit, nimmt aber oft alte Probleme mit.
Was sollte die Geschäftsführung vor einer Vertragsverlängerung fragen?
Welche Systeme hängen an VMware? Was kostet ein Verbleib? Wie lange hätten wir Support? Welche Alternativen wurden technisch getestet? Und wie viele Monate bräuchten wir für eine geordnete Migration?
Quellen und weiterführende Informationen
- T-Mobile moving tens of thousands of virtual machines off VMware amid lawsuit – Ars Technica
- Broadcom: T-Mobile will mit rund 1.000 Applikationen weg von VMware – Golem
- T-Mobile appears to be quitting VMware – and fighting a very familiar battle for support rights on the way out – The Register
- T-Mobile streitet mit Broadcom um VMware-Support – heise online
- T-Mobile USA, Inc. v Broadcom Inc. – 2026 NYSlipOp 02226
- Migrate VMware VMs to Azure (agentless) – Microsoft Learn
Hinweis: Für diesen Artikel wurden KI-gestützte Recherche- und Editierwerkzeuge verwendet. Der Inhalt wurde redaktionell geprüft. Stand: 2026-07-04
