The debate over lift and shift versus refactoring is one of the most persistent in cloud migration planning. It’s also frequently framed as a binary choice when it shouldn’t be. Most organizations will do both — the question is which approach applies to which workload, and in what order.
Getting this decision wrong is expensive. Over-refactoring adds months to migration timelines and cost that’s difficult to justify. Under-refactoring leaves organizations running cloud-hosted versions of on-premises architecture, missing most of the benefits of moving to AWS in the first place.
The AWS 6 Rs Framework
AWS describes migration strategies across six options, commonly called the 6 Rs. Understanding the spectrum matters more than debating the two extremes:
- Rehost (Lift and Shift): Move the application as-is to AWS infrastructure. Fastest and lowest risk. No code changes, no architecture changes — same application, different hardware.
- Replatform (Lift, Tinker, and Shift): Make targeted optimizations during migration without changing core architecture. Example: moving from self-managed MySQL to Amazon RDS while keeping the application layer unchanged.
- Refactor / Re-architect: Redesign the application to take advantage of cloud-native capabilities. Highest investment, highest return. Typically involves moving to microservices, serverless, or managed services like Lambda and Aurora.
- Repurchase: Replace the existing application with a SaaS alternative. Often the right answer for CRM, HR, and productivity tools.
- Retire: Decommission applications that no longer serve a business purpose. Discovery typically reveals 10-20% of an application portfolio can be retired rather than migrated.
- Retain: Keep specific workloads on-premises, at least temporarily. Appropriate for applications with regulatory constraints, recent hardware investments, or complex dependencies.
When Lift and Shift Makes Sense
Rehosting gets unfairly maligned. For the right workloads, it’s exactly the right choice. Lift and shift is appropriate when:
The application is stable and not a candidate for modernization in the near term. The primary goal is data center exit or cost reduction on hardware. The application has complex dependencies that make refactoring risky. The organization needs to move quickly and can optimize later.
The “optimize later” caveat is important. Many organizations rehost first and refactor selectively over the following 12-24 months, after they’ve had time to understand their usage patterns in AWS. This phased approach reduces risk while still realizing cloud economics.
When Refactoring Earns Its Investment
Refactoring makes sense when the application is a core business system with active development investment, when scaling requirements exceed what a rehosted architecture can handle cost-effectively, or when cloud-native services offer a material capability advantage.
The clearest signals that refactoring is worth it: the application is expensive to scale horizontally in its current form, it has variable traffic patterns that would benefit from serverless or auto-scaling architectures, or it’s a competitive differentiator where faster deployment cycles have real business value.
Refactoring a legacy batch processing application that runs nightly and never changes is rarely worth it. Refactoring a customer-facing application that your development team touches daily and that needs to handle unpredictable load spikes often is.
A Practical Decision Framework
For each workload in your migration portfolio, answer three questions:
- How frequently does this application change? (Infrequent = rehost; frequent = refactor candidate)
- What are the scaling requirements? (Predictable/modest = rehost; variable/aggressive = refactor)
- What’s the cost of getting it wrong? (Mission-critical with complex dependencies = rehost first, refactor later)
The output is a migration wave plan where quick-win rehosting candidates move first, generating cloud cost savings that fund subsequent refactoring investments.
Executing the Strategy
Migration strategy decisions are easier to make on paper than in practice. The application portfolio analysis required to apply the 6 Rs framework properly takes expertise and tooling that most organizations don’t have in-house — which is exactly what a Migration Readiness Assessment addresses before a single workload moves.
As an AWS Premier Tier Partner, Opti9 brings over a decade of migration experience across industries. We’ve executed lift-and-shift migrations at speed and complex re-architecture projects, and we know which approach applies where.
Get in touch to discuss the right migration strategy for your application portfolio.
