Your legacy systems still pay the bills. They also page you at 3 a.m., resist every change you try to make, and quietly fail audits you didn’t know you had. Keeping them running gets more expensive every quarter, and the people who understand them are leaving.
So at some point you decide to move to AWS. The trap is treating that as one decision. It isn’t. Every application in your portfolio deserves its own answer, and the most useful map for those answers is AWS’s 6 Rs: Rehost, Replatform, Refactor, Repurchase, Retire, and Retain.
Here’s what each one actually means, when it’s the right call, and where it tends to bite.
The 6 Rs of Modernization
Rehost (lift-and-shift)
Pick up the app, drop it on EC2, change as little as possible. No code rewrites, no new architecture, just a new home.
It’s the fastest way to vacate a data center, and sometimes that deadline is the whole point. If a lease is expiring or hardware is dying, rehost gets you out.
The catch is that you’ve moved your problems, not solved them. A VM that was inefficient on-prem is an inefficient VM on EC2, except now you’re paying for it by the hour. Rehosting buys you time, not cloud benefits. Plan a second pass to actually optimize, or your bill will remind you.
Replatform (lift, tinker, shift)
Same idea as rehost, but you make a few targeted swaps on the way in. The classic move is taking a self-managed database off a VM and putting it on Amazon RDS or Aurora, so you stop babysitting backups, patching, and failover yourself.
This is the sweet spot for a lot of workloads. You get real operational wins (managed backups, automated patching, multi-AZ) without committing to a rewrite. Other common swaps: pushing static assets to S3, or moving a container off a hand-built host onto ECS.
Refactor / re-architect
Rewrite the thing to be cloud-native. Break the monolith into services, move to containers on ECS or EKS, pull event-driven pieces into Lambda. This is the most work, and the most reward.
You refactor when the existing architecture is the actual problem: it can’t scale past a certain point, it can’t ship features fast enough, or a single deploy means downtime for everyone. Those constraints don’t go away with a lift-and-shift. They follow you.
Just be honest about the cost. Refactoring is real engineering time and real risk, so reserve it for the apps where the payoff is worth it. Not everything earns a rewrite.
Repurchase (replace)
Kill the in-house app and buy a SaaS product that does the job. The thing you’ve been maintaining for six years might be a solved problem someone else sells for a monthly fee.
This is usually the right call for commodity functions: CRM, HR, payroll, ticketing. If your differentiation isn’t in that code, every hour you spend maintaining it is an hour you’re not spending on what makes you money.
Retire
Turn it off. A surprising share of any portfolio is apps nobody uses, duplicates of duplicates, and services kept alive by inertia. They still cost you in compute, licenses, attack surface, and the audits they drag into scope.
Inventory everything. Whatever has no users and no dependents, shut it down. It’s the cheapest “modernization” you’ll ever do.
Retain
Leave it alone, on purpose. Some apps aren’t worth moving yet: low business value, a looming vendor change, a dependency that isn’t ready, or a compliance situation you don’t want to disturb mid-flight.
Retain is a legitimate choice, not a failure to decide. The danger is “retain by default,” where an app sits untouched because nobody owns the decision. Put a review date on it so it stays a choice.
How to Decide Which R Fits
The right R for an app comes from its constraints, not from whatever’s trendy. A few factors carry most of the weight:
- Cost. Do you need a quick win now, or can you invest up front for lower run-rate later?
- Timeline. Is a hard date (lease, end-of-support, contract) forcing the schedule?
- Compliance. Do HIPAA, PCI DSS, or SOC 2 dictate specific architecture, encryption, or data residency?
- Scalability. Does this app need to handle real growth or global traffic, or is it flat and predictable?
- Innovation. Is there genuine value in moving to serverless or managed services, or is that just resume-driven design?
Run every significant app through those questions. You’ll often find that one portfolio needs four different Rs, and that’s the correct outcome.
Common Mistakes
- One R for everything. Re-architecting every app is as wrong as lift-and-shifting every app. The portfolio is mixed; the strategy should be too.
- Treating compliance as a later problem. Bolting HIPAA or PCI controls on after the fact is expensive rework. Design IAM, encryption, and logging in from the start.
- Lifting and shifting, then walking away. Rehosting without a follow-up optimization pass is how a migration “saves money” right up until the AWS bill lands.
- Making it an IT-only project. Which apps matter, which can die, and what compliance applies are business decisions. Engineers shouldn’t be guessing at them alone.
A Real Example
A healthcare startup came to us with a legacy app handling sensitive patient data. Single deploys meant downtime, scaling was manual, and the compliance story was thin enough to scare off enterprise customers.
One R wasn’t enough. We replatformed the data tier onto AWS managed services and refactored the critical paths: the processing-heavy components moved to Lambda, the long-running services moved to containers on ECS. HIPAA and SOC 2 controls (encryption, access boundaries, audit logging) were part of the design from the first commit, not patched in later.
The result was faster, lower-risk deploys, scaling that no longer needed a human, lower run costs, and a compliance posture they could put in front of customers without flinching.
Build the Right Roadmap
The 6 Rs aren’t a ranking, and refactoring isn’t the “winning” answer. They’re six honest options, and a good modernization plan uses several of them across the same portfolio. The work is matching each app to its real constraints: cost, timeline, compliance, and whether the architecture is actually holding you back.
Not sure how your portfolio sorts out? That assessment is most of what we do. We help teams build modernization roadmaps grounded in AWS best practices, so the plan fits the systems you actually have. Talk to our experts and let’s map it out.