VMware Migration & Modernization

Reduce VMware Dependency Without Increasing Operational Complexity

Applied AI Consulting (AAIC) helps you assess, migrate, modernize, and operate your VMware estate across AWS, Azure, Google Cloud, Kubernetes, and retained infrastructure. We match the destination to your workloads and business needs.

Know what to keep. Know what to move. Know how you’ll operate it afterward.

Discuss Your VMware Environment See How We Approach VMware Migration
VMware estateWorkload view
Business appsRehost
DatabasesReplatform
ERPInvestigate
File servicesReplatform
Internal appsModernize
Dev/TestRetire
Plant / EdgeKeep
Legacy systemsInvestigate
↓Dependencies · ownership · economics↓
KeepRehostReplatformModernizeRetireInvestigate

Start with the estate. Assess each workload before choosing a destination.

Illustrative workload paths. The destination follows the assessment.

Cloud delivery foundationAmazon Web Services Advanced Consulting PartnerManaged CloudOps, DevOps & SREPublished migration outcomes

01 / Why now

Your Next VMware Renewal Is an Infrastructure Decision

Platform, licensing, and lifecycle changes put the whole estate on the table. The decision reaches beyond the renewal: which workloads still belong, which should move, and whether the result will be easier to operate.

October 11, 2027

A lifecycle decision point

Broadcom lists End of Service for ESXi 8.x, vCenter Server 8.x, vSAN 8.x, NSX 4.x, and VCF 5.2.x. Check the exact products and contract in your estate.

Broadcom lifecycle guidance
Beyond the VM

Operations need a transition too

Dependency mapping, business continuity, operating practices, and workforce readiness belong in the migration plan from the start.

AWS transition guidance
OLA + MAP

Build a supported business case

AWS offers VMware assessment and migration programs. Qualified migrations may be eligible for incentives, subject to program requirements and approval.

AWS VMware migration programs

02 / Workload decisions

Don’t start with “Where should we move VMware?”

Start With “What Should Actually Move?”

We connect technical discovery to business ownership, criticality, cost, and recovery requirements. Keeping a workload can be the right decision. So can retiring it.

See a workload decision register
01Keep

Keep workloads on VMware where it remains the right operational or economic choice.

Decision signals
Hardware dependencies, plant latency, investment still in use, or a strong existing operating model.
Risk to resolve
Confirm the supported platform version, renewal economics, recovery plan, and future review date.
Possible target
Retained VMware or a supported private infrastructure platform, with a named owner and review point.
02Rehost

Move suitable workloads with minimal application change.

Decision signals
Supported operating systems, well-understood dependencies, and a practical reason to exit the current estate.
Risk to resolve
Moving oversized VMs can recreate the same cost problem. Check network behavior and license portability.
Possible target
Right-sized virtual machines on Amazon EC2, Azure VMs, or Google Compute Engine, based on the workload decision.
03Replatform

Reduce infrastructure work by adopting managed services where compatibility allows.

Decision signals
Standard database or file-service requirements, supported engines, and manageable application changes.
Risk to resolve
Validate engine extensions, access patterns, backup behavior, and application compatibility before cutover.
Possible target
Compatible managed database or file services on AWS, Azure, or Google Cloud, after application and recovery validation.
04Modernize

Change application architecture where the business benefit justifies the work.

Decision signals
Active product development, deployable service boundaries, repeatable builds, and measurable maintenance overhead.
Risk to resolve
Separate migration deadlines from application redesign. Test state handling, scaling, and rollback paths.
Possible target
Containers, managed databases, or serverless components with CI/CD and observability built in.
05Retire

Remove infrastructure that no longer serves a valid business need.

Decision signals
No active business owner, replaced functionality, unused environments, or data already held elsewhere.
Risk to resolve
Low utilization alone is not permission to delete. Check retention, seasonal usage, audit needs, and dependencies.
Possible target
Owner-approved decommissioning with archived data and evidence of dependency checks.
06Investigate

Pause the destination decision until the workload is understood.

Decision signals
Unknown ownership, missing traffic data, undocumented integrations, or unclear business criticality.
Risk to resolve
Treating an unknown workload as low risk can break a business process that nobody mapped.
Possible target
A time-bounded discovery backlog with an accountable owner, evidence gaps, and decision criteria.

03 / The AAIC approach

Decide Transform Operate

Migration is one phase. The infrastructure decision starts before it, and operational responsibility continues afterward.

01

Decide

Know your estate before committing to a destination.

Connect inventory and utilization to the people, applications, and business processes that depend on each workload.

What we assess and deliver
  • VMware inventory and resource utilization
  • Application dependencies and business ownership
  • Workload criticality and operating-system constraints
  • Licensing and security requirements
  • Recovery objectives and cloud readiness
  • Migration risk and target economics
Output

A workload-level decision register, business case, and migration roadmap.

02

Transform

Move each workload through the right transformation path.

Establish the target foundation, prove a pilot, then migrate in dependency-aware waves. Retain what should stay and retire what is no longer needed.

What we assess and deliver
  • Landing zone and identity controls
  • Rehost or replatform with compatibility validation
  • Selective containerization and application modernization
  • Infrastructure as code and deployment pipelines
  • Recovery rehearsals and rollback gates
  • Business validation before decommissioning
Output

Tested workloads, a controlled cutover, and an accepted operational handover.

03

Operate

Make the resulting environment easier to run.

Define ownership across AWS, Azure, Google Cloud, retained infrastructure, Kubernetes, managed databases, SaaS, monitoring, and ITSM before the migration finishes.

What we assess and deliver
  • CloudOps and platform ownership
  • DevOps and SRE runbooks
  • FinOps budgets and cost allocation
  • Monitoring and incident escalation
  • Backup and disaster-recovery tests
  • OpsRabbit-assisted investigation with engineer review
Output

An operating model with service ownership, runbooks, cost visibility, and evidence-backed investigations.

04 / Day-2 operations

Migration Doesn’t End at Cutover

After transformation, operational context can sit across cloud services, containers, retained systems, monitoring, and ITSM. A better platform can still be harder to investigate.

Our engineers support the environment through CloudOps, DevOps, SRE, and FinOps. OpsRabbit helps correlate evidence and structure investigations across connected systems, with engineer review before action.

See OpsRabbit Operations Intelligence
AWS / infrastructureKubernetesMonitoringITSM / changesLogs / metricsRetained systems
OpsRabbitOperations Intelligence PlatformCorrelate available operational context
  1. Evidence
  2. Correlation
  3. Likely root cause
  4. Recommended next action
AAIC DevOps / SRE engineer validates findings, chooses the action, and owns escalation.
Follow the investigation workflow
  1. Application latency: a monitoring alert identifies the affected service and time window.
  2. Infrastructure context: review available cloud, Kubernetes, and retained-system signals for that window.
  3. Change context: compare recent deployments, configuration changes, and relevant incident history.
  4. OpsRabbit assistance: correlate the accessible evidence, identify a likely cause, and outline the next checks. Missing evidence remains an explicit gap.
  5. Engineer decision: AAIC validates the findings and selects remediation, escalation, or further investigation. A correlation is not proof of causation.
Investigation assistance across the connected environment. Findings depend on the available integrations, permissions, and evidence.

05 / The right destination

AWS, Azure, Google Cloud, or Kubernetes. Start With the Workload.

We support migration and modernization across cloud platforms and retained infrastructure, comparing application compatibility, dependencies, licensing, recovery needs, cost, and your team's ability to operate the result.

Amazon Web Services

AWS

Rehost on EC2, adopt managed data services, or modernize selected applications on ECS or EKS. Connect the landing zone, migration waves, recovery, and ongoing operations.

AWS migration guidance
Microsoft Azure

Microsoft Azure

Assess VMware dependencies and readiness with Azure Migrate. Plan compatible Azure VM destinations, identity, networking, security, cutover, and operational handover.

Azure migration guidance
Google Cloud

Google Cloud

Evaluate Compute Engine rehosting and selective application modernization. Use Migration Center and Migrate to Virtual Machines where they fit the inventory and migration requirements.

Google Cloud migration guidance
Kubernetes

Kubernetes & Containers

Containerize suitable applications on EKS, AKS, GKE, or an appropriate on-premises platform. Kubernetes is a modernization path, not a drop-in replacement for every VM.

Kubernetes production guidance

Our AWS Advantage: Partner Expertise + Migration Programs

AAIC is an Amazon Web Services Advanced Consulting Partner. When AWS is the right fit, we bring that delivery experience and help evaluate OLA and MAP eligibility. Program benefits strengthen the business case; they do not determine the destination.

AWS Optimization and Licensing Assessment

AWS OLA evaluates resource usage, licensing, and dependencies to inform an AWS business case. It helps test whether the target economics justify a move.

Explore AWS OLA

AWS Migration Acceleration Program

MAP offers migration methods, tools, resources, and training for VMware transitions. Eligibility and any incentives depend on the proposed migration and AWS approval.

Explore AWS MAP

AWS Transform for VMware

AWS Transform can assist discovery, dependency mapping, wave planning, network conversion, and server rehosting. It is an AWS service, used where its supported capabilities fit the plan.

Read AWS Transform capabilities
How do we choose between cloud VMs, managed services, and Kubernetes?

Start with workload compatibility and the operating model. EC2, Azure VMs, or Compute Engine can suit rehosting. Managed databases need engine and application validation. EKS, AKS, or GKE fit applications that justify containerization and have clear platform ownership. Retained VMware and edge systems remain valid destinations when latency, support, or economics require them.

Identity, networking, infrastructure as code, observability, backup, recovery, and cost controls span the whole design. A migration does not require multi-cloud complexity, and it does not require turning every application into a Kubernetes workload.

06 / Migration case study

VMware Data Center AWS

For an industrial manufacturing company, we connected workload assessment, selective migration, and operational ownership across the estate. The customer remains anonymous.

186VM workloads
72 TBstorage
40+applications
Keep27 of 18627
Rehost82 of 18682
Replatform31 of 18631
Modernize24 of 18624
Retire14 of 18614
Investigate8 of 1868

Engagement outcome

30% lower three-year infrastructure TCO

A workload-by-workload plan reduced unnecessary migration, addressed oversized capacity, and retained systems with operational constraints.

  • 14 workloads retired instead of migrated.
  • 23 workloads rightsized before placement.
  • 24 workloads selected for application modernization.
  • Six controlled workload waves after the foundation phase.
Read the VMware to AWS Case Study

AAIC migration case studies

Workload Decisions. Modernization. Operations.

Explore our work across industrial manufacturing, B2B software, and hybrid operations. Each case study covers the engineering approach without identifying the customer.

07 / More migration stories

Other AAIC Migration & Modernization Stories

Explore more of our cloud delivery work, including Azure-to-AWS modernization, batch-processing migration, and application operations.

Customer experience management platform

Azure to AWS infrastructure modernization

AAIC's published case study describes EKS, managed PostgreSQL, infrastructure security, and application deployment. It reports 40% operational cost savings for that engagement.

Read the published engagement

Content marketing platform

Rundeck to AWS Batch

The engagement reports a 70% operational cost reduction from batch-processing modernization, with CloudWatch monitoring and workflow automation.

Read the published engagement

Content marketing technology platform

Migration and application operations on AWS

AAIC helped a content marketing platform migrate applications, automate deployments, and modernize operations on AWS, connecting infrastructure change to ongoing application support.

Read the published engagement

08 / Practical answers

VMware Migration FAQs

Workload decisions, cloud and Kubernetes options, migration risk, economics, and operational continuity.

What is VMware migration and modernization?
VMware migration moves applications, virtual machines and data from an existing VMware environment to a chosen destination. Modernization changes selected applications or operating practices rather than simply relocating servers. AAIC’s service starts with workload assessment and destination decisions, then covers migration planning, validation and operational handover. The objective is a supportable environment, not an indiscriminate move of every VM.
Why should an organization evaluate VMware alternatives?
Evaluate alternatives when renewal terms, licensing requirements, hardware refreshes or product lifecycle milestones change the economics or risk of your environment. Compare those pressures with application compatibility, staff skills and the cost of running a replacement. Keeping a supported VMware footprint can still be appropriate. A decision should use your contracts and measured workload demand, not assumed savings or a blanket exit policy.
Do all VMware workloads need to move to the cloud?
No. Some workloads may need to remain on premises because of latency, data residency, hardware dependencies or application vendor restrictions. Others may suit public cloud, another hypervisor or retirement. Separate the decision to reduce VMware dependency from the decision to adopt cloud. Cloud Engineering planning should compare connectivity, security and operating requirements before selecting a destination for each application.
How do you decide which workloads to retain, migrate or modernize?
Build an application inventory with business owners, utilization, dependencies, operating system versions, licensing constraints and recovery requirements. Evaluate each application against business value, technical compatibility, change risk and total operating cost. Record a recommended disposition and the evidence behind it. Use dependency groups to sequence waves, and require application-owner acceptance criteria before approving production moves rather than ranking VMs only by size.
What migration options are available besides a full VMware exit?
Options include retaining supported VMware systems, rehosting on AWS, Azure, or Google Cloud, adopting managed services, and modernizing suitable applications with Kubernetes. Other hypervisors can also be evaluated. Retire unused systems before increasing migration scope. Compare application compatibility, backup and recovery, licensing, connectivity, and team readiness. A mixed destination plan is reasonable when it avoids forcing incompatible applications onto one platform.
Can AAIC migrate VMware workloads to Azure or Google Cloud?
Yes. AAIC supports VMware assessment, migration, modernization, and operations across Azure and Google Cloud as well as AWS. Azure Migrate supports discovery, dependency analysis, assessment, and migration planning. Google Cloud Migrate to Virtual Machines supports moving vSphere VMs to Google Cloud. Destination selection still requires operating-system, application, licensing, network, and recovery validation for the specific estate.
Is Kubernetes a replacement for every VMware virtual machine?
No. Kubernetes is a platform for running containerized applications, not a direct conversion target for every VM. AAIC evaluates application boundaries, state, deployment practices, security, recovery, and operational ownership before recommending containers. Suitable applications can use EKS, AKS, GKE, or an appropriate on-premises platform. The Kubernetes production guidance explains the infrastructure, availability, and management decisions that remain part of the operating model.
Can VMware workloads migrate to AWS without retaining the VMware platform?
Yes. Compatible Windows and Linux workloads can be rehosted to Amazon EC2 rather than running on a VMware platform. AWS Transform supports discovery, migration planning, network configuration transformation and server rehosting. Validate operating system support, application licensing and target architecture first. Automation assists the move; application testing, security review and cutover approval remain explicit responsibilities.
How long does a VMware migration take?
Duration depends on application count, dependency complexity, data volumes, connectivity, change windows and the amount of modernization included. Establish the schedule after discovery and a representative pilot, using measured replication and testing results. Plan time for landing-zone readiness, remediation, business validation and stabilization. A credible estimate identifies assumptions and critical dependencies rather than promising a fixed number of weeks before assessing the estate.
What drives the cost of VMware migration and ongoing operations?
Budget for assessment, migration tooling, engineering, data transfer, temporary parallel environments, testing and staff training. Compare recurring destination costs for compute, storage, networking, software licenses, backup, support and operations. Model utilization and growth instead of copying provisioned VM capacity into a cloud estimate. Include contract overlap and decommissioning costs, and distinguish one-time migration expense from the steady-state operating budget.
What is an AWS Optimization and Licensing Assessment, or OLA?
An AWS Optimization and Licensing Assessment uses resource consumption and licensing information to build a business case for AWS. It can inform rightsizing and licensing choices before migration. AWS describes OLA as a no-cost assessment; confirm availability and scope for your engagement. It is an assessment input, not a substitute for application testing or a guarantee of savings.
What is the AWS Migration Acceleration Program, or MAP?
The AWS Migration Acceleration Program provides a framework covering Assess, Mobilize, and Migrate & Modernize. It brings migration tools, training and potential financial support into a structured AWS transition. For VMware estates, use the phases to connect the business case, platform readiness and migration waves. Program participation does not remove the need for workload decisions, security controls or acceptance testing.
Is AWS migration funding automatic for VMware customers?
No. Treat funding as unconfirmed until AWS reviews the opportunity and confirms applicable eligibility, scope and terms. Ask which activities or credits are covered, what evidence is required and when approval must occur. AWS VMware migration programs describe available assessment and migration routes, but a published program is not an entitlement. Keep the business case viable without assuming an award.
Must applications be rewritten as part of a VMware migration?
No. Rehost applications that are compatible with the destination and do not need immediate architectural change. Apply Application Modernization selectively when unsupported components, scaling constraints, release friction or maintenance costs justify it. Separate mandatory remediation from optional redesign, with independent testing and acceptance criteria. This lets infrastructure change proceed without making every application’s rewrite a prerequisite for the migration.
How are application dependencies handled before migration?
Map communication between application tiers, databases, identity services, DNS, file shares, integrations and scheduled jobs. Combine observed traffic with configuration review and owner interviews so infrequent dependencies are not missed. Group tightly coupled components into migration waves, validate firewall and routing changes, and test business transactions across environment boundaries. Record unresolved dependencies as cutover blockers rather than discovering them after servers have moved.
How do you plan downtime and rollback during cutover?
Agree on an acceptable outage window with business owners, rehearse the cutover and measure final synchronization time. Define entry checks, validation steps, decision owners and a rollback deadline. Account for writes made after switchover: returning traffic to the old environment may require data reconciliation, not just restarting VMs. Zero downtime should not be promised without validating the application’s architecture and replication behavior.
How should disaster recovery change when VMware workloads move?
Re-establish recovery time and recovery point objectives for each application on its destination platform. Check backup compatibility, replication, retention, encryption and recovery access independently of the migration tool. Test restores and application failover, including dependencies such as identity and DNS. Migration replication is not a complete disaster recovery strategy; document failback procedures, ownership and recurring recovery exercises before retiring existing protection.
How do you operate a phased or hybrid environment after migration starts?
Define service ownership across retained VMware systems and new platforms, with common incident escalation, access controls, observability and cost reporting. Establish patching, backup and change procedures for each environment, then retire duplicate tooling when safe. DevOps Engineering and AI Operations can support the operating model. AWS transition guidance also treats operational transformation and team readiness as part of migration, not an afterthought.
When does vSphere 8 support end, and what should we plan for?
Broadcom’s End of Service notice lists October 11, 2027 for ESXi 8.x, vCenter Server 8.x, vSAN 8.x, NSX 4.x and VMware Cloud Foundation 5.2.x. It states that technical support and new patches end for those versions after that date. VVF for VDI licensed environments follow a separate lifecycle. Confirm your exact products and entitlements, then schedule an upgrade, migration or mixed plan with time for testing.

Your next infrastructure decision

Before Your Next VMware Decision, Know Your Options.

Understand what should stay, what should move, what should modernize, and what the resulting environment will cost and require to operate.

Discuss Your VMware Environment Read the VMware to AWS Case Study
Talk to expert