Leaving VMware: Should You Rehost to Cloud VMs or Replatform to Containers?

Should I rehost to cloud VMs (EC2) or replatform to containers when leaving VMware?

Rehost to cloud VMs when your constraint is a VMware renewal date, when the workload is stateful or vendor-packaged, or when nobody on your team has carried a Kubernetes pager. Replatform to containers only when the service is stateless, deployed more than once a month, and burning idle capacity 24/7. Most organizations end up doing both: rehost the long tail first to clear the date, replatform the high-traffic slice second. The destination can be Amazon EC2, Google Compute Engine, Azure VMs, Scaleway Instances, or your existing Kubernetes cluster, including an on-prem one.

A forced VMware exit is a deadline problem first and an architecture problem second. That framing settles most arguments. Here are the three paths in plain terms:

• Rehost (lift-and-shift): move a vSphere VM to a cloud VM (EC2, GCE, Azure VM, Scaleway Instance) with the OS and config intact.
• Replatform: repackage the app into containers on Kubernetes (EKS, GKE, AKS, Scaleway Kapsule, or self-managed).
• Refactor: rewrite the app. Almost never the right call under a license deadline.

The four inputs that actually decide this are your contract deadline, workload statefulness, the licensing and vendor support matrix, and your team's operational skill. Technology preference is not on the list. Run this Monday-morning triage on every workload:

• Does it deploy more than once a month? Yes points to containers.
• Is it stateful? Yes points to a VM.
• Does a vendor support matrix govern it? Yes points to a VM.
• Is there a Dockerfile or CI artifact for it today? No points to a VM.

Why are so many teams leaving VMware in the first place?

The trigger is commercial, not technical. Broadcom completed its $69 billion acquisition of VMware on November 22, 2023, then moved the portfolio to subscription bundles (VMware Cloud Foundation and vSphere Foundation) and ended perpetual licensing and standalone SnS renewals. An open-ended modernization project turned into a hard-dated migration overnight.

The cost impact is real but you should quote it from named sources only. The cloud trade body CISPE, in its competition complaint to the European Commission, says bundling, minimum commitments, and up-front payment demands have raised some customers' costs by more than 1,000 percent, and The Register's reporting cites cases as high as 1,500 percent. Broadcom disputes the characterization. Licensing minimums shifted too: alongside the long-standing 16-core-per-CPU floor, Broadcom introduced a 72-core-per-order minimum in April 2025 that it later walked back under pressure. The point is not the exact percentage, it is that renewals became unpredictable.

So people are moving. CloudBolt's 2025 research found 86 percent of companies are actively reducing their VMware footprint, and Gartner expects 35 percent of VMware workloads to move off the platform by 2028. The strategic consequence is simple: the renewal date caps how much replatforming you can realistically finish, which is why rehost-first usually wins the first wave.

To be fair, leaving is not the only answer. Staying on VMware, or moving to Nutanix, Proxmox, or OpenStack, is legitimate and sometimes cheaper, especially for heavy stateful estates, strict data-residency needs, or predictable capacity where a hyperscaler bill would be higher than a renewal. Say that to your CFO before you commit.

When is rehosting to cloud VMs the right call?

Rehost when the cost of being wrong is high and the clock is short. VM-to-VM replication preserves the OS, the configuration, and the failure modes you already understand, which is exactly what you want for the undocumented workloads that make up most of a VMware estate.

The hard-deadline path is block-level replication. AWS Application Migration Service (MGN) performs continuous block-level replication from vSphere sources into a staging area, then cuts over with downtime measured in minutes, not days. Azure Migrate does agentless VMware replication using snapshots and changed block tracking, and Google Migrate to Virtual Machines replicates continuously until you trigger cut-over. All three keep the source running while they sync, so your rollback is to simply not cut over.

Workload signals that say rehost: stateful monoliths, COTS and vendor-packaged software with certified support matrices, Windows apps with licensing ties, and anything with a kernel module, appliance image, or hardware dongle. Team signals that say rehost: nobody has been on call for Kubernetes, there is no platform team, no container registry, and no CI pipeline producing deployable artifacts today.

What rehosting does not fix: deployment speed, idle capacity, snowflake servers, or configuration drift. You relocate the problem and keep paying for it. Two traps to check first. One, Windows Server and SQL Server license mobility is governed by Microsoft's Product Terms and Azure Hybrid Benefit rules, and some bring-your-own-license scenarios force dedicated hosts. Two, you lose VMware's overcommit ratio when you map to dedicated cloud instances, so like-for-like shapes can cost more. Rehost on like-for-like shapes to hit the date, then right-size in month two or three using real utilization data from Amazon CloudWatch, Google Cloud Monitoring, or Azure Monitor.

When does replatforming to containers actually pay off?

Replatforming pays off on services that are already stateless and shipped often, because that is where bin-packing, autoscaling, and self-service deploys convert into measurable cost and cycle-time wins. A service deployed twice a year gains nothing from Kubernetes except a new way to break.

Good candidates: stateless HTTP services, internal tools, batch and cron jobs, anything already behind a load balancer with a working health check. Bad candidates: databases (use Amazon RDS, Cloud SQL, Azure Database, or Scaleway managed databases instead), licensed appliances, and anything with shared mutable local state or hard affinity to a single host.

The cost savings come from density versus one-app-per-VM, horizontal autoscaling, and stopping non-production environments outside working hours. That last one matters more than people expect: Flexera's 2025 report estimates 27 percent of cloud spend is wasted, with idle and overprovisioned resources making up about 60 percent of it. The velocity comes from one artifact promoted across environments, preview environments per pull request, and rollbacks that are a tag change. The payoff is not abstract: in the 2024 DORA State of DevOps report, elite performers deploy on demand with change lead times under a day and change failure rates around 5 percent.

The real bill nobody budgets for is the platform layer: ingress, TLS, secrets, image registry, CI/CD, RBAC, logging, metrics, and cluster upgrades. Treat it as a product, not a ticket. Kubernetes itself is mainstream now, with 82 percent of container users running it in production per the 2025 CNCF survey, but mainstream is not the same as free. My rule of thumb: containerize the 10 to 20 percent of services that absorb most of your deployments, not the whole estate.

What does each path cost, and over what timeline?

Rehosting is cheap to execute and expensive to keep; replatforming is expensive to execute and cheaper to keep, but only if you right-size and automate. Split every estimate into three honest buckets: migration effort in person-weeks, steady-state infrastructure, and ongoing operational toil.

Here is the number most business cases miss: plan to pay Broadcom and your cloud provider at the same time for the length of your cutover wave plus a rollback buffer, typically three to six months, and put that double-run line in the business case on day one. It is the single most commonly skipped cost in a VMware exit.

The levers that actually move the steady-state bill are committed-use discounts: AWS Compute Savings Plans and Reserved Instances up to about 72 percent off on-demand, Google committed use discounts up to 57 percent, and Azure Reservations. These stay in your own name when you deploy into your own cloud account rather than a vendor's. And watch the execution risk: McKinsey found roughly 75 percent of cloud migration programs run over budget, so pad the plan.

What is the hybrid path most teams end up on?

Run two tracks in parallel: rehost the long tail to cloud VMs to clear the VMware deadline, while replatforming a thin, high-traffic slice to containers so the target platform is proven in production before the bulk arrives. The failure mode is the opposite, a big-bang Kubernetes rewrite scheduled against a license expiry. Do not do that.

The sequence that works:

• Step 1: Inventory and tier the estate by deploy frequency and statefulness, not business criticality alone.
• Step 2: Pick 2 to 3 pilot services, containerize them, and run them in production before the mass move.
• Step 3: Rehost everything else with a replication tool, a written cutover runbook per wave, and a documented rollback.
• Step 4: Retire and consolidate; a meaningful share of enterprise VMs are zombies nobody will miss, and with idle resources making up about 60 percent of the 27 percent of cloud spend Flexera calls wasted, deleting them is the cheapest saving available.
• Step 5: Fund the replatform backlog quarter by quarter from right-sizing savings, with explicit exit criteria per tranche.

How do you replatform to containers without building a platform team first?

Buy or adopt the platform layer instead of building it. What kills container migrations is not Docker or Kubernetes, it is the glue work between a running cluster and developers who can self-serve: ingress, DNS, TLS, secrets, RBAC, CI/CD, preview environments, cluster upgrades, and log and metric pipelines. That last item alone is a standing tax, since Kubernetes supports only the three most recent minor releases on a roughly 15-week cadence, so you are upgrading forever.

This is not a solved problem for most shops. Puppet's State of DevOps work found about 51 percent of organizations have adopted platform engineering, which also means roughly half have not, and building the layer in-house is a multi-quarter effort with real headcount.

An internal developer platform supplies that layer on day one. Qovery runs on top of your own AWS, GCP, Azure, or Scaleway account, or an existing Kubernetes cluster including self-managed and on-prem, so the cloud bill and any committed-use discounts stay in your name (BYOC). The capabilities that matter for a VMware exit: git-push deployments, preview environments per pull request, environment auto-stop for non-production, managed cluster upgrades, per-environment RBAC, and databases backed by managed cloud services. That is the difference between shipping in weeks and hiring for a year.

Be fair about the alternatives. Use AWS MGN, Azure Migrate, or Google Migrate to Virtual Machines for the rehost leg. For simple stateless container workloads, Amazon ECS on Fargate, Google Cloud Run, and Azure Container Apps are excellent and need no cluster. If you are buying a full vendor platform, Red Hat OpenShift and VMware Tanzu are credible. If you genuinely want to build it yourself, Terraform plus Argo CD plus Helm is the honest DIY stack. Qovery is not the answer for pure VM rehosting with no containerization intent, or for heavily licensed appliance workloads that will never be containerized.

Should I rehost to EC2 or replatform to containers when leaving VMware?

Rehost when the deadline is a VMware renewal, the workload is stateful or vendor-packaged, or the team has no Kubernetes experience. Replatform the stateless, frequently-deployed services where autoscaling and self-service pay off. EC2 is one target among several: Google Compute Engine, Azure VMs, Scaleway Instances, and your existing Kubernetes cluster are equally valid.

Is lift-and-shift from VMware to the cloud cheaper than staying on VMware with Broadcom subscription pricing?

Sometimes, but not automatically. Rehosting carries oversized VM shapes into the cloud and loses VMware's overcommit ratio, so savings only arrive after right-sizing and committed-use discounts like AWS Savings Plans or Google CUDs. Model both bills honestly, including the double-run period.

Which VMware workloads should never be containerized?

Databases, licensed appliances, COTS software with certified support matrices, Windows apps with licensing ties, and anything with a kernel module or shared mutable local state. Rehost these to cloud VMs and use managed database services where you can.

How long does a VMware to cloud migration take, and how long do you pay for VMware and cloud at the same time?

A rehost wave runs days to a few weeks per batch; replatforming runs one to three months per tranche. Budget a double-run of roughly three to six months where you pay Broadcom and your cloud provider simultaneously, plus a rollback buffer.

Can I move VMware VMs to Kubernetes directly, or do I have to containerize them first?

You containerize first. Kubernetes runs containers, not vSphere VMs, so replatforming means writing a Dockerfile, externalizing state, and building a deploy pipeline. If that work is not justified, rehost the VM to EC2, GCE, Azure VMs, or Scaleway Instances instead.

Do I need a dedicated platform team to run Kubernetes after leaving VMware?

Not if you adopt a platform layer. Running Kubernetes well means owning ingress, TLS, secrets, RBAC, CI/CD, and perpetual cluster upgrades. An internal developer platform like Qovery supplies that inside your own AWS, GCP, Azure, or Scaleway account, or your existing cluster, so a small team ships without first hiring a platform group.