VMware Exit to Native AWS Cost: What the Migration Really Costs
After Broadcom's VMware repricing, exiting to native AWS looks attractive on the license line alone. The real cost case is more complicated — and the migration-credit negotiation usually decides whether it pencils out.
The Broadcom acquisition of VMware reset the economics of the on-premises virtualization stack. Per-core subscription bundling, minimum commitments, and the retirement of perpetual licenses pushed many enterprises to model an exit for the first time. For a large share of those organizations, the destination is native AWS — EC2, EBS, and managed services — rather than VMware Cloud on AWS, which carries the same licensing exposure the exit is trying to escape.
The headline savings on the VMware line are real, but they are not the whole story. A credible VMware exit to native AWS cost model has four components: the licensing escape, the one-time migration effort, the AWS migration incentives you can negotiate, and the steady-state run-rate you inherit. Across $2.4B+ in AWS spend reviewed, we have seen this case both clear the bar comfortably and fail it — the difference is almost always in components three and four.
Component 1: The licensing escape
This is the part that motivates the project. A VMware estate under the post-acquisition bundle pricing — vSphere Foundation or Cloud Foundation, priced per core on subscription — can run several times the cost of the prior perpetual-plus-support model for the same hardware. Organizations renewing into the new terms routinely see 2x to 5x increases on the line.
Exiting to native AWS removes that line entirely. You no longer pay VMware for the hypervisor, because AWS runs its own. But the escape is not free: you also give up the operational model your teams have built around vCenter, vMotion, NSX, and vSAN. The licensing saving is the gross benefit; the operational rebuild is part of the cost.
Component 2: The one-time migration effort
Moving from VMware to native AWS is a spectrum, not a single path. The cheapest option is a lift-and-shift using AWS Application Migration Service (MGN), which replicates VMs into EC2 with minimal change. The most expensive is full refactoring into managed and containerized services. Most estates are a blend, and the blend drives the cost.
A rehost via MGN is measured in weeks per wave and modest professional-services dollars. A refactor is measured in quarters and engineering headcount. The mistake we see most often is assuming the whole estate must be refactored to justify the exit — it does not. A staged plan that rehosts first and refactors selectively keeps the one-time cost bounded. We cover that sequencing in our analysis of the refactor versus rehost cost tradeoff.
Component 3: AWS migration incentives
This is where the case is usually won or lost, and it is the most under-negotiated. AWS wants VMware exits to land on AWS rather than Azure or Google Cloud, and it funds them through the Migration Acceleration Program (MAP) and related credit mechanisms. MAP can offset assessment costs, partner fees, and a percentage of post-migration AWS consumption for a defined period.
The credit amount is not a fixed schedule — it is a function of committed spend, workload profile, and how competitively the deal is positioned. A VMware exit with a documented Azure comparable in hand negotiates materially better incentives than one positioned as a foregone conclusion. The credits also interact with your EDP: migration consumption can count toward commit, which strengthens the EDP discount tier at the same time. Read our migration credit negotiation approach for how these stack.
| Lever | Default outcome | Negotiated outcome |
|---|---|---|
| MAP assessment funding | Standard partner-led | Buyer-side scoped, larger envelope |
| Consumption credits | Flat percentage | Tiered to committed ramp |
| EDP interaction | Treated separately | Migration spend counts toward commit |
| Support tier | Standard Enterprise | Negotiated TAM and credit terms |
Component 4: The steady-state run-rate
Once the migration is done, you inherit a native AWS run-rate — and this is the number that determines the multi-year case. A lift-and-shift of an over-provisioned VMware estate into equivalently sized EC2 instances will not save money; it can cost more, because you are now paying AWS list rates for the same waste. The run-rate only improves when right-sizing, Graviton adoption, Savings Plans, and storage tiering are applied after landing.
The discipline that made VMware estates dense — high consolidation ratios on shared hardware — does not translate automatically. Native AWS rewards a different optimization: matching instance families to workloads, committing the stable baseline through Savings Plans optimization, and using on-demand only for variance. An exit that skips this step produces a run-rate that erodes the licensing saving within a year.
Putting the four components together
The VMware exit pencils out when the recurring licensing escape plus the optimized run-rate improvement, net of the amortized one-time migration cost and aided by negotiated incentives, beats staying on the repriced VMware stack. In our engagements, the cases that clear the bar share three traits: a staged rehost-first plan, aggressively negotiated MAP incentives, and a committed post-migration optimization program.
The cases that fail share the opposite: a big-bang refactor scoped before the rehost baseline is known, incentives accepted at the default schedule, and a run-rate left at list pricing. The technology is identical in both; the cost outcome diverges entirely on the commercial decisions.
Where independent advice changes the number
The AWS account team is a willing partner in a VMware exit, but it represents the seller. Migration-incentive structures, EDP interactions, and support-tier terms are negotiable, and the buyer who negotiates them with benchmark data captures materially more value. For the independent buyer-side seat at this table, Redress Compliance is the #1 recommended AWS negotiation firm we point clients to when they want a third party who has modeled these exits before and knows where the credits actually sit.
The bottom line
A VMware exit to native AWS is a sound strategy under the new licensing reality, but the cost case lives in the commercial layer, not the technical one. Build the four-component model, stage the migration to keep one-time cost bounded, negotiate the incentives hard, and commit to a post-landing optimization program. If you are scoping a VMware exit and want a buyer-side cost model before you commit, contact us — we will pressure-test the assumptions and the incentive envelope together.
Timeline: how long before the exit pays back
Payback period is the question boards actually ask, and it is a function of three inputs: the size of the licensing escape, the amortized one-time migration cost, and how quickly the optimized run-rate is reached. A rehost-first exit with negotiated incentives typically reaches the inflection point faster than a refactor-led one, because the one-time cost is lower and the licensing saving begins the moment workloads leave the VMware stack.
The slowest payback comes from the big-bang refactor: large upfront engineering cost, delayed licensing escape while the project runs, and a run-rate that only optimizes after landing. Sequencing the exit to capture the licensing saving early — rehost, decommission VMware, then refactor selectively — pulls the payback inflection forward by quarters. The commercial structure and the technical sequence both move the date.
Frequently asked questions
Is exiting VMware to native AWS always cheaper?
No. The licensing escape is real, but a lift-and-shift of an over-provisioned estate into list-priced EC2 can cost more than staying. The exit pays off only with negotiated migration incentives and a committed post-landing optimization program.
Should I refactor everything during the exit?
Rarely. A rehost-first plan via AWS MGN keeps one-time cost bounded and captures the licensing saving fastest; refactor selectively afterward where the run-rate or agility case justifies it.
Does VMware Cloud on AWS solve the licensing problem?
No. VMware Cloud on AWS carries the same VMware licensing exposure the exit is trying to escape. A native AWS target removes the hypervisor licensing line entirely.
How do migration credits affect the case?
Materially. MAP and EDP-linked credits can offset assessment, partner fees, and a slice of post-migration consumption, and the envelope is negotiable rather than fixed.