VMware zu Proxmox migrieren: Ablauf, Risiken, Stolpersteine

Ausgangslage: Wann die Migration ansteht

Warum 2026 so viele KMU über den Wechsel nachdenken, habe ich an anderer Stelle durchgerechnet. Die Lizenzkosten von VMware und Proxmox im Vergleich unterscheiden sich im typischen 3-Host-Szenario gegenüber VMware Cloud Foundation um rund den Faktor sechs. Dazu kommen die Broadcom-Lizenzänderungen: Am 11. Oktober 2027 endet der Support für vSphere 8, ein harter Stichtag. Dieser Beitrag setzt dort an, wo die Entscheidung grundsätzlich gefallen ist und die Umsetzung geplant wird.

Schritt 1: Bestandsaufnahme vor der Migration

Bevor die erste VM umzieht, braucht es ein vollständiges Bild der Umgebung. Diese Liste hat sich in der Praxis bewährt:

• VM-Inventar: alle VMs mit Betriebssystem, Größe, CPU/RAM und Kritikalität. Jetzt ist der Moment, Altlasten zu identifizieren, die gar nicht mitziehen müssen.
• Abhängigkeiten: Wer redet mit wem? Reihenfolgen bei Anwendungs- und Datenbankservern, Lizenzserver, Zeitdienste, Verzeichnisdienste.
• Besonderheiten: USB-Dongles, durchgereichte Hardware (GPU, serielle Schnittstellen), VMs mit Lizenzbindung an MAC-Adresse oder Hardware-IDs, VMs mit virtuellem TPM und BitLocker (Wiederherstellungsschlüssel sichern).
• Storage: Wo liegen die VMs heute? Wichtig, weil der Import-Assistent VMs auf vSAN nicht direkt importieren kann und verschlüsselte virtuelle Festplatten vorher entschlüsselt werden müssen (dazu unten mehr).
• Netzwerk: VLANs, Trunk-Ports, Firewall-Regeln und die Netzwerkkonfiguration der Gäste, damit die Proxmox-Bridges von Anfang an richtig konfiguriert sind.
• Backup-Kette: aktuelles Backup-Produkt, Aufbewahrungsfristen, Restore-Fähigkeit alter Sicherungen auch nach dem Wechsel.
• Lizenz-Stichtage: Wann läuft das VMware-Abo oder der Support aus? Das Datum bestimmt den Zeitplan rückwärts.

Schritt 2: Der Proxmox-Import-Assistent für ESXi

Seit Version 8.2 (April 2024) bringt Proxmox VE einen integrierten Import-Assistenten mit, laut Proxmox getestet mit ESXi 6.5 bis 8.0. Er liest die Quell-VMs ausschließlich über öffentliche ESXi-Schnittstellen und ist damit nicht auf das VMware-Entwicklerpaket VDDK angewiesen, dessen öffentlichen Download Broadcom Ende August 2026 eingestellt hat. Der Ablauf in Kurzform:

• ESXi-Host in Proxmox als Import-Quelle einbinden (Datacenter, Storage, Hinzufügen, Typ ESXi). Ein vCenter geht auch, laut Proxmox aber deutlich langsamer; besser direkt den Host angeben.
• VM in der Quellansicht auswählen: Der Assistent übernimmt die Konfiguration wie CPU, RAM, virtuelle Festplatten und Netzwerkkarten und schlägt eine Zuordnung vor.
• Ziele festlegen: auf welchen Speicher die virtuellen Festplatten kommen (etwa ZFS, LVM-Thin oder Ceph), an welche Bridge die Netzwerkkarten, und bei Windows-VMs den Festplatten-Bus auf SATA statt SCSI stellen (dazu Schritt 3).
• Import starten: Vorher die Quell-VM herunterfahren. Mit dem Live-Import startet die VM bereits auf Proxmox, während die virtuellen Festplatten im Hintergrund übertragen werden; das verkürzt die Ausfallzeit deutlich.

Schritt 3: Windows-VMs richtig behandeln

Die meisten Stolpersteine einer ESXi-Migration betreffen Windows. Mit der richtigen Reihenfolge sind sie alle vermeidbar:

• Beim Import die Systemfestplatte von Windows-VMs auf SATA statt des vorgeschlagenen SCSI stellen, so empfiehlt es das Proxmox-Wiki. Ohne VirtIO-Treiber bootet Windows sonst nicht vom VirtIO-SCSI-Controller.
• Nach dem ersten Start die VirtIO-Treiber installieren (Treiber-ISO des virtio-win-Projekts, über das Proxmox-Wiki erhältlich) und die Festplatte anschließend auf VirtIO SCSI umstellen. Alternativ lassen sich die Treiber schon vorab in der Quell-VM installieren; ob das sauber klappt, sollte eine Testmigration zeigen.
• VMware Tools vor dem Umzug deinstallieren, weil sie sich danach oft nur schwer entfernen lassen, und auf Proxmox den QEMU Guest Agent installieren.
• MAC-Adressen übernehmen, wenn DHCP-Reservierungen, Firewall-Regeln oder Software-Lizenzen daran hängen.
• Aktivierung einplanen: Durch die neue virtuelle Hardware kann Windows oder einzelne Software eine Reaktivierung verlangen. Lizenzschlüssel und Zugangsdaten bereitlegen.

Schritt 4: Ausfallzeit realistisch planen

• Reihenfolge: erst eine unkritische Test-VM, dann Infrastrukturdienste, dann die Fachanwendungen. Jede Welle bestätigt den Ablauf für die nächste.
• Wartungsfenster je VM statt Umstellung auf einen Schlag: Der Live-Import drückt die Unterbrechung pro VM typischerweise auf Minuten, die Übertragung der virtuellen Festplatten großer VMs braucht trotzdem ihre Zeit über das Netzwerk. 10-Gbit-Verbindungen zwischen Alt- und Neuumgebung zahlen sich hier aus.
• Rollback-Pfad: Die Quell-VM auf ESXi bleibt nach dem Import zunächst unangetastet. Erst löschen, wenn die neue VM einige Tage produktiv sauber läuft und gesichert ist.
• Puffer einplanen: Einzelne VMs brauchen erfahrungsgemäß einen zweiten Anlauf, meist wegen Treibern oder Aktivierung. Das ist normal und kein Grund zur Panik, wenn der Zeitplan Luft hat.

Schritt 5: Backup neu aufstellen

Die Backup-Frage entscheidet sich zwischen zwei guten Wegen:

• Bei Veeam bleiben: Veeam Backup & Replication unterstützt Proxmox VE über ein Plug-in seit Version 12.2 (August 2024), anwendungskonsistente Backups von Windows- und Linux-VMs, etwa mit SQL Server, Oracle oder PostgreSQL, seit Version 13 (September 2025). Version 13.1 (Juli 2026) ergänzt Replikation zwischen Proxmox-Hosts und Instant Recovery, Letzteres vorerst mit experimentellem Support. Lizenziert wird pro gesicherter Proxmox-VM über die Veeam Universal License, prüfen Sie also Ihre vorhandenen Lizenzen. Restore-Punkte der alten VMware-Umgebung bleiben nutzbar und lassen sich auch auf Proxmox zurückspielen.
• Auf den Proxmox Backup Server wechseln: eng integriert, mit Deduplizierung, inkrementellen Backups und Verifikation. Subscriptions kosten netto ab 560 EUR pro Server und Jahr (Community, laut Hersteller für nicht produktive Umgebungen), für den produktiven Einsatz ab 1.120 EUR (Basic), jeweils mit unbegrenzt vielen Clients.

Typische Stolpersteine und ihre Lösungen

Was nach dem Wechsel anders bleibt

Fairerweise: Proxmox ersetzt vSphere nicht in jedem Detail, und Gartner warnt zu Recht davor, die Umstellung zu unterschätzen. Die wichtigsten Unterschiede im Alltag:

• Lastverteilung: Seit Version 9.2 (Mai 2026) bringt Proxmox einen integrierten dynamischen Load Balancer mit, der HA-verwaltete Gäste anhand der aktuellen Auslastung automatisch live migriert. Er greift nur bei HA-verwalteten Gästen und ist deutlich jünger als VMware DRS, dessen Reife und Funktionsumfang er noch nicht erreicht. In kleinen Clustern ist das selten ein echtes Problem, sollte aber in die Abwägung einfließen.
• vSAN wird zu Ceph oder ZFS: Ceph spielt seine Stärken ab drei Knoten aus, für kleinere Umgebungen sind ZFS mit Replikation oder klassischer Shared Storage der pragmatischere Weg.
• Kein NSX-Gegenstück: Das Proxmox-SDN deckt VLANs sowie VXLAN- und EVPN-Overlays ab, dazu kommt die eingebaute Firewall. Komplexe Mikrosegmentierung und zentrales Sicherheits-Management wie mit NSX bildet es nicht ab.
• Ökosystem prüfen: Monitoring-Agenten, Storage-Integrationen und Spezialsoftware, die direkt mit vCenter sprechen, brauchen ein Proxmox-Pendant oder einen anderen Weg.

Selbst machen oder begleiten lassen?

Mit solidem Linux-Know-how im Haus ist die Migration gut selbst machbar, das Proxmox-Wiki ist ausgezeichnet. Ohne dieses Know-how, bei engen Wartungsfenstern oder ab etwa zehn produktiven VMs lohnt die Begleitung durch einen Dienstleister mit Proxmox- und VMware-Erfahrung. Genau das biete ich im Rahmen der IT-Infrastruktur-Betreuung an: Bestandsaufnahme, Testmigration, Umzug in Wellen und danach der laufende Betrieb mit Monitoring, Updates und Backup-Kontrolle. Wichtig ist vor allem eines: früh anfangen, denn bis zum vSphere-8-Support-Ende im Oktober 2027 bleibt nur noch gut ein Jahr, und Wartungsfenster lassen sich nicht beliebig verdichten.