Entrazure
“The renewal came in and we cannot sign it”
The situation is familiar enough that we now hear it in the same words. The VMware estate has been stable for years, nobody was asking to change it, and the infrastructure team had a long list of more urgent work. Then the renewal quote arrived.
The structure changed as much as the number. Perpetual licenses with support have moved to subscription bundles, product editions have been consolidated, and minimum core count commitments mean a small cluster can be charged as though it were larger than it is. The direction of travel is not ambiguous, and finance has noticed.
So a decision meant for three years out is being made in three months, by a team that still runs everything else. Procurement wants an answer before the renewal date. The infrastructure lead knows the estate holds servers whose purpose nobody can explain and dependencies nobody has mapped. And someone is proposing to move all of it over a long weekend.
That is the moment where a VMware exit goes badly, and the damage is done in the first three weeks of planning rather than on the cutover night.
Why the usual answer fails
Lift and shift everything, sized on what is allocated. This is the most common approach and the most expensive. Someone exports the vCenter inventory, maps each virtual machine to the nearest Azure VM size, adds it up, and presents a monthly figure. The figure is wrong, usually by a wide margin, for one structural reason: on-premise clusters are oversubscribed. You bought physical cores once and allocated far more virtual ones on top, because most machines idle most of the time. Azure bills what you provision, continuously. A one-to-one mapping of allocated capacity moves an oversubscribed estate onto a metered one, and the first full month’s invoice is the moment the program loses credibility. Everything after that is a cost recovery exercise run under suspicion.
Swap one hypervisor for another. Move to Hyper-V, Nutanix or Proxmox, keep the operating model, defer the question. The appeal is obvious: the skills mostly transfer and nothing about the application changes. The problem is that the migration effort is comparable to a move to Azure, so you pay the full disruption cost and land somewhere with the same structural exposure, three or four years later, to whoever owns that product by then. It is a defensible choice for a data-sovereignty or latency requirement that genuinely cannot be met otherwise. It is a poor choice made for the reason it is usually made, which is that it is the option requiring the fewest decisions.
Treat Azure VMware Solution as the destination. AVS runs your existing vSphere environment on dedicated Azure hardware, and it solves a real problem: when the renewal date is closer than any re-architecture could be, it gets you out from under the contract without touching a virtual machine. It fails when it is sold as the end state. You then hold capacity commitments in Azure instead of license commitments on-premise, the same VM sprawl, and none of the platform services that made the move worth doing. AVS is a bridge, and a bridge with no exit written into the plan is a longer version of the problem.
Plan the waves from a spreadsheet. Discovery done by interviewing application owners produces a dependency map that is confident and incomplete. The missing entries are always the same kind: the scheduled job on an unmanaged server that writes a file the finance close depends on, the hard-coded IP address in an appliance nobody has logged into since 2019, the license server pinned to a MAC address. These do not appear in interviews because the people who knew about them have left. They appear at 2am on cutover night.
How we run an exit
Discovery from observed traffic, not from memory. Azure Migrate with dependency mapping running over several weeks of real network activity, long enough to catch month-end and quarter-end behavior. The output is a map of what actually talks to what, plus a utilisation profile per machine, which is what makes right-sizing defensible rather than optimistic.
Four dispositions, decided per workload. Retire, because a meaningful part of every estate receives no traffic and exists only because deleting it felt risky. Rehost, for machines that should move as they are. Replatform, where the destination is a managed service rather than a VM: SQL Server to Azure SQL Managed Instance, file servers to Azure Files, web tiers to App Service. Retain, for the workloads that stay on-premise for latency, physical interface or residency reasons, brought under Azure Arc so they live under the same policy and monitoring as everything else instead of becoming a second operating model.
A cost model built before commitment. Sizing from measured utilisation, then reservations and savings plans against the stable core of the estate, Azure Hybrid Benefit where Windows Server and SQL Server licenses with Software Assurance allow it, and the scenario where the numbers do not work shown next to the one where they do. Same discipline as our approach to cloud cost optimization, applied before the spend exists.
The landing zone first, not after. Management groups, Azure Policy, hub-and-spoke networking, identity and centralized logging are in place before the first workload lands. Migrating into an ungoverned subscription is how estates end up needing a governance project eighteen months later, at which point everything has to be moved twice. This is the four-week Azure landing zone engagement, and on an exit it runs in parallel with discovery rather than in sequence.
Waves with a rollback path. Grouped by dependency cluster, not by department. Acceptance criteria agreed per wave, source environment kept intact and powered until they are met, DNS as the switch, and a stated time limit on the rollback decision. The first wave is deliberately small and deliberately rehearsed.
The engagement that delivers it
Two to four weeks of assessment, producing the dependency map, the disposition list per workload, the cost model with and without reservations, and a wave plan with dates. That document is also the strongest thing to take into a renewal negotiation, because it turns “we might move” into a schedule.
The landing zone runs four weeks alongside it. Waves follow, each sized to fit a maintenance window and to leave the estate working. Where the calendar forces it, we assess whether Azure VMware Solution should carry what cannot be re-architected in time, with its exit written into the same wave plan.
You keep the dependency map, the Terraform for the landing zone in your own repository, the cost model, the wave plan and a decommissioning list with the licenses it releases.
A migration is the cheapest moment to fix data residency and audit logging, so the compliance architecture is designed in rather than added later, with residency enforced by policy at the management group level. Clinical environments carry additional PHI segmentation constraints, covered in our healthcare architecture work. It is also the natural point to move identity and network access to a zero trust model: the flat network you are leaving is rarely worth reproducing.
Questions we get
Our renewal is in four months. Is that enough time to move?
It is enough time to know exactly what you are doing and to have started, which is a stronger negotiating position than a signature under duress. Four months covers discovery, the landing zone and the first two waves. It does not cover a full estate exit, and anyone promising that is planning to be somewhere else when the cutover weekend arrives.
Is Azure VMware Solution the destination or a staging area?
Usually a staging area with a written exit date. It runs your existing vSphere estate on Azure hardware, which is genuinely useful when a renewal deadline is closer than a re-architecture. Treated as the endpoint it reproduces the original problem inside an Azure SKU, with capacity reservations of its own. We use it when NSX dependencies, vSphere-bound appliances or the calendar make it the honest answer, and we write the exit into the same plan.
Will it actually cost less than renewing?
Sometimes yes, sometimes no, and the difference is entirely in how the estate is sized. A one-to-one move of allocated vCPU to cloud VMs almost always costs more, because on-premise clusters are oversubscribed and Azure bills what you provision. Sized on observed utilisation, with reservations and Azure Hybrid Benefit applied, the picture changes. We build that model before you commit, and we show the version where it does not work.
What about the servers nobody can identify?
Every estate has them. Dependency mapping over several weeks of real network traffic tells you what talks to what, which is how a server with no known owner gets classified as either load-bearing or retirable. The ones that receive no traffic at all are the cheapest win in the whole program.
Can we keep some workloads on-premise?
Yes, and for latency-bound industrial or clinical systems it is often correct. The point is to stop running two unrelated operating models. Azure Arc brings the remaining servers, Kubernetes clusters and SQL instances under the same policy, monitoring and update management as everything else.
What is the rollback plan if a wave goes wrong?
Each wave keeps the source environment intact and powered until the acceptance criteria are met, with DNS as the switch and a documented time limit on the decision. Rollback is rehearsed for the first wave, not improvised on the third. A migration plan without a stated rollback path is a plan that has not been thought through.