Eine VMware-Migration nach Broadcom ist ein geplantes Projekt, kein Notfall. Gut umgesetzt liefert sie eine Plattform, die Sie kontrollieren, und in den von uns modellierten Projekten 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. Den Unterschied machen ein strukturiertes Assessment, eine ehrliche TCO-Modellierung und Engineers, die das bereits produktiv umgesetzt haben.
Ænix führt VMware-Migrationen für Organisationen, die VCF verlassen, durchgängig durch. Die Engineers, die Cozystack entwickelt haben und mitpflegen — die Zielplattform, die wir typischerweise empfehlen —, arbeiten bei Assessment, Reihenfolgeplanung und Umsetzung mit Ihrem Team zusammen.
Passt zu: Ænix Public Cloud Platform für alle, die Cloud verkaufen — Hoster, die VMware Cloud Director verlassen (das häufigste 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 2026 eine VMware-Migration durchführt
Organisationen mit folgenden Auslösern:
- Verlängerung des Broadcom-Abonnements — in den Projekten, die wir begleiten, liegen Verlängerungsangebote beim 2- bis 5-Fachen des bisherigen Vertrags; ELAs fallen weg; VCF-Bundling wird Pflicht. VCF-Preise sind nicht veröffentlicht, der Faktor ist also unsere Beobachtung, keine Branchenzahl
- Souveränitätsdruck — DORA, NIS2 und sektorale Regeln zwingen kritische Workloads auf kundenkontrollierte Infrastruktur
- KI-/GPU-Ökonomie — dauerhaft ausgelastete Workloads, bei denen das GPU-Modell von VMware zusätzliche Lizenzkomplexität bringt
- Repatriierungsstrategie — VMware-Workloads in der Public Cloud, die auf private Infrastruktur zurückziehen
- Modernisierung — ein alter VCF-Bestand, bei dem der Upgrade-Pfad zugleich der Ausstiegspfad ist
Treffen zwei oder mehr davon zu, verstärkt eine strukturierte Migration den Nutzen. Ist die Verlängerung tragbar und gibt es keinen weiteren Auslöser, lautet die ehrliche Empfehlung „bleiben und optimieren“.
Was eine VMware-Migration mit Ænix umfasst
1. Inventarisierung und Assessment Inventar von vSphere / VCF / vCD: Anzahl der Workloads, OS-Mix, vSAN-Abhängigkeiten, NSX-Integrationen, eigene Dienste, Multi-Site-Topologie. Workload-Klassifizierung: jetzt migrieren / später migrieren / bleiben / neu aufsetzen.
2. Zielarchitektur Zielplattform auf Kunden-Hardware. Standardmäßig Cozystack (KubeVirt + Cilium + LINSTOR + Tenant-CRD); andere Optionen, wo sinnvoll. Sizing, Kapazitätsmodell, Betriebskonzept.
3. Migrationsdurchführung Migration in Kohorten. Konveyor Forklift steuert virt-v2v und KubeVirt CDI; die Bereinigung der Windows-Gäste ist automatisiert. Netzwerk- und Storage-Cutover. Parallelbetrieb mit VMware bis zur Validierung. Cutover-Reihenfolge ausgerichtet an den Laufzeiten der VCF-Abonnements.
4. Rückbau Rückbau von VMware, sobald Kohorten abgeschlossen sind. Hardware wird, wo möglich, weiterverwendet. Die letzte Verlängerung entfällt.
Forklift: die VM-Transfer-Engine in der Plattform
Ænix liefert Konveyor Forklift — das Kubernetes-Migrationswerkzeug für Virtualisierung — als Bestandteil seiner Plattformen 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 einen reinen GUI-Workflow.
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 bestimmtes Multus-Attachment 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 Ziel-StorageClass abgebildet, mit Volume Mode (BlockoderFilesystem) und Access Mode je Zuordnung.PlanundMigration— ein Plan ist eine Gruppe von VMs mit gemeinsamen 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 einem Snapshot pro Stunde. 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“ — und genau darauf kommt es bei einer großen Datenbank-VM an.
- Warm setzt voraus, dass CBT auf jeder Quell-VM und jeder ihrer Disks vor Beginn der Migration aktiviert ist, und eine VM verträgt maximal 28 CBT-Snapshots. Windows-Gäste brauchen zusätzlich installierte VMware Tools, bei denen Volume Shadow Copy Service und VMware Snapshot Provider auf „Manuell“ oder „Automatisch“ stehen, sonst scheitert der Snapshot-Schritt.
Was virt-v2v am Gastsystem ändert. VirtIO-Treiber werden injiziert, VMware Tools und VMware-spezifische NIC-Konfiguration entfernt, die Boot-Konfiguration angepasst und der QEMU Guest Agent installiert. Statische IP-Adressen aus vSphere bleiben erhalten, Windows-Laufwerksbuchstaben ebenfalls. Das ist die automatisierte Fassung jener manuellen Nacharbeit, die selbst gebaute VMware-Migrationen so mühsam macht.
VDDK — und das Lizenzproblem, das Sie erben. Das VMware Virtual Disk Development Kit ist der schnelle Lesepfad für Disks und in der Praxis 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 abzulegen, kann gegen die VMware-Lizenzbedingungen verstoßen. Die Plattform nimmt die Image-Referenz als Konfiguration entgegen; das Image bereitzustellen ist Ihr Schritt, und genau deshalb steht es auf der Pre-Flight-Checkliste.
Andere Quellen als vSphere. Dieselbe Engine deckt oVirt/RHV, OpenStack, OVA-Dateien und entfernte KubeVirt-Cluster als kalte Migration 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 sollten im Assessment auffallen, nicht erst beim 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 derzeit gibt es keinen Workaround. Planen Sie diese als Neuaufbau, oder lassen Sie sie stehen, bis das Gast-Betriebssystem aktualisiert ist. - VMs im Ruhezustand (Hibernation) werden nicht unterstützt; der Ruhezustand wird vorher 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. Klären Sie das, bevor Sie eine migrieren, nicht danach.
- Gast-Betriebssysteme, die
virt-v2vnicht unterstützt, lassen sich im Raw-Copy-Modus bewegen. Sie landen dann aber auf emulierten Geräten statt auf 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 in den Ænix-Plattformen enthalten. Die Arbeit, es im Open-Source-Cozystack als Self-Service-VM-Import für Tenants verfügbar zu machen, befindet sich im Review und ist noch in keiner veröffentlichten Cozystack-Version enthalten. Wer Cozystack selbst betreibt statt einer Ænix-Plattform, stellt Forklift vorerst daneben bereit.
Woran VMware-Migrationen häufig scheitern
Keine ehrliche TCO vor der Migration In der Theorie sieht die Wirtschaftlichkeit der Migration attraktiv aus; in der Praxis werden Hardware-Erneuerung, Kapazität des Plattform-Teams und die operative Lernkurve nicht eingerechnet. Das Projekt stockt, wenn die Zahlen anders ausfallen als angenommen.
Versuchter Big-Bang-Cutover Ein einzelnes Wochenende nach dem Motto „wir ziehen alles um“ funktioniert im Enterprise-Maßstab selten. Migration in Kohorten mit validiertem Parallelbetrieb ist das Muster, das funktioniert.
Unzureichende Zielarchitektur Workloads landen auf einer Private Cloud, die nicht für den Produktivbetrieb ausgelegt wurde. Operative Altlasten häufen sich; das Team gibt der Migration die Schuld, obwohl das Problem die Reife der Zielplattform ist.
Netzwerk- und Storage-Neuentwurf übersprungen Networking und Storage auf Cozystack (oder einer Alternative) funktionieren anders als NSX und vSAN. Wer den Neuentwurf überspringt, erzeugt einen fragilen Betrieb.
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. Das eigenständige Werkzeug und die Methodik finden Sie im VMware-Kostenrechner.
VMware-Ausstieg: Einsparungsrechner
Illustrativ, in USD. Ænix-Support laut Preisliste pro 10 physische Nodes und Monat bei jährlicher Abrechnung; Migration: Richtwert aus unserer TCO-Methodik (8.000 USD Einrichtung + 140 USD pro VM); das endgültige Angebot folgt nach der Analyse Ihrer Umgebung. Hardware, Personal und Aufbauprojekt sind nicht enthalten. Preise · Methodik
Wie Ænix bei einer VMware-Migration vorgeht
Der Ablauf folgt unserem Platform Readiness Assessment, mit Schwerpunkt auf der VMware-Migration:
- Assessment (14 oder 28 Tage, Festpreis) — Inventar des VMware-Bestands, Zielarchitektur, Workload-Klassifizierung, Cutover-Reihenfolge, Roadmap für Phase 2.
- Phase 2: Umsetzung — Ænix-Engineers arbeiten für die Migrationskohorten in Ihrem Team mit. Validierung im Parallelbetrieb. Wissenstransfer durchgängig. Ein Bestand mit 100 VMs ist typischerweise in 8–12 Monaten migriert, einer mit 1.000 VMs in 18–24 Monaten.
- Phase 3 (optional) — verwalteter Betrieb von Cozystack nach Abschluss der Migration.
Zur Wahl des Ziels siehe VMware-Alternative (unsere Empfehlung), Cozystack vs. VMware (direkter Vergleich) oder VMware-Alternativen 2026 (Marktvergleich). Sie treffen die Entscheidung für die Infrastruktur? Siehe den Leitfaden für Infrastrukturleiter.
Warum Ænix für die VMware-Migration
- Erfahrung direkt aus Cozystack. Wir haben die Zielplattform, auf der viele Migrationen landen, entwickelt und pflegen sie mit. Unsere Aufwandsschätzungen für die Umsetzung beruhen auf Projekten, die wir abgeschlossen haben.
- Keine Hyperscaler-Voreingenommenheit. Unsere Empfehlungen folgen der technischen Eignung, nicht Partner-Provisionen. Wenn es richtig ist, sagen wir „bleiben Sie in der Cloud“.
- Teams in der EU und in Zentralasien. Engineering-Teams in der EU und in Zentralasien; EU-Verträge über die AENIX s.r.o. (Tschechien).
- Open-Source-Ziel. Cozystack steht unter Apache 2.0; Sie betreiben die Plattform, auf die Sie migrieren, ohne Lizenzkosten für die Plattform.
Typischer Zeitplan einer Migration
| Wann | Was |
|---|---|
| Tag 0 | Discovery-Gespräch (kostenlos) — Eignung prüfen |
| Tage 1–13 (oder 1–27) | Platform Readiness Assessment mit VMware-Schwerpunkt |
| Tag 14 (oder 28) | Abschlusspräsentation für die Geschäftsführung — schriftlicher Plan |
| Monate 1–3 | Fundament der Zielplattform |
| Monate 3–12 | Workload-Kohorten ziehen um (Takt ausgerichtet an den VCF-Laufzeiten) |
| Monate 12–24 | Bei größeren Beständen (~1.000 VMs): Rückbau von VMware abgeschlossen |
Ein Bestand mit 100 VMs ist typischerweise in 8–12 Monaten migriert, einer mit 1.000 VMs in 18–24 Monaten.
Unternehmen, die Plattformen mit Ænix betreiben
Hosting-Anbieter, die Ænix Public Cloud Platform in Produktion betreiben
Hosting-Anbieter, die die Ænix Public Cloud Platform produktiv betreiben.
"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
Preise
Das Platform Readiness Assessment hat einen Festpreis (14 oder 28 Tage). Die Umsetzung wird nach dem Assessment angeboten, nach Aufwand oder mit festem Umfang. Folgt die Umsetzung auf das Assessment, wird die Assessment-Gebühr je nach Umfang angerechnet. Die Support-Stufen für die resultierende Cozystack-Plattform finden Sie auf der Preisseite.
- VMware-Migration: Tools und Strategie
- VMware-Alternative — unsere Empfehlung
- Cozystack vs. VMware — direkter Vergleich
- VMware-Alternativen 2026 — Marktvergleich
- Platform Readiness Assessment
- Cozystack
Ænix hat Cozystack entwickelt (ein CNCF-Sandbox-Projekt) und pflegt es gemeinsam mit Maintainern anderer Unternehmen. Darauf aufbauend bietet Ænix drei Plattformen an — Public Cloud, Private Cloud und AI.