Structured POC before migrating a public sector datacenter

Why a structured POC

In the public sector, an infrastructure migration decision cannot rest on a commercial benchmark or a vendor demo. It must be grounded in formal, documented, reproducible technical validation.

This public organisation wanted to migrate from VMware. Broadcom had made renewal significantly more expensive. But the technical leadership rightly refused a "go" based on third-party experience reports. They wanted their own evidence, on their own representative workloads, with validation criteria defined upfront.

:::Mission context Regulated environment, contractual service continuity, small IT team. The risk was not only technical — a failed migration would have had direct regulatory consequences. :::

What a good POC must demonstrate

Before starting, three hours of scoping were used to define what the POC should not do: prove that Proxmox works in a lab. What it had to do: prove that Proxmox works on their workloads, with their network, their storage, their operational constraints.

Validation criteria defined upfront:

• Automatic HA failover in under 8 minutes on representative workloads
• Restore of a critical VM from Proxmox Backup Server in under 10 minutes
• Network isolation between regulated segments maintained identically
• Simultaneous ramp-up of N+2 VMs with no measurable degradation
• Full execution of a rollback procedure by the internal IT team

:::Critical point A criterion not defined upfront becomes a subjective criterion after the fact. If RTO targets are not written before the test, every stakeholder interprets the result from their own perspective. :::

Structure of the 7 phases

Each phase produced a validated interim technical report before moving to the next.

1. Base architecture — Proxmox cluster deployment, initial network configuration, integration into the existing environment
2. Network — VLANs, inter-segment routing, regulated traffic inspection
3. Storage — ZFS vs Ceph benchmark against identified usage profiles, parameter calibration
4. High Availability — failover tests under simulated failure (node, network, power), real RTO measurement
5. DRP — full execution of a recovery scenario from backup, RPO/RTO measurement
6. Load testing — simultaneous load simulation representative of peak activity
7. Operations — execution of routine maintenance procedures by the internal IT team, without external assistance

:::Field observation Phase 7 was the most revealing. A technology that a 2-person team cannot operate alone is not a viable solution, regardless of its technical performance. :::

What the POC struggled to validate

In the interest of honesty: two points required mid-POC adjustments.

Integration with the internal directory service (a regulatory constraint) required an unanticipated technical workaround. The network configuration of one of the regulated segments had a peculiarity documented only in a local configuration file we had not initially identified.

Both points were documented in the final report with the solutions adopted and the residual constraints.

:::What gets discovered too late Legacy network configurations often live in the minds of long-tenured operations staff, not in formal documentation. A serious POC surfaces them. A superficial POC hides them until production. :::

Result

Full validation report delivered to IT management, covering all 7 phases with measured metrics. Target architecture defined, residual constraints documented with their remediation plan. The organisation committed to migration on this basis — with an auditable technical dossier available for any regulatory scrutiny.