Post-Broadcom-VMware-Migration ist ein geplantes Projekt, kein Notfall. Gut umgesetzt liefert sie eine Plattform, die Sie kontrollieren, und eine Kostenreduktion von 30-60% bei den migrierten Workloads. Schlecht umgesetzt produziert sie operative Altlasten und eine stockende Migration, die zum Notfall des nächsten Jahres wird. Der Unterschied liegt in strukturiertem Assessment, ehrlicher TCO-Modellierung und Engineers, die das bereits produktiv geliefert haben.
Ænix führt End-to-End-VMware-Migrationen für Organisationen durch, die VCF verlassen. Dieselben Engineers, die Cozystack gebaut haben und betreiben — die Zielplattform, die wir typischerweise empfehlen — arbeiten für Assessment, Sequenzierung und Implementierung mit Ihrem Team zusammen.
Passt zu: Ænix Public Cloud Platform für alle, die Cloud verkaufen — Hoster, die VMware Cloud Director verlassen (häufigstes Muster 2026), MSPs, Telcos, nationale Betreiber; Ænix Private Cloud Platform für regulierte Unternehmen, die VCF für den Eigenbedarf ablösen. Kostenlose VMware-Migrations-Checkliste →.
Wer führt 2026 eine VMware-Migration durch
Organisationen mit folgenden Auslösern:
- Broadcom-Subscription-Verlängerung — beobachtete Preiserhöhungen um das 2-5-Fache; Bruch von ELAs; verpflichtendes VCF-Bundling
- Souveränitätsdruck — DORA, NIS2 und sektorale Regeln zwingen kritische Workloads auf kundenkontrollierte Infrastruktur
- KI-/GPU-Ökonomie — dauerhaft ausgelastete Workloads, bei denen das VMware-GPU-Modell Lizenzkomplexität hinzufügt
- Repatriierungs-Strategie — VMware-on-Cloud-Workloads, die auf private Infrastruktur wandern
- Modernisierung — alter VCF-Bestand, bei dem der Upgrade-Pfad zugleich der Ausstiegspfad ist
Wenn zwei oder mehr davon zutreffen, verstärkt eine strukturierte Migration den Nutzen. Wenn die Verlängerung komfortabel ist und kein weiterer Auslöser besteht, ist „bleiben und optimieren“ die ehrliche Empfehlung.
Was eine VMware-Migration von Ænix abdeckt
1. Inventarisierung und Assessment vSphere-/VCF-/vCD-Inventar: Workload-Anzahl, OS-Mix, vSAN-Abhängigkeiten, NSX-Integrationen, Custom-Services, Multi-Site-Topologie. Workload-Klassifizierung: jetzt migrieren / später migrieren / bleiben / die Plattform neu aufzusetzen.
2. Zielarchitektur Zielplattform auf Kunden-Hardware. Cozystack als Standard (KubeVirt + Cilium + LINSTOR + Tenant CRD); andere Optionen, wo sinnvoll. Sizing, Kapazitätsmodell, Betriebsdesign.
3. Migrations-Ausführung Kohorten-basierte Migration. KubeVirt CDI für die Image-Konvertierung. Automatisierte Windows-VM-Bereinigung. Network- und Storage-Cutover. Parallelbetrieb mit VMware bis zur Validierung. Cutover-Sequenzierung ausgerichtet an den VCF-Subscription-Abläufen.
4. Decommission VMware-Decommission, sobald Kohorten abgeschlossen sind. Hardware wird wo möglich weiterverwendet. Letzte Verlängerung vermieden.
Forklift: die VM-Transfer-Engine in der Plattform
Ænix liefert Konveyor Forklift — das Kubernetes-Migrationstoolkit für Virtualisierung — als Bestandteil der Plattform aus. Eine Kohorte von vSphere zu holen braucht damit kein separates Werkzeug, keine separate Lizenz und kein separates Projekt. Forklift ist dieselbe Open-Source-Engine, die Red Hat als Migration Toolkit for Virtualization vertreibt; darunter arbeiten virt-v2v und KubeVirt CDI, und konfiguriert wird über Kubernetes-Objekte statt über eine reine GUI.
Wie es konfiguriert wird. Vier Objekttypen decken eine Migration ab:
Provider— die Verbindung zu vCenter (oder direkt zu ESXi) und zum Zielcluster.NetworkMap— jede Quell-Portgruppe wird auf ein Zielnetz abgebildet: das Pod-Netz, ein bestimmter Multus-Anschluss oderignored. DernetworkIPModepro Netz entscheidet, ob eine statische Adresse erhalten bleibt, durch DHCP ersetzt oder unverändert gelassen wird.StorageMap— jeder Quell-Datastore wird auf eine StorageClass abgebildet, mit Volume Mode (BlockoderFilesystem) und Access Mode je Zuordnung.PlanundMigration— ein Plan ist eine Menge von VMs mit gleichen Parametern und Zuordnungen, eine Migration führt ihn aus. Pro Plan läuft jeweils eine Migration, und der Power-State jeder Quell-VM bleibt über den Umzug hinweg erhalten.
Kalt und warm. Beides wird von vSphere aus unterstützt, und der Unterschied ist planungsrelevant:
- Kalt — die Quell-VM wird ausgeschaltet, konvertiert und dann übertragen. Weil die Konvertierung vor dem Datentransfer läuft, scheitert eine nicht konvertierbare VM sofort statt nach Stunden des Kopierens. Das ist der Standard und die richtige Wahl für alles mit Wartungsfenster.
- Warm — die VM läuft weiter, während ihre Disks inkrementell über VMware Changed Block Tracking (CBT) kopiert werden, standardmäßig mit stündlichen Snapshots. Beim Cutover wird die VM heruntergefahren und nur das verbleibende Delta übertragen. Warme Migration ist keine Live-Migration: Der RAM-Zustand wird nicht mitgenommen, es gibt also weiterhin einen Neustart. Sie verkürzt die Auszeit von „Dauer einer vollständigen Disk-Kopie“ auf „Dauer des letzten Deltas“ — worauf es bei einer großen Datenbank-VM ankommt.
- Warm setzt CBT auf jeder Quell-VM und jeder ihrer Disks vor Beginn voraus, und eine VM verträgt maximal 28 CBT-Snapshots. Windows-Gäste brauchen zusätzlich installierte VMware Tools mit Volume Shadow Copy Service und dem VMware Snapshot Provider auf Manuell oder Automatisch, sonst scheitert der Snapshot-Schritt.
Was virt-v2v am Gastsystem macht. VirtIO-Treiber werden injiziert, VMware Tools und VMware-spezifische NIC-Konfiguration werden entfernt, die Boot-Konfiguration wird angepasst, und der QEMU Guest Agent wird installiert. Statische IP-Adressen aus vSphere bleiben erhalten, Windows-Laufwerksbuchstaben ebenfalls. Das ist die automatisierte Fassung jener manuellen Nacharbeit, die handgestrickte VMware-Migrationen mühsam macht.
VDDK — und das Lizenzproblem, das Sie erben. Das VMware Virtual Disk Development Kit ist der schnelle Lesepfad für Disks und praktisch nicht optional:
- Ohne VDDK fällt der Transfer auf einen deutlich langsameren Pfad zurück.
- Bei VMs auf vSAN ist VDDK zwingend — solche Migrationen funktionieren ohne es nicht.
- Das VDDK darf nicht weitergegeben werden. Weder Ænix noch das Forklift-Projekt dürfen es ausliefern. Sie laden es unter Ihrer eigenen Broadcom-Berechtigung herunter, bauen daraus ein Container-Image und legen dieses in Ihrer eigenen Registry ab. Es in einer öffentlichen Registry zu speichern, kann die VMware-Lizenzbedingungen verletzen. Die Plattform nimmt die Image-Referenz als Konfiguration entgegen; das Bereitstellen ist Ihr Schritt und steht genau deshalb auf der Pre-Flight-Checkliste.
Andere Quellen als vSphere. Dieselbe Engine deckt oVirt/RHV, OpenStack, OVA-Dateien und entfernte KubeVirt-Cluster als Kaltmigration ab; warme Migration gibt es nur von vSphere und RHV. Unterstützt wird vSphere ab Version 6.5.
Was Forklift nicht leistet. Diese Punkte sind real und gehören ins Assessment, nicht in den Cutover:
- Windows-VMs mit Measured Boot lassen sich nicht migrieren — sie werden auf der Zielseite neu aufgebaut. Bei Secure-Boot-VMs muss Secure Boot auf der Zielseite unter Umständen deaktiviert werden.
- Windows Server 2012 und 2012 R2 booten nach der Konvertierung nicht;
virtio-winenthält keine Treiber dafür und es gibt derzeit keinen Workaround. Planen Sie diese als Neuaufbau oder lassen Sie sie stehen, bis das Gast-Betriebssystem aktualisiert ist. - VMs im Ruhezustand werden nicht unterstützt; der Ruhezustand wird zuvor auf der Quelle deaktiviert.
- ISOs und CD-ROMs müssen ausgehängt sein, jede NIC braucht eine Adresse, und VM-Namen müssen DNS-konform und eindeutig sein.
- Hersteller-Appliances, die als OVA ausgeliefert werden, fallen nach der Konvertierung womöglich aus den Supportbedingungen des Herstellers. Das klärt man vorher, nicht hinterher.
- Gast-Betriebssysteme, die
virt-v2vnicht unterstützt, lassen sich im Raw-Copy-Modus bewegen — sie landen dann aber auf emulierten Geräten statt VirtIO und booten oder laufen möglicherweise schlechter. Das ist ein Rückfallweg, kein Plan.
Forklift deckt die Disk- und Gast-Ebene ab. Es entscheidet nicht über Ihr Mandantenmodell, Ihren Adressplan oder Ihre Cutover-Reihenfolge — dafür sind Assessment und Kohortenfolge da.
Zum Upstream-Stand, klar gesagt: Forklift ist heute Bestandteil der Ænix-Plattform. Die Arbeit, es im Open-Source-Cozystack als Self-Service-VM-Import für Mandanten verfügbar zu machen, befindet sich im Review und steckt noch in keiner veröffentlichten Cozystack-Version. Wer Cozystack selbst betreibt statt der Ænix-Plattform, stellt Forklift derzeit daneben bereit.
Wo VMware-Migrationen häufig scheitern
Keine ehrliche TCO vor der Migration Die Migrations-Ökonomie sieht in der Theorie attraktiv aus; in der Praxis werden Hardware-Refresh, Kapazität des Plattform-Teams und die operative Lernkurve nicht eingerechnet. Das Projekt stockt, wenn sich die Ökonomie anders als angenommen entwickelt.
Versuchter Big-Bang-Cutover Ein einzelnes Wochenende nach dem Motto „wir verschieben alles“ funktioniert im Enterprise-Maßstab selten. Kohorten-basierte Migration mit validiertem Parallelbetrieb ist das funktionierende Muster.
Unzureichende Zielarchitektur Workloads landen auf einer Private Cloud, die nicht für die Produktion konstruiert wurde. Operative Altlasten häufen sich; das Team gibt der Migration die Schuld, obwohl das Problem die Reife der Zielplattform ist.
Übersprungenes Network- und Storage-Redesign Networking und Storage auf Cozystack (oder einer Alternative) unterscheiden sich von NSX/vSAN. Das Redesign zu überspringen produziert operative Fragilität.
Die Kostendifferenz abschätzen
Modellieren Sie das Delta, bevor Sie sich festlegen. Geben Sie Ihre Bestandsgröße und den aktuellen VMware-Preis ein; der Rechner zeigt die jährliche Ersparnis, das Drei-Jahres-Netto nach der Migration und wie schnell sich die Migration amortisiert. Für das eigenständige Tool und die Methodik siehe den VMware-Kostenrechner.
VMware-Ausstieg: Einsparungsrechner
Illustrativ. Werte editierbar. Lizenzwegfall = Apache 2.0; Sie zahlen Support und/oder Aufbau.
Wie Ænix bei einer VMware-Migration vorgeht
Die Engagement-Struktur spiegelt unser Platform Readiness Assessment mit VMware-Migrations-Schwerpunkt wider:
- Assessment (14-28 Tage) — VMware-Bestandsinventar, Zielarchitektur, Workload-Klassifizierung, Cutover-Sequenzierung, Phase-2-Roadmap.
- Phase-2-Implementierung (6-18 Monate) — Ænix-Engineers integriert mit Ihrem Team für die Migrations-Kohorten. Parallelbetrieb-Validierung. Wissenstransfer durchgängig.
- Phase 3 (optional) — verwalteter Cozystack-Betrieb nach Abschluss der Migration.
Für VMware-spezifische Zielführung siehe VMware Alternative (Singular, herstellerfokussiert) oder die VMware-Alternativen-Liste (Plural, Marktüberblick).
Warum Ænix speziell für die VMware-Migration
- Cozystack-native Erfahrung. Wir haben die Zielplattform gebaut, auf der viele Migrationen landen. Aufwandsschätzungen für die Implementierung sind an ausgelieferter Arbeit kalibriert.
- Keine Hyperscaler-Voreingenommenheit. Empfehlungen spiegeln technische Eignung wider, nicht Partner-Ökonomie. Wir sagen „in der Cloud bleiben“, wenn es richtig ist.
- Teams in der EU + Zentralasien. Zeitzonenfreundlich; ausgerichtet an DACH-/EU-Regulierungsrahmen.
- Open-Source-Ziel. Cozystack ist Apache 2.0; die Plattform, auf die Sie migrieren, gehört Ihnen.
Typischer Migrations-Zeitplan
| Wann | Was |
|---|---|
| Tag 0 | Discovery-Call (kostenlos) — Eignung bestätigen |
| Tage 1-13 (oder 1-27) | Platform Readiness Assessment mit VMware-Schwerpunkt |
| Tag 14 (oder 28) | Executive-Readout — schriftlicher Plan |
| Monate 1-3 | Fundament der Zielplattform |
| Monate 3-12 | Workload-Kohorten migrieren (Kadenz ausgerichtet an VCF-Abläufen) |
| Monate 12-24 | VMware-Decommission abgeschlossen |
Ein Bestand von 100 VMs wird typischerweise in 8-12 Monaten abgeschlossen. Ein Bestand von 1.000 VMs in 18-24 Monaten.
VMware-Migrationen, die wir begleitet haben
"Running Nuvolos on sovereign bare metal meant we needed hyperscaler-grade multi-tenancy without the hyperscaler. Cozystack delivered exactly that — isolated tenants, shared GPUs, KubeVirt for legacy workloads — and it's why we can promise our customers infrastructure control, not just a workspace."
Alexandru PopescuCEO, Nuvolos
Assessment
Auf Anfrage
Implementierung
nach Aufwand oder zum Festpreis. Auf Anfrage
Wenn Phase 2 auf das Assessment folgt, wird die Assessment-Gebühr je nach Scope angerechnet.
Weitere Fragen? Siehe den Artikel zum VMware-Migrations-Playbook oder sprechen Sie mit uns.
- VMware-Migrations-Tools und -Strategie
- VMware Alternative — Zielfokus
- VMware-Alternativen-Liste — Marktüberblick
- Platform Readiness Assessment
- Cozystack
Ænix ist das Team hinter Cozystack (CNCF-Projekt), und wir bieten Ænix Platform an — unser kommerzielles produktisiertes Angebot auf Basis von Cozystack.