Moving physical servers onto VMware vSphere sounds like a tooling job: install the converter, pick a server, press go. On a programme of over 800 physical servers the tool was the easy part. The work that decided whether it went well was inventory, planning in waves, agreeing downtime with the business and cleaning up afterwards. These are the lessons I would apply on the next one.
Start with an honest inventory
Before converting anything, list every server with its owner, application, operating system, hardware age, disk size and how much downtime the business will accept. Add what it talks to. A server that looks idle can still be the one a monthly finance job depends on.
Some servers should not be converted at all:
- Domain controllers. Build new virtual domain controllers, move the roles and retire the physical ones. Converting a domain controller risks replication problems.
- Servers that are being retired anyway. Decommission them instead of carrying them forward.
- Very old operating systems. Check that the version is supported on the target ESXi release and that a conversion tool can still handle it. Sometimes a rebuild is the safer path.
Plan in waves
Group servers into waves by application and dependency, not by rack or alphabet. Servers that work together should move together, or the application spends a weekend split between two worlds. Start with low-risk servers to prove the process, then speed up.
Agree downtime and rollback before the change
For each wave, agree the change window, the test steps and the rollback with the application owner. The simplest rollback is to leave the physical server powered off but untouched for an agreed period, so it can be switched back on if the virtual machine misbehaves.
For servers with changing data, such as file or database servers, take a final synchronisation inside the change window, or do a cold conversion with services stopped, so nothing is lost between the copy and the cutover.
Clean up after conversion
A converted server still thinks it is running on its old hardware. After each conversion:
- Remove the hardware vendor's agents and management software.
- Remove hidden network adapters left behind by the old hardware, and set the IP configuration on the new adapter.
- Install VMware Tools and use the VMXNET3 network adapter and the paravirtual SCSI controller where the operating system supports them.
- Right-size CPU and memory. Physical servers are often far larger than the workload needs.
- Check licensing. Moving Windows Server and application licences from a physical server to a virtual host can change what you need.
Measure and report
Track each wave: servers moved, issues found and time taken. It shows the business progress, and it shows where the process needs work. Over a programme of this size, the hardware footprint and licensing savings become a strong part of the case for the next phase.
The short version
Treat P2V as a programme, not a tool. Know what you have, move applications together, agree rollback before the change window, and clean up every server after it moves.