If you are evaluating legacy modernization strategies, the short answer is this: rehost when speed and infrastructure cost are your priorities, replatform when you want cloud benefits without a full rewrite, and refactor when the application is business-critical and its current architecture is blocking your roadmap. Most large estates end up using all three, applied selectively per application. The mistake is treating modernization as a single decision instead of a portfolio of decisions.
Below, I walk through how I actually make these calls with clients, the trade-offs each path carries, and a decision framework you can apply to your own estate.
Start With the Reader's Real Problem
Nobody modernizes for its own sake. You are here because one or more of these is true:
- Your data center lease or hardware refresh is forcing a move.
- Licensing and maintenance costs on the old stack keep climbing.
- The application is fragile, and every change risks an outage.
- You cannot hire people who want to work on the current tech.
- The business wants features the current architecture cannot support.
The right strategy depends on which of these pressures dominates. A hardware deadline pushes you toward speed. A roadmap blocker pushes you toward deeper change. Name the primary driver before you compare approaches, because it changes the answer.
The Three Core Cloud Migration Approaches
The "6 Rs" framing from AWS is a useful reference (rehost, replatform, refactor, repurchase, retire, retain). Here I focus on the three that dominate real decisions.
Rehosting ("Lift and Shift")
Rehosting means moving an application to new infrastructure with minimal changes to the code. You take what runs on a physical or virtual server and run it on cloud compute.
When it fits:
- You have a hard deadline (data center exit, acquisition integration).
- The application is stable and you rarely change it.
- You want to stop the bleeding on infrastructure cost first, then optimize later.
What you get: Fast migration, lower project risk, immediate exit from aging hardware.
What you don't get: Cloud-native benefits. A monolith on a large VM is still a monolith. You are paying cloud prices for on-prem architecture, which can actually be more expensive if you don't right-size.
A typical rehost of a virtual machine to a cloud instance looks like this:
# Export existing VM disk, then import to cloud object storage
aws s3 cp legacy-app-disk.vhd s3://migration-staging/
# Import as an image
aws ec2 import-image \
--description "legacy-app rehost" \
--disk-containers "file://containers.json"
# Launch, right-size, and attach existing security groups
aws ec2 run-instances \
--image-id ami-0abc123 \
--instance-type m6i.large \
--security-group-ids sg-0legacyapp
The instance type choice matters. Rehosting without right-sizing is the most common way teams overspend in the first year.
Replatforming ("Lift, Tinker, and Shift")
Replatforming keeps the core application intact but swaps out specific components for managed services. You are not rewriting business logic; you are changing what the application depends on.
Common replatform moves:
- Move a self-managed database to a managed one (for example, self-hosted PostgreSQL to a managed instance).
- Containerize the application and run it on a managed orchestration service.
- Replace a self-managed message broker or cache with a managed equivalent.
When it fits:
- The application is worth investing in but not worth rewriting.
- Operational toil (patching, backups, failover) is eating your team's time.
- You want measurable cloud benefits inside a single quarter.
When I compare rehosting vs replatforming, the deciding factor is usually operational burden. If your team spends its weeks babysitting databases and middleware, replatforming buys that time back. A minimal containerization step often looks like this:
FROM eclipse-temurin:17-jre
WORKDIR /app
COPY target/legacy-app.jar app.jar
# Externalize config so the same image runs across environments
ENTRYPOINT ["java","-jar","app.jar","--spring.profiles.active=${ENV}"]
That single change, externalizing configuration and packaging the app as an immutable artifact, unlocks repeatable deployments without touching business logic.
Refactoring (Re-architecting)
Refactoring means changing the application's structure, often decomposing a monolith into services, adopting event-driven patterns, or rebuilding for elasticity. This is the deepest and most expensive path.
When it fits:
- The application is core to revenue and central to your roadmap.
- The current architecture cannot scale, or cannot ship features fast enough.
- You have the team capacity and stakeholder patience for a multi-quarter effort.
What to watch: Refactoring has the highest failure rate because scope grows. The discipline that keeps it safe is incremental decomposition, not a big-bang rewrite. The strangler fig pattern lets you route traffic to new services one capability at a time while the old system keeps running.
Client → API Gateway
├── /orders → new order service (refactored)
├── /customers → new customer service (refactored)
└── /* → legacy monolith (still serving everything else)
You migrate one route at a time. Each cutover is small, reversible, and independently testable. This is how you get the benefits of refactoring without betting the business on a single release.
A Decision Framework for Legacy Modernization Strategies
I score each application against a short set of questions before choosing a path. You can build this into a spreadsheet across your entire portfolio.
- Business value. Is this application strategic, supporting, or a candidate for retirement? Low-value apps should be retired or rehosted, never refactored.
- Change frequency. How often does the code change? High-change apps justify deeper investment. Frozen apps do not.
- Technical health. Can you build and deploy it today without heroics? Poor health raises the cost of every option.
- Constraint clock. Is there a hard external deadline? Deadlines bias toward rehosting.
- Team capacity. Do you have people who understand the domain and can do the work? Refactoring without domain knowledge fails.
A simple way to read the scores:
- High value + high change + poor architecture → refactor, incrementally.
- Medium value + moderate operational burden → replatform.
- Low change + deadline pressure → rehost, then reassess.
- Low value + low use → retire or retain, do not spend on it.
This portfolio view is the heart of any credible application modernization program. It prevents the two classic errors: over-investing in apps that should be retired, and under-investing in apps that block the roadmap.
Sequencing Matters More Than the Label
The strategies are not mutually exclusive, and they are not permanent. A common and sensible sequence:
- Rehost the estate to exit the data center and hit the deadline.
- Replatform the databases and stateful components to cut operational toil.
- Refactor the two or three applications that actually drive the business.
This staged approach to your digital transformation spreads risk and cost over time, and it lets you fund later stages with the savings from earlier ones. Many teams find their engineering and cloud capabilities are best applied to the refactoring stage, where domain expertise pays off most, while earlier stages are more mechanical.
Sequencing also depends on your sector. Regulated environments have constraints that reshape the plan, which is why we tailor modernization roadmaps by industry context rather than applying one template everywhere.
Common Pitfalls to Avoid
- Right-size after rehosting, not never. Set a calendar reminder. Cloud cost creep is real.
- Do not skip observability. You cannot modernize what you cannot measure. Instrument before you migrate.
- Avoid the big-bang refactor. Use the strangler pattern. Every cutover should be reversible.
- Match the strategy to business value, not engineer enthusiasm. The most interesting technical work is not always the highest-value work.
- Plan for data. Data migration and consistency are usually harder than the compute move.
FAQ
What is the difference between rehosting and replatforming?
Rehosting moves an application to new infrastructure with essentially no code or dependency changes. Replatforming keeps the core application but swaps specific components, such as moving to a managed database or containerizing the app, to gain cloud benefits and reduce operational work. Replatforming takes more effort than rehosting but delivers more durable value.
Is refactoring always better than rehosting?
No. Refactoring is the most expensive and highest-risk path. It only makes sense for applications that are strategic, change frequently, and are constrained by their current architecture. For stable, low-change applications, rehosting or replatforming delivers better return on the effort.
Can I use more than one modernization strategy at once?
Yes, and most large organizations do. Modernization is a portfolio decision. A typical program rehosts most of the estate to meet a deadline, replatforms stateful components to cut toil, and refactors only the handful of applications that drive the business.
How do I decide which strategy to use for a given application?
Score each application on business value, change frequency, technical health, external deadlines, and team capacity. High-value, high-change, poorly-architected apps justify refactoring. Apps with operational burden but sound logic suit replatforming. Stable apps under deadline pressure suit rehosting. Low-value apps should be retired.
Will rehosting to the cloud automatically save money?
Not automatically. If you move an oversized on-prem workload to an equivalently sized cloud instance without right-sizing, you can spend more. Savings come from right-sizing after migration, adopting managed services, and eventually re-architecting for elasticity.
Production-grade cloud, software, and engineering teams for scaling companies.
