Wir migrieren seit dem Broadcom-Lizenzschock 2024 verstärkt VMware-Cluster auf Proxmox VE. Die Whitepaper, die zu diesem Thema kursieren, sind technisch nicht falsch — sie sind nur nicht das, was am Ende einen reibungslosen Cutover ausmacht. Hier die sieben Punkte, die nach unseren echten Projekten den Unterschied gemacht haben.

1. Active-Directory-Schema-Audit vor dem ersten VM-Move

Klassischer Stolperstein: ein gewachsenes AD enthält Schema-Erweiterungen aus 15 Jahren — Custom-Attribute für Praxisverwaltungs-, ERP- oder HR-Lösungen, die in keiner aktuellen Doku stehen. Diese Attribute hängen oft an Service-Accounts oder werden via SOAP-Calls von Anwendungen gelesen.

In einem unserer Healthcare-Projekte hatten wir eine Patientennummer-Erweiterung im userPrincipalName-Schema, die nur bei der Test-Migration einer einzelnen VM auffiel. Hätten wir das am Cutover-Wochenende entdeckt, wäre die Praxisverwaltung ausgefallen.

Was zu tun ist: ein vollständiges schemaUpgrade-Audit (z. B. via PowerShell Get-ADObject -SearchBase "CN=Schema,...") plus Cross-Reference mit den bekannten Anwendungs-Integrations­dokumenten. Mindestens zwei Wochen vor dem ersten Test-Cutover.

2. Drittanbieter-Stack-Freigaben einholen, BEVOR die Hardware steht

Manche Branchenlösungen sind ausschließlich für VMware-HCL zertifiziert. Mehr noch: einige Hersteller verweigern bei Bekanntwerden einer Plattformänderung sofort jeden Support, auch für nicht-betroffene Module.

Üblich in: SAP-Stacks mit erweitertem Hersteller-Support, DICOM-PACS-Lösungen, Banking-Kernsysteme, einige Industrie-MES-Systeme.

Was zu tun ist: Liste aller Drittanbieter-Software, deren Hersteller proaktiv anschreiben, schriftliche Zusage bzw. Absage einholen. Bei Absage rechtzeitig Alternativen evaluieren — niemals erst während der Migration.

3. Storage-Performance: vSAN-Profil ist nicht 1:1 Ceph

Auf vSAN konfigurierte Storage-Policies (Mirror, Erasure Coding, Stretched-Cluster) lassen sich konzeptionell auf Ceph übertragen, aber die Default-Werte und Performance-Charakteristika unterscheiden sich. Ceph mit drei Replica und CRUSH-Default ist nicht der gleiche IOPS-Pfad wie vSAN-RAID-1 mit Inline-Dedup.

Konkrete Praxisfall-Zahlen aus einem unserer 5-Knoten-Cluster: vSAN lieferte 28k IOPS auf der OLTP-DB-VM, das initiale Ceph-Setup (gleiche NVMe, BlueStore mit Default-Settings) nur 18k. Erst nach Tuning (BlueStore-DB auf separater NVMe, RBD-Cache, Bluestore-min-alloc-size auf 4k) waren wir bei 32k.

Was zu tun ist: Storage-Profil pro VM-Klasse (DB, File, Web) im Test-Cluster mit der echten Workload validieren. Nicht das Vendor-Datenblatt vertrauen.

4. Backup-Lizenzen sauber rechnen — Veeam vs. PBS

Wer Veeam Universal Licenses pro VM hat, kann diese in den meisten Fällen auf Proxmox migrieren — Veeam unterstützt Proxmox seit V12.3 nativ. Das ist die kostenneutrale Variante.

Wer mit der Migration auf Proxmox Backup Server umsteigen will, hat keine zusätzlichen Lizenzkosten (PBS ist kostenfrei), muss aber neue Hardware einplanen — typischerweise 12 – 30 k€ für einen produktiven PBS-Server inkl. ZFS-Pool und Offsite-Sync.

Was zu tun ist: Backup-Strategie EXPLIZIT vor der Migration entscheiden, nicht „klären wir nach dem Cutover”. Sonst läuft der erste Tag ohne brauchbares Backup-Konzept — ein vermeidbares Risiko.

5. Lifecycle-Management nach dem Cutover

vRealize / Aria liefert in VMware-Welten zentrales Inventory, Auto-Patching, Compliance-Reports, Capacity Planning. Im Proxmox-Stack gibt es das nicht out-of-the-box. Wer das ignoriert, hat nach drei Monaten ein neues Excel-„Inventar”.

Was wir bei Modern Next stattdessen einsetzen: Ansible für Patching und Standard-Härtung (versioniert in Git), CheckMK oder Zabbix für Monitoring, ein eigenes Wazuh-Detection-Pack für Compliance-Reports, gelegentlich Netbox als Single-Source-of-Truth fürs Inventory.

Was zu tun ist: Tooling-Map für die Post-Migration-Phase explizit definieren. Welche Funktion war in Aria, wer übernimmt das jetzt, und wie wird der monatliche Compliance-Report erzeugt?

6. NSX-Microsegmentation auf OPNsense + VLAN übersetzen

NSX-T mit Microsegmentation auf Layer 7 ist ein Feature, das es in Proxmox + OPNsense in dieser Tiefe nicht gibt. Die meisten Mittelständler nutzen NSX aber nicht so granular — die Realität ist „Network-Per-Tenant”-Segmentation auf VLAN-Basis.

Diese 90 % der NSX-Use-Cases lassen sich sauber auf OPNsense + Cluster-VLANs übertragen. Default-Deny zwischen Zonen, dokumentierte Freigabelisten, optional Suricata für IDS auf den Übergängen. Service-Inserts (Layer-7-Aware Firewall-Regeln zwischen VMs) bleiben draußen — wer das braucht, muss bei NSX bleiben oder Calico/Cilium auf einem Kubernetes-Overlay einsetzen.

Was zu tun ist: NSX-Konfiguration vor der Migration in Layer-3- vs. Layer-7-Regeln aufteilen. Die L3-Regeln gehen ohne Reibung über, die L7-Regeln brauchen entweder einen Workaround oder eine Architektur-Anpassung.

7. Hand-over an das interne Team — Skill-Mapping

Der häufigste Fehler nach erfolgreicher Migration: das interne Team kann zwar VMware, hatte aber auf Proxmox nur Test-Berührung. Drei Monate nach dem Cutover gibt es ein Operational-Issue, niemand traut sich an die Konsole, der Dienstleister wird angerufen — und plötzlich ist die Plattform „instabil”.

Was zu tun ist: dokumentiertes Skill-Mapping vor dem Cutover — pro Team-Mitglied, welche Operations sie sicher beherrschen, welche sie noch trainieren müssen. Bei Modern Next setzen wir Schulungen IN der echten Cluster-Umgebung ein, nicht in einer abstrakten Test-VM. Wer einmal selbst eine Live-Migration ausgelöst und einen HA-Failover beobachtet hat, hat danach kein Bauchgefühl-Problem mehr.

Fazit

Eine Proxmox-Migration ist technisch zu 80 % das, was in den Whitepapers steht. Die restlichen 20 % sind operativ, organisatorisch oder politisch — und sie entscheiden, ob der Cutover sauber durchläuft oder ob er die Plattform für die nächsten zwei Jahre als „nicht produktiv-ready” stigmatisiert.

Wenn Sie über eine Migration nachdenken: unser ROI-Rechner liefert eine erste Größenordnung der Lizenz-Differenz. Für eine ehrliche Einschätzung Ihres konkreten Setups melden Sie sich — 30 Minuten reichen.

Eigenes Vorhaben in dem Bereich?

30 Minuten reichen für eine ehrliche Einschätzung. Kostenfrei, ohne Vertriebsdruck.

← Zurück zur Blog-Übersicht