Centrogest’s move from VMware to Proxmox VE offers a useful example of why a virtualization migration should begin with architecture rather than license replacement. A Hardware Upgrade report on the project says AXOL Server designed a three-node Proxmox cluster with distributed NVMe storage, redundant 10 GbE networking, a separate Proxmox Backup Server, and an offsite copy protected by Object Lock. The previous platform had redundant compute nodes, but its data remained on one aging storage system. That made storage the critical weakness. The project therefore addressed performance, resilience, recovery, and power-loss behavior together. This is the central lesson in any Proxmox and VMware comparison: the hypervisor matters, but migration outcomes depend on the complete operating model around it.
The Migration Solved a Storage Problem First
Centrogest’s former environment had developed through successive additions and no longer matched the company’s growth. The VMware cluster provided compute redundancy, while data remained concentrated on a single system built with aging 10,000-rpm mechanical disks. AXOL Server assessed the workloads and then sized compute, memory, storage, networking, backup, and power protection as one design. The new cluster uses three Proxmox nodes, each with three 8 TB NVMe drives. The report describes 72 TB of raw capacity with three-way replication, leaving approximately 24 TB available to virtual machines after redundancy. The design also includes 768 GB of installed memory and redundant 10 GbE switches. The important planning principle is that raw capacity does not equal usable capacity. Replication, failover headroom, performance requirements, and maintenance states all reduce what can be safely assigned to workloads.
Backup Was Built as a Separate Recovery Layer
The cluster protects against a node failure, but Centrogest did not treat cluster redundancy as a backup. A separate physical server runs Proxmox Backup Server with local storage, encryption, deduplication, and extended retention. Selected data is then copied to S3-compatible storage with Object Lock, creating an offsite layer intended to remain protected if the primary environment is compromised. The design also includes file-level backup, local Microsoft 365 protection, and replicated volume snapshots. Each mechanism addresses a different failure mode. Administrators planning a similar project should review the capabilities and operational requirements of Proxmox Backup Server, then define recovery objectives before selecting retention, immutability, and offsite capacity. A backup architecture is complete only when teams can restore the required service within an agreed time.
Power and Operations Belong in the Migration Plan
The project also connects the UPS to the Proxmox environment through Network UPS Tools. When battery capacity falls below a defined threshold, the system begins an orderly sequence that shuts down virtual machines before the cluster nodes. That detail matters because platform migrations often focus heavily on conversion tools and overlook facilities, monitoring, shutdown order, documentation, and support ownership. Centrogest retained responsibility for application priorities while AXOL Server handled assessment, architecture, configuration, migration, and production deployment. This division made technical responsibilities explicit. A structured VMware migration assessment should likewise inventory dependencies, storage behavior, network paths, backup coverage, application owners, test criteria, and rollback options before workloads move. Centrogest’s case shows that a successful VMware exit is an infrastructure redesign with measurable recovery and availability goals, not a one-for-one hypervisor swap.
Originally published on the Mr.PlanB blog.
Top comments (0)