How to move from VMware to AWS? Start with this low-risk playbook from Geniusee’s AWS team

By Maksym Hnoinskyi, DevOps Competence Lead & Anton Kolvakh, DevOps Engineer at Geniusee

As AWS experts, we want to start with a fact: the business case for moving from VMware to AWS is hard to ignore.

According to the 2024 IDC Business Value study, organizations running VMware workloads on AWS cloud achieve:

On paper, the decision should be automatic. Yet, in leadership teams across the industry, the migration roadmap often remains frozen in the “planning” phase.

Why? Because for most CTOs, the risk of breaking business-critical workloads outweighs the promise of future efficiency.

We have guided dozens of enterprises through this exact transition, and we see the same pattern every time: the hesitation isn’t about lack of ambition. It stems from a very reasonable fear of disrupting a legacy environment that has quietly run the business for a decade.

If that’s where you are right now, this story is for you.

The reality: “We know we should move… but we’re scared to touch it.”

When a client reaches out to us about Cloud Migration Services, the conversation rarely starts with AWS services. It usually starts with the pain points:

• “We’re spending more and more just to keep the lights on.”
• “Our data center contract is up for renewal, and the numbers are painful.”
• “We want to ship features faster, but infrastructure is a bottleneck.”

Almost nobody says, “We just want the cloud.” What they actually want is lower, more predictable costs, less risk around outages, and a platform that doesn’t conflict with their product roadmap.

At the same time, they are sitting on a massive VMware environment that has been growing for ten years. People have changed roles, documentation is half‑true at best, and everyone knows there are a few legacy systems that nobody fully understands anymore.

Moving all of that to AWS feels like defusing a bomb.

Our approach: Move without breaking your business

So, how do we defuse the bomb? The first thing we tell clients is: 

We’re not going to start by touching your servers. We’re going to start by understanding your story.

Here are 5 steps we use to turn a risky migration into a predictable process:

1. Start with “why”, not “how.”

We’ve made this mistake early in our careers: jumping straight into architecture diagrams, instance types, and migration tools. It felt productive, but it completely skipped the real question: Why are we doing this, and how will we know it was worth it?

Now, we always begin with simple, almost naïve questions:

• What hurts you the most about your current setup?
• What would be a win in a year after the migration?
• What happens if you change nothing for the next couple of years?

The answers are often very specific. A CFO might say they’re tired of black‑box invoices from hosting providers, while a CTO might fear that one old cluster everyone prays over before Black Friday.

Once these motivations are on the table, the migration stops being a purely technical initiative. It becomes a tool to change how the business operates.

2. Make the invisible visible

The most intimidating part of VMware is often the feeling that nobody really sees the whole picture anymore. Before we talk about AWS regions and landing zones, we need to shed some light on the current environment.

This doesn’t mean spending a year on a discovery project. It means gathering just enough truth to make good decisions.

We pull data from vCenter. We look at which VMs exist, how they’re grouped, and what networks and datastores they live on. We add a small amount of automated discovery to see who talks to whom.

And then (this part is critical!) we talk to the people who have been keeping everything alive.

They know which servers are “do not touch” and which ones nobody would miss. At this stage, we aren’t trying to create a perfect configuration management database. We’re trying to build a mental map that says:

• This group of servers is actually one product.
• This database is shared by three different teams.
• This batch job only runs once a month, but if it fails, payroll stops.

We’re slowly turning a dark room full of unknown servers into a landscape you can reason about.

3. Choose how much change you can handle

Once the picture is clear, we can have an honest conversation about how each part of your estate should move.

Strategy A: Relocating (speed first). Sometimes the right move is almost a straight copy into AWS. If the business has a hard deadline (a data center exit, a lease ending, or a vendor contract you don’t want to renew), there simply isn’t enough time to redesign a whole platform.

In these cases, we prioritize speed. We move the workloads “as-is,” but we are clear with stakeholders: This is not the end of the story; it is just the first step.

Strategy B: Modernization (value first). For other systems, the pain is already so big that moving them “as-is” would just move the problem to the cloud. 

Maybe you’re running your own database clusters that constantly keep your team awake at night. Maybe your web app is glued together with manual scripts, and nobody wants to touch it on Fridays. For these, we choose to move to managed databases or containers, or to optimize deployments, even if it requires more time upfront.

For those, we talk about moving to managed databases, or containers, or simplifying deployment, even if it means spending a bit.

4. Build a сloud foundation, people aren’t afraid of

You’ve probably seen landing zone diagrams that look like a subway map. They can be impressive, but they can also be completely unusable for a team just starting its AWS journey.

When we design a landing zone, our goal is simple: make it a place your engineers are comfortable living in, not one they’re afraid to break.

We focus on 3 non-negotiables:

• Isolation. We separate environments so that development experiments can never accidentally touch production.
• Guardrails. Then we implement basic security limits so that it’s hard to make a catastrophic mistake by accident.
• Visibility. We centralize logs and backups so that when something goes wrong, you actually have the data to understand the reason.

We do it in a way that your people can read and change. A beautiful architecture that only exists in a PDF and in our heads is useless. What matters is what’s committed in code, explained in a few pages of docs, and understandable for someone who joins your team a year from now.

Why we avoid “heroic” migrations

There is a certain type of project that always makes us nervous: the huge, all‑or‑nothing migration with an ambitious deadline and a long list of critical systems. It might look impressive in an executive update, but from an engineering and risk perspective, it’s asking for trouble.

Instead, at Geniusee, we aim for something almost boring: small, repeatable waves.

Here is how it works:

1. Pilot: We start with 1 or 2 applications that matter but won’t bring the whole company down if something goes wrong. We run them all the way through: assessment, design, migration, validation, and handover.
2. Calibration: We learn where our process is rough, where the landing zone needs improvement, and where your internal processes need tweaking.
3. Scale-Up: Then we take the next wave. Each wave becomes a bit smoother. The tooling improves. Your team gets more confident. By the time we reach the crown‑jewel systems, the process is no longer an experiment. It’s just what we do.

If a migration feels like a constant adrenaline rush, something is wrong.

Our insight: The best compliment we can get as architects is: “That was surprisingly uneventful.”

Using AWS as a partner (not just a vendor)

There is another part of the story that many companies don’t realize at first: if you work with an AWS partner, they are not just the place where your servers will live. It’s also a co‑investor in your journey.

As a certified AWS Partner, we at Geniusee can help clients tap into specific funding programs. Behind the acronyms is something very practical: AWS can fund part of your assessment, pilots, and migration work if your case fits their criteria.

The two most critical programs are:

• Optimization and Licensing Assessment (OLA). We use this to analyze your actual resource consumption. This often allows us to right-size instances before migrating, preventing you from paying for unnecessary resources.
• Migration Acceleration Program (MAP). For larger migrations, AWS provides credits and cash funding to offset the “double bubble” cost (paying for both on-prem and cloud during the transition).

For you, this means two things:

1. Budget relief. Moving to AWS doesn’t have to be a huge one‑time hit to your cash flow.
2. Validation. You get external proof that the plan we build together makes sense: AWS is willing to support it with their own money.

We love this element because it shifts the project’s tone. It isn’t just “our vendor tells us to move to their cloud.” It becomes: “Here is a concrete plan, supported by tools, funding, and know‑how, to get us from where we are to where we want to be.”

Why migrations often fail after the last VM moves

It’s tempting to think of VMware to AWS migration as a project with a clear end. The last VM moves, the last data center rack is decommissioned, someone rings a bell, and we’re done.

In reality, the day you shut down your old VMware cluster is not the end. It is Day 1 of running your business on a different platform.

This is where many “failed” migrations reveal themselves. If nobody thought about who would operate the new world, you end up with the same incidents, the same guesswork around capacity, and the same stress around change windows, just with a different logo on the console.

When we plan a migration, we always have a second timeline in our heads: how your operations model will change:

• Will your own team run everything using the automation we built together?
• Will we run it for you as a managed service?
• Will we share responsibilities for a while and then gradually hand things over?

There is no one right answer, but there is one thing we are sure about: if we don’t talk about Day‑2 operations early, we’re setting everyone up for disappointment.

So, should you move?

If you’ve read this far, you probably don’t need us to convince you that the cloud has value. You’re likely worried about whether your organization is ready, and whether the move will actually deliver what it promises.

Our honest advice as DevOps engineers is this: don’t start with a big, loud commitment. Start with a clear conversation and a small, bounded experiment.

Before you sign anything:

• Understand what you want to fix in your current world.
• Get a realistic picture of your VMware estate.
• Run an assessment that a non‑technical executive can read in one sitting.
• See exactly what support (and funding) AWS is ready to provide for your case.

Then decide whether now is the right time.

Sometimes the conclusion is “not yet.” Sometimes it’s “yes, but slower than we thought.” And sometimes it’s “we should’ve done this 2 years ago — let’s not waste another one.”

Our job, and the job of our team at Geniusee, is not to push you into the cloud at any cost. It’s to make sure that, if and when you decide to move, you have a path that is technically sound, financially sane, and humanly manageable.

If you’re staring at your VMware dashboard, wondering how to turn it into something less fragile, you’re not alone. And you don’t have to figure it out from scratch. Get in touch with us to discuss your unique case.