Lift with MGN
AWS Application Migration Service handles replication and cutover for stable workloads that need to exit VMware now.
Cloud Migration & Modernization
Exit VMware to AWS. Modernize While You Go.
Broadcom's VMware licensing changes forced a decision every infrastructure leader is working through. If AWS is the target, the question is no longer whether to go, but how to make the move count.
We deliver VMware-to-AWS migrations that land workloads on native AWS services - not on another virtualization layer - so the move you are forced to make becomes the modernization you have been planning.
AWS Advanced Consulting Partner. Engineer-led migrations. Modernization-first, not lift-and-shift.
.png)
.png)
.png)
.png)
The Opportunity
VMware's exit window is also a modernization window
Broadcom's licensing changes created an industry-wide reckoning. Organizations that were content with vSphere are being pushed to make strategic decisions they had not planned to make, on timelines they did not choose.
The Challenge
The reflex response is lift-and-shift: move VMware workloads somewhere else, run them the same way, minimize disruption. But this preserves every architectural problem the workloads had before the migration.
3x to 10x VMware licensing cost increases
Lift-and-shift preserves operational debt
Monolithic applications and over-provisioned VMs travel with workloads
Manual runbooks and three-tier topologies remain unchanged
Our Approach: Migrate with MGN. Modernize Into Native AWS.
We design VMware-to-AWS migrations around three questions answered workload-by-workload: what does this application really need, what does AWS already provide, and what is the right path to get there.
Refactor with App2Container
Extract .NET and Java applications from VMs, containerize, and deploy to ECS or EKS with modern pipelines.
Replatform to Managed Services
Move SQL Server to RDS, file shares to S3/FSx, and message queues to SQS - eliminating VM overhead.
Replace with Cloud-Native
For workloads approaching end-of-life, use the VMware exit as the moment to replace rather than move.
How We Deliver
Four-phase approach from portfolio discovery to decommission.
1
Portfolio Discovery & Strategy
2-4 weeks. Inventory VMware estate, classify workloads by migration pattern, and sequence into waves.
2
AWS Foundation
2-6 weeks. Landing zone, networking, security baseline, and observability foundation.
3
Wave-Based Migration
6-18 months. Execute lifts, refactors, and replatforms in sequenced waves with full testing and validation.
4
Decommission & Optimize
Progressive VMware environment drawdown with post-migration optimization and operational handoff.
What This Engagement Covers
Complete migration from VMware to native AWS services.
Application Portfolio Discovery
Inventory of VMware estate, dependencies, traffic flows, and workload-level migration plan with patterns assigned.
AWS Target Architecture
Account structure, VPC design, IAM baseline, and foundation services coordination.
Migration Wave Execution
MGN lifts, App2Container refactors, managed-service replatforms, and data migrations with full testing.
Outcomes
- Workloads running as native AWS services, not virtualized layers
- Elimination of VMware licensing costs and operational overhead
- Modern container-based deployment pipelines for refactored applications
- Managed service benefits: elasticity, cost optimization, reduced operations
Ideal Fit
- VMware estates of 50+ VMs with licensing pressure or upcoming renewals
- Mixed workload types where one-size-fits-all lift-and-shift leaves value on the table
- Organizations willing to invest in modernization during migration
- Teams that want AWS engineering depth, not just project management
Migration Patterns
The right pattern for each workload type
Most real-world portfolios use all four patterns. The value is making the pattern choice deliberately rather than by default.
Lift with MGN
Fast Exit
AWS Application Migration Service for stable workloads that need to exit VMware immediately.
Best Fit
Stable applications, well-understood workloads, speed matters more than architectural change.
Tradeoffs
Preserves existing architecture and operational patterns.
IVI Recommendation
Right for workloads where modernization investment is not justified by the roadmap.
Recommended
Refactor with App2Container
Best ROI
Extract .NET and Java applications from VMs into containers with modern deployment pipelines.
Best Fit
.NET or Java applications with straightforward deployment, container-based future intent.
Tradeoffs
Requires more engineering effort but delivers better long-term outcomes.
IVI Recommendation
Consistently delivers the best outcome-to-effort ratio we see.
Replatform to Managed Services
Operational Reduction
Move databases, queues, file services to AWS managed equivalents.
Best Fit
SQL Server, Oracle, file shares, message queues, schedulers.
Tradeoffs
May require application connection string changes.
IVI Recommendation
Eliminates VM overhead while gaining managed service benefits.
Replace with Cloud-Native
Strategic Reset
Use VMware exit as the moment to replace rather than move end-of-life applications.
Best Fit
Applications approaching end-of-life, SaaS alternatives available.
Tradeoffs
Highest effort but can deliver transformational business outcomes.
IVI Recommendation
Only recommended when economics and application roadmap align.
Why IVI
Modernization-first, not lift-and-shift by default
AWS Advanced Consulting Partner with Application Engineering Depth
We work at the application layer - refactoring, containerization, database migration - rather than handing that work off to subcontractors.
Engineering Approach
Every engagement starts with workload-by-workload analysis. We don't assume modernization is always right, but we don't default to lift-and-shift because it's easier to scope.
Aegis Continuity
The same engineers who migrate your workloads can operate them under Aegis co-managed services, ensuring operational knowledge stays with the people who built the environment.
Honest About the Hard Parts
VMware exits are not easy. Some applications won't migrate cleanly. Some dependencies will surface mid-project.
Realistic Planning
We plan for complexity, communicate when it happens, and price the work honestly rather than promising fixed outcomes that ignore application reality.
Proven Methodology
Our four-pattern approach (lift, refactor, replatform, replace) has been tested across hundreds of VMware workloads and diverse application portfolios.
Heading
A popup in HTML refers to a small window that appears on top of a web page. It's commonly used to display additional information, alerts, or interactive content without navigating away from the current page.
Related Resources
Related Resources
Review related solution pages, supporting materials, and additional resources that help explain where this solution fits and how it can be applied.
FAQs
Frequently Asked Questions
Common questions about VMware to AWS migration and modernization.
How long does a typical VMware-to-AWS migration take?
A mid-market portfolio of 200-500 VMs typically runs 9-15 months from kickoff to final decommission, including modernization. Lift-only migrations of smaller portfolios can complete in under six months. Larger estates scale the timeline proportionally.
Do we have to modernize every workload?
No. We recommend the right pattern for each workload. For most portfolios, a blend of lift, refactor, and replatform produces better outcomes than forcing one pattern across everything. Some workloads are appropriate to lift and leave.
What about workloads that cannot migrate to AWS?
Some workloads have genuine constraints: latency-bound clinical systems, licensing tied to physical hardware, regulatory requirements that demand on-prem residency. We identify these early and coordinate with our Aegis Hybrid Infrastructure service for modernized on-prem alternatives.
Can we use VMware Cloud on AWS as an interim step?
Yes, and for some portfolios VMware Cloud on AWS is the right interim destination. We deploy it when it fits: typically for workloads that need to exit on-premises VMware urgently but are not yet candidates for refactoring. It becomes a staging ground for incremental modernization.
How do you handle our existing Microsoft licensing?
Depends on the agreement. Some workloads benefit from License Mobility to AWS. Others are better served by subscription-based licensing on AWS. SQL Server workloads frequently benefit from the move to RDS or Aurora in both cost and operational terms. We include license strategy in the portfolio analysis phase.
Will IVI operate the AWS environment after migration?
Yes, if you want us to. Our Aegis co-managed services model covers AWS operations, or we can run a co-managed model where your team operates day-to-day with IVI engineering depth on call. Or we can hand off cleanly and leave. All three patterns are common.