Rehost, replatform or refactor: how to choose an AWS migration strategy
“How do we migrate to AWS?” does not have one answer, it has six — and it is normal for three or four of them to coexist in the same company, one per system. Choosing wrong does not break the migration: it makes it twice as expensive or leaves the problems you wanted to solve untouched. This article explains each option by what it demands and what it returns, and gives criteria for deciding without relying on gut feeling.
First: you do not pick one for everything
The most common mistake is treating migration as a single decision. “We are migrating to AWS” translates in practice to deciding, system by system, what happens to each one.
A company with twelve systems might end up retiring three, moving five as-is, improving three along the way, and leaving one where it is. That split is the migration strategy. Any proposal that applies the same recipe to the whole inventory is oversimplifying something that cannot be oversimplified.
The six strategies, by effort and return
| Strategy | Effort | Benefit |
|---|---|---|
| Rehost "lift and shift" | Low | Low to medium |
| Replatform "move and improve a little" | Medium | Medium to high |
| Refactor "redesign" | High | High, but over time |
| Repurchase "switch to a product" | Variable | High if it fits |
| Retain "leave it where it is" | None | Avoids wasted spend |
| Retire "switch it off" | None | Immediate saving |
When each one applies
Rehost "lift and shift"
The server moves as-is to an EC2 instance, without touching the application or the operating system.
When: There is a hard deadline — an expiring datacenter contract, hardware that is dying — or the system is a black box nobody knows how to modify.
Watch out for: Whatever was wrong with the old server comes with you to the cloud. If it was oversized, you pay for that excess every month.
Replatform "move and improve a little"
The application moves, but pieces of infrastructure swap for managed services: the database moves to RDS, files to S3, load balancing to an ELB.
When: The application works fine and you do not want to rewrite it, but you do want to stop administering the database engine and backups by hand.
Watch out for: This is usually where effort and payoff line up best, which is why it is the most common choice for an SMB.
Refactor "redesign"
Parts of the application get rewritten to take advantage of the cloud: containers, serverless functions, queues, splitting into services.
When: The current architecture is itself the problem — it does not scale, every deploy is risky, or cost grows faster than usage.
Watch out for: It is the only one that can truly change the system’s economics, and also the only one that can derail a project. It does not happen during the migration: it happens after, in pieces.
Repurchase "switch to a product"
You drop the in-house system and buy a product that does the same job.
When: What you maintain does not differentiate you from anyone: a homegrown CRM, an intranet, a document manager.
Watch out for: Data migration and the habit change usually cost more than the license. The real saving shows up in year two.
Retain "leave it where it is"
You consciously decide not to migrate that system, for now.
When: There is a legal restriction, a dependency on specific hardware, or the system will be retired within a year and moving it is not worth it.
Watch out for: It is a valid decision, not a defeat. What matters is writing down the reason and a review date.
Retire "switch it off"
It gets shut down because nobody uses it anymore.
When: The inventory reveals servers nobody claims. These show up in almost every initial assessment.
Watch out for: It is the most profitable strategy on the list and the most overlooked. Every system you do not migrate is work you do not do and a bill you do not pay.
Four questions that settle almost every case
Ask these for each system in the inventory, in this order. The first one that gets a clear “yes” usually settles the decision.
1. Does anyone still use it?
Look at access and traffic from the last few months, not anyone's opinion. If nobody uses it: retire. Starting here shrinks the scope of the project before you spend a dollar.
2. Does this differentiate you from competitors?
If it is a generic CRM, an intranet, or a file manager, a product that does it better probably exists: repurchase. Maintaining in-house software that does not set you apart is a permanent cost with no return.
3. Is the current architecture the problem?
If it does not scale, every deploy is scary, or cost grows faster than usage, moving the problem to AWS will not fix it: refactor. But do it after migrating, not during — mixing the two is the most common way a project doubles in length.
4. Is there a date you cannot move?
An expiring contract or failing hardware forces rehost: get out first, optimize later. Without deadline pressure, replatform almost always pays off better.
The pure-rehost trap
Moving everything as-is is tempting: it is the fastest, the cheapest to execute, and generates the least debate. The problem shows up on the first bill.
A physical server gets bought once and then forgotten; being oversized does not hurt every month. In the cloud, it does. A box bought with headroom for five years of growth, replicated as-is onto an EC2 instance, bills that headroom every month from day one.
So if you choose rehost because of a deadline, schedule a rightsizing review for the weeks right after cutover — once you have real usage metrics on AWS and can adjust with data instead of guesses.
What this looks like in a real plan
Once each system has an assigned strategy, the migration gets organized into waves — groups that move together because they share dependencies. It usually looks like this:
- Wave zero: switch off what nobody uses. No risk, and it shrinks everything that follows.
- First wave: secondary systems or test environments. Useful for validating the procedure where a mistake is cheap.
- Middle waves: production, from least to most critical, validating each one before moving on.
- Last wave: the system everything else depends on. It moves last, once the team is trained by the earlier waves.
- Afterward: rightsizing and any refactor work decided earlier, now without cutover pressure.
For databases, continuous replication keeps the source active until the final cutover, so the downtime window is measured in minutes, not hours.
If you have the inventory but are not sure which strategy fits each system, that is exactly the conversation a Migration Readiness Assessment has.
Request a Migration Readiness Assessment