How do you compare AWS migration approaches for a company with its own infrastructure?

How do you compare AWS migration approaches for a company with its own infrastructure?

When you have your own server room or a VMware cluster and ask “how do I move this to AWS”, the real question is not “which tool” but “which approach for which application”. A smaller company rarely migrates everything one way: some systems move as-is, some are worth improving on the way, and a few are worth rebuilding. This article compares the approaches and shows how to fit them to what you actually have in your infrastructure.

The four approaches that really apply

AWS describes the “7 Rs” (rehost, replatform, repurchase, refactor, relocate, retain, retire), but for a company with its own infrastructure four migration decisions matter most. The other three are edge cases: relocate mainly covers moving a whole VMware estate (VMware Cloud on AWS), retain is a deliberate “leave it for now”, and retire is switching off what nobody uses anyway.

A practical rule: start with rehost as the default and move away from it only where replatform or refactor genuinely pays off. Rebuilding everything up front is the most common way migrations overrun and burn budget.

What your infrastructure type changes

“Own infrastructure” is not one thing. The starting point changes which approach is easiest:

• VMware (vSphere). You already have virtual machines, so rehost is natural: a replication tool maps VMs onto EC2 instances. If you want to migrate without rewriting and keep the VMware operating model, VMware Cloud on AWS (relocate) is an option. We set out the full logic in our VMware to AWS migration guide.
• On-premise on physical servers (bare metal). There is no virtualisation layer, so rehost means first capturing a system image and replicating to EC2, or moving the application onto freshly provisioned instances. A good moment to replatform some systems straight away (database on RDS instead of your own server).
• Your own colocation with an expiring contract. The deadline sets the pace: rehost for most, modernise later in the cloud. A predictable cutover matters more than architectural elegance here.
• A mixed estate (some VMware, some bare metal, some SaaS). The most common case. You map application by application, not the whole estate with one approach.

How to decide application by application

Rather than picking one approach for the company, run three questions for each application:

1. Is there a deadline? If yes (end of support, expiring colocation, an audit), rehost takes the pressure off and you modernise later in the cloud.
2. Does maintenance hurt more than the code? If backups, patching and database upkeep eat the most time, replatforming onto managed services pays off immediately, without touching the application.
3. Is the app strategic and holding growth back? Only then does refactor make sense. Rebuilding an app that works and causes no trouble is cost with no return.

What about “own infrastructure versus staying put”? That is a separate decision (retain), not a migration approach. Sometimes the sensible move is to leave a system in place until the next cycle rather than force it into the cloud. A mature migration also knows what not to touch.

Cost and funding

The approach drives migration cost: rehost is the cheapest to run, refactor the most expensive, though it can cut the target bill the most. We set out realistic cost ranges by company size in our article on AWS cloud migration costs and process. Separately it is worth knowing the rehost tools themselves, because the choice can decide the deadline: we compared them in our article on AWS lift-and-shift migration. As an AWS partner we also help secure AWS MAP and PoC funding, which can cover a large share of migration cost.

How Devopsity runs an own-infrastructure migration

Devopsity starts with an inventory: what you have in the server room or on VMware, what depends on what, and which system has which deadline. Then we map applications to approaches (rehost, replatform, repurchase, refactor), set the order and a predictable cutover plan, and deliver and operate the migration itself, not just write it up. Where modernisation makes sense, we do it in the cloud afterwards, on the principle of “move safely first, improve second”. The full scope is on our cloud migration page, and we set out the no-downtime modernisation logic in a separate modernisation guide.

Have your own infrastructure and thinking about AWS?

Book a free 30-minute call. We will review your environment (VMware, on-premise), map your applications to migration approaches, and propose a plan with a predictable cutover.

Book a call Send us a message

Frequently asked questions

How do AWS migration approaches compare for a company with its own infrastructure?

A company with its own infrastructure (VMware, on-premise, bare metal) chooses from four practical approaches to migrating to AWS. Rehost (lift-and-shift) moves systems as-is, fastest and lowest-risk, good under a hard deadline. Replatform moves with small improvements (database to RDS, app to a container on ECS), shedding some operational burden straight away. Repurchase drops your own install for a SaaS service. Refactor rebuilds for the cloud, the longest and most expensive but with the highest payoff, worth it only for strategic applications. You do not pick one approach for the whole estate; you map applications by deadline, maintenance cost and business value. Devopsity runs that decision and delivers the own-infrastructure migration, not just advice.

What is the difference between rehost and replatform in an AWS migration?

Rehost (lift-and-shift) moves a server to AWS as-is, machine by machine, usually with a replication tool; it is the fastest and least risky, but it does not by itself reduce maintenance cost. Replatform moves the application with small improvements on the way, for example a database onto Amazon RDS instead of your own server, or an app into a container on ECS, without rewriting code. Choose rehost when time and predictability matter; choose replatform when you want to hand AWS some of the upkeep straight away (patching, backups, HA), accepting a slightly longer migration.

How do you migrate a VMware environment to AWS?

You usually migrate a VMware environment to AWS by rehost: you already have virtual machines, so a replication tool maps them onto EC2 instances with minimal downtime at cutover. If you want to keep the VMware operating model and migrate without rewriting, VMware Cloud on AWS (the relocate approach) is an option. Good practice is to rehost most machines to hit the deadline, then replatform or modernise selected systems later, in the cloud. Devopsity runs VMware to AWS migrations with dependency inventory and a predictable cutover plan.

Do you have to pick one migration approach for the whole company?

No. For a company with its own infrastructure, combining approaches is the norm: you rehost some applications as-is, replatform some onto managed services, refactor a few strategic ones, and deliberately leave some in place (retain) until the next cycle. The decision is made application by application, looking at the deadline, maintenance cost and business value of each. Trying to rebuild everything at once is the most common cause of migrations that overrun and burn through budget.