VMware Workload Decision Guide

A VMware workload decision is a documented choice about a business service and the systems supporting it. Start with its purpose, constraints, evidence, and owner. Choose a destination only after the treatment is clear.

This guide is for CIOs, infrastructure and platform leaders, application owners, architects, and finance stakeholders working through a renewal, infrastructure refresh, support milestone, or modernization program.

The aim is not to move the largest number of VMs. It is to reach decisions the business can defend and the engineering team can deliver. Use the framework to organize a review, then take the worksheet into the discussion with application owners and operations.

1. Define the Decision Before the Destination

Write down why this review is happening. A renewal cost, support milestone, capacity problem, acquisition, or application constraint can produce quite different priorities. Identify the decision deadline and what must be known before it.

Agree the scope: which business services, locations, environments, contracts, and recovery systems are included? Distinguish reducing VMware dependency from leaving a data center, modernizing an application, and changing an operating model. One does not automatically achieve the others.

Broadcom’s lifecycle notice lists October 11, 2027 as End of Service for ESXi 8.x, vCenter Server 8.x, vSAN 8.x, NSX 4.x, and VCF 5.2.x. Review the precise releases and contracts in your environment. VVF for VDI follows a separate lifecycle. A product milestone is a planning input, not evidence that all VMware infrastructure must move.

Decision output: a named sponsor, a bounded workload scope, the reason for change, the deadline, and the people authorized to accept the outcome.

2. Start with Business Services, Not VM Counts

An application can span several VMs, databases, queues, external services, and scheduled processes. A shared database can support more than one application. Counting servers does not resolve those relationships.

Create an application or business-service register and connect its components to the infrastructure inventory. Record missing ownership explicitly. Separate production, non-production, backup, recovery, and shared platform components so they are not mistaken for independent applications.

Collect enough evidence to explain both normal operation and less frequent activity. Performance samples should cover relevant peaks, batch runs, reporting cycles, and seasonality. Short observation windows need a recorded limitation.

Microsoft’s assessment overview distinguishes readiness, rightsizing, and estimated Azure resource cost. Record the observation period and sizing assumptions when using such tooling. A recommended VM size is not a complete application decision.

Agree recovery targets with the business owner. The recovery time objective (RTO) is the target time to restore service. The recovery point objective (RPO) expresses the tolerable data-loss window in time. The proposed recovery design then needs testing against those targets.

3. Map the Dependencies That Can Change the Plan

Record the relationships that would break or become unacceptable if components were separated. Include identity, name resolution, certificates, firewall policy, licensing services, shared storage, file transfers, monitoring, and backup infrastructure alongside application traffic.

Network observations are one input. Validate them with application owners, configuration, runbooks, and scheduled processing. A quiet dependency during discovery may be critical at month end.

Classify each relationship:

• Must move together: separation would violate an application, latency, consistency, or support requirement.
• Can span environments: a tested network and security design can support the separation.
• Can be replaced or removed: change the dependency deliberately and test the new behavior.
• Unknown: assign an investigation owner before accepting the target design.

Use these relationships to define move groups. A move group is a set of related components that needs coordinated treatment; a wave is a scheduled delivery unit that can include several groups. Avoid using a convenient batch size as evidence that an application can be split.

Google’s migration-planning guidance places workload discovery, component mapping, and dependency mapping before migration waves. Repeat discovery where the application or proposed architecture changes.

4. Give Each Workload a Defensible Treatment

The six paths below are a buyer-friendly assessment framework. They organize the conversation; they do not replace detailed platform compatibility checks or a migration methodology.

Keep

Retain a workload when business value, vendor support, latency, physical dependencies, economics, or change timing justify it. Document the reason, the support plan, and the next review trigger. Keeping something should be a conscious decision, not the absence of an owner.

For plant and edge systems, determine which application components need to remain close to equipment and which can change independently. Do not assume an entire service must stay because one component does.

Rehost

Move a compatible application to a new compute environment without redesigning it. Validate operating-system support, storage behavior, networking, identity, licensing, backups, and performance. Rightsize with evidence rather than copying every provisioned resource unchanged.

A successful rehost can still preserve application debt. Decide separately whether later optimization or modernization has enough business value to warrant another workstream.

Replatform

Change selected platform components while preserving the application’s core purpose. A managed database may be a candidate, but engine compatibility, extensions, operational access, performance, and data migration need validation.

Write down what the provider will operate and what remains your responsibility. Managed services do not remove ownership of application behavior, permissions, data protection, or the overall recovery design.

Modernize

Change application architecture or delivery practices where there is a specific outcome: a release bottleneck, support problem, scaling constraint, or operational burden worth addressing.

Separate the modernization scope from migration unless the dependency is unavoidable. Confirm access to code, test coverage, release ownership, acceptance criteria, and the ability to operate the target. Containers are one possible implementation, not the definition of modernization.

Retire

Remove a workload only after the business owner confirms it is no longer needed and dependent teams agree. Check infrequent jobs, recovery roles, records retention, contractual obligations, and data access before shutdown.

Document the removal sequence and acceptance evidence. Confirm when infrastructure, monitoring, backup, and license costs actually stop. Low utilization on its own is insufficient evidence.

Investigate

Use this state when ownership, dependencies, support, utilization, or economics are not sufficiently understood. Name the missing evidence, the person who will obtain it, and the next review date.

Investigate is not a permanent destination and not a seventh migration strategy. It prevents a gap in evidence from becoming a false recommendation. Google’s offline assessment documentation likewise recognizes insufficient data as a possible assessment result.

How This Relates to the AWS 7 Rs

AWS’s migration strategies include retain, retire, rehost, replatform, refactor or re-architect, relocate, and repurchase. Our review labels align as follows:

These are not one-to-one product mappings. A relocation that preserves a VMware operating model may solve a facilities problem without reducing VMware dependency. A SaaS replacement creates data, integration, security, and adoption work of its own.

Back to contents ↑

5. Test the Constraints Before Ranking the Options

A weighted score can make an unsupported recommendation look precise. First identify constraints that can stop a path entirely. A lower cost estimate does not override an unsupported application, an unmet recovery requirement, or a prohibited data location.

Use the following review questions for each candidate:

• Support: Does the application vendor support the proposed OS, database, virtualization, or managed-service combination?
• Data and security: Are residency, access, encryption, audit, and retention requirements addressed?
• Performance: Can the service meet its observed demand, latency, throughput, and storage needs?
• Recovery: Can the design meet agreed recovery time and recovery point objectives, with test evidence?
• Dependencies: Can linked systems move together or operate acceptably across environments?
• Delivery: Are code, skills, test environments, change windows, and decision-makers available?
• Operations: Is there a receiving team with access, runbooks, monitoring, and escalation responsibility?

Record confidence alongside the answer: validated, supported by partial evidence, or unresolved. Confidence describes the evidence; it is not a predicted migration success rate. Unresolved blockers stay visible until an owner accepts or resolves them.

6. Compare the Full Cost of Staying and Changing

Use the same workload scope, service level, capacity assumptions, and comparison period on both sides. Separate current cash expense from allocated cost and future capital replacement. Finance should be able to reconcile the baseline to its source records.

Staying can include platform and application licensing, hardware refresh, facilities, connectivity, security, monitoring, backup, recovery, and operating effort.

Changing adds discovery, engineering, application remediation, migration tools, data transfer, connectivity changes, testing, temporary dual running, training, and decommissioning. The destination then needs a recurring operating model, not just compute and storage.

Record assumptions about rightsizing, utilization, purchasing commitments, growth, currency, and when old costs cease. Do not count the same benefit twice across retirement, consolidation, rightsizing, and a new pricing model.

Test a downside case. Fewer retirements, delayed decommissioning, additional network capacity, or a licensing constraint can change the result. Keep one-time transition costs visible rather than hiding them inside a monthly run-rate comparison.

When AWS is a suitable destination, review OLA and MAP eligibility separately. Benefits depend on applicable requirements and approval. Do not make unapproved funding a guaranteed saving or describe every AAIC assessment as free.

Decision output: an attributable baseline, a target model, transition costs, sensitivities, and a named owner for each important assumption.

7. Choose a Destination Your Team Can Operate

Compare destinations against the validated requirements, not against a predetermined vendor preference.

Start with the smallest set of platforms that meets the requirements. Multiple valid destinations do not imply a need for a multi-cloud deployment.

For VMware-preserving options, distinguish changing hosting location from changing the virtualization model. Confirm current offering availability, procurement, and licensing directly with the provider. For Kubernetes, validate the application and platform work separately; it is not a universal hypervisor replacement.

AAIC’s approach covers assessment, migration, modernization, and operations across supported destination choices. Explore VMware Migration and Modernization for the service scope.

Back to contents ↑

8. Turn Decisions into Waves and Acceptance Gates

Give each accepted treatment an implementation path. Establish the target foundation, access model, network, observability, backup, and infrastructure automation before using production workloads to discover missing platform controls.

Choose an initial move group that teaches the team something useful without combining every risk at once. Rehearse. Record what changed in the plan. Update the assumptions for later waves.

For each group, identify entry criteria, migration steps, validation evidence, decision authority, and exit criteria. State the actual business workflows that must pass. Define what happens if they do not.

Rollback needs special attention for stateful systems. After the target accepts writes, redirecting traffic to an old source can lose or conflict with data. Define reconciliation, the last safe rollback point, forward-recovery options, and the owner authorized to choose. AWS’s cutover guidance distinguishes recovery before and after new data is written.

Recovery testing must demonstrate that backups can be restored and services can function within their agreed objectives. A green replication status is not the same evidence.

9. Make Day-2 Ownership Part of the Decision

Describe who operates the resulting business service across its complete path: cloud, retained infrastructure, identity, application, data, monitoring, vendors, and deployment tooling.

Agree coverage, responsibilities, access controls, escalation, and change authority. A support agreement should distinguish investigation from approval to make a production change. Confirm monitoring and runbooks with the people receiving the service, not only the project team.

Include patching, backup, disaster recovery, security operations, deployments, and cost review. Set the stabilization period around business activity. An infrequent batch cycle may need explicit testing beyond the first days after cutover.

AWS’s VMware transition guidance treats operational transformation as a distinct part of the move. Its post-cutover guidance also addresses monitoring and a workload-appropriate support period.

In AAIC’s managed model, CloudOps, DevOps, SRE, and FinOps engineers provide the operational ownership defined in the engagement. OpsRabbit assists with evidence correlation and structured investigation across connected systems. Engineers validate findings and determine the response. The accelerator does not remove customer application ownership or replace tested recovery procedures.

Watch OpsRabbit in action: From Alert to Root Cause in Minutes.

10. See the Framework in an AAIC Engagement

For an anonymous industrial manufacturer, the VMware environment included 186 VM workloads, 72 TB of storage, and more than 40 applications. The decision register separated the work before migration:

Twenty-three workloads were rightsized within the rehost group; they are not an additional category. Delivery used a foundation phase and six controlled workload waves, while selected plant systems remained on retained infrastructure.

The engagement achieved 30% lower infrastructure total cost of ownership (TCO) over 3 years. That outcome is engagement-specific, not a savings promise for another environment. Read the manufacturing case study for the engineering context.

The companion application-modernization case study covers selective treatment of a B2B software environment. The Day-2 operations case study covers operational ownership across the resulting hybrid environment.

Workload Decision Worksheet

Use one row per decision unit, with supporting VM or component identifiers. If a service has different treatments across tiers, record linked decisions rather than forcing the whole application into one label.

The register includes business and technical ownership, purpose, criticality, dependency evidence, observed demand, support and security constraints, RTO and RPO, disposition, candidate destination, rationale, confidence, unknowns, next actions, cost assumptions, move group, acceptance, rollback authority, and Day-2 ownership.

Bring a small set of important services into the first review. Confirm facts with owners. Leave unknown values blank or mark them unresolved. Keep detailed credentials, personal data, secrets, and sensitive infrastructure exports out of documents shared externally.

The worksheet is a planning aid, not an automated assessment or a substitute for a validated architecture.

Back to contents ↑

What a Decision-Ready Review Produces

Before committing to delivery, check whether the review can answer these questions:

1. Does every in-scope service have a business and technical owner?
2. Can each workload decision be traced to evidence and a clear rationale?
3. Are dependencies, blockers, and unresolved items visible and assigned?
4. Does the target design meet support, security, performance, and recovery requirements?
5. Can finance reconcile the current baseline and challenge the target assumptions?
6. Are migration waves, acceptance, rollback, and recovery plans practical to execute?
7. Has the receiving operations team accepted the responsibilities and access it needs?
8. Are source retirement, retention obligations, and cost removal explicitly approved?

A review can be useful before every answer is complete. It becomes dangerous when the unanswered questions disappear from the plan.

Sources and Further Reading

This is an AAIC engineering synthesis, not a vendor certification or an automated recommendation. The workflow and worksheet are our planning aids. Vendor terminology and capabilities remain governed by their own documentation. References were reviewed on October 27, 2026; recheck lifecycle, licensing, program, and product details before making a commitment.

• Broadcom: product-specific End of Service notice.
• AWS: the seven migration strategies.
• Microsoft: Azure Migrate assessment overview.
• Google Cloud: migration planning and migration-wave planning.
• Google Cloud: offline fit assessment and insufficient data.
• AWS: cutover planning and data-aware rollback.
• AWS: post-cutover monitoring and support.
• AWS: VMware operational transition.
• AWS: VMware migration programs.