VMware Migration: How to Move Off VMware Without Breaking Production
If you have decided to move off VMware, the hypervisor is the least of your problems. The risk lives in everything wired around it. This is an honest guide to what a VMware migration actually involves, the dependencies that catch people out, and a phased way to do it without a production incident or a regret in two years, from advisers who do not resell VMware licences.
A VMware migration is a dependency project, not a VM move. Converting virtual machines is largely solved. The effort and risk sit in data gravity, disaster recovery, networking, backup, storage and operations. Move in phases with clear gates, prove failover and restore in a pilot, and do not let the renewal date set the engineering pace. You do not have to switch everything on day one. And before you commit, check that leaving really beats a right sized renewal, because often it does not.
C4C is an independent UK technology consultancy. We do not resell VMware licences, so we gain nothing from you staying or leaving. Often the right answer is to stay and renegotiate, because the cost and disruption of moving outweigh the increase, and our guide to reducing your VMware renewal covers that. When leaving genuinely wins, we plan and deliver the migration onto a platform that fits, on the best commercials, and structured so you are not left over a barrel at the next renewal. Ask us for a migration review.
This guide assumes you have already made the decision. If you are still weighing whether to leave at all, start with our honest decision framework, because migrating when you did not need to is its own expensive mistake. What follows is the how, not the whether, and not the renewal economics, which we cover in the renewal cost guide.
Should you migrate, or renegotiate first?
Migration is a strategic choice, not a negotiating bluff. For many estates a right sized renewal, with the cores, bundle and term corrected, costs less over the next two years than replatforming, retraining and the risk of the move. For others, a hardware refresh, a skills shift or the workload profile already points away from VMware, and leaving is right. Model both on the same basis before you commit. Our decision guide covers the whether, and our renewal guide covers the levers if staying wins.
C4C assesses both sides before you commit: the full cost of staying against the full cost of moving to Nutanix, Microsoft Azure or Azure Local, Hyper-V, Proxmox or OpenShift, including migration services, running both platforms during the move, hardware, tooling and retraining, and the technical limits that could stop a workload moving, from application vendor support to the networking, storage and disaster recovery features you rely on. You get a clear recommendation: renegotiate and stay, move part of the estate, or move. We do not resell VMware licences. We do supply Nutanix and Veeam, and say so where they are in the running. Talk to us about a stay or migrate assessment.
Why is a VMware migration harder than it looks?
Almost everyone underestimates a VMware migration in the same way. They picture it as moving virtual machines from one hypervisor to another, scope the project around that, and are then ambushed by everything else. Converting a VM and booting it on a new platform is largely a solved problem. Modern tooling from every credible destination handles the conversion well, with one caveat since August 2026: some of that tooling depends on VMware's VDDK library, which Broadcom no longer offers as a public download, so check how your chosen tool obtains it before the schedule depends on it. Our guide to the VDDK withdrawal and your migration routes covers the options. If conversion were the whole job, migration would be a weekend.
It is not the whole job. The hypervisor sits at the centre of a web of dependencies that your organisation has built up over a decade or more, and it is that web, not the VMs, that determines whether the move is smooth or painful. The work is driven by data gravity, disaster recovery coupling, network and firewall dependencies, backup interlock, storage replatforming, and the operational tooling and runbooks your teams use every day. Scope the project around those, and the hypervisor takes care of itself.
A VMware migration is not a virtualisation project. It is a dependency untangling project that happens to end with a different hypervisor. The teams who treat it that way finish on time. The teams who treat it as a VM move discover the real scope halfway through, when they are already committed.
Which six dependencies carry the risk in a VMware migration?
Here are the six dependencies that carry the real risk and the real effort. Map every one of them honestly before you set a timeline, because each can quietly double the work if you find it late.
Data gravity
The single biggest driver of effort and elapsed time
Large volumes of data are slow and risky to move, and your applications expect that data to be in a particular place, with particular performance, at cutover. Replicating terabytes or petabytes across to a new platform, keeping it in sync until you switch, and validating integrity afterwards is where most of the elapsed time goes. The more data and the tighter the performance expectation, the more this dominates everything else.
Disaster recovery coupling
The dependency people forget until an auditor asks
Your DR design is very likely built around VMware specific replication and orchestration. Moving the production platform means rebuilding the DR story too, and for a window during the migration you may be running with degraded or untested failover. Regulated workloads cannot sit in that state for long, so the DR rebuild has to be planned as a first class part of the project, not an afterthought once production is moved.
Network and firewall dependencies
Where cutovers silently break
If you use distributed switching, microsegmentation or software defined networking, those constructs do not transfer one to one to a new platform. IP addressing, VLANs, load balancer configuration and firewall rules are often pinned to assumptions about the old environment. A VM that boots perfectly on the new platform but cannot reach its database, or is silently blocked by a rule nobody documented, is the classic migration failure.
Backup and recovery interlock
Easy to overlook, expensive to get wrong
Your backup product, its agents, its retention policies and its recovery runbooks are integrated with VMware today. The new platform may need different agents, a different backup approach, or a new product entirely, and you cannot declare a workload migrated until you have proven you can actually restore it on the new platform. Backups that quietly stop working are only discovered at the worst possible moment.
Storage replatforming
Often a migration inside the migration
If you run vSAN, your storage layer is leaving with VMware, so you are choosing and standing up new storage at the same time as a new hypervisor. Even with external arrays, datastore layout, multipathing and performance tiering have to be redesigned for the target. This is the moment many organisations sensibly ask whether to move from hyperconverged to a disaggregated design, which we cover in disaggregating from HCI.
Operational tooling and runbooks
The dependency that outlives the project
Monitoring, automation, patching, infrastructure as code, scripts, dashboards and the muscle memory of your operations team are all built on VMware. After cutover your people have to run the new platform on day one, at production scale, often with tooling that does not yet exist or that nobody has used in anger. Underinvesting here is how a technically successful migration becomes an operational mess.
How long does a VMware migration take, and in what phases?
A migration of any size should move through four phases, with a clear gate between each. Rushing the gates is the most common way to turn a controlled project into a production incident.
1. Assessment and design
Before anything moves, build a complete picture of the estate: every workload, its dependencies, its data volume, its performance profile, its DR and backup posture, and its tolerance for downtime. Map the six dependencies above for each application group. Choose the target platform on evidence, design the network, storage, DR and backup approach for it, and define the order of migration so that low risk workloads prove the process before anything critical moves. The output is a design and a runbook, not a slide.
2. Pilot
Migrate a small, representative but non critical set of workloads end to end, including the parts people skip: failover testing, a real restore from backup on the new platform, network and firewall validation, and a day of operations running it for real. The pilot exists to surface the things the assessment missed, because there are always some. Treat every surprise here as a gift, since the alternative is finding it during the production cutover.
3. Execution
Move the rest in planned waves, grouped so that interdependent systems travel together and each wave is small enough to validate and, if necessary, roll back. Keep data replicating ahead of each cutover so the switch itself is short. Validate connectivity, performance, backup and DR after every wave before starting the next. The discipline is boring on purpose: small waves, clear gates, proven rollback.
4. Closure
Migration is not finished when the last VM lands. It is finished when the old environment is decommissioned, the licences are released, the DR design is fully rebuilt and tested, the runbooks are updated, and the operations team is genuinely comfortable running the new platform without external help. Skipping closure is how organisations end up paying for two platforms and trusting neither.
Many migrations are triggered by a renewal date, which creates pressure to rush. Resist letting the renewal clock set the engineering timeline. A short bridging renewal that buys time to migrate properly is almost always cheaper than a rushed move that breaks production or quietly recreates lock in elsewhere. Keeping that leverage is the whole point of starting early.
Do you need to switch everything off VMware on day one?
No, and trying to is how migrations go wrong. Most organisations run VMware and the new platform side by side for a period, moving workloads in waves and decommissioning the old environment only when the new one has proven itself. Some deliberately keep a smaller VMware footprint for workloads that are hard to move, and renew only for that. A short bridging renewal that buys time to migrate properly is usually cheaper than a rushed move, and it keeps the decision in your hands. If you are still choosing a destination or a migration route, our VMware migration route finder narrows the options for your estate.
What commonly goes wrong in a VMware migration?
The failure patterns are consistent across organisations, which is good news, because it means they are avoidable.
- Scoping to the VM move. The single most common error. The project is sized around hypervisor conversion and the dependencies are discovered late, after commitment.
- Untested DR and backup. Workloads declared migrated without ever proving a failover or a restore on the new platform. The gap is invisible until you need it.
- Network assumptions. Firewall rules, load balancer configs and addressing that were pinned to the old environment and not carried across, so things break silently after cutover.
- Recreating lock in. Choosing a destination under time pressure for the wrong reasons and ending up just as locked in, only to a different vendor. We cover avoiding this in the decision framework.
- Underinvesting in operations. A clean technical migration handed to a team with no tooling and no runbooks, which then struggles for months.
What should you validate before you commit?
Before you sign off the plan and start moving production, you should be able to answer each of these honestly:
- Have we mapped every workload to its data volume, dependencies, DR posture and downtime tolerance, rather than assuming?
- Have we proven, in a pilot, that we can fail over and restore from backup on the target platform?
- Have we validated network, firewall and load balancer behaviour on the target, not just that VMs boot?
- Do we have the storage design, including any move away from vSAN, settled and tested?
- Will the operations team have the tooling, runbooks and confidence to run the new platform on day one?
- Have we kept enough commercial leverage that the renewal date is not forcing an unsafe pace?
If you cannot answer one of these, that is precisely where the next piece of work sits. The destinations themselves are real and credible, whether that is Nutanix, Azure Local for Microsoft aligned estates, or HPE for HPE aligned and edge heavy estates, but the right one depends on your workloads, and the migration effort is driven by the dependencies above far more than by which platform you pick.
Who can help you migrate away from VMware?
We have spent years at Dell, EMC and across the infrastructure market, on both the technical and the commercial side, so we understand VMware, the alternatives and the migrations from the inside. We do not resell VMware licences and have no preferred destination. Where we can supply the platform you choose, such as Nutanix or Veeam for backup, we say so up front, and it does not change the recommendation. That means we will run the assessment, design the target honestly, pressure test the plan, and help you keep commercial leverage so the renewal clock does not force an unsafe move. You can see how this played out for a Fortune 500 company in our VMware and Broadcom licensing case study, where independent analysis and negotiation took the renewal to 56 percent below Broadcom's quote, saving more than £1 million, and kept the client in control of the decision rather than cornered by it. Whether you need an assessment, a migration plan, delivery of the move or support negotiating a bridging renewal, tell us where you are.
Planning a move off VMware? Get an independent migration review
Send us your situation and we will give you an evidence based view: where the real migration risk sits in your estate, what a safe phased plan looks like, whether staying and renegotiating would cost less, and how to keep leverage at renewal. We have sat on the other side of the table.
How we are paid. For the work itself: a fixed fee, a share of the saving, or professional services such as an assessment or the migration. Never a margin on VMware licences. Where we supply a destination platform, such as Nutanix or Veeam, we say so up front.
Prefer email? Reach us directly at hello@c4cgroup.co.uk.
Frequently asked questions
How long does a VMware migration take?
It depends far more on data gravity and dependencies than on the number of VMs. A small, simple estate can move in a few months. A large estate with significant data, tight DR requirements and complex networking can run well over a year when done safely. The honest answer comes only after an assessment, because the elapsed time is set by data movement and validation, not by the hypervisor conversion.
What is the hardest part of moving off VMware?
Not the hypervisor. The hard parts are data gravity, rebuilding disaster recovery, carrying network and firewall behaviour across, proving backups restore on the new platform, replatforming storage if you run vSAN, and re equipping the operations team with new tooling and runbooks. The VM conversion itself is largely solved by modern tooling, although since August 2026 you should confirm how your chosen tool obtains the VDDK library it may depend on, because Broadcom no longer offers it as a public download.
Can I migrate off VMware before my renewal date?
Sometimes, but letting the renewal date set the engineering pace is risky. A rushed migration is how production breaks and how organisations recreate lock in elsewhere. A short bridging renewal that buys time to migrate properly is usually cheaper than the cost of getting it wrong, and it keeps the decision in your hands.
Which platform should I migrate to?
It depends on your workloads, your team and your wider strategy. Nutanix, Azure Local for Microsoft aligned organisations and HPE for HPE aligned or edge heavy estates are all credible destinations. The right choice is best made on evidence in the assessment phase, and the migration effort is driven by your dependencies far more than by which destination you pick.
How do I avoid breaking production during the migration?
Move in small, planned waves with a clear gate between each, keep data replicating ahead of every cutover so the switch is short, and validate connectivity, performance, backup and DR after each wave before starting the next. Prove the whole process on a non critical pilot first, including a real failover and a real restore, so the surprises surface before anything critical moves.
Do we need to replace our storage when we leave VMware?
If you run vSAN, yes, because that storage layer leaves with VMware, so you are choosing new storage at the same time as a new hypervisor. With external arrays you keep the hardware but still redesign datastore layout and tiering for the target. Many organisations use the moment to ask whether to move from hyperconverged to a disaggregated, three tier design.
Do I need to switch everything off VMware on day one?
No. Most organisations run VMware and the new platform side by side, move workloads in planned waves and decommission the old environment only once the new one has proven itself. Some keep a smaller VMware footprint for workloads that are hard to move. A short bridging renewal that buys time to migrate properly is usually cheaper than a rushed move.
Should we renegotiate our VMware renewal instead of migrating?
Often, yes. For many estates a right sized renewal, with the cores, bundle and term corrected, costs less over the next two years than the replatforming, retraining and risk of a migration. Migration makes sense when a hardware refresh, a skills shift or the workload profile already points away from VMware. Model both on the same basis before deciding.
Who can help us migrate away from VMware?
Look for an adviser who will tell you whether to migrate at all, map the dependencies honestly, and deliver the move, without a financial interest in the answer. C4C does not resell VMware licences, plans and delivers VMware migrations as professional services, and will tell you when a renegotiated renewal is the better option.