Managed Proxmox Onboarding, Takeover, and Migration

Build new platforms, accept operational responsibility, and migrate from VMware or unmanaged Proxmox

Onboarding, takeover, and migration

Managed Proxmox onboarding is complete only when Assistance can safely operate the agreed boundary and the customer has accepted the platform, workloads, restore path, and support workflow. Build, takeover, and migration projects should be staged rather than treated as a single big cutover.

Onboarding paths#

Path	Use when	Main risk
New build	Hardware or provider environment is ready and workloads will be migrated later	Design decisions must be validated before production workloads depend on them
Existing Proxmox takeover	The customer already runs Proxmox but wants Assistance to operate it	Unknown configuration, weak backups, stale patches, or unclear access may need remediation first
VMware or Hyper-V migration	Existing VMs need to move from a commercial virtualization platform	Conversion, drivers, licensing, downtime, and rollback require testing
Bare-metal to VM	Physical workloads need virtualization for manageability	Hardware-tied software, performance, and recovery behavior must be tested
Cloud VM to Proxmox	Workloads need dedicated hardware or private-platform economics	Network, DNS, storage, provider features, and data-transfer windows can drive complexity

Intake checklist#

platform source, version, administrator contacts, and current runbooks;
VM inventory with owners, criticality, OS, CPU/RAM/disk, network, backups, and dependencies;
current backup status and last restore-test evidence;
DNS, firewall, VPN, public IP, certificate, and reverse-proxy dependencies;
application maintenance windows and customer acceptance tests;
licensing, activation, hardware binding, and vendor-support constraints;
rollback plan and maximum acceptable downtime per workload;
support hours, severity definitions, and escalation contacts.

Existing Proxmox takeover gate#

Assistance should not accept day-2 responsibility for an existing environment until these are reviewed:

Area	Acceptance evidence
Access	Named admin access, emergency path, and customer-approved permission model
Backups	Successful backup jobs, known retention, target capacity, and restore-test plan
Storage	Pool health, capacity headroom, redundancy assumptions, and disk health
Network	Bridge/VLAN/firewall map, management exposure, DNS ownership, and public access list
Versions	Proxmox version, package repositories, firmware age, pending security updates
Inventory	VM/LXC owner map, criticality, resource usage, and support contacts
Monitoring	Host, storage, VM, and backup alerts routed to the agreed channel
Risks	Known gaps recorded with customer acceptance or remediation plan

Migration from VMware or Hyper-V#

A safe migration plan includes:

inventory and dependency mapping;
target VM sizing and storage mapping;
test conversion of a non-critical VM;
driver, boot mode, network, and filesystem validation;
application smoke test owned by the customer or scoped application team;
cutover window and communication plan;
rollback criteria and source-platform retention period;
post-migration backup, monitoring, and documentation update.

Do not decommission the source platform until rollback requirements expire and customer acceptance is recorded.

Migration from unmanaged Proxmox#

Unmanaged Proxmox migrations often need less VM conversion work but more operational cleanup. Expect to review naming, storage sprawl, backup gaps, undocumented firewall rules, abandoned accounts, no-longer-needed VMs, and unclear owner mapping.

Pilot-first rollout#

Start with a representative but lower-risk workload. The pilot should prove:

VM creation or import path;
network reachability and DNS/certificate flow;
backup and restore procedure;
monitoring and alert route;
customer acceptance test;
change record and rollback pattern;
handoff notes for the next migration batch.

Go-live acceptance#

Production go-live requires agreement on current known risks, backup status, restore owner, monitoring route, support channel, customer approver, and what remains out of scope. If a risk is accepted instead of fixed, record who accepted it and why.