Cloud Migration Strategies — 6 Rs, Lift-and-Shift, Re-Platform, Refactor & Assessment

In this tutorial, you'll learn about Cloud Migration Strategies. We cover key concepts, practical examples, and best practices to help you understand and apply this topic effectively.

Cloud Migration is the process of moving applications, data, and workloads from on-premises data centers to cloud infrastructure using strategies like rehosting, replatforming, and Refactoring.

What You'll Learn

You'll learn the 6 Rs Migration strategies, how to assess application readiness, plan Migration waves, execute migrations with minimal downtime, and optimize post-Migration costs and performance.

Why It Matters

90% of enterprises have cloud Migration initiatives, but 40% exceed their Migration budget. Choosing the wrong Migration strategy increases costs and delays benefits. Hybrid Cloud architectures often serve as the Migration bridge. DodaZIP was migrated to AWS using the re-platform strategy to take advantage of managed databases.

Real-World Use

A healthcare company uses the 6 Rs framework: rehosts legacy patient records (lift-and-shift), refactors the billing system to Microservices, replaces the scheduling system with a SaaS solution, and retains the radiology system on-premises due to hardware dependencies.

The 6 Rs of Cloud Migration

Rehost (Lift-and-Shift)

Rehosting moves applications to the cloud with minimal changes. Use AWS Application Migration Service (MGN) or Azure Migrate for automated Replication.

# AWS MGN: install replication agent on source server
# Source server (on-premises Linux):
wget -O ./aws-replication-installer.sh \
  https://aws-application-migration-service-us-east-1.s3.amazonaws.com/latest/linux/aws-replication-installer.sh

chmod +x aws-replication-installer.sh
sudo ./aws-replication-installer.sh

# Launch a test instance in AWS
aws mgn start-test \
  --source-server-id s-0abcdef1234567890 \
  --launch-disposition TEST_AND_CUTOVER

# Cutover to production
aws mgn finalize-cutover \
  --source-server-id s-0abcdef1234567890

Expected behavior: The on-premises server replicates continuously to AWS. A test instance validates the configuration. Cutover finalizes the Migration with minimal downtime.

Replatform (Lift, Tinker, Shift)

Replatforming makes targeted changes to use managed services without changing the application architecture.

flowchart LR
  A[On-Prem MySQL] -->|Replatform| B[RDS MySQL Multi-AZ]
  C[On-Prem Web Server] -->|Replatform| D[EC2 Auto Scaling Group]
  E[On-Prem File Server] -->|Replatform| F[S3 + CloudFront]
  A -.->|Self-managed backups| G
  B -.->|Automated backups, Multi-AZ| G
  style A fill:#f80,color:#fff
  style C fill:#f80,color:#fff
  style E fill:#f80,color:#fff
  style B fill:#4a4,color:#fff
  style D fill:#4a4,color:#fff
  style F fill:#4a4,color:#fff

# Replatform assessment: identify candidates
def replatform_score(database_engine, os_type, dependencies):
    score = 0
    if database_engine in ["MySQL", "PostgreSQL", "Oracle"]:
        score += 3  # AWS RDS or Aurora available
    if os_type == "Linux":
        score += 1  # No Windows licensing complexity
    if len(dependencies) <= 5:
        score += 2  # Few external dependencies
    return score

app = {
    "name": "customer-portal",
    "database_engine": "MySQL",
    "os_type": "Linux",
    "dependencies": ["auth-ldap", "smtp-relay", "redis-cache"]
}
print(f"Replatform score: {replatform_score(**app)}/6")

Expected output:

Replatform score: 6/6

Refactor (Re-architect)

Refactoring rewrites applications to use cloud-native patterns like Microservices, Serverless, and managed databases.

# Before: monolithic database connection
import mysql.connector

def get_user_data(user_id):
    conn = mysql.connector.connect(
        host="db.internal",
        user="app",
        password="hardcoded",
        database="monolith"
    )
    cursor = conn.cursor()
    cursor.execute("""
        SELECT u.*, o.*, p.*
        FROM users u
        JOIN orders o ON u.id = o.user_id
        JOIN payments p ON o.id = p.order_id
        WHERE u.id = %s
    """, (user_id,))
    return cursor.fetchall()

# After: microservices with managed DynamoDB and RDS
import boto3

dynamodb = boto3.resource("dynamodb")
users_table = dynamodb.Table("Users")

def get_user_data_refactored(user_id):
    # User service queries its own table
    user = users_table.get_item(Key={"id": user_id}).get("Item")
    # Orders come from a different service via API
    orders = requests.get(f"http://orders-service/api/orders/{user_id}")
    return {"user": user, "orders": orders.json()}

Expected behavior: Each microservice owns its data. The user service reads from DynamoDB, orders service reads from its own database. Services communicate via APIs, not shared databases.

Migration Assessment Framework

Common Errors

1. Lift-and-shift without optimization: Rehosting without right-sizing leads to higher cloud costs than on-premises. Always right-size after Migration.
2. Missing dependency mapping: An application that depends on an on-premises database fails if the database is migrated in a different wave. Map all dependencies first.
3. No rollback plan: If the Migration fails, the original on-premises environment must still be operational. Plan for rollback before cutover.
4. Ignoring licensing: Some software licenses do not transfer to the cloud. Check bring-your-own-license (BYOL) eligibility for Windows, SQL Server, Oracle.
5. Testing only in the cloud: The migrated application must work in the hybrid state. Test with cloud DNS, security groups, and networking before cutover.
6. Underestimating data transfer time: Large databases can take days to transfer over the internet. Use AWS Snowball or Azure Data Box for petabyte-scale data.

Practice Questions

1. Which R strategy is best for a legacy monolith that will be decommissioned in 2 years? Rehost. Minimal investment, no re-architecture, and the application will be retired soon.
2. What is the difference between replatform and refactor? Replatform uses managed services without changing code. Refactor rewrites the application for cloud-native patterns.
3. When would you retain an application on-premises? When it has hardware dependencies, strict latency requirements, or regulatory Compliance that prevents cloud hosting.
4. What is a Migration wave? A group of applications that are migrated together, typically organized by dependency groups and business timelines.
5. Challenge: A company has 200 on-premises servers running 50 applications. 10 apps are critical, 20 are standard, 15 are experimental, and 5 are unused. Design a Migration plan using the 6 Rs, including wave grouping and timeline estimates.

Mini Project

Create a complete Migration plan for a sample application portfolio:

• Download and install AWS Application Discovery Service agent (simulated)
• Discover 5 sample applications with dependencies
• Classify each application into a Migration strategy (6 Rs)
• Create Migration waves (3 waves of 2-3 apps each)
• Execute a rehost Migration for a web server using AWS MGN (simulated)
• Execute a replatform Migration for a MySQL database to RDS using DMS
• Decommission the source server after cutover validation
• Run a post-Migration cost comparison

Built by the developers of Doda Browser, DodaZIP, and Durga Antivirus Pro.