Cloud Migration: 6R Approach Guide
A manufacturing company wanted to "move everything to the cloud." After analyzing their 120 applications, we found: 15% should be retired, 25% should stay on-premises, 40% should be rehosted (lift-and-shift), and only 20% would benefit from cloud-native redesign.
Their original plan would have cost $800,000/year in cloud fees. Our 6R analysis brought it down to $320,000/year — while actually improving performance for the workloads that truly belonged in the cloud.
The 6R framework is the most practical tool for cloud migration decisions. Here's how to use it.
What is the 6R Framework?
[Architecture Diagram: /images/blog/cloud-migration.svg]
The 6R framework, originally defined by Gartner and refined by AWS, categorizes every workload into one of six migration strategies:
Rehost (lift-and-shift): Move as-is to cloud infrastructure.
Replatform (lift-and-optimize): Move with minor optimizations.
Refactor (re-architect): Redesign for cloud-native architecture.
Repurchase (drop-and-shop): Switch to a SaaS alternative.
Retire: Decommission applications no longer needed.
Retain: Keep on-premises for now.
The key insight: not every workload should be migrated. The goal is to put each workload in the right place, not to move everything to the cloud.
Strategy 1: Rehost (Lift-and-Shift)
What it means: Move the VM as-is from on-premises to cloud IaaS (EC2, Azure VMs). No code changes, no architecture changes. Just change the hosting platform.
Effort: Low (days to weeks per application).
Cost: Low migration cost, moderate ongoing cloud cost.
When to use:
Legacy applications with no cloud-native path.
Time-sensitive migrations (data center lease expiring).
Applications that work fine as-is but need to move off aging hardware.
Real example: A law firm moved 30 file servers from on-premises to AWS EC2 in 2 weeks. No code changes. The servers work exactly the same — just running on AWS instead of Dell hardware. Cost: $3,000/month in EC2 fees vs $15,000/year in hardware refresh.
Watch out: Rehosted applications don't get cloud-native benefits (auto-scaling, managed services). You're just renting someone else's server.
Strategy 2: Replatform (Lift-and-Optimize)
What it means: Move to cloud with minor optimizations. Not a full redesign, but take advantage of managed services where it's easy.
Effort: Medium (weeks to months per application).
Cost: Moderate migration cost, lower ongoing cost than rehosting.
When to use:
Applications that can benefit from managed databases (RDS, Azure SQL).
Workloads that can use managed file storage (EFS, Azure Files).
Applications where swapping components is low-risk.
Real example: A hospital moved their ERP database from on-premises SQL Server to AWS RDS (managed SQL Server). Same application, same SQL queries, but AWS handles patching, backups, and HA. Saved 40% on database administration.
Watch out: Replatforming can introduce subtle compatibility issues. Test thoroughly.
Strategy 3: Refactor (Re-architect)
What it means: Redesign the application for cloud-native architecture. Break monoliths into microservices, use containers (ECS/EKS), serverless (Lambda), and cloud-native databases.
Effort: High (months to years per application).
Cost: High migration cost, lowest ongoing cost.
When to use:
Applications with high scaling requirements (web apps, APIs).
When the current architecture can't meet performance or cost targets.
When you have budget and time for a proper redesign.
Real example: An e-commerce platform refactored from a monolithic PHP application to microservices on Kubernetes. Deployment frequency went from monthly to daily. Auto-scaling handled 10x traffic spikes automatically. Ongoing cost dropped 60% after the refactor.
Watch out: Refactoring is expensive and risky. Only do it for high-value applications with clear ROI.
Strategy 4: Repurchase (Drop-and-Shop)
What it means: Replace your custom application with a SaaS alternative. Don't migrate the app — replace it.
Effort: Medium (data migration + user training).
Cost: SaaS subscription replaces custom development/maintenance costs.
When to use:
Custom CRM → Salesforce.
Custom HR system → Workday or BambooHR.
Custom email → Microsoft 365 or Google Workspace.
Real example: A 200-person company replaced their custom-built HR system (10 years old, barely maintained) with BambooHR. Implementation took 4 weeks. Ongoing cost: $8/user/month vs $50,000/year in maintenance.
Watch out: SaaS means less customization. If your custom app has unique business logic, SaaS may not cover it.
Strategy 5: Retire
What it means: Decommission applications that are no longer needed.
Effort: Low (audit + shutdown).
Cost: Zero migration cost. Saves ongoing maintenance costs.
When to use:
Applications with zero or very few users.
Duplicate applications (two systems doing the same thing).
Legacy apps replaced by newer systems but never decommissioned.
Real example: During a 6R assessment, we found a 500-person company running 87 applications. 22 had zero active users. Retiring them saved $180,000/year in licensing and maintenance.
Watch out: Retiring applications requires stakeholder buy-in. Someone "owns" every app, and they may resist retirement.
Strategy 6: Retain
What it means: Keep the application on-premises for now. Revisit in 6-12 months.
Effort: Zero.
Cost: No change.
When to use:
Applications with data sovereignty requirements that cloud can't meet yet.
Recently upgraded applications (don't migrate right after a major investment).
Applications with unclear business value (need more analysis).
Real example: A bank's core banking system was recently upgraded at a cost of $2M. Retaining it on-premises for 3 more years makes financial sense. Cloud migration will be evaluated in 2027.
How to Apply 6R to Your Applications
Here's our step-by-step process:
Inventory: List all applications. Include owner, users, dependencies, and current infrastructure.
Assess: For each application, evaluate business value, technical complexity, and cloud readiness.
Categorize: Assign each application a 6R strategy. Use the decision tree: Is it needed? → Retire or Retain. Is there a SaaS alternative? → Repurchase. Can it run as-is? → Rehost. Can it be optimized? → Replatform. Should it be redesigned? → Refactor.
Prioritize: Start with quick wins (Retire, Rehost). Build momentum. Save Refactor for high-value applications.
Execute: Migrate in waves. Each wave = 5-10 applications. Test, validate, optimize, then move to the next wave.
Best Practices
Don't force everything into one strategy. The power of 6R is that different workloads get different treatments.
Start with Retire and Retain. These are zero-effort decisions that immediately clarify your migration scope.
Rehost first, refactor later. Get to the cloud quickly with rehosting. Optimize in place over time.
Estimate total cost of ownership (TCO) for each strategy. The cheapest migration isn't always the cheapest long-term.
Involve application owners early. They know their apps best and will be key to successful migration.
Conclusion
The 6R framework prevents the #1 cloud migration mistake: treating every workload the same. Some apps should be retired. Some should stay on-premises. Some should be rehosted. Only a few benefit from full refactoring.
Start by inventorying your applications. Apply the 6R framework. You'll likely find that 20-40% of your portfolio doesn't need to move to the cloud at all — and that realization saves you hundreds of thousands of dollars.
Want to go deeper? Explore [Run infrastructure services](/en/products/run), [industry solutions](/en/solutions), or [contact our team](/en/contact).
FAQ
Q: How long does a 6R assessment take?
A: For a 50-application portfolio: 2-4 weeks. For 200+ applications: 6-8 weeks. The assessment itself is the most valuable part — it prevents costly migration mistakes.
Q: Can an application use multiple 6R strategies?
A: Not simultaneously, but over time. You might rehost first, then refactor later as the business case justifies it. The strategy is a snapshot in time.
Q: What tools help with 6R assessments?
A: AWS Migration Acceleration Program (MAP), Azure Migration Program, and third-party tools like Cloudamize and Turbonomic provide automated discovery and assessment.
Q: What's the biggest risk in cloud migration?
A: Underestimating complexity. Rehosting looks easy but can reveal hidden dependencies. Refactoring looks ambitious but may be necessary for cost optimization. The 6R framework helps you make informed decisions.
Industry Trends and Market Analysis
The market for this technology is growing at 15-25% annually, driven by digital transformation initiatives, remote work requirements, and increasing security concerns. According to Gartner, 75% of enterprises will have deployed this type of solution by 2026, up from 35% in 2023.
Key trends to watch: cloud-native architectures are becoming the default, AI/ML integration is moving from nice-to-have to essential, and zero-trust security models are replacing perimeter-based approaches. Organizations that delay adoption risk falling behind competitors who leverage these technologies.
Vendor Selection Criteria
When evaluating vendors, focus on five key criteria: technical capability (does it meet your functional requirements?), scalability (can it grow with your organization?), support quality (what is the SLA and response time?), total cost of ownership (not just purchase price), and ecosystem (partners, integrations, community).
We recommend creating a weighted scoring matrix with these criteria. Assign weights based on your priorities (e.g., if support is critical, give it 30% weight). Score each vendor on a 1-5 scale for each criterion. The vendor with the highest weighted score is usually the best fit.
Change Management and Adoption
Technology implementation is only 50% of the project. The other 50% is change management. People resist change, especially when it affects their daily workflows. Invest in communication, training, and support to ensure adoption.
Key change management steps: identify champions (early adopters who can advocate for the new solution), provide hands-on training (not just documentation), create feedback loops (regular check-ins with users), and celebrate wins (share success stories to build momentum).