You’ve already decided to leave. Or at least, Broadcom decided for you when they tripled your renewal. The question now is what it costs to actually get out.
Most of the content online about VMware migration cost is either vendor marketing (suspiciously cheap) or Gartner research aimed at Fortune 500s running 5,000+ VMs (terrifyingly expensive). If you’re a mid-market company running 100 to 500 VMs, neither number applies to you.
This post is a budget-building exercise. Real ranges, real team sizes, real timelines. The kind of numbers you need to walk into a CFO meeting and not get laughed out.
First: what you’re already paying Broadcom
Before you can build a migration business case, you need to know what “staying” costs. And after Broadcom’s changes, that number is probably higher than you think.
VMware now sells four products. The two that matter for most mid-market companies:
- vSphere Foundation (VVF): roughly $38-50 per core per year
- VMware Cloud Foundation (VCF): roughly $350 per core per year
Both are subscription-only. Perpetual licenses are gone. And you’re licensing every physical core in every CPU, with a minimum of 16 cores per socket.
Here’s what that looks like for a typical mid-market environment:
| Environment size | Cores (typical) | VVF annual cost | VCF annual cost |
| 10 servers, 2 sockets, 16 cores each | 320 cores | $12,160-16,000 | $112,000 |
| 25 servers, 2 sockets, 16 cores each | 800 cores | $30,400-40,000 | $280,000 |
| 50 servers, 2 sockets, 24 cores each | 2,400 cores | $91,200-120,000 | $840,000 |
Those are annual numbers. And if you miss your renewal anniversary, Broadcom tacks on a 20% penalty retroactively.
For a company that was paying $40,000-80,000 a year under the old perpetual licensing model, seeing that number jump to $120,000+ is the moment the migration conversation starts.
The migration itself: a cost breakdown by phase
Gartner published research in early 2025 estimating that large-scale VMware migrations (2,000+ VMs, 100+ servers) require 7-10 FTEs for initial scoping and up to 6 FTEs for nine months of execution, with total timelines of 18-48 months. External migration services run $300-3,000 per VM depending on complexity.
Those numbers are for large enterprises. Mid-market is different. Here’s what we actually see.
Phase 1: Assessment and planning (4-6 weeks)
This is the inventory, dependency mapping, and workload classification phase. You’re figuring out what you have, what talks to what, and which workloads go where.
| Cost item | Range |
| Internal team time (2-3 engineers, part-time) | $15,000-30,000 in loaded salary cost |
| Assessment tooling (vROps export, Aria, or third-party discovery) | $0-5,000 |
| External consulting (if you need help) | $15,000-40,000 |
| Phase 1 total | $15,000-75,000 |
Most companies can do this with internal staff if they have someone who knows the VMware environment well. You’re paying for their time, not for tools. The external consulting cost shows up when nobody on the team has done a migration before and you need someone to run the assessment methodology.
Phase 2: Platform build-out (4-8 weeks)
This is standing up the target environment. Kubernetes cluster, networking, storage, CI/CD pipelines, monitoring. Whether you go managed (EKS, GKE, AKS) or self-hosted, there’s setup work.
| Cost item | Range |
| Managed Kubernetes (monthly, ongoing) | $500-3,000/month |
| Infrastructure (compute, storage, networking) | $3,000-15,000/month |
| Monitoring and observability stack setup | $5,000-20,000 (one-time) |
| CI/CD and GitOps tooling setup | $5,000-15,000 (one-time) |
| Internal team time (2-4 engineers) | $20,000-50,000 |
| External consulting | $20,000-60,000 |
| Phase 2 total | $50,000-160,000 |
The wide range here depends mostly on one thing: managed vs. self-hosted Kubernetes. Going managed (EKS, GKE, AKS) cuts setup time in half but adds ongoing cloud spend. Going self-hosted on bare metal saves on monthly costs but requires more engineering time upfront.
One thing people consistently underbudget: observability. You need monitoring on day one of the new environment, not as an afterthought after the first outage. An open-source stack (Prometheus, Grafana, Loki) keeps the licensing cost at zero, but someone still has to deploy and configure it. Budget the time.
Phase 3: Migration execution (3-6 months)
This is the actual work of moving workloads in waves. The cost depends heavily on workload complexity.
| Cost item | Range |
| Internal team time (3-5 engineers, dedicated) | $75,000-200,000 |
| External migration services | $50,000-200,000 |
| Application refactoring (if needed) | $20,000-100,000 |
| Parallel running costs (old + new infrastructure) | $30,000-80,000 |
| Testing and validation | $10,000-30,000 |
| Phase 3 total | $185,000-610,000 |
The parallel running costs are the one everybody forgets. You’re paying for both your VMware environment and your new Kubernetes environment for the entire migration period. That’s 3-6 months of double infrastructure spend.
We had a client whose CFO signed off on the migration budget, then nearly killed the project three months in when the second infrastructure bill showed up. His exact words: “Nobody mentioned we’d be paying for both at the same time.” Put the parallel costs in your initial proposal. Finance discovering them on their own is how projects get cancelled.
Phase 4: Post-migration optimization (1-3 months)
After cutover, you’re right-sizing, tuning, decommissioning VMware infrastructure, and training the team on the new stack.
| Cost item | Range |
| VMware decommissioning and license termination | $5,000-15,000 |
| Kubernetes optimization and right-sizing | $10,000-30,000 |
| Team training and certification | $5,000-15,000 per engineer |
| Documentation and runbook creation | $5,000-10,000 |
| Phase 4 total | $25,000-85,000 |
Kubernetes training is not optional. Your vSphere admins are smart people, but Kubernetes is a different operational model. Budget $5,000-15,000 per engineer for training and CKA/CKAD certification. Skimping here means your team will spend six months learning through production incidents instead of through coursework.
Add it all up
For a mid-market company running 100-500 VMs:
| Phase | Low estimate | High estimate |
| Assessment and planning | $15,000 | $75,000 |
| Platform build-out | $50,000 | $160,000 |
| Migration execution | $185,000 | $610,000 |
| Post-migration optimization | $25,000 | $85,000 |
| Total | $275,000 | $930,000 |
That’s a wide range. Where you land depends on:
- How many VMs you’re moving (100 vs. 500 is a big difference)
- How much you do internally vs. with a consulting partner
- Whether your apps need refactoring or can be lift-and-shifted
- Managed Kubernetes vs. self-hosted
- How much of your team’s time you can dedicate (part-time migration teams take twice as long, which doubles the parallel running costs)
When does the migration pay for itself?
This is the slide your CFO actually cares about.
Take a company paying $120,000/year under the new VMware pricing (a 25-server environment on VVF, which isn’t unusual). Their Kubernetes infrastructure costs after migration might run $40,000-60,000/year for managed services, or $20,000-35,000/year self-hosted if they already own the hardware.
| Scenario | Annual VMware cost | Annual post-migration cost | Annual savings | Migration cost (mid-range) | Payback period |
| 100 VMs, managed K8s | $60,000 | $30,000 | $30,000 | $350,000 | ~12 months |
| 250 VMs, managed K8s | $120,000 | $50,000 | $70,000 | $500,000 | ~7 months |
| 500 VMs, hybrid | $280,000 | $100,000 | $180,000 | $700,000 | ~4 months |
Platform9 published an analysis showing 49% TCO reduction when moving from VMware to Kubernetes with KubeVirt. Michelin cut platform costs by 44% after moving 450 apps off VMware Tanzu to open-source Kubernetes. Those numbers are consistent with what we see: a 40-60% reduction in annual infrastructure spend once the migration is done and the VMware licenses are gone.
The breakeven math works for most companies within 12-24 months. Larger environments with higher VMware bills break even faster because the savings scale but the migration overhead doesn’t scale proportionally.
The costs that don’t show up in spreadsheets
Some of the real costs of this migration aren’t line items.
Your team’s morale during the migration matters. Running two platforms simultaneously is exhausting. The on-call rotation gets heavier. People burn out. We’ve seen good engineers leave mid-migration because nobody planned for the extra load. If you’re running a 6-month migration with the same team that’s keeping production running, either hire a contractor to backfill operations or accept that your velocity on everything else drops to near zero.
Opportunity cost is the other one. Every engineer working on the migration isn’t building product features. For some companies, that trade-off is fine. For others, especially startups trying to ship quickly, it’s a real problem. This is a big reason mid-market companies bring in external help: not because their engineers can’t do it, but because they can’t afford to stop doing everything else for six months.
Team size: what you actually need
Gartner’s estimate of 7-10 FTEs for scoping is for large enterprises. Here’s what mid-market looks like:
- Assessment phase: 2-3 people, 4-6 weeks (one VMware admin, one architect, maybe one external consultant)
- Migration execution: 3-5 people dedicated for 3-6 months (platform engineer, 1-2 migration engineers, VMware admin, project manager)
- Post-migration: 2-3 people, 1-3 months (platform engineer, application team leads rotating in)
If you’re bringing in an external consulting partner, that typically replaces 2-3 of those roles during the migration phase, and your internal team shadows them to learn the new stack. That’s the model that tends to work best: external expertise does the heavy lifting, internal team inherits the operational knowledge.
Build the business case, then move
If you’ve read this far, you’re probably building a proposal. Here’s a one-page summary you can steal:
The problem: VMware licensing costs increased [X]% after Broadcom’s acquisition. Staying on VMware costs us $[Y]/year with no path back to the old pricing.
The ask: $[Z] over [N] months to migrate [number] VMs to Kubernetes.
The payback: Annual infrastructure savings of $[A], with full ROI in [B] months. Additional benefits include reduced vendor lock-in and a platform that scales without per-core licensing surprises.
The risk if we wait: Every quarter we delay costs $[Y/4] in inflated licensing. Migration costs won’t decrease because Kubernetes talent is getting more expensive, not less.
Fill in your numbers from the tables above. Adjust for your environment. Don’t round down to make the proposal look better. CFOs respect honest numbers more than optimistic ones, and you’ll need that credibility when the parallel running costs show up on the invoice.
Where Obsium fits
We help mid-market companies run the numbers, then run the migration. Assessment, platform build-out, wave-based execution, and the observability layer that tells you whether the new environment is actually performing better than the old one.
We deploy Prometheus, Grafana, Loki, and Tempo inside your infrastructure. You own the data. No per-host monitoring fees eating into the savings you just fought to get.
If you need help building the business case or you’re ready to start, talk to us.
