Von der Bestandsaufnahme bis zur Abnahme: Was eine sichere Migration von VMware zu Proxmox benötigt und welche Faktoren Aufwand und Ausfallzeit bestimmen.
September 15, 2026
oneCorp Team
Proxmox bringt einen Importassistenten für VMware-ESXi mit, der offiziell noch als Technologievorschau gilt. Entscheidend sind eine gründliche Bestandsaufnahme, eine repräsentative Testmigration, ein realistisch geplantes Wartungsfenster mit Rückfallplan und eine Abnahme, zu der auch ein Wiederherstellungstest gehört.
Proxmox VE kann für Unternehmen eine passende Alternative zu VMware sein. Ob ein Wechsel sinnvoll ist, entscheidet sich jedoch nicht allein beim Vergleich der Lizenzkosten – diese Frage behandelt unser Vergleich von Proxmox und VMware. Ist die Entscheidung gefallen, müssen die vorhandenen Anwendungen zuverlässig weiterlaufen, Daten vollständig übertragen und Betriebsabläufe angepasst werden.
Eine erfolgreiche Migration von VMware zu Proxmox beginnt deshalb mit einer technischen Bewertung. Erst danach lassen sich Aufwand, Ausfallfenster und Kosten belastbar planen. Dieser Ratgeber zeigt, wie ein strukturiertes Migrationsprojekt aufgebaut ist und welche Fragen vor der ersten produktiven Umstellung beantwortet sein sollten.
Proxmox hat mit Proxmox VE 8.2 im April 2024 einen integrierten Importassistenten für VMware-ESXi-VMs eingeführt (Proxmox: Pressemitteilung). Er überträgt virtuelle Maschinen und ordnet ihre Konfiguration der Zielplattform zu. Auch in der aktuellen Version 9.2 führt die Dokumentation den Assistenten noch als Technologievorschau („tech preview“): Er arbeitet laut Hersteller stabil, wird aber weiterentwickelt (Proxmox: Administration Guide).
Daraus folgt keine automatische Übernahme der gesamten VMware-Umgebung. Netzwerke, Storage, Berechtigungen, Backup und Automatisierung müssen für das Zielsystem geprüft und eingerichtet werden. Die zentrale Frage lautet daher: Welche Funktionen und Betriebsabläufe benötigt Ihre Umgebung – und wie werden sie unter Proxmox umgesetzt?
Bei Fachanwendungen kommt eine weitere Prüfung hinzu: Technische Lauffähigkeit und offizieller Herstellersupport sind zwei verschiedene Dinge. Klären Sie vorab, ob der jeweilige Softwareanbieter die geplante Konfiguration unterstützt.
Eine VM-Liste mit CPU, Arbeitsspeicher und Festplattengröße ist ein Anfang. Für die Planung werden zusätzlich tatsächliche Auslastung, Abhängigkeiten und Besonderheiten benötigt.
| Bereich | Fragen für die Bestandsaufnahme |
|---|---|
| Anwendungen | Welche Geschäftsprozesse hängen daran? Wer übernimmt die fachliche Abnahme? |
| Abhängigkeiten | Welche Datenbanken, Verzeichnisdienste, DNS-Dienste und Schnittstellen werden benötigt? |
| Leistung | Welche Lastspitzen, Speicherlatenzen und Datenmengen treten tatsächlich auf? |
| Gastkonfiguration | Welche Betriebssysteme, Treiber, Bootverfahren und Verschlüsselungen sind vorhanden? |
| Storage und Netzwerk | Welche Speicherverfahren, VLANs, IP-Adressen und Sonderkonfigurationen werden genutzt? |
| Betrieb | Wie funktionieren Monitoring, Backup, Updates und Wiederherstellung heute? |
Einige Konfigurationen verdienen eine gesonderte Vorprüfung. Laut Proxmox-Migrationsleitfaden gilt derzeit (Proxmox: Migrationsleitfaden):
Dokumentieren Sie außerdem Systeme, die nicht mehr benötigt werden. Eine Migration ist ein guter Zeitpunkt zur Bereinigung – sofern die Stilllegung fachlich bestätigt ist.
Die Proxmox-Umgebung sollte nach den Anforderungen der Anwendungen dimensioniert werden – mit ausreichenden Reserven bei Wartung oder Hardwareausfall sowie einem passenden Storage- und Netzwerkkonzept. Ein Wechsel des Hypervisors verlangt nicht automatisch den Wechsel auf Ceph: Ob vorhandener gemeinsamer Speicher weiterverwendet oder eine neue Architektur aufgebaut wird, ist eine eigene Entscheidung.
Bewerten Sie dabei nicht nur die nutzbare Kapazität. Leistung, Redundanz, Betriebskenntnisse, Erweiterbarkeit und Wiederherstellbarkeit beeinflussen den späteren Aufwand ebenso. Die Zielumgebung sollte bereits vor der ersten produktiven Migration überwacht und gesichert werden: Ein erfolgreich gestarteter Server ohne eingerichtete Datensicherung ist noch kein abgeschlossener Übergang.
Proxmox empfiehlt ausdrücklich, die Migration zuerst mit einer oder mehreren Test-VMs zu erproben, bevor die produktive Umgebung umzieht. Ein kleiner Testserver liefert erste Erkenntnisse. Für eine belastbare Planung sollte der Pilot aber auch typische Schwierigkeiten Ihrer Umgebung abbilden – etwa eine größere Datenbank, eine ältere Windows-Anwendung oder einen Server mit mehreren Schnittstellen.
Der Migrationsleitfaden nennt einige technische Punkte, die häufig unterschätzt werden:
Der Pilot sollte mehr beantworten als „Startet die VM?“:
Aus diesen Ergebnissen entstehen die realistischen Zeit- und Aufwandsannahmen für die weiteren Migrationsgruppen. Größere Mengen sollten nicht gleichzeitig angestoßen werden: Proxmox empfiehlt, wegen der begrenzten Verbindungen der ESXi-Schnittstelle nicht mehr als vier VM-Festplatten parallel zu importieren.
Eine pauschale Zusage zur Ausfallzeit ist ohne Prüfung der Umgebung nicht belastbar. Beim sogenannten Live-Import startet die Ziel-VM bereits während der Datenübertragung. Die Quell-VM auf ESXi bleibt dabei jedoch ausgeschaltet – es entsteht also eine Unterbrechung. Schlägt der Import fehl, gehen laut Proxmox alle seit Beginn des Imports geschriebenen Daten verloren. In Netzen mit geringer Bandbreite oder hoher Fehlerrate sollte das Verfahren daher vermieden werden.
Eine einfache Rechnung zeigt, warum die Datenmenge relevant ist: 1 TB über eine vollständig nutzbare Verbindung mit 1 Gbit/s benötigt rechnerisch mindestens rund 2 Stunden und 13 Minuten. Grundlage sind dezimale Einheiten: 1 TB entspricht 8.000 Gigabit, geteilt durch 1 Gigabit pro Sekunde ergeben sich 8.000 Sekunden.
Das ist eine theoretische Untergrenze. Protokollaufwand, Quell- und Zielspeicher, Konvertierung und andere Lasten verlängern sie; über vCenter dauert der Import zusätzlich deutlich länger. Das Wartungsfenster wird deshalb anhand des getesteten Verfahrens geplant – einschließlich Abschlussarbeiten, Funktionsprüfung und Zeitreserve.
Für jede Migrationsgruppe sollte vorab feststehen, wann die Verarbeitung auf dem Quellsystem endet, wann die Zielumgebung freigegeben wird und wer diese Freigabe erteilt. Genauso wichtig ist ein dokumentierter Rückfallplan mit klaren Entscheidungspunkten: Welche Fehler führen zum Abbruch? Wie lange wird analysiert? Wann wird spätestens zurückgeschaltet?
Besondere Aufmerksamkeit verdienen Daten, die nach der Umschaltung neu entstehen. Wird auf dem Zielsystem bereits gearbeitet, kann ein einfaches Einschalten der alten VM diese Änderungen verlieren oder widersprüchliche Datenstände erzeugen. Legen Sie deshalb fest, wie neue Daten bei einem Rückfall behandelt werden, und verhindern Sie, dass Quell- und Zielsystem unbeabsichtigt gleichzeitig mit derselben Identität oder IP-Adresse laufen.
Die Anzahl virtueller Maschinen ist nur einer von mehreren Aufwandstreibern. Zehn eng gekoppelte Fachanwendungen können mehr Arbeit verursachen als eine größere Zahl ähnlich aufgebauter Standardserver. Ein nachvollziehbares Angebot unterscheidet diese Positionen:
| Kostenblock | Typischer Inhalt |
|---|---|
| Analyse | Inventarisierung, Abhängigkeiten, Kompatibilität und Zielplanung |
| Zielumgebung | Einrichtung von Hosts, Storage, Netzwerk und Zugriffsschutz |
| Pilot | Testmigration, Leistungsmessung und Prüfung des Verfahrens |
| Produktiver Umzug | Übertragung, Anpassungen, Wartungsfenster und Abnahme |
| Betriebsübernahme | Monitoring, Backup, Dokumentation und Einweisung |
| Übergangszeit | Parallelbetrieb, zusätzliche Kapazität und Vertragsüberschneidungen |
Hinzu kommen gegebenenfalls neue Hardware, angepasste Softwarelizenzen und Unterstützung durch Hersteller von Fachanwendungen. Betrachten Sie einmalige Wechselkosten und laufende Betriebskosten getrennt: Eine günstigere Subscription allein zeigt noch nicht, wann sich die Investition amortisiert.
Nach der Umschaltung folgt eine definierte Stabilisierungsphase. Beobachtet werden nicht nur Fehlermeldungen, sondern auch Antwortzeiten, geplante Aufgaben und die Ergebnisse der Datensicherung.
Ein Wiederherstellungstest gehört zur Abnahme. Wird Proxmox Backup Server eingesetzt, prüfen sogenannte Verify-Jobs, ob die gespeicherten Sicherungen noch zu ihren Prüfsummen passen (Proxmox Backup Server: Wartung). Das bestätigt die Unversehrtheit der Daten – nicht aber, dass ein wiederhergestelltes System startet und die Anwendung funktioniert. Diesen Nachweis liefert nur ein praktischer Test.
Die alte Umgebung sollte erst nach bestätigter Abnahme und entsprechend dem vereinbarten Rückfall- und Aufbewahrungsplan stillgelegt werden.
Proxmox ist besonders dann eine interessante Option, wenn die benötigten Funktionen abgedeckt sind und der Wechsel einen nachvollziehbaren technischen oder wirtschaftlichen Nutzen bietet. Bestehen ungeklärte Herstellerfreigaben oder schwer ersetzbare Integrationen, sollten diese vor einer Terminentscheidung gelöst werden.
oneCorp plant, migriert und betreibt Proxmox-Umgebungen – als Managed Proxmox Cluster in deutschen Rechenzentren, einschließlich der Migration bestehender VMware- oder Hyper-V-Maschinen (Managed Proxmox Cluster). Gemeinsam betrachten wir Ihre Anwendungen, Anforderungen an die Verfügbarkeit und mögliche Migrationswege. Daraus entsteht eine Grundlage für Aufwand, Zielarchitektur und laufende Betreuung.
Stand: Oktober 2026. Importverfahren und Einschränkungen beziehen sich auf Proxmox VE 9.2 und den Migrationsleitfaden des Herstellers; prüfen Sie sie gegen die tatsächlich eingesetzten Quell- und Zielversionen.
