What physical-to-physical migration is
P2P (Physical-to-Physical) server migration moves a full operating system, applications and data from one physical server to another — with no hypervisor layer. Unlike P2V migration, the system still runs directly on hardware after cutover.
Typical P2P scenarios:
- Hardware refresh — ageing Dell/HP → new AMD EPYC platform
- Rack or datacentre relocation
- Replacing a failed node with spare identical hardware
- Workloads historically labelled “non-virtualisable” (per-socket licensing, HSM, dedicated PCIe cards)
P2P is not VM cloning or VMware → Proxmox migration. It is disk- and boot-loader level engineering — closer to disaster recovery than consolidation.
When P2P fits — and when it does not
| Scenario | P2P (bare-metal) | P2V on Proxmox VE |
|---|---|---|
| 1:1 hardware refresh, no time for redesign | Yes — fast lift-and-shift | Better long-term |
| Consolidating 10+ physical servers | No — cost scales linearly | Yes — 10:1 ratio is realistic |
| HA and fast failover required | App clusters or duplicate hardware | Built-in Proxmox HA |
| Oracle/SQL per-core licensing | Full socket on every server | Denser VMs on fewer sockets |
| PCIe card (FPGA, GPU, dedicated HBA) | Passthrough or bare-metal | PCIe passthrough in Proxmox |
| OPEX reduction (power, rack, support) | Minimal | Up to ~75% less power (P2V calculator) |
Practical rule: if you are planning P2P for more than 2–3 servers in the same budget cycle — stop and model TCO for P2V consolidation on Proxmox. In 8 out of 10 audits we run, P2P turns out to be the more expensive detour.
How we execute P2P migration
Safe physical-to-physical server migration needs disk, firmware and boot engineering — copying files over the network is not enough. Our proven process:
Hardware audit and dependency mapping
RAID model (hardware vs mdadm/ZFS), firmware versions, NIC layout (bonding, VLAN), PCIe cards, kernel and driver set. We document boot order and disk identifiers (UUID/labels).
Block replication or disk image
Depending on the OS: Clonezilla, dd with compression, block-level rsync, or vendor tools (e.g. Dell iDRAC virtual media). For Windows — VSS snapshot before copy or Disk2vhd as an intermediate step.
Adaptation to new hardware
initramfs with modules for the new RAID/NVMe controller, GRUB update, network interface mapping, Windows/RHEL licence checks after machine UUID changes.
Testing and production cutover
Boot in an isolated network, application tests, delta sync where possible, service window for DNS/IP cutover. Source server kept for rollback for an agreed period.
The P2P trap: same model on new hardware
A bare-metal refresh only fixes ageing hardware. It does not fix structural infrastructure problems:
- Low density — every app still owns a full physical server even at 15% CPU use
- No elasticity — adding RAM or disk needs a service window on the physical host
- Licensing cost — Windows Server, Oracle, SQL Server licensed per core on every host
- Manual HA — failover needs a second identical server plus complex app config
- Backup and DR — agent per host, no hypervisor-level snapshots
After a third P2P cycle in ten years many organisations have newer hardware but the same operational chaos — just a more expensive rack and higher power bills.
Strategic mistake: planning P2P for an entire DC without asking “can these workloads run as VMs?” is the most common reason clients return a year later asking for real consolidation.
Why the end state should be Proxmox VE
Instead of another wave of bare-metal servers, plan P2V migration to Proxmox VE — even if you must run P2P first on a critical legacy system.
CAPEX and OPEX
10:1 consolidation — 10 physical servers can run on 1–2 Proxmox hosts. Up to 75% power and rack savings — model it in the physical server calculator.
HA without hardware duplication
Proxmox HA + live migration — VM failover in minutes without a second physical server per app. Affinity rules like vSphere — see our HA affinity guide.
Licensing
Fewer physical sockets = lower Oracle EE and SQL Server Enterprise cost. EPYC 9175F sizing for databases is a deliberate licensing strategy.
Backup and ransomware resilience
Proxmox Backup Server — VM-level snapshots, deduplication, encryption and off-site replication. One backup policy instead of agents on every bare-metal box.
Proxmox VE does not need expensive per-core licences like post-Broadcom VMware — the software is free, support subscription optional. TCO comparison: VMware vs Proxmox and official Proxmox pricing.
Hybrid path: refresh → consolidation
You do not have to choose “P2P or Proxmox” on day one. Recommended model for mixed bare-metal estates:
- Stage 1 — audit: inventory workloads and decide bare-metal vs VM (details below).
- Stage 2 — P2P only where required: critical legacy on new hardware with an exit plan.
- Stage 3 — Proxmox cluster: 3-node HA deployment (Proxmox implementation services).
- Stage 4 — phased P2V: migrate remaining servers to VMs — process as in our step-by-step migration guide, with < 2 min windows per VM.
- Stage 5 — decommission old bare-metal: after 30–90 days of stable Proxmox production.
Stage 1 in practice: what stays on physical hardware
In a typical audit, 70–85% of servers qualify for VMs on Proxmox. Bare-metal is reserved for exceptions — the categories we check first. If a workload does not match any of them, we default to P2V.
| Category | Examples | Why it stays physical |
|---|---|---|
| HSM and hardware cryptography | Thales Luna, Utimaco, PKCS#11 modules on PCIe/USB | Private keys must not leave the device; FIPS / Common Criteria / PCI DSS often forbid a shared hypervisor |
| Sub-ms latency (deterministic) | HFT, matching engines, CNC/robotics control, telecom sync | VM jitter, shared CPU cache and I/O scheduling break real-time SLAs — even when average latency looks fine |
| Vendor licence lock | Legacy ERP/ISV “physical server only”, OEM without VM rights, activation tied to motherboard UUID | Licence terms or activation do not allow rehost — VM migration needs vendor negotiation or P2P as a transitional step |
| Dedicated PCIe without guest support | FPGA (e.g. trading), capture cards, legacy Fibre Channel HBAs with boot-from-SAN | Driver or firmware is unstable in a VM; WWPN/WWNN binding on SAN boot |
| OT / SCADA / industrial automation | PLC gateways, vision systems, MES with vendor certification | Warranty and support only on qualified physical servers — platform change voids support |
| Legacy hardware binding | USB dongles, MAC-bound licences, disk UUID, parallel-port keys | Application will not start after machine ID changes — needs 1:1 P2P or licence reconfiguration before P2V |
What usually does not stay physical (moves to VMs without debate): web and API servers, Active Directory, DNS/DHCP, file servers, mail, most databases (PostgreSQL, MSSQL, Oracle — with a deliberate per-core licensing strategy), monitoring, backup, logs, dev/test. Proxmox VE hosts themselves are bare-metal — the layer VMs run on, not another “application server”.
Grey area — verify before keeping physical: GPUs (PCIe passthrough in Proxmox is often enough instead of a dedicated physical server). In the audit we classify each row: is the constraint technical, licensing-related, or just historical (“we always did it this way”).
Audit deliverable: server matrix → category (bare-metal / VM / passthrough) → rationale → migration plan (P2P, P2V or hybrid). Management then sees how many physical servers truly must remain vs how many can be consolidated in the first P2V wave.
Outcome: you keep business continuity where P2P is unavoidable — while building infrastructure that cuts CAPEX/OPEX and gives management auditable savings.
Plan your P2P migration or Proxmox transition
We will analyse your physical servers for free — and tell you what belongs in P2P vs what should be virtualised on Proxmox VE straight away. Quote within 24 hours.
⚡ Free environment analysis → P2V migration on Proxmox