The 6Rs of Cloud Migration: Choosing the Right Strategy for Each Workload

The 6Rs framework provides a structured approach to cloud migration decisions. Originally introduced by Gartner as the “5Rs” and later expanded by AWS, this framework helps organizations categorize applications and choose appropriate migration strategies.

After guiding hundreds of workloads through cloud migrations, we have found that the 6Rs framework prevents the common mistake of treating all applications the same way. This guide explains each strategy and when to apply it.

The 6Rs Overview

Strategy	Description	Effort	Cloud Benefit
Rehost	Lift-and-shift as-is	Low	Limited
Replatform	Lift-and-optimize	Medium	Moderate
Refactor	Re-architect for cloud	High	Maximum
Repurchase	Replace with SaaS	Medium	High
Retire	Decommission	Low	Cost savings
Retain	Keep on-premise	None	None

The key insight is that different applications deserve different strategies. A legacy system scheduled for replacement next year does not warrant the same investment as a strategic platform expected to run for a decade.

Rehost (Lift-and-Shift)

Rehosting moves applications to the cloud with minimal changes. Virtual machines become cloud VMs. Storage becomes cloud storage. The application code remains unchanged.

When to Rehost

Time-constrained migrations - When data center leases expire or business deadlines demand rapid migration, rehosting provides the fastest path to the cloud.

Legacy applications - Applications without source code access, vendor support, or internal expertise for modifications are rehost candidates.

Pre-retirement workloads - Applications scheduled for replacement within 12-24 months do not justify refactoring investment.

Risk-averse scenarios - When stability outweighs optimization, rehosting minimizes change-related risk.

Rehost Example

A traditional three-tier application running on VMware:

Before (on-premise):

2 web servers (Windows Server, IIS)
2 application servers (Windows Server, .NET)
1 database server (Windows Server, SQL Server)

After (rehosted to AWS):

2 EC2 instances (web tier)
2 EC2 instances (app tier)
1 EC2 instance (database) or RDS for SQL Server

# Terraform example for rehosted web tier
resource "aws_instance" "web" {
  count         = 2
  ami           = "ami-windows-server-2022"
  instance_type = "m5.large"
  subnet_id     = aws_subnet.web.id

  tags = {
    Name = "web-server-${count.index + 1}"
    Migration = "rehost"
  }
}

Rehost Tools

AWS:

AWS Application Migration Service for automated VM replication
AWS Database Migration Service for database moves

Azure:

Azure Migrate for discovery and migration
Azure Site Recovery for VM replication

GCP:

Migrate to Virtual Machines for VM migrations

Rehost Limitations

Rehosting provides the least cloud benefit:

No auto-scaling without additional work
No managed service benefits
Similar operational overhead
May be more expensive than optimized deployments

Consider rehosting as a starting point, not an end state. Many organizations rehost first, then optimize incrementally.

Replatform (Lift-Tinker-and-Shift)

Replatforming makes targeted optimizations during migration without changing core application architecture. You swap infrastructure components for managed services while keeping application code largely intact.

When to Replatform

Quick wins available - When managed services can replace self-managed infrastructure with minimal code changes.

Operational burden reduction - Trading self-managed databases, caching, or message queues for managed equivalents.

Moderate modernization budget - When you have some time and resources but not enough for full refactoring.

Containerization candidates - Applications that can be containerized without significant code changes.

Replatform Examples

Database replatforming:

Before: EC2 instance running self-managed MySQL After: Amazon RDS for MySQL or Aurora

Benefits gained:

Automated backups
Point-in-time recovery
Read replicas with minimal effort
Automated patching

Container replatforming:

Before: Application deployed on VMs with manual deployment scripts After: Application containerized and deployed to Amazon EKS or Azure AKS

# Containerize existing application
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

# Deploy to Kubernetes
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: web
        image: myregistry/web-app:latest
        ports:
        - containerPort: 3000
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"

For Kubernetes migrations, containerization during replatforming sets the foundation for future cloud-native improvements.

Caching replatforming:

Before: Self-managed Redis on EC2 After: Amazon ElastiCache or Azure Cache for Redis

Application code changes are minimal (connection string updates), but operational benefits are significant.

Replatform Considerations

Replatforming requires some code changes:

Configuration changes for managed service endpoints
Authentication updates for cloud IAM integration
Minor code adjustments for service-specific features

Budget for testing. Even “minor” changes can introduce issues in production.

Refactor (Re-architect)

Refactoring redesigns applications to take full advantage of cloud-native capabilities. This is the most transformative strategy, yielding the greatest benefits but requiring the most investment.

When to Refactor

Strategic applications - Core business systems expected to run and evolve for years deserve refactoring investment.

Scalability requirements - Applications that need elastic scaling, global distribution, or high availability benefit most from cloud-native architectures.

Feature velocity needs - When faster development cycles are a business priority, microservices and cloud-native patterns help.

Technical debt payoff - Sometimes migration is the right time to address accumulated technical debt.

Refactor Examples

Monolith to microservices:

Before: Single monolithic application handling all business functions After: Decomposed microservices with independent deployment

# Microservices architecture on Kubernetes
# User service
apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: user-service
        image: myapp/user-service:latest
---
# Order service
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
spec:
  replicas: 5
  template:
    spec:
      containers:
      - name: order-service
        image: myapp/order-service:latest
---
# Inventory service
apiVersion: apps/v1
kind: Deployment
metadata:
  name: inventory-service
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: inventory-service
        image: myapp/inventory-service:latest

Serverless refactoring:

Before: Always-on web servers handling API requests After: Serverless functions responding to events

// AWS Lambda function example
export const handler = async (event) => {
  const { orderId } = JSON.parse(event.body);

  // Process order using managed services
  const order = await dynamodb.get({
    TableName: 'orders',
    Key: { orderId }
  }).promise();

  // Publish event for downstream processing
  await sns.publish({
    TopicArn: process.env.ORDER_TOPIC,
    Message: JSON.stringify(order)
  }).promise();

  return {
    statusCode: 200,
    body: JSON.stringify({ status: 'processed' })
  };
};

Event-driven architecture:

Before: Synchronous request-response patterns After: Asynchronous event-driven processing with message queues

This pattern improves resilience, scalability, and decoupling between services.

Refactor Investment

Refactoring requires significant investment:

Development time - Redesigning and rewriting application components
Testing effort - Validating new architecture behaves correctly
Team training - Learning cloud-native patterns and services
Operational changes - New monitoring, deployment, and debugging approaches

Our DevOps consulting services help organizations build the CI/CD pipelines and observability infrastructure that cloud-native applications require.

Refactor Incrementally

Full refactoring does not have to happen at once. The strangler fig pattern allows incremental modernization:

Deploy new microservice alongside monolith
Route specific traffic to new service
Gradually migrate functionality
Eventually retire the monolith

# Incremental traffic routing with Istio
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: orders
spec:
  hosts:
  - orders.myapp.com
  http:
  - match:
    - headers:
        user-type:
          exact: beta
    route:
    - destination:
        host: orders-v2  # New microservice
  - route:
    - destination:
        host: orders-v1  # Legacy monolith

Repurchase (Drop and Shop)

Repurchasing replaces existing applications with commercial off-the-shelf (COTS) products or SaaS solutions. Instead of migrating your CRM, you move to Salesforce. Instead of migrating your email servers, you adopt Microsoft 365.

When to Repurchase

Commodity functionality - When your application provides standard business functionality available from established vendors.

High maintenance burden - When significant effort goes into maintaining functionality available as a service.

Better alternatives exist - When SaaS products offer superior features, security, or compliance capabilities.

Total cost favorable - When SaaS subscription costs are lower than migration and operation costs.

Repurchase Examples

Legacy Application	SaaS Replacement
On-premise CRM	Salesforce, HubSpot
Email servers	Microsoft 365, Google Workspace
HR systems	Workday, BambooHR
Project management	Jira, Asana, Monday.com
Collaboration tools	Slack, Microsoft Teams
Business intelligence	Tableau Cloud, Power BI

Repurchase Considerations

Data migration complexity - Moving data to new platforms requires mapping, transformation, and validation.

Integration requirements - SaaS products need integration with remaining systems via APIs.

Change management - Users need training on new tools and workflows.

Vendor lock-in - SaaS subscriptions create dependency on vendor pricing and roadmaps.

Compliance verification - Ensure SaaS providers meet your regulatory requirements.

Repurchase and Integration

Modern repurchasing often requires integration work:

// Example: Integrating Salesforce CRM with internal systems
const salesforce = require('salesforce');
const internalAPI = require('./internal-api');

// Sync customer data from internal system to Salesforce
async function syncCustomer(customerId) {
  const customer = await internalAPI.getCustomer(customerId);

  await salesforce.sobject('Account').upsert({
    External_Id__c: customer.id,
    Name: customer.companyName,
    Website: customer.website,
    Industry: customer.industry
  }, 'External_Id__c');
}

Retire

Retiring means decommissioning applications that are no longer needed. Migration projects often reveal redundant, outdated, or unused applications.

When to Retire

No business value - Applications that serve no current business purpose.

Duplicate functionality - When multiple applications do the same thing, retire the inferior ones.

Usage analytics - Applications with minimal or no active users.

Post-acquisition consolidation - Redundant systems from merged organizations.

Retire Discovery Process

Usage analysis:

-- Identify least-used applications by login frequency
SELECT
  application_name,
  COUNT(DISTINCT user_id) as unique_users_30d,
  MAX(login_time) as last_login
FROM application_access_log
WHERE login_time > NOW() - INTERVAL '30 days'
GROUP BY application_name
ORDER BY unique_users_30d ASC;

Cost analysis:

Infrastructure costs (servers, storage, licenses)
Support costs (tickets, maintenance)
Integration costs (APIs, data feeds)

Risk assessment:

Data retention requirements
Compliance obligations
Business continuity implications

Retire Benefits

Retirement provides immediate benefits:

Cost reduction - Eliminate infrastructure and licensing costs
Security improvement - Fewer systems to secure and patch
Reduced complexity - Simpler environment to manage
Migration scope reduction - Fewer applications to migrate

Organizations typically find 10-20% of applications can be retired during migration assessment.

Retain

Retaining means keeping applications on-premise, at least temporarily. Not everything should move to the cloud immediately.

When to Retain

Compliance constraints - Regulations requiring data to remain in specific locations or environments.

Latency requirements - Applications requiring ultra-low latency to on-premise systems.

Recent investments - Hardware or software purchased recently with significant remaining value.

Complex dependencies - Applications deeply integrated with systems that cannot migrate.

Mainframe workloads - Legacy mainframe applications not practical to migrate.

Retain Strategies

Temporary retention: Plan to migrate later when:

Compliance frameworks evolve
Cloud offerings mature
Business priorities shift
Technical debt is addressed

Hybrid architecture: Connect retained applications to cloud resources:

# AWS Site-to-Site VPN for hybrid connectivity
Resources:
  VPNGateway:
    Type: AWS::EC2::VPNGateway
    Properties:
      Type: ipsec.1

  VPNConnection:
    Type: AWS::EC2::VPNConnection
    Properties:
      Type: ipsec.1
      CustomerGatewayId: !Ref CustomerGateway
      VpnGatewayId: !Ref VPNGateway
      StaticRoutesOnly: false

Long-term retention: For applications that will remain on-premise indefinitely:

Document the decision rationale
Plan for ongoing maintenance
Ensure connectivity to cloud services
Review periodically for changed circumstances

Applying the 6Rs Framework

Portfolio Assessment

Assess your entire application portfolio before migration:

Inventory applications - Document all applications, their purpose, and owners
Gather metrics - Collect usage, cost, and dependency data
Interview stakeholders - Understand business value and future plans
Score applications - Rate on complexity, strategic value, and migration readiness
Assign strategies - Match each application to appropriate 6R strategy

Decision Matrix

Use criteria to guide strategy selection:

Criteria	Rehost	Replatform	Refactor	Repurchase	Retire	Retain
Time constraint	High	Medium	Low	Medium	High	N/A
Budget	Low	Medium	High	Medium	Low	Low
Strategic value	Low	Medium	High	Varies	None	Varies
Technical debt	Deferred	Partial	Addressed	Eliminated	N/A	Deferred
Cloud benefits	Minimal	Moderate	Maximum	High	Cost save	None

Migration Waves

Group applications into migration waves:

Wave 1: Quick wins

Simple rehost candidates
Low-risk applications
Team learning opportunities

Wave 2: Core modernization

Replatform candidates
Important but not critical systems
Building migration competency

Wave 3: Strategic transformation

Refactor candidates
Business-critical applications
Maximum cloud benefit targets

Wave 4: Cleanup

Remaining rehost migrations
Final retirements
Hybrid architecture completion

Our cloud migration services guide organizations through this entire assessment and execution process.

Common Mistakes

Over-engineering

Mistake: Refactoring everything when simpler strategies suffice.

Reality: Not every application deserves microservices. A simple internal tool used by 10 people does not need the same architecture as your customer-facing platform.

Under-investing

Mistake: Rehosting strategic applications that deserve refactoring.

Reality: Saving money on migration by rehosting often costs more long-term in operational overhead and missed cloud benefits.

Skipping assessment

Mistake: Starting migration without portfolio analysis.

Reality: Migration projects regularly discover applications that should be retired, saving significant effort. Assessment is not overhead; it is essential.

Ignoring dependencies

Mistake: Migrating applications without mapping dependencies.

Reality: An application migrated before its dependencies can fail in production. Map dependencies and migrate in the right order.

One-size-fits-all

Mistake: Applying the same strategy to all applications.

Reality: The 6Rs exist because different applications have different needs. Use the framework to make intentional choices for each workload.

Summary

The 6Rs framework provides a vocabulary and structure for cloud migration decisions:

Rehost for speed with minimal change
Replatform for quick wins with moderate effort
Refactor for maximum cloud benefits with significant investment
Repurchase for commodity functionality better served by SaaS
Retire for applications that no longer provide value
Retain for workloads that should stay on-premise

Success comes from applying the right strategy to each application based on business value, technical complexity, and organizational constraints.

Need Help with Cloud Migration Strategy?

We help organizations assess application portfolios and execute cloud migrations using the 6Rs framework. Our cloud migration services include discovery, strategy development, and migration execution across AWS, Azure, and GCP.

Book a free 30-minute consultation to discuss your cloud migration strategy.