“Should we exit VMware?” sounds decisive, but it is usually the wrong first question. It collapses hundreds of different applications, databases, dependencies, recovery requirements and contracts into one platform decision. The useful question is narrower: where should each workload run next, and what must be true before it moves?
This framework deliberately allows four outcomes. Some workloads remain on VMware. Some move with minimal change. Some justify application modernization. Others should be retired instead of migrated. That is not indecision; it is portfolio management.
Why workload placement matters now
Infrastructure economics no longer fit into a clean “data center versus public cloud” comparison. Technology leaders must account for software licensing, private cloud, public cloud, data center capacity, AI infrastructure and the cost of operating two environments during a transition.
The State of FinOps 2026 reflects this expansion: 64% of respondents manage licensing, 57% manage private cloud, 48% manage data center costs and 98% manage AI spend. The same report says pre-deployment architecture costing is among the most desired capabilities. Placement and economics now need to meet before a commitment is signed.
Search behaviour points in the same direction. In our August 2026 review of the previous 12 months, Google Trends showed materially more relative interest in “VMware cloud” than “VMware alternative”. A separate comparison showed stronger interest in private and hybrid cloud than in generic infrastructure-modernization wording. Trends is a normalized 0–100 signal rather than search volume, but the direction is useful: teams are looking for operating choices, not only replacement products.
The four placement outcomes
| Decision | Good fit | Evidence required | Typical next step |
|---|---|---|---|
| Keep | Stable, tightly coupled, latency-sensitive or regulated workload with acceptable economics. | Supported lifecycle, tested recovery, known capacity plan and explicit owner. | Harden, automate, document and review at a defined date. |
| Move | Infrastructure-bound workload that can gain resilience or flexibility without application redesign. | Dependency map, landing zone readiness, TCO, test plan and rollback path. | Rehost or relocate in a controlled migration wave. |
| Modernize | Application constrained by release speed, scaling, reliability or obsolete components. | Business case for change, product owner, engineering capacity and measurable outcome. | Replatform, containerize or selectively refactor. |
| Retire | Duplicate, unsupported, unused or low-value system whose capability exists elsewhere. | Usage evidence, data-retention plan, dependency sign-off and accountable approver. | Archive required data, remove integrations and decommission safely. |
The “keep” decision must not mean “ignore.” It needs an expiry date, lifecycle assumptions and the same resilience evidence expected from a migrated workload. Likewise, “modernize” is not automatically superior to “move.” Modernization consumes scarce product and engineering capacity and should compete against other investments.
Score every workload against five dimensions
1. Business criticality
Define the process supported, revenue or operational impact, acceptable outage, peak periods and the executive owner. Technical teams should not infer business criticality from CPU or storage use.
2. Technical and dependency fit
Map upstream and downstream systems, data gravity, latency, hardware dependencies, operating-system support and integration patterns. A low-complexity virtual machine can still be a high-complexity move when its dependencies are undocumented.
3. Economics and commitments
Compare a realistic unit of service, not a VM list price. Include licenses, support, facilities, connectivity, backup, people, commitments and the temporary overlap between old and new environments. Record assumptions so finance can challenge them.
4. Risk, security and data control
Evaluate recovery evidence, privileged access, segmentation, encryption, residency, audit requirements and the blast radius of change. Risk can justify either moving or staying; the evidence determines which.
5. Operating readiness
Ask who owns the workload after the decision. Identity, observability, incident response, patching, deployment, cost allocation and SLOs need owners in both the transition and target state.
Design one operating model before building two platforms
Hybrid infrastructure fails when each platform becomes an organizational island. VMware has one access model, Google Cloud another; monitoring stops at the boundary; application teams use tickets for one environment and pipelines for the other; finance cannot compare costs.
The target model should define common controls across the estate:
- Identity: one authoritative identity lifecycle, least privilege and traceable elevation.
- Networking: explicit trust zones, routing ownership, DNS, egress control and dependency visibility.
- Delivery: infrastructure as code, repeatable environments and approved deployment paths.
- Operations: shared service ownership, SLOs, telemetry, incident command and recovery testing.
- Economics: comparable cost allocation and forecasting across licenses, data center, cloud and AI capacity.
This is where platform engineering becomes relevant. A service catalogue or golden path is not only a developer-experience project; it can become the interface that hides platform differences while keeping controls consistent.
Add AI placement without turning the roadmap into hype
AI introduces a second placement discussion. Model access may favour public cloud, while sensitive data, predictable inference, latency or sovereignty can favour private or hybrid deployment. Google now explicitly positions Google Distributed Cloud for AI in a customer data center, at the edge and in air-gapped environments.
Use the same discipline: identify the data boundary, latency target, model requirement, capacity pattern, unit economics and operational owner. Do not buy private AI infrastructure before measuring the workload, and do not send regulated data to a public endpoint before proving the control model.
Turn the matrix into a roadmap
- Stabilize first. Close recovery, identity or observability gaps that would make any later change unsafe.
- Remove obvious waste. Retire unused systems and eliminate duplicate capacity before sizing the target.
- Pilot a representative workload. Choose something meaningful enough to test the operating model but reversible enough to limit risk.
- Build waves around dependencies. Do not group workloads only by department or server count.
- Use decision gates. Recheck business value, economics, recovery evidence and team readiness before each wave.
A useful roadmap contains 90-, 180- and 365-day horizons. The first horizon should produce evidence and remove blockers. The second should scale a proven pattern. The third should address the highest-value modernization work, not simply the remaining server count.
Common mistakes
- Declaring a universal platform destination before inventory and dependency work.
- Comparing infrastructure prices while excluding licenses, people and transition overlap.
- Treating “temporary hybrid” as an operating model with no exit criteria.
- Moving technical debt and calling it modernization.
- Building a landing zone without defining application-team access and ownership.
- Measuring migration success by VM count instead of resilience, cost, delivery speed and retired risk.
The minimum useful deliverable
A defensible workload placement exercise does not require a year-long transformation programme. Its minimum useful output is a workload matrix, directional TCO, target control model, risk register and sequenced roadmap with named owners. It should clearly show what is known, what is assumed and what evidence is still missing.
If the answer for some workloads is “stay on VMware and improve operations,” that is a valid result. If another group should move to Google Cloud, modernize on GKE or be retired, the same framework should explain why.
Sources and methodology
- FinOps Foundation: State of FinOps 2026 — technology cost scope, priorities and decision involvement.
- Google Cloud: New innovations in Google Distributed Cloud — hybrid, sovereign and on-premises AI positioning.
- Google Trends methodology — normalization, sampling and low-volume limitations.
Build the workload decisions before the migration backlog.
Cloudpeakify's Hybrid Infrastructure Blueprint turns estate, cost and risk evidence into a placement matrix, target operating model and an actionable roadmap.