Skip to main content
⚡ Calmops
🤖 AI 🏗️ Architecture 🌐 Web 🗃️ Database ⚙️ DevOps 🌍 Network 💻 Programming 🧮 Algorithms 📐 Software Eng. ☁️ Cloud 🔒 Security 📈 Finance More →

Cloud Migration Strategies: The Complete Guide to the 6 R's

Created: March 5, 2026 CalmOps 12 min read

Introduction

Cloud migration one of the most represents significant technology transformations organizations undertake in the modern era. Whether moving from on-premises data centers, legacy hosting environments, or even between cloud providers, the decisions made during migration profoundly impact operational efficiency, cost structures, and future flexibility. Yet many organizations underestimate the complexity of migration planning, treating it as a simple lift-and-shift exercise when in reality, successful migrations require strategic decision-making for each workload.

The “6 R’s” of cloud migration provide a structured framework for evaluating and deciding how to migrate each application and workload. Originally formulated by Gartner and subsequently popularized by Amazon Web Services, these six strategies—Rehost, Replatform, Refactor, Repurchase, Retire, and Retain—offer a comprehensive decision matrix that accounts for business requirements, technical constraints, cost considerations, and strategic objectives.

Understanding when to apply each migration strategy is critical. A poorly chosen migration approach can result in underutilized cloud resources, missed optimization opportunities, or worst-case scenario—failed migrations that waste significant time and money. Conversely, thoughtful application of the appropriate migration strategy for each workload maximizes cloud benefits while minimizing disruption and risk.

This comprehensive guide examines each of the six migration strategies in detail, providing practical guidance on when to use each approach, the tools and services available to support implementation, and common pitfalls to avoid. Whether you are planning your first migration or looking to optimize an existing cloud transformation program, this guide provides the knowledge necessary to make informed decisions.

Understanding Cloud Migration

Cloud migration is the process of moving digital assets—applications, data, workloads, and IT processes—from on-premises infrastructure or legacy hosting environments to cloud computing platforms. This transformation extends beyond simple infrastructure relocation; it often involves modernization, optimization, and sometimes complete re-architecture of applications to leverage cloud-native capabilities.

Why Migrate to the Cloud?

Organizations pursue cloud migration for various strategic reasons:

Cost Optimization: Cloud computing transforms capital expenditure into operational expenditure, eliminating the need for upfront hardware purchases and reducing ongoing data center operational costs. The pay-as-you-go model allows organizations to align costs with actual usage.

Scalability and Elasticity: Cloud platforms provide on-demand scalability, enabling organizations to handle traffic spikes without over-provisioning and scale down during quiet periods. This elasticity is particularly valuable for businesses with variable workloads.

Agility and Speed: Cloud environments enable faster provisioning of resources, reducing the time from concept to deployment. Development teams can spin up new environments in minutes rather than weeks.

Global Reach: Major cloud providers maintain data centers worldwide, enabling organizations to deploy applications closer to customers regardless of geographic location.

Managed Services: Cloud providers offer managed versions of complex systems—databases, caching, search engines, machine learning—that dramatically reduce operational burden.

The Migration Challenge

Despite the clear benefits, cloud migration presents significant challenges. Legacy applications often have dependencies that make cloud migration complex. Data transfer times can be substantial for large datasets. Applications may require modification to function optimally in cloud environments. And organizations must maintain business continuity throughout the migration process.

The key to navigating these challenges lies in strategic planning—specifically, evaluating each workload individually and selecting the appropriate migration strategy based on a clear understanding of requirements, constraints, and objectives.

The Six Migration Strategies

Each of the six migration strategies represents a different approach to moving workloads to the cloud, with distinct tradeoffs between speed, cost, complexity, and long-term cloud optimization. Understanding these tradeoffs is essential for making informed decisions.

1. Rehost (Lift and Shift)

Rehosting involves moving applications to the cloud without making any changes to the application itself. This approach essentially lifts the application from its current environment and shifts it to equivalent cloud infrastructure—virtual machines in AWS EC2, Azure Virtual Machines, or Google Compute Engine.

Rehosting is the fastest way to get applications running in the cloud, making it attractive for organizations under time pressure or those seeking quick wins in their migration program. Because no code changes are required, rehosting carries the lowest technical risk of all migration strategies.

# Example: AWS VM Import/Export for rehosting
aws ec2 import-image \
    --description "WindowsServer2012-R2" \
    --disk-containers file://containers.json

# containers.json contents:
# [
#   {
#     "Description": "Windows 2012 R2 VMDK",
#     "Format": "vmdk",
#     "UserBucket": {
#       "S3Bucket": "my-bucket",
#       "S3Key": "windows2012.vmdk"
#     }
#   }
# ]

However, rehosting provides limited cloud optimization benefits. Applications run on virtual machines much as they would on physical servers, without leveraging cloud-native features like auto-scaling, managed services, or serverless execution. Many organizations treat rehosting as an initial step, planning to optimize (replatform or refactor) applications after migration.

When to Choose Rehosting:

  • Tight migration timelines requiring rapid deployment
  • Applications approaching end-of-life that warrant minimal investment
  • Lift-and-shift as an interim step before modernization
  • Applications with complex dependencies that make modification risky
  • Proof-of-concept migrations to validate cloud viability

Considerations:

  • Limited cost savings compared to cloud-native architectures
  • May require license optimization to avoid increased costs
  • Security configurations need review for cloud environment
  • Operational monitoring requires additional configuration

2. Replatform (Lift, Tweak, and Shift)

Replatforming involves making targeted modifications to applications to take advantage of cloud capabilities without fully re-architecting the application. This approach strikes a balance between migration speed and cloud optimization.

Common replatforming modifications include migrating from self-managed databases to managed database services, adjusting storage configurations to use cloud object storage, or implementing auto-scaling based on workload patterns.

# Example: Migrating from self-managed MySQL to Amazon RDS
# Before: EC2 instance with MySQL
# After: Amazon RDS for MySQL with Multi-AZ deployment

# Terraform configuration for RDS replatforming
resource "aws_db_instance" "main" {
  identifier           = "mydb"
  engine               = "mysql"
  engine_version       = "8.0"
  instance_class       = "db.t3.medium"
  allocated_storage    = 100
  storage_encrypted    = true
  multi_az             = true
  backup_retention_period = 7
  skip_final_snapshot  = true
  
  # Managed service benefits:
  # - Automated backups
  # - Automatic patching
  # - High availability
  # - Performance insights
}

Replatforming typically delivers 20-40% cost savings compared to rehosting while requiring modest additional effort. It represents a pragmatic approach for organizations seeking tangible cloud benefits without undertaking risky re-architecture projects.

When to Choose Replatforming:

  • Applications running on legacy database infrastructure
  • Workloads requiring basic cloud optimizations like auto-scaling
  • When moving to managed services reduces operational overhead
  • Moderate timeline allowing for targeted modifications
  • Applications with reasonable cloud compatibility

Considerations:

  • Requires assessment of current application dependencies
  • Database migration may require schema compatibility review
  • Some replatforming changes can introduce unexpected complications
  • Benefits are limited compared to full refactoring

3. Refactor (Re-architect)

Refactoring involves re-architecting applications to fully leverage cloud-native capabilities. This approach fundamentally changes how applications are designed, often breaking monolithic applications into microservices, implementing serverless components, or adopting cloud-native data architectures.

Refactoring is the most resource-intensive migration strategy, requiring significant development effort and carrying the highest technical risk. However, it also offers the greatest long-term benefits in terms of scalability, cost optimization, and operational efficiency.

// Example: Refactoring monolithic application to microservices
// Before: Single monolithic Node.js application
// After: Multiple microservices using AWS Lambda and API Gateway

// Order Service (Serverless)
const AWS = require('aws-sdk');
const dynamodb = new AWS.DynamoDB.DocumentClient();

exports.createOrder = async (event) => {
    const order = JSON.parse(event.body);
    
    const params = {
        TableName: 'orders',
        Item: {
            orderId: order.id,
            customerId: order.customerId,
            items: order.items,
            total: order.total,
            status: 'PENDING',
            createdAt: new Date().toISOString()
        }
    };
    
    await dynamodb.put(params).promise();
    
    return {
        statusCode: 201,
        body: JSON.stringify({ message: 'Order created', orderId: order.id })
    };
};

// Product Service
const productParams = {
    TableName: 'products',
    // Products managed independently
};

// Customer Service  
const customerParams = {
    TableName: 'customers',
    // Customer data separated for security
};

Refactoring decisions should be based on clear business value—typically driven by requirements for massive scale, rapid feature development, or fundamental architectural improvements that the current system cannot support.

When to Choose Refactoring:

  • Applications requiring massive horizontal scalability
  • When decomposing monoliths into microservices provides business value
  • Legacy applications needing comprehensive modernization
  • Greenfield projects building on cloud-native principles
  • When cloud-native features are core to competitive advantage

Considerations:

  • Significant development time and expertise required
  • Highest risk of all migration strategies
  • Requires comprehensive testing of new architecture
  • May require new operational skills and tooling
  • Consider phasing refactoring to reduce risk

4. Repurchase (Drop and Shop)

Repurchasing involves replacing existing applications with cloud-based Software-as-a-Service (SaaS) alternatives. Rather than migrating the current application, organizations “drop” the existing solution and “shop” for equivalent SaaS products.

This strategy is particularly relevant for applications that are not core to competitive differentiation. For example, migrating email to Microsoft 365 or Google Workspace, implementing Salesforce for CRM, or adopting Workday for HR functions.

# Example: Migration to SaaS email and collaboration
# Before: Self-hosted email infrastructure
# After: Google Workspace / Microsoft 365

# Google Workspace migration example using GAM
# gam create user jsmith
# gam update user jsmith password "temp-password" 
# gam migrate email [email protected] target [email protected]

# Azure AD Connect for identity management
# Connect on-premises AD to Azure AD for SaaS single sign-on

Repurchasing can dramatically reduce operational burden, as the SaaS provider manages infrastructure, security, and updates. However, it introduces dependency on external vendors and may require workflow changes to accommodate SaaS capabilities.

When to Choose Repurchasing:

  • Non-core applications where operational overhead exceeds value
  • Applications lacking strategic differentiation
  • When SaaS alternatives meet functional requirements
  • Desire to eliminate infrastructure management entirely
  • Subscription pricing preferred over capital expenditure

Considerations:

  • Data migration from legacy systems may be complex
  • Vendor lock-in with potentially limited customization
  • Subscription costs may exceed operational savings over time
  • Integration with remaining systems requires planning
  • Potential resistance from users accustomed to existing tools

5. Retire

Retiring involves decommissioning applications that are no longer needed. This strategy is often overlooked but can deliver significant benefits by reducing complexity, lowering costs, and improving security posture.

Many organizations maintain applications that are no longer actively used, have been replaced by other systems, or serve purposes that no longer align with business objectives. These applications consume resources—both cloud and human—without providing value.

# Example: Identifying and retiring unused resources
# AWS: Analyze CloudTrail for last access
aws cloudtrail lookup-events \
    --lookup-attributes AttributeKey=EventSource,AttributeValue=ec2.amazonaws.com \
    --max-results 50

# Azure: Review unused resources
az resource list --query "[?tags.AutoShutdown=='true']"

# Identify VM last login times
aws ec2 describe-instances \
    --filters "Name=instance-state-name,Values=running" \
    --query "Reservations[].Instances[].{ID:InstanceId,LastUsed:LaunchTime}"

Before retiring any application, ensure proper data preservation if records need retention, communicate with stakeholders to confirm the application is truly unused, and verify no regulatory requirements mandate keeping the system operational.

When to Choose Retiring:

  • Applications with no active users
  • Redundant systems replaced by other applications
  • Applications serving deprecated business functions
  • Systems where maintenance costs exceed value
  • Applications approaching end-of-support

Considerations:

  • Must ensure data retention requirements are met
  • Requires thorough stakeholder consultation
  • May uncover dependencies that need addressing
  • Document the retirement for institutional knowledge
  • Consider archiving rather than complete deletion

6. Retain

Retaining involves deciding not to migrate certain applications to the cloud—at least not in the current migration wave. This strategy acknowledges that not all workloads are suitable for cloud migration, whether due to technical constraints, regulatory requirements, or business decisions.

Common reasons for retaining applications on-premises include regulatory requirements mandating data location, applications with specific latency requirements that cannot be met in cloud environments, or systems so complex that migration成本 exceeds any potential benefit.

# Example: Hybrid architecture - keeping certain workloads on-premises
# while migrating others to cloud

# Cloud workloads
aws:
  ec2:
    instances:
      - web-servers
      - api-servers
  rds:
    - primary-database
  
# On-premises workloads (retained)
on-premises:
  legacy-systems:
    - mainframe-integration
    - highly-sensitive-data-processing
  compliance:
    - regulated-databases
    - audit-logging-systems

Retaining applications should be a conscious decision based on analysis, not default neglect. Document the rationale for retaining each application and establish review cadences to reassess periodically as cloud capabilities evolve.

When to Choose Retaining:

  • Regulatory constraints preventing cloud deployment
  • Applications with extreme latency requirements
  • Systems where cloud migration cost exceeds benefit
  • Applications scheduled for decommissioning anyway
  • Strategic decisions to maintain certain capabilities on-premises

Considerations:

  • Document clear rationale for retention
  • Establish periodic review to reassess cloud viability
  • Ensure retained systems are properly secured
  • Plan for potential future migration
  • Consider hybrid architectures that combine cloud and on-premises

Choosing the Right Strategy

Selecting the appropriate migration strategy for each workload requires systematic evaluation across multiple dimensions.

Assessment Framework

When evaluating each application, consider the following factors:

Business Value: Is the application core to business operations or competitive differentiation? Core applications may warrant refactoring for optimal cloud performance, while non-core applications might be candidates for repurchasing or retiring.

Technical Complexity: How complex are the application’s dependencies? Highly interconnected systems may be better suited to rehosting or replatforming rather than refactoring.

Cost Implications: What are the direct migration costs, ongoing operational costs, and potential optimization savings? Build business cases for each option.

Time Constraints: What is the migration timeline? Tight timelines often favor rehosting, while longer programs can accommodate refactoring.

Risk Tolerance: What is the organization’s risk tolerance? Refactoring carries higher technical risk but potentially higher rewards.

Common Patterns

Many organizations adopt a portfolio approach, applying different strategies to different applications:

  • Rehost 20-30%: Quick wins to demonstrate progress
  • Replatform 30-40%: Most applications for balance of speed and optimization
  • Refactor 10-20%: Strategic applications requiring modernization
  • Repurchase 10-15%: Non-core applications replaced by SaaS
  • Retire 5-10%: Unused applications identified during assessment
  • Retain 5-10%: Applications with legitimate on-premises requirements

Implementation Considerations

Regardless of the chosen strategy, successful migrations require attention to several cross-cutting concerns.

Migration Tools

Major cloud providers offer tools to support migration:

AWS: AWS Migration Hub, AWS Database Migration Service, AWS Server Migration Service, AWS Application Discovery Service

Azure: Azure Migrate, Azure Database Migration Service

Google Cloud: Migration Center, Database Migration Service

# Example: Using AWS Application Discovery Service
# Discover on-premises infrastructure before migration
aws discovery describe-agents
aws discovery list-configurations --filter-attribute-name="HOST_NAME" --filter-values="web-server-*"

Security Considerations

Each migration strategy requires appropriate security measures:

  • Rehosted applications need security group configuration review
  • Replatformed databases require IAM role configuration
  • Refactored applications need new security architecture
  • Repurchased solutions require vendor security assessment
  • Retired applications require secure data disposal
  • Retained applications may need enhanced on-premises security

Testing and Validation

Comprehensive testing is essential regardless of migration strategy:

  • Functional testing validates application behavior
  • Performance testing confirms adequate cloud performance
  • Security testing identifies vulnerabilities
  • Integration testing ensures connectivity with dependent systems
  • User acceptance testing confirms business requirements are met

Conclusion

Cloud migration is not a one-size-fits-all undertaking. The six migration strategies—Rehost, Replatform, Refactor, Repurchase, Retire, and Retain—provide a comprehensive framework for evaluating each workload individually and selecting the optimal approach.

Successful cloud transformations combine multiple strategies across the application portfolio. The key is thoughtful assessment, strategic decision-making, and recognition that migration decisions have long-term implications for operational efficiency, cost structure, and business agility.

Begin with honest assessment of your current application portfolio. Engage stakeholders across the organization to understand business value and technical constraints. Build the business case for each migration option. And remember that migration is not a single event but an ongoing journey—strategies can evolve as cloud capabilities advance and organizational needs change.

The right migration strategy depends on your specific circumstances. What matters most is making informed decisions based on clear understanding of tradeoffs, then executing with discipline and attention to operational excellence.

Resources

Comments