04Migration
Move to VEXO with confidence.
Modernize your virtualization environment with structured migration workflows from established virtualization platforms.
Migration methodology designed around validation, rollback and workload-specific downtime planning.
Method
Six stages, in order.
Each stage exists so a problem surfaces while it is still cheap to find. Select a stage to read what happens in it.
Stage 01 — Discover
Inventory the source environment: hosts, machines, disks, networks and the dependencies between them.
Principles
What the method refuses to do.
Three commitments that shape every other decision in a migration.
The source stays intact
Conversion produces a new machine on VEXO. The originating environment is not modified and remains the fallback until validation passes.
Rollback is defined before cutover
Every cutover has a written way back. A rollback path decided during an incident is not a rollback path.
Downtime is planned, not promised away
Each workload gets a window sized for what it actually is. A single-figure downtime claim across a whole estate is a claim about the estate somebody wished they had.
Sources
Where workloads come from
Three source platforms, and the disk formats each one brings with it.
VMware
vSphere and ESXi estates, including workloads on VMDK.
Microsoft Hyper-V
Hyper-V hosts and clusters, with VHD and VHDX disks.
KVM
Existing KVM or libvirt environments already using open formats.
Every disk format handled
- VMDK
- VHD
- VHDX
- QCOW2
- RAW
VEXO Migrate is on the product roadmap. Downtime is planned per workload; VEXO does not claim a guaranteed zero-downtime migration.
Migration
Start with an assessment, not a cutover date.
Tell us what the source estate looks like. The first useful output of a migration is an honest list of what will not convert cleanly.