Beyond "Lift and Shift"
The conversation about cloud migration has matured significantly over the past decade. Early migrations were dominated by lift-and-shift approaches: take what is running on premises and run it on virtual machines in the cloud. While this gets workloads to the cloud quickly, it often fails to deliver the cost savings and agility benefits that motivated the migration in the first place.
A mature cloud migration strategy recognizes that different workloads deserve different approaches. The framework most widely used to categorize these approaches is the "6 R's" model, originally articulated by Gartner and refined by AWS.
The 6 R's of Cloud Migration
Rehost (Lift and Shift)
Rehosting moves applications to the cloud with minimal or no changes. Virtual machines become EC2 instances or Azure VMs. The application code, configuration, and architecture remain the same.
When to rehost:
- Data center exit with a hard deadline (lease expiration, hardware end-of-life)
- Applications that will be retired or replaced within 12 to 24 months
- Applications with complex, undocumented dependencies where refactoring risk is high
- As a first step before optimization (get to cloud, then modernize)
Limitations:
- Does not leverage cloud-native services
- May cost more than on-premises due to always-on VM pricing
- Does not improve scalability, resilience, or operational efficiency
Replatform (Lift, Tinker, and Shift)
Replatforming makes targeted optimizations during migration without changing the core architecture. Examples include moving a self-managed MySQL database to Amazon RDS, or replacing a file-based session store with ElastiCache.
When to replatform:
- Applications that would benefit from managed services but do not need architectural changes
- Databases that can move to managed equivalents (RDS, Cloud SQL, Azure SQL Database)
- Applications where operational burden (patching, backups, scaling) is a significant pain point
Common replatforming moves:
- Self-managed databases to managed database services
- Application servers to managed container platforms (ECS, AKS)
- File storage to object storage (S3, Blob Storage)
- Self-managed message queues to managed services (SQS, Azure Service Bus)
Refactor (Re-architect)
Refactoring involves rearchitecting the application to take full advantage of cloud-native capabilities. This might mean decomposing a monolith into microservices, adopting serverless computing, or redesigning for horizontal scalability.
When to refactor:
- Applications with strong business cases for cloud-native benefits (auto-scaling, global distribution, event-driven architecture)
- Applications that will be actively developed for many years
- When the current architecture fundamentally limits the application's ability to meet business requirements
Caution: Refactoring is the most expensive and risky migration strategy. It should be reserved for workloads where the investment is clearly justified by long-term business value.
Repurchase (Drop and Shop)
Repurchasing replaces an existing application with a SaaS alternative. For example, replacing a self-hosted CRM with Salesforce, or replacing a self-hosted email server with Microsoft 365.
When to repurchase:
- When a mature SaaS product exists that meets your requirements
- When the operational burden of running the application exceeds the value of customization
- When the application is not a competitive differentiator
Considerations:
- Data migration complexity
- Integration requirements with other systems
- Customization limitations of the SaaS product
- Long-term SaaS subscription costs vs self-hosted costs
Retire
Retirement involves decommissioning applications that are no longer needed. Migration projects frequently reveal applications that are redundant, unused, or replaceable by functionality in other systems.
When to retire:
- Applications with no active users
- Redundant applications (three different project management tools when one would suffice)
- Applications whose functionality has been absorbed by other systems
Retiring applications reduces migration scope, lowers costs, and simplifies the overall portfolio. Organizations typically find that 10 to 20 percent of their application portfolio can be retired.
Retain (Revisit Later)
Some applications should stay on premises, at least for now. Valid reasons to retain include:
- Regulatory requirements that prohibit cloud hosting
- Applications with extremely low latency requirements to on-premises equipment
- Applications nearing end-of-life that do not justify migration investment
- Mainframe workloads where migration is technically complex and costly
The Assessment Process
Application Discovery and Portfolio Analysis
Before deciding how to migrate, you need a complete picture of what you have:
TCO Analysis: Avoiding Common Pitfalls
Total Cost of Ownership analysis is essential but frequently misleading:
Common TCO pitfalls:
- Ignoring operational costs: On-premises TCO must include staff time for patching, hardware maintenance, capacity planning, and incident response. These costs are real but often not tracked at the application level.
- Comparing list prices: Cloud pricing is complex. On-demand pricing is the highest tier. Realistic TCO projections should include reserved instance discounts, savings plans, and architectural optimizations.
- Forgetting data transfer costs: Moving data to the cloud is free. Moving it out can be expensive. If your workloads generate significant egress traffic, factor this into the analysis.
- Ignoring migration costs: The migration itself has costs: planning, execution, testing, training, and the temporary period of running both environments simultaneously.
- Assuming 1:1 mapping: A 16-core, 128GB on-premises server does not necessarily need a 16-core, 128GB cloud instance. Right-sizing during migration can significantly reduce costs.
Hybrid Considerations
For many enterprises, the end state is not 100% cloud. Hybrid architectures that span on-premises and cloud environments are common and valid:
- Data gravity: Large data stores may be expensive to move. Processing near the data, whether on-premises or in the cloud, may be more cost-effective than moving everything.
- Regulatory constraints: Some data or workloads may need to remain on-premises for compliance reasons.
- Latency requirements: Applications that need low-latency access to on-premises equipment (manufacturing systems, medical devices) may need to remain close to that equipment.
Migration Wave Planning
Migrations should be organized into waves that respect application dependencies and organizational capacity:
Wave 1: Quick Wins
Start with applications that are low-risk and have minimal dependencies:
- Standalone web applications
- Development and testing environments
- Internal tools with small user bases
The goal of Wave 1 is to build organizational experience and confidence, not to tackle the hardest problems first.
Wave 2: Foundation Services
Migrate shared services that other applications depend on:
- Active Directory / identity services (or establish cloud-native identity)
- DNS and networking infrastructure
- Monitoring and logging platforms
- Shared databases
Wave 3: Business Applications
With foundation services in place, migrate business applications in order of priority, respecting dependency chains.
Wave 4: Complex Workloads
Tackle the most complex migrations last, when your team has the most experience:
- Mission-critical applications with high availability requirements
- Applications with complex integration landscapes
- Large databases with stringent performance requirements
After Migration: Optimization
Migration is not the finish line. Post-migration optimization is where cloud economics improve:
- Right-size based on actual utilization data: After 30 to 60 days in the cloud, review utilization metrics and adjust instance sizes.
- Adopt managed services incrementally: Replace self-managed components with managed equivalents as operational patterns stabilize.
- Implement auto-scaling: Configure auto-scaling for workloads with variable demand.
- Optimize storage tiers: Move infrequently accessed data to cheaper storage classes.
- Review architecture: Now that you are in the cloud, evaluate whether architectural changes could improve cost efficiency and performance.
Tags
EaseOrigin Editorial
EaseOrigin Team
The EaseOrigin editorial team shares insights on federal IT modernization, cloud strategy, cybersecurity, and program delivery drawn from real-world project experience.
