Assess readiness for Proxmox: The Virtualisation Exit Check evaluates inventory, target design and risks. Discuss the evidence.
This VMware migration checklist is a template for a migration readiness assessment. It separates available evidence from open assumptions and supports approval of individual migration waves. It is no certification. Technical sources as of October 2026; approval always applies to the versions actually deployed.
Contents
- Define status and ownership
- Inventory and application approvals
- Storage, networking and guest configuration
- Backups and migration rehearsal
- Approve cutover and rollback
- Hand over operations and retire sources
- Sources
Define status and ownership
Use met, open, blocked or not applicable with a reason for each item. Add evidence, date and an owner. This is an editorial working template, not a standardised score. A critical blocker must not disappear inside an average rating.
Use the VMware exit strategy for the economic decision. If target selection remains open, start with the alternatives comparison. This article covers technical and organisational preparation for the Proxmox path.
Inventory and application approvals
| Check | Evidence to provide | Approval owner |
|---|---|---|
| Hosts and VMs | versions, placement, CPU/RAM, disks, usage and load history | infrastructure owners |
| Applications | services, databases, interfaces, dependencies and criticality | application owners |
| Support and licences | target hypervisor and guest approval; reviewed licence terms | software owners |
| Identities and devices | directory services, certificates, licence servers, USB/GPU/passthrough | relevant technical team |
| Requirements | permitted data loss, recovery objective and acceptance criteria | IT and business owners |
A hardware profile or successful boot cannot replace application approval. Explicitly include appliances and hardware-bound licences. Windows licensing needs separate review; the licensing overview helps frame the questions but cannot replace the actual contract.
Storage, networking and guest configuration
The Proxmox migration documentation covers import methods and preparation including VirtIO drivers, BIOS/UEFI and guest networking. Check prerequisites against actual source and target versions. These are assessment tasks, not a claim that every combination can be imported.
- Storage: Record every disk and its datastore, including external data paths. Flag vSAN, encrypted disks and snapshot chains separately; establish a documented import, export or application-level transfer method. Evidence target capacity including test copies and rollback reserve.
- Networking: Map port groups to bridges and VLANs; check routing, DNS, DHCP reservations, IP/MAC bindings and firewall rules. Treat NSX functions as a separate replacement requirement rather than assuming they are included in VM import.
- Guest: Document BIOS or UEFI, boot order, controllers, network drivers and guest tools. Check VirtIO and guest-agent suitability and required changes beforehand.
- Keys and devices: Require separate recovery evidence for vTPM, Secure Boot, guest encryption and passthrough. Keep recovery keys available outside the source VM with controlled access.
The migration guide describes implementation steps. Recognising a VM disk establishes neither complete network migration nor application acceptance.
Assess open checks: The Virtualisation Exit Check evaluates dependencies, target architecture and risks before implementation.
Backups and migration rehearsal
Prepare an approved test plan first. Select VMs by technical characteristics and application dependencies; an arbitrary non-critical VM does not automatically cover every pattern. Start test copies in isolation to avoid conflicts from identical addresses or services writing in parallel.
| Test | Define acceptance criteria beforehand | Evidence after execution |
|---|---|---|
| Recovery | data state, key access, boot and services | restore record with deviations |
| Guest and network | boot, disks, addresses, DNS, routes, permissions | actual configuration against target |
| Application | specific business flows, interfaces and data checks | application-owner approval |
| Load and transfer | agreed requirements under relevant load | actual measurements and test conditions |
| Repetition and rollback | consistent write boundary and executable return path | recorded procedure and open findings |
PBS verify jobs check the integrity of backup data. This table additionally requires recovery and business acceptance. The restore-test guide distinguishes those tasks. Enter measurements only after tests have been executed; this template supplies no performance or duration figures.
Approve cutover and rollback
Before a wave, establish at least the following:
- Related services, responsible people and communication channels are named.
- The write freeze, final consistent data state and transfer method are documented.
- Source and target instances do not write to production independently at the same time.
- Business acceptance and abort criteria are agreed before starting.
- Rollback defines treatment of new target data and decision authority.
- Target backups, monitoring and reachable operational ownership are in place.
Missing critical evidence blocks approval. Lesser residual findings require a named risk owner and documented treatment. A technical live import is not a blanket commitment to an interruption-free move either.
Hand over operations and retire sources
Document access, backup jobs, recovery, monitoring, updates and escalation. After acceptance, resolve retention and contracts before controlled source decommissioning. Remove rollback copies only after the agreed approval.
The result is an evidence list, blockers and approved waves. WZ-IT assesses the Proxmox path in the Virtualisation Exit Check; VMware migration is the subsequent implementation commission.
Turn the checklist into an assessment: View the Virtualisation Exit Check or arrange a discussion.
