What's included
| Move | When it's used |
|---|---|
| Physical to virtual (P2V) | Retiring old hardware, consolidating |
| Virtual to virtual (V2V) | Changing hypervisor, for example away from VMware |
| Virtual to physical (V2P) | Licensing or performance needs dedicated hardware |
| Physical or virtual to cloud | Moving workloads to Azure, AWS, Google Cloud |
| Cloud to on premises | Bringing workloads back for cost or data-residency reasons |
| Data center to data center | Relocation or consolidation |
- Discovery and dependency mapping, so nothing breaks unexpectedly
- Wave plans, test migrations, agreed cut-over windows, rollback ready for each wave
- Post-move checks and sign-off per wave
One migration wave
Text version of this diagram
- Discover and map dependencies → Plan the wave
- Plan the wave → Test migration
- Test migration → Tests pass?
- Tests pass? → Plan the wave (no)
- Tests pass? → Cut-over window (yes)
- Cut-over window → Healthy?
- Healthy? → Roll back (no)
- Roll back → Plan the wave
- Healthy? → Sign-off and decommission source (yes)
Who it's for
- Companies retiring old hardware
- VMware customers changing platform
- Businesses moving to or from the cloud
What you get
- Discovery and dependency map
- Wave plan with dates and rollback
- Migrated workloads with sign-off per wave
- Decommissioning of the old systems
Questions
How long does a migration take?
Small estates take weeks; large ones run in monthly waves. The discovery step gives a firm plan.
Can we go back if it doesn't work?
Every wave has a tested rollback until you sign it off.
Will users notice the move?
Most moves happen in planned windows outside working hours, with a short cut-over.