Moving to the cloud is rarely a single decision. It's a portfolio of decisions, made application by application, workload by workload. The biggest mistake I see organisations make is treating cloud migration as a single project with a uniform approach — then wondering why their cloud bill is three times higher than their old data centre.
The 6 R's framework — originally articulated by Gartner and popularised by AWS — gives you a vocabulary for these decisions. This article explains each strategy, when to use it, and how to sequence them into a coherent migration programme.
Why Strategy Matters More Than Technology
The cloud isn't inherently cheaper, faster, or more secure than on-premises infrastructure. The potential value — lower TCO, elastic scale, global reach, managed services — only materialises when you migrate strategically.
The most common (and expensive) mistakes
- Lift-and-shift everything: Moving monolithic apps to VMs often results in cloud bills 2–3× higher than the original data centre cost, because cloud pricing rewards elasticity you never configured.
- Over-engineering early: Rebuilding a simple internal tool as Kubernetes microservices wastes months that should go to product.
- Under-investing in security: On-premises network controls don't follow you to the cloud. New attack surfaces appear and most teams discover this during an incident.
The right strategy matches the migration approach to the business value and technical complexity of each workload. That's the entire job.
The 6 R's at a Glance
← Less change / effortMore change / effort →
Decision Framework: Which R Do You Choose?
Before diving into each strategy, use this decision tree to quickly classify each application:
| Ask yourself… | If No | If Yes |
|---|---|---|
| Is this app still needed? | Retire it | Continue → |
| Does a mature SaaS product exist? | Continue → | Repurchase |
| Do you have a strict timeline? | Continue → | Rehost first, optimize later |
| Is the infra painful but core app OK? | Continue → | Replatform |
| Does scale/velocity require rearchitecting? | Retain for now | Refactor |
Start with discovery, not strategy
Before classifying a single application, invest 2–4 weeks in portfolio discovery. Inventory every running application, identify owners, measure actual usage, and document dependencies. Most organisations are surprised to discover that 15–25% of their estate can simply be retired.
The 6 R's in Depth
1. Rehost ("Lift and Shift")
Move the application to the cloud with minimal changes — same code, same architecture, now running on a managed VM.
When it makes sense:
- You have a hard deadline (data centre exit, lease expiry)
- The workload is stable, low-risk, and doesn't justify investment now
- You have limited cloud expertise and need early wins
- The application is a candidate for deeper optimisation after migration
What you gain immediately: Managed hardware, automated snapshots, geographic redundancy, SLA-backed uptime, pay-as-you-go billing for idle capacity.
What you don't gain yet: Elasticity, managed services, cloud-native cost optimisation. A lift-and-shift is the beginning of cloud value, not the destination.
Cost impact: Roughly neutral. You eliminate hardware refresh cycles and data centre overheads, but don't yet benefit from auto-scaling or right-sizing. Revisit 6–12 months post-migration.
Key tooling: Azure Migrate, AWS Application Migration Service (MGN), Google Migrate for Compute Engine.
"Lift then optimise" is a legitimate two-step strategy
For organisations under time pressure, it's entirely valid to rehost first and refactor later. Document the decision so the follow-on work gets scheduled, not forgotten.
2. Replatform ("Lift, Tinker, and Shift")
Make targeted optimisations during migration — without changing the core architecture. The application itself stays largely the same; the infrastructure layer evolves.
Common replatforming moves:
- Self-managed database → Azure SQL Managed Instance, Amazon RDS, or Cloud SQL
- Self-managed message broker → Azure Service Bus, Amazon SQS/SNS
- Bare-metal deployment → containerised workloads (without changing app code)
- Self-hosted caching → Azure Cache for Redis, ElastiCache
When it makes sense:
- Specific infrastructure layers are painful to manage and managed equivalents exist
- Your team lacks the operational bandwidth to run databases, queues, or caches at scale
- You want meaningful operational improvements without a full refactor
The scope creep risk: Replatforming projects have a habit of expanding. Engineers discover adjacent improvements and the project grows. Define a clear scope boundary upfront and log anything out of scope as a future backlog item.
Cost impact: Moderate positive. Managed services typically reduce operational overhead significantly. Database licensing costs often drop substantially when moving to managed PaaS vs. SQL Server Enterprise.
3. Refactor ("Re-architect")
Fundamentally rethink the application to take full advantage of cloud-native capabilities. This is the highest-effort, highest-reward option.
What refactoring typically involves:
- Breaking a monolith into independently deployable services
- Adopting serverless compute (Azure Functions, AWS Lambda, Cloud Run)
- Event-driven architecture using cloud-native messaging (Event Hub, Kinesis, Pub/Sub)
- Stateless, horizontally-scalable application design
- API-first design with proper contract versioning
When it makes sense:
- The current architecture cannot support your growth targets
- Development velocity is severely constrained by architectural coupling
- The workload is revenue-critical and the business case is clear
- You have the engineering capacity and a realistic timeline
The refactor trap
Refactoring projects are notorious for running 2–3× over schedule. Common failure modes: scope creep ("while we're in here..."), underestimating dependency complexity, and insufficient testing investment. Use the Strangler Fig pattern — route traffic to the new system incrementally while the old one remains live — rather than attempting a big-bang cutover.
Cost impact: Done correctly, this is where the real cloud economics live. Auto-scaling, serverless pricing, and right-sized compute can reduce infrastructure costs by 40–70% for the right workloads, while simultaneously improving performance.
Key architectural patterns: Strangler Fig, CQRS, Event Sourcing, Saga pattern for distributed transactions.
4. Repurchase ("Drop and Shop")
Replace the existing application with a commercial SaaS product.
Classic examples:
- Custom-built CRM → Salesforce / HubSpot
- On-premises HR system → Workday / BambooHR
- Self-hosted email → Microsoft 365 / Google Workspace
- Custom analytics → Snowflake + Looker / Power BI
- Self-hosted Git → GitHub / GitLab SaaS
When it makes sense:
- The application provides no competitive differentiation
- A mature SaaS product covers 80%+ of your requirements
- Your total cost of ownership (TCO) for maintaining the system exceeds SaaS pricing
- Your team's time is better invested in differentiating systems
The change management challenge: Technology is often the easy part. People resist new tools. Budget for change management, user training, and a transition period where both systems run in parallel. Data migration and integration costs are real and frequently underestimated.
Data portability: Before committing, evaluate the SaaS vendor's data export capabilities. Vendor lock-in is a legitimate concern; assess your exit strategy before signing.
5. Retire
Identify applications that are no longer needed and decommission them.
This is pure, unambiguous value.
Every retired application is one fewer system to:
- Migrate and maintain
- Patch and secure
- Pay cloud hosting costs for
- Onboard new engineers to
You have more to retire than you think
In every portfolio discovery exercise I've run, between 10 and 25% of applications are candidates for retirement. Check your access logs — many applications have zero or near-zero active users. People stopped using them years ago; no one ever turned them off.
Before retiring: Document what the application does, confirm with stakeholders that it's truly unused, verify any regulatory retention requirements for the underlying data, and archive the codebase.
6. Retain ("Revisit")
Decide not to migrate certain workloads — at least for now.
Legitimate reasons to retain:
- The application was just rebuilt or significantly upgraded
- Genuine technical constraints: sub-millisecond latency requirements, specialised hardware (GPU clusters, FPGA, HSM)
- Regulatory mandates that require data to remain in your own physical infrastructure
- The migration business case is genuinely weak
This is not the same as "too hard." If the reason for retaining is complexity or lack of capacity, that needs to be scheduled, not indefinitely deferred. Document why you're retaining, and set a calendar review date.
Building Your Migration Portfolio
In practice, a mid-sized organisation's migration programme might classify its estate like this:
| Application | Strategy | Rationale |
|---|---|---|
| ERP system | Repurchase | No differentiation; vendor taking over maintenance burden |
| Core product API | Refactor | Revenue-critical; current architecture blocks scale |
| Internal tooling suite | Rehost | Low priority; engineering capacity needed elsewhere |
| Legacy reporting portal | Retire | Superseded by new BI platform; zero active users |
| Customer portal | Replatform | Migrate DB to managed service; containerise deployment |
| Edge processing system | Retain | Sub-10ms latency requirement; cloud latency unacceptable |
| Self-hosted email | Repurchase | Microsoft 365 covers all requirements |
Score each application
Assess every application on two dimensions: business value (revenue impact, user count, strategic importance) and technical complexity (age, dependencies, documentation quality). This creates a portfolio matrix that makes prioritisation defensible to stakeholders.
Migration Wave Planning
Once you've classified your portfolio, sequence migrations into waves:
- →Retire unused apps
- →Rehost stable workloads
- →Start portfolio visibility
- →Replatform DB/queue layers
- →Repurchase commodity apps
- →IaC for rehoseted workloads
- →Refactor revenue-critical systems
- →Serverless/event-driven architecture
- →Cost optimisation pass
The sequencing principles:
- Retire first — Before spending a single hour on migration, shut down everything that can be shut down. Shrink the problem.
- Rehost quick wins — Early momentum builds organisational confidence and demonstrates progress to leadership.
- Don't start your riskiest Refactor in Wave 1 — Use early waves to build cloud operational competence.
- Migrate dependencies before dependants — Map your dependency graph and sequence accordingly.
- Never migrate interconnected critical systems simultaneously — Maintain rollback capability at all times.
What the Discovery Phase Looks Like
Every migration programme I've led starts with a proper discovery phase. This typically takes 2–4 weeks and includes:
- Application inventory: Every running application, its business owner, its tech stack, and its last active deployment
- Usage analysis: Log analysis to identify actual user counts and traffic patterns
- Dependency mapping: Network and application-level dependency graphs
- Technical assessment: Code quality, documentation, test coverage, infrastructure configuration
- Business value scoring: Revenue impact, user count, strategic importance, regulatory scope
This upfront investment prevents the far more expensive mistake of migrating applications in the wrong order or with the wrong approach — and it builds the shared understanding that migration decisions require across business and technology stakeholders.
Cloud migration strategy is one of my core areas of practice. If you're planning a migration programme or evaluating your cloud estate, I'm happy to review your portfolio and help you build a prioritised migration roadmap. Let's talk.