VMware zu Proxmox migrieren: Der komplette Leitfaden (2026)

Seit Broadcom VMware übernommen hat, gibt es keine Dauerlizenzen mehr: Alles ist Abo, alles ist gebündelt, und Verlängerungsangebote für KMU und Mittelstand haben sich vervielfacht — für denselben Hypervisor, den Sie ohnehin schon betreiben. Dieser Leitfaden ist der realistische Migrationspfad zu Proxmox VE: was unverändert umzieht, was Vorbereitung braucht, wo es typischerweise wehtut — und, ganz ehrlich, wann Bleiben die richtige Entscheidung ist.

Die Kurzfassung: Ihre VMs ziehen ohne Neuaufbau um, der eingebaute Import-Assistent erledigt den Großteil der Arbeit, und eine gestaffelte Migration hält die Ausfallzeit bei Minuten pro VM. Die Arbeit steckt in der Planung, nicht im Kopieren.

Warum Teams VMware gerade jetzt verlassen

Technisch ist nichts kaputtgegangen. VMware vSphere ist weiterhin exzellente Software — das darf man laut sagen. Kaputt ist das kommerzielle Modell: Abos pro Core, Bundles, die niemand bestellt hat, und Verlängerungen zum Drei- bis Fünffachen der bisherigen Rechnung. Bei einer Mittelstands-Umgebung mit ein paar Dutzend VMs wurde aus einem Budgetposten eine Grundsatzdiskussion.

Proxmox VE erledigt denselben Kern-Job — KVM-Virtualisierung, Live-Migration, Hochverfügbarkeit, Software-defined Storage (ZFS/Ceph), integriertes Backup — auf Open-Source-Basis. Das typische Ergebnis für KMU- und Mittelstands-Umgebungen: bis zu 40 % niedrigere Gesamtkosten. Den Feature-für-Feature-Vergleich finden Sie auf unserer Managed-Proxmox-Seite; dieser Leitfaden behandelt das Wie.

Schritt 0 — Erst die Inventur, dann alles andere

Jede schmerzhafte Migration, die wir gesehen haben, hat diesen Schritt übersprungen. Bevor Sie irgendetwas anfassen:

• Alle VMs auflisten: OS, vCPU/RAM/Disk, Kritikalität, Verantwortliche. Die Liste aus vCenter exportieren — nicht dem Gedächtnis vertrauen.
• Storage und Netzwerk kartieren: Datastores, vSwitches, VLANs, vSAN-Besonderheiten. Proxmox braucht ein passendes Ziel (ZFS für Einzelknoten, Ceph für Cluster).
• Sonderfälle markieren: VMs mit GPU-/USB-Passthrough, Appliances mit Hardware-gebundenen Lizenzen, alles, was an VMware Tools hängt.
• Prüfen, ob Ihre Backups wiederherstellbar sind. Sie werden sie bei sauberer Staffelung nicht brauchen — genau dann testet man sie am besten.
• Das Ziel festlegen: eigene Hardware, Colocation oder ein Managed Cluster. Diese Entscheidung bestimmt alles Weitere — vom Storage-Design bis zur Frage, wer Rufbereitschaft hat.

Der Migrationspfad, Phase für Phase

Phase 1 — Parallelaufbau (ohne Risiko für die Produktion)

Ein Proxmox-VE-Cluster entsteht neben Ihrer VMware-Umgebung — die Produktion bleibt unangetastet. Der Storage wird passend zu Ihren Workloads entworfen (ZFS oder Ceph), das Netzwerk spiegelt Ihre VLANs, und das Backup-Ziel (Proxmox Backup Server) ist von Tag eins an verdrahtet. Dimensionieren Sie den Cluster nach der realen Inventur aus Schritt 0, nicht nach dem Datenblatt.

Phase 2 — Import, VM für VM

Seit Proxmox VE 8.2 gibt es einen eingebauten ESXi-Import-Assistenten; im aktuellen Proxmox VE 9 ist er der Standardweg. Sie binden den ESXi-Host als Import-Quelle ein, wählen eine VM, mappen Disks und Netzwerke — fertig. Es gibt sogar einen Live-Import-Modus: VM auf ESXi stoppen, sofort auf Proxmox starten, die Disk-Daten strömen bei Bedarf nach.

Die Reihenfolge, die sich bewährt hat: mit den unkritischsten VMs beginnen, die eigene Routine pro VM einüben, dann die Kritikalitätsleiter hochsteigen. Zwei OS-spezifische Hinweise:

• Windows-VMs: VirtIO-Treiber installieren, bevor Disk und NIC auf VirtIO umgestellt werden — oder den ersten Boot im Kompatibilitätsmodus (SATA/e1000) fahren und danach umstellen. VMware Tools erst deinstallieren, wenn die VM auf Proxmox läuft.
• Linux-VMs: booten in der Regel unverändert. /etc/fstab auf Datastore-spezifische Mounts prüfen und open-vm-tools danach entfernen.

Phase 3 — Validieren, dann umschalten

Jede importierte VM wird validiert, bevor sie Produktionsverkehr übernimmt: Boot, Dienste, Netzwerk-Erreichbarkeit, Performance gegen die Baseline aus Schritt 0. MAC-Adressen beibehalten, wo Software-Lizenzen daran hängen. Die alte VMware-VM bleibt ausgeschaltet — nicht gelöscht — als sofortiger Fallback.

Phase 4 — Abschalten und aufhören zu zahlen

Erst wenn jeder Workload eine vereinbarte Zeit sauber auf Proxmox gelaufen ist — wir empfehlen 30 Tage — wird VMware stillgelegt. Das ist der Tag, an dem die Broadcom-Verlängerung nicht mehr Ihr Problem ist.

Das ehrliche Wort zu „ohne Ausfallzeit“

Sauber gestaffelt erleben Ihre Nutzer keine Ausfallzeit: Dienste ziehen einzeln um, außerhalb der Geschäftszeiten, mit der alten Seite als Fallback. Pro VM sollten Sie ein kurzes Final-Sync-Fenster einplanen — Minuten für die meisten Workloads, länger bei großen Datenbanken, für die ein echtes Wartungsfenster gehört. Wie glatt das läuft, entscheidet vor allem das Netzwerk: Kann der Proxmox-Cluster die bestehenden IP-Adressen Ihrer VMs announcen — unkompliziert innerhalb derselben L2-/Broadcast-Domain, deutlich anspruchsvoller über L3-Grenzen oder in EVPN-Setups —, behalten Ihre VMs ihre Adressen, und niemand bemerkt den Umzug. Kann er es nicht, braucht jeder Cutover Re-Adressierung oder DNS-Änderungen — und genau dort steckt der eigentliche Planungsaufwand. Wer verspricht, eine große Umgebung mit buchstäblich null Sekunden Umschaltzeit zu migrieren, will Ihnen etwas verkaufen.

Sechs Fallstricke, die zu Anrufen um 2 Uhr nachts führen

1. Fehlende VirtIO-Treiber unter Windows. Der Klassiker. Die VM importiert sauber und zeigt beim ersten Boot mit VirtIO-Disks einen Bluescreen. Treiber vorher installieren oder im Kompatibilitätsmodus booten.

2. Snapshots ziehen nicht mit um. VMware-Snapshots vor dem Export konsolidieren oder löschen — Importe von VMs mit Snapshots sind die Quelle der Korruptionsgeschichten.

3. MAC-Adressen und Lizenzen. Manche Software bindet die Lizenz an die NIC-MAC. MAC mitnehmen oder eine Re-Lizenzierung einplanen.

4. Netzwerkplanung auf den letzten Drücker. Der größte Fallstrick. Ob VMs ihre bestehenden IPs behalten, hängt davon ab, ob der Proxmox-Cluster sie announcen kann — einfach in derselben L2-/Broadcast-Domain, richtig schwierig über L3 oder EVPN. VLANs spiegeln und die IP-Frage in Phase 1 klären, nicht in der Cutover-Nacht.

5. Die Backup-Lücke. Am Tag des Umzugs deckt der alte Backup-Job die VM nicht mehr ab. Proxmox Backup Server muss ab Phase 1 laufen, nicht nachträglich.

6. Performance-Annahmen. KVM ist nicht langsamer als ESXi — ein anderes Storage-Design kann es sein. Den neuen Stack mit realer Last benchmarken, bevor die kritischen VMs umziehen.

Wann Bleiben die richtige Entscheidung ist

Wir reden Ihnen keine Plattform aus, die passt. Bleiben Sie, wenn:

• Ihre Verlängerung noch auf Jahre zu Vor-Broadcom-Konditionen festgeschrieben ist — der Druck ist weg, bis er es nicht mehr ist.
• Sie tief im VMware-Ökosystem stecken (NSX im großen Maßstab, SRM, Appliances, die nur für ESXi zertifiziert sind).
• Ihr Team dieses Jahr keinerlei Kapazität für eine Migration hat — eine überhastete Migration kostet mehr als eine teure Verlängerung.

Die Rechnung kippt, wenn die Verlängerung auf dem Tisch liegt, wenn Preise pro Core Ihr Wachstum bestrafen oder wenn Sie die Exit-Option wollen, die Open Source Ihnen gibt. Bei den meisten Umgebungen, die wir migriert haben, kippte sie mit dem ersten Broadcom-Angebot.

Selbst machen oder machen lassen?

Alles oben Beschriebene ist mit einem fähigen Team in Eigenregie machbar — genau deshalb haben wir es aufgeschrieben. Die Alternative: Wir analysieren, migrieren und validieren Ihre VMware-Landschaft — inklusive des Netzwerk-Designs, mit dem Ihre VMs ihre IPs behalten — und betreiben den Proxmox-Cluster anschließend 24/7 in unserem Frankfurter Rechenzentrum — Patches, Upgrades, SLA. Die Migration selbst ist bei jährlichem Managed-Vertrag kostenlos. Wenn Sie erst die Zahlen sehen wollen: Sprechen Sie mit einem Experten — 30 Minuten, kein Verkaufsgespräch. Schicken Sie uns Ihr VMware-Setup und das Verlängerungsangebot, und wir sagen Ihnen ehrlich, was eine Migration sparen würde und was sie bedeutet.

Häufige Fragen

Wie lange dauert eine Migration von VMware zu Proxmox?
Für eine typische KMU-Umgebung (20–100 VMs): zwei bis sechs Wochen von Anfang bis Ende, gestaffelt. Die Kalenderzeit ist vor allem Validierung, nicht Kopieren.

Überleben meine Windows-VMs den Umzug?
Ja — Windows- und Linux-VMs ziehen um, wie sie sind, ohne Neuaufbau. Windows braucht VirtIO-Treiber vor oder während der Umstellung; das ist der eine Schritt, den Sie nicht auslassen dürfen.

Brauche ich neue Lizenzen für Proxmox VE?
Die Software ist Open Source, ohne Gebühren pro Socket oder Core. Optional gibt es Enterprise-Support-Subscriptions; sie kosten einen Bruchteil einer Broadcom-Verlängerung.

Was passiert mit vSAN?
Proxmox ersetzt es durch ZFS (Einzelknoten) oder Ceph (Cluster) — beides integriert. Ihre Daten ziehen mit den VM-Disks beim Import um; die Storage-Architektur wird in Phase 1 entworfen.

Was, wenn mitten in der Migration etwas schiefgeht?
Das gestaffelte Modell heißt: Die alte VMware-VM ist immer da, ausgeschaltet, als Fallback. Sie schalten pro VM in Minuten zurück — genau dafür laufen beide Seiten parallel.