A VMware migration is usually planned as a hypervisor decision and experienced as an operations project. The virtual machines are rarely the hard part. What takes the time is everything that grew up around the platform over the last decade: the backup configuration, the monitoring, the runbooks, the automation, and the assumptions your team stopped noticing years ago.
This is a practical account of what changes when you move, what does not, and what to settle before the first workload is touched.
What does not change
Worth starting here, because the fear is usually larger than the reality.
Your virtual machines are still virtual machines. Guest operating systems, applications and data move without being rewritten, provided the destination is another virtualization platform rather than a refactor into cloud-native services. Storage and network topology can usually be reproduced. Most of the workload-level detail survives.
If someone has told you a migration means rebuilding your applications, they are describing a modernization project, not a migration. Those are different pieces of work with different costs and different justifications, and conflating them is how migration budgets get rejected.
What changes immediately
Management tooling. The console your team uses every day is different. Everything routine is briefly unfamiliar, and the muscle memory built over years does not transfer. This is temporary and it is real, and it should be budgeted as reduced capacity for a period rather than ignored.
Automation and scripting. Anything built against vSphere APIs needs rewriting or replacing. Most organizations have more of this than they think, because it accumulated one useful script at a time. Inventory it during discovery, not during cutover.
Backup and recovery. This is the one that catches people. Your backup software supports the platform you are moving to, or it does not, and the configuration does not simply follow the workloads across. Job definitions, retention policies, application-aware processing and restore procedures all need re-establishing and re-testing. A recovery objective that was being met before the migration is an assumption afterwards until it has been demonstrated again.
Monitoring and alerting. Different metrics, different thresholds, different integrations. Alert fatigue in the weeks after a migration is common and usually comes from thresholds carried across unchanged from a platform that behaved differently.
Support model. Commercial support, community support, or a managed provider. This is a bigger decision than it looks, because it determines what happens at 2am when something you have never seen before is happening to production.
What changes gradually
Operational cost profile. The licensing saving is visible on day one. The operational cost takes a couple of quarters to settle, as the team gets fluent and as automation is rebuilt. Business cases that model only the licensing line usually overstate the first-year benefit.
Capacity planning. Different platforms schedule resources differently. Sizing assumptions carried over from the old platform are a starting point, not an answer, and the real numbers only appear under production load.
Skills. Your team becomes competent quickly and expert slowly. Plan for the gap between those two states, particularly around the first incident.
The platform decision, briefly
Three destinations come up most often, and they suit different situations.
Proxmox VE is an open-source virtualization platform that runs KVM virtual machines and LXC containers under a single management interface. It suits organizations with genuine platform engineering capability that would rather trade licensing cost for operational ownership. Proxmox sells optional subscriptions priced per CPU socket, and every feature is available at every tier. The tiers differ in support: the entry Community tier provides the stable enterprise repository without ticket support, while Basic, Standard and Premium add direct vendor support.
Virtuozzo sits in the managed and provider-delivered category, aimed at organizations and service providers that want a supported platform rather than one they operate themselves. Opti9 is the exclusive North American distribution partner for Virtuozzo, so treat that as a disclosed commercial interest rather than a neutral assessment.
AWS is a different kind of destination. Moving as-is is a lift and shift, which preserves the operating model and delivers the fastest exit. Rebuilding to use managed services is a refactor, which costs more and is the only path that changes what the workload can do. Most estates end up doing both, to different workloads.
The choice between them is less about features than about who you want operating the platform, and how much of your team’s time you want spent on it.
What to settle before you move
Confirm application vendor support. Some applications are supported only on named hypervisors. Finding that out mid-migration removes options at the worst possible time.
Complete dependency discovery. Not an inventory of servers, a map of what talks to what. This is where migrations overrun, and it is the cheapest phase to do properly.
Establish the backup and recovery design up front. Decide how data protection works on the destination before the first workload moves, not after. Then test a restore on the new platform before you migrate anything that matters.
Agree the rollback position. For each wave, what is the trigger to stop, and how do you get back. A migration plan without a rollback position is a plan that assumes success.
Decide what is not moving. Some workloads are cheaper and safer left in place until their hardware or support lifecycle forces the question. Excluding them explicitly shrinks the project and improves the business case.
Frequently asked questions
How long does a VMware migration take? It depends on workload count and dependency complexity more than on platform choice. Any estimate produced before dependency discovery is a guess, which is why discovery is usually the first funded piece of work rather than part of the project.
Do we need to rebuild our applications? Not for a platform migration. Virtual machines move as virtual machines. Rebuilding applications is modernization, which is a separate decision with a separate business case.
What happens to our backups? They do not transfer automatically. Backup software support for the destination platform needs confirming, and jobs, retention and restore procedures need rebuilding and re-testing. Treat this as a workstream, not a task.
Can we migrate in phases? Yes, and it is usually the better approach. Phasing by workload tier reduces risk and spreads cost, and it lets the team build competence on lower-stakes systems first.
Is Proxmox suitable for production? It is used in production by many organizations. Whether it is right for yours depends on your platform engineering capability, your support requirements and your application vendors’ policies, which is a different question from whether the technology works.
Where Opti9 fits
Opti9 runs migrations across AWS, private cloud and hybrid environments, and holds both AWS Premier Tier Services Partner status and Veeam Platinum VCSP Partner status, which means the backup and recovery workstream is designed alongside the migration rather than after it. We are also the exclusive North American distribution partner for Virtuozzo, and we would rather say so than have you find out later.
