Every AWS blog explains what the 7 Rs are. The hard part is not understanding them. It is choosing the wrong one and discovering the cost six months later.
I have been through multiple cloud migrations. Rehosted monoliths that tripled our cloud bill. Replatformed databases that looked seamless until load testing. Refactored pipelines that took nine months but paid for themselves in the first year. Each migration taught me that the framework itself is easy. The decisions inside it are where teams get burned.
This guide skips textbook definitions. Every R below is grounded in a real project with actual numbers.
The 7 Rs at a Glance
| Strategy | When to Use | Risk to Watch | Timeline |
|---|---|---|---|
| Rehost | Deadline-driven lift-and-shift | Cloud bill surprise | Days-weeks |
| Replatform | Managed services swap | Hidden config complexity | Weeks |
| Repurchase | Commodity workloads (CRM, HR) | Vendor lock-in, integration debt | Weeks-months |
| Refactor | Cloud-native transformation | Long commitment, rollback risk | Months |
| Retire | Unused or redundant apps | Stakeholder resistance | Days |
| Retain | Compliance/regulatory constraints | Stagnation if not reviewed | Ongoing |
| Relocate | VMware-heavy, regulated infra | Rarely long-term | Weeks |
The rest of this post covers the six Rs I have worked with firsthand. Relocate is acknowledged in the table but omitted below because I have no first-person experience to draw from.
Rehost: Fast, Until the Bill Arrives
Rehosting is the fastest path to “we’re in the cloud.” Lift the server image, drop it on EC2, call it done. The problem shows up later.
One team I worked with rehosted a monolith overnight to hit a go-live deadline. Six months later the cloud bill was 3x what anyone expected. The monolith had been provisioned for peak on-prem capacity, meaning it sat idle at roughly 15% utilization most of the day. On-prem, that idle capacity was already paid for. In the cloud, it was metered.
The fix took longer than the migration itself. Right-sizing instances and moving batch workloads to Lambda brought costs down to about 60% of the original on-prem spend. Good outcome, but only because someone budgeted for a Phase 2 optimization effort.
Key lesson: rehost is a starting line, not a finish line. Budget Phase 2 optimization from day one, or plan to pay 2-3x what you expected.
For specific Lambda cost techniques, see AWS Lambda Cost Optimization: Practical Tips.
Replatform: The Middle Ground That Hides Gotchas
Replatforming swaps self-managed components for managed services without rearchitecting the application. It sounds like the safe middle ground. Usually it is, until configuration surface area bites you.
We swapped self-hosted Redis for ElastiCache. On paper, a seamless drop-in. Same protocol, same client library, same data structures. What we missed: maxmemory-policy defaults differed, connection timeout behavior changed in cluster mode, and eviction patterns under load diverged from what our application expected.
Surface metrics looked fine. CPU, memory, throughput all normal. But P99 latency spiked intermittently under sustained load. It took weeks to diagnose because we assumed “managed” meant “no tuning required.”
Key lesson: managed services remove operational burden but introduce config surface area you did not have before. “Managed” does not mean “zero effort.” Allocate time for config tuning and load testing before cutting over.
Repurchase: The SaaS Bet
Repurchasing replaces a custom-built tool with a SaaS equivalent. For commodity capabilities like CRM, ticketing, or HR, this often makes sense. The real risk is not the subscription cost. It is integration debt.
The pattern I have seen: a team replaces an internal tool with a SaaS product that handles 90% of the use cases beautifully. The remaining 10% requires custom integration with existing systems. That glue code costs more in engineering time than the subscription saves in the first year.
Key lesson: evaluate the integration surface before committing. If the SaaS product cannot connect cleanly to your existing systems through standard APIs, the total cost of ownership is higher than it appears on the pricing page.
Refactor: The Biggest Payoff, If You Can Afford It
Refactoring means rearchitecting for cloud-native. It is the slowest, most expensive option upfront and the one that pays off the most over time, if the investment window is long enough.
We refactored a media processing pipeline into serverless microservices. The result: 90% reduction in ops overhead. But it took nine months, three rounds of user testing, and multiple rollback plans to get there.
Along the way we learned every serverless constraint the hard way. Lambda’s 15-minute execution ceiling forced us to break long-running jobs into chains. Memory-CPU coupling meant we could not optimize one without affecting the other. The 10GB /tmp limit shaped how we handled intermediate files. Some workloads that needed sustained throughput moved to Fargate instead of Lambda.
The cost model shifted too. Predictable monthly server bills became variable per-invocation charges. That was mostly good, except for logging. CloudWatch Logs ingestion cost 2.3x what Lambda compute cost until we tuned log retention and switched verbose debug logging to sampled mode.
Key lesson: refactoring unlocks real savings, but only if you budget for the learning curve. Serverless constraints are well-documented. The surprise is how they compound when you hit three or four of them in the same workflow.
For more on the serverless vs container decision, see Serverless vs Containers: A Decision Framework. For Lambda-specific parallelism patterns, see Parallel Processing in AWS Lambda with Python.
Retire: The Easiest Win Nobody Wants to Do
Retiring applications is the highest-ROI migration activity. No architecture, no testing, no rollback plan. Just turn it off. The hard part is never technical. It is political.
We found 12 unused applications costing roughly $8K per year. Every one of them had a “what if we need it” champion. Someone in the org who remembered a time, years ago, when that app mattered.
The breakthrough was data. We pulled utilization metrics: zero requests in 90 days, zero active users, zero downstream dependencies. Presented to leadership as a simple table. Twelve apps, twelve rows of zeros, $8K/year. Approval took one meeting.
Key lesson: run a utilization audit before migration planning begins. Every app you retire is one fewer to migrate, secure, and maintain in the cloud.
Retain: Sometimes the Best Migration Is No Migration
Retain gets treated as the “do nothing” option. It is not. It is a deliberate architectural decision, often the right one when compliance, regulatory, or latency constraints make migration impractical.
A financial client retained their mainframe for batch clearing. Regulatory requirements mandated specific processing guarantees that no cloud service could certify at the time. Instead of forcing a migration, we wrapped APIs around the mainframe to expose data to cloud-native services. The application layer modernized. The compliant core stayed put.
A different constraint drove a similar outcome with AWS China. Cross-partition replication between aws and aws-cn does not exist. ICP filing requirements and data residency laws meant China infrastructure had to stay in aws-cn. The solution was a serverless pull model that synced data across partitions without forcing either side to migrate. For the full architecture, see A Serverless Bridge Between AWS Global and AWS China.
Key lesson: retain is a deliberate decision, not avoidance. Build adapters to connect retained systems with modern services. Review annually to check if the constraints still hold.
Migration Decision Checklist
Before you assign an R to any application, walk through these questions:
- Have you inventoried every application and its dependencies? If not, stop here.
- Is a hard deadline driving the migration? Rehost now, optimize later.
- Is this a commodity capability (CRM, ticketing, HR)? Evaluate repurchase.
- Has anyone touched this application in 90 days? If no, retire it.
- Do compliance, regulatory, or latency constraints prevent migration? Retain and wrap with APIs.
- Is the long-term goal cloud-native? Replatform or refactor based on available time and budget.
- Are you mixing strategies across your portfolio? You should be. Most migrations use three or more Rs.
Key Takeaways
- Rehost is a starting line, not a finish line. Budget Phase 2 optimization or expect to pay 2-3x what you projected.
- Managed services are not zero-effort. Config surface area bites hardest during load testing.
- Retire before you migrate. Every unused app cut is one fewer to move, secure, and maintain.
- Retain is a strategy, not avoidance. Compliance and regulatory constraints are valid reasons to stay put.
- No migration uses a single R. Your portfolio will span three or more strategies. Plan for that from the start.
Discussion
Comments are powered by GitHub Discussions. Sign in with GitHub to join the conversation.