VMware Exit method
Run a VMware Exit program.
Six steps to decide on evidence, migrate in controlled waves and transfer operations without an implicit point of no return.
Technical audit
Understand before recommending
Complete inventory of the existing VMware environment: VMs, networks, storage, inter-service dependencies, backup tools, existing DRP. Identification of hardware, licensing and internal skills constraints. Deliverable: audit report with recommendations and risk matrix.
Target architecture
Design the Proxmox infrastructure suited to your context
Definition of the Proxmox VE architecture: HA clustering, storage strategy (NFS, Ceph, iSCSI), network segmentation, PBS backup policy. Resource sizing. HLD and LLD documentation delivered before work begins.
POC or test environment
Validate the architecture before production
Setting up a representative Proxmox environment on your hardware or on VSHIFT Cloud. Migration of a representative subset of VMs. Cutover, rollback and performance tests. Configuration adjustments before going to production.
Wave migration
Migrate progressively, keeping VMware on standby
VM migration in ordered groups by criticality: non-critical first, production systems last. At each wave: functional validation, load tests, business team sign-off. The VMware environment remains operational in parallel until final validation.
Knowledge transfer
Make your teams autonomous
Training sessions on Proxmox VE, PBS and associated tools. Writing operational runbooks: escalation procedures, alert management, node updates, backup restoration. The goal is for your teams to operate the infrastructure autonomously without dependency on VSHIFT.
Post-delivery support
Ensure stability after cutover
4 to 8 week stabilisation period post-migration: proactive monitoring, resolution of migration-related incidents, configuration optimisations. Optionally: managed Proxmox Enterprise subscription, architect access on tickets, recurring support.
Who signs off what
A typical allocation, confirmed when each engagement is scoped. No wave starts without an identified owner for every validation.
IT sponsor
Owns scope, business priorities and GO / NO-GO decisions.
VSHIFT architect
Produces recommendations, technical evidence, the wave plan and rollback scenario.
Application owners
Validate application behaviour, dependencies and acceptance criteria.
Operations team
Validates monitoring, backup, runbooks and readiness to operate the target.
Responsibilities, deliverables and evidence
The method states who produces each deliverable, who validates it and which evidence supports the decision.
- Phase
- Audit and architecture
- Owner
- VSHIFT architect
- Deliverable
- Inventory, risks, HLD and LLD
- Expected evidence
- Approved scope and traceable sizing assumptions
- Phase
- POC
- Owner
- VSHIFT and application owners
- Deliverable
- Test report
- Expected evidence
- Performance, failover, restore and rollback measurements
- Phase
- Wave migration
- Owner
- IT, business and operations
- Deliverable
- Wave runbook
- Expected evidence
- Signed stop criteria, validations and rollback scenario
- Phase
- Stabilisation
- Owner
- Operations team
- Deliverable
- Operations pack
- Expected evidence
- Validated alerts, backups, procedures and knowledge transfer
Our operational commitments
Everything is documented
Architecture, runbooks, technical decisions: every deliverable is written and belongs to you.
Operational autonomy
Our engagements include the knowledge transfer and procedures needed to limit dependency on VSHIFT.
Rollback path defined
Each wave has a rollback scenario adapted to the workload. The VMware source is retained until the agreed validation by your teams.
First step: qualify the scope, dependencies and stop criteria.
Scope the first step →