Hybrid Cloud - Learning Module

Loading content...

0/273

Migration Patterns

The Art and Science of Cloud Migration

Cloud migration is not a single event—it's a journey. Organizations don't simply 'migrate to the cloud' as a single action; they execute a carefully orchestrated series of decisions, transformations, and deployments that can span months or years.

The risk of getting migration wrong is substantial. Poorly executed migrations lead to:

Unexpected costs that exceed on-premises spend
Performance degradation affecting customer experience
Extended downtime during cutover
Security vulnerabilities during the transition
Failed migrations that require rollback

Migration patterns provide proven approaches for transitioning workloads from on-premises to cloud environments, each with different risk profiles, cost implications, and organizational requirements. Mastering these patterns is essential for any architect leading hybrid or cloud transformation initiatives.

What You Will Learn

By the end of this page, you will understand the major migration patterns (Rehost, Replatform, Refactor, Repurchase, Retain, Retire), their tradeoffs, and when to apply each. You'll learn the technical mechanisms for executing migrations, including data migration strategies, cutover approaches, and rollback planning.

The 6 Rs of Cloud Migration

AWS popularized the '6 Rs' framework for categorizing migration approaches. Each represents a different level of transformation, cost, and benefit. Understanding these patterns helps organizations make strategic decisions about each workload.

The 6 Rs of Cloud Migration
Pattern	Description	Effort	Cloud Benefits	Best For
Rehost (Lift & Shift)	Move as-is to cloud VMs	Low	Minimal	Quick migration, legacy apps
Replatform (Lift, Tinker, Shift)	Minor optimization during move	Low-Medium	Moderate	Database-to-managed, OS updates
Refactor (Re-architect)	Rebuild using cloud-native services	High	Maximum	Strategic apps, new features needed
Repurchase	Replace with SaaS solution	Medium	High (outsourced)	Commodity functions (CRM, email)
Retain	Keep on-premises	None	None	Compliance, unsupported apps
Retire	Decommission	Low	Cost savings	Unused, redundant systems

Understanding the spectrum:

These patterns exist on a spectrum from minimal change (Retire, Retain, Rehost) to significant transformation (Refactor, Repurchase). Most organizations apply a mix:

70% Rehost/Replatform — The bulk of applications migrate with minimal changes to establish cloud presence quickly.
20% Refactor — Strategic applications receive investment to become cloud-native.
10% Retire/Retain — Some applications are decommissioned; others stay on-premises permanently.

The right mix depends on organizational goals, timelines, budget, and technical debt levels.

Migration is Not One-Size-Fits-All

Each application in your portfolio may follow a different 'R'. A critical customer-facing app might be refactored; a stable back-office system might be rehosted; an obsolete reporting tool might be retired. Portfolio assessment is the foundation of migration planning.

Rehost (Lift and Shift) Deep Dive

Rehosting moves applications to cloud infrastructure with minimal changes. The application runs on cloud VMs (EC2, Azure VMs, Compute Engine) instead of physical servers, but the code, configuration, and architecture remain unchanged.

Rehost Advantages

•Fastest migration timeline
•Lowest risk—no code changes
•Exits data center quickly
•Staff leverage existing skills
•Becomes baseline for future optimization

Rehost Disadvantages

•Doesn't leverage cloud-native features
•May not reduce costs (often increases)
•Carries technical debt to cloud
•Same operational overhead
•Licensing costs may be higher

Rehosting Approaches:

Manual Rehost — Install fresh cloud VMs, deploy application, migrate data. Most control, most effort.
Automated Rehost with AWS Application Migration Service (MGN) — Agents on source servers stream changes to cloud. Final cutover is a reboot. Minimal downtime.
VMware Cloud on AWS / Azure VMware Solution — Migrate VMware VMs to cloud-hosted vSphere. Minimal changes, leverages existing VMware skills and licensing.
Containerization during Rehost — Package application in container, run on ECS/EKS/AKS. Not pure lift-and-shift, but provides cloud portability.

mgn-agent-installation.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
#!/bin/bash
# AWS Application Migration Service (MGN) Agent Installation
# Run on source server to begin replication to AWS
 
# Prerequisites:
# - Network connectivity to AWS MGN endpoints
# - IAM credentials with MGN permissions
# - Sufficient disk space for staging
 
# Download the MGN agent installer
wget -O ./aws-replication-installer-init \
    https://aws-application-migration-service-<region>.s3.<region>.amazonaws.com/latest/linux/aws-replication-installer-init
 
chmod +x aws-replication-installer-init
 
# Install with staging credentials
# Agent will replicate all attached volumes to AWS
sudo ./aws-replication-installer-init \
    --region us-east-1 \
    --aws-access-key-id $ACCESS_KEY \
    --aws-secret-access-key $SECRET_KEY \
    --no-prompt
 
# Agent now runs as service: aws-replication-agent
# Monitor replication status in AWS MGN Console
# Cutover when replication is synced (lag < 1 minute)
 
# Post-cutover:
# - Update DNS to point to new cloud instance
# - Validate application functionality
# - Decommission source server after validation period

The 'Lift and Shift, Then Optimize' Trap

Many organizations plan to 'lift and shift now, optimize later.' In practice, the optimization phase never happens—teams move on, budgets shift, and the legacy application runs indefinitely on expensive VMs. If cloud-native benefits are important, build optimization into the migration plan upfront.

Replatform Strategies

Replatforming makes targeted optimizations during migration—enough to capture some cloud benefits without full re-architecture. It's the pragmatic middle ground between lift-and-shift and complete refactoring.

Common Replatform Optimizations

•Database → Managed Database — Self-managed MySQL on VM → Amazon RDS or Aurora. Reduces operational burden, enables backups, read replicas, and automatic patching.
•File Storage → Object Storage — Local file system → S3/Blob Storage. Enables infinite scale, lower cost, integrated lifecycle management.
•Message Queues → Managed Queues — RabbitMQ on VM → Amazon SQS or Azure Service Bus. Eliminates queue management overhead.
•Load Balancing → Cloud LB — HAProxy/nginx → ALB/NLB/Cloud Load Balancing. Integrates with auto-scaling, health checks, logging.
•OS Modernization — Windows 2008 → Windows 2019; RHEL 6 → RHEL 8. Addresses security vulnerabilities, enables newer features.

Replatforming Decision Matrix
Component	Pure Rehost	Replatform Option	Effort Delta	Benefit
Database	Self-managed on EC2	RDS / Aurora	Medium	Managed backups, HA, patching
Cache	Redis on EC2	ElastiCache	Low	Managed HA, automatic failover
Session State	Local file system	ElastiCache/DynamoDB	Medium	Enables horizontal scaling
Static Assets	Apache on EC2	S3 + CloudFront	Medium	Global CDN, reduced server load
SSL Termination	On application server	Load Balancer / CloudFront	Low	Centralized cert management

Database Migration Specifics:

Database replatforming is the most impactful and risky replatform change. Key considerations:

Schema Compatibility — Managed databases may not support all features (e.g., PostgreSQL extensions, Oracle packages). Audit dependencies before migrating.
Connection String Changes — Application configuration must point to new endpoint. Parameterize connections for smooth cutover.
Data Migration — Use AWS DMS, Azure Database Migration Service, or native tooling (pg_dump, mysqldump). Plan for initial sync + CDC for ongoing updates.
Performance Differences — Instance types and storage (IOPS, gp3 vs io1) affect performance. Benchmark before production cutover.
Downtime Planning — Some migrations require brief downtime for final sync. Coordinate with business for maintenance windows.

Maximize Bang for Buck

Focus replatform effort on components with the highest operational burden. Self-managed databases and message queues typically consume disproportionate ops time. Moving these to managed services often delivers more value than refactoring application code.

Refactor (Re-architect) Approach

Refactoring fundamentally reimagines the application architecture to leverage cloud-native capabilities. This is the most expensive and time-consuming approach, but delivers the greatest cloud benefits—scalability, resilience, and cost efficiency.

Refactoring Transformations

•Monolith → Microservices — Decompose monolithic application into independently deployable services. Enables independent scaling, deployment, and team ownership.
•Synchronous → Event-Driven — Replace synchronous API calls with event-based communication (Kafka, SNS/SQS). Improves resilience and decoupling.
•Server-Based → Serverless — Migrate suitable workloads to Lambda, Cloud Functions. Eliminates server management, scales to zero, pay-per-execution pricing.
•Traditional DB → Purpose-Built Stores — Use DynamoDB for session data, Elasticsearch for search, Redis for caching, S3 for documents. Right database for each workload.
•Containers + Kubernetes — Package applications in containers, orchestrate with EKS, AKS, GKE. Enables cloud portability and standardized operations.

The Strangler Fig Pattern:

Complete refactoring of a monolith is risky and slow. The Strangler Fig pattern (named after strangler fig trees that gradually envelop host trees) provides an incremental approach:

Identify a bounded context — Select a module or feature to extract (e.g., user authentication, order processing).
Build the new implementation — Create a cloud-native microservice that handles the functionality.
Route traffic incrementally — Use API gateway or routing layer to send a percentage of traffic to the new service.
Monitor and validate — Compare behavior, performance, and correctness between old and new.
Complete cutover — When confident, route 100% of traffic to the new service.
Decommission old code — Remove the equivalent functionality from the monolith.
Repeat — Continue extracting services until the monolith is fully strangled.

This pattern allows continuous delivery of new services while maintaining application stability.

api-gateway-strangler-config.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# AWS API Gateway configuration for Strangler Fig pattern
# Gradually migrates traffic from monolith to microservice
 
apiVersion: apigatewayv2.aws.crossplane.io/v1alpha1
kind: Route
metadata:
  name: orders-route
spec:
  forProvider:
    apiIdRef:
      name: main-api
    routeKey: "POST /api/orders"
    
    # Canary deployment: 90% monolith, 10% new service
    target:
      type: "AWS_PROXY"
      integrations:
        - weight: 90
          uri: "http://monolith.internal/api/orders"
          connectionType: VPC_LINK
        - weight: 10
          uri: "arn:aws:lambda:us-east-1:123456789:function:orders-microservice"
          
    # Gradually increase microservice weight:
    # Week 1: 10%
    # Week 2: 25%
    # Week 3: 50%
    # Week 4: 90%
    # Week 5: 100% (decommission monolith endpoint)

Refactoring Requires Investment

Refactoring is a significant engineering investment. Don't refactor applications that don't warrant it—stable, rarely-changing applications are fine as rehost. Reserve refactoring budget for applications that need new features, must scale significantly, or have crippling technical debt.

Data Migration Strategies

Migrating data is often the most complex and risky aspect of cloud migration. Unlike applications that can be deployed and rolled back, data exists in a single state of truth. Data migration requires careful planning, execution, and validation.

Data Migration Approaches

•Big Bang Migration — Stop the source, migrate all data, start the target. Simplest conceptually but requires extended downtime. Only feasible for small datasets or planned maintenance windows.
•Trickle Migration (Phased) — Migrate data in batches over time. Reduces risk but requires careful coordination to handle data changing during migration.
•Initial Sync + CDC — Perform initial bulk transfer, then use Change Data Capture to replicate ongoing changes. Minimizes cutover downtime. Most common for databases.
•Dual-Write — Application writes to both old and new datastore simultaneously. Ensures both are synchronized. Requires application changes; complex to implement correctly.
•Offline Transfer (Snowball) — For massive datasets, physical devices ship data faster than network transfer. AWS Snowball, Azure Data Box, GCP Transfer Appliance.

Data Migration Pattern Selection
Pattern	Downtime	Data Volume	Complexity	Risk
Big Bang	Hours to days	< 100 GB	Low	Medium (all-or-nothing)
Phased Trickle	Minimal per batch	Any	Medium	Low (incremental)
Initial + CDC	Minutes	100 GB	Medium-High	Low
Dual-Write	Zero (gradual)	Any	High	Medium (consistency)
Offline (Snowball)	Days (shipping)	10 TB	Medium	Low

Validation is Non-Negotiable:

Migrated data must be validated before cutover:

Row counts — Source and target table row counts must match.
Checksum validation — Hash samples of data to verify integrity.
Application testing — Run test workloads against migrated data.
Referential integrity — Verify foreign key relationships are intact.
Edge cases — Check boundary conditions: NULLs, Unicode, large BLOBs.
Performance validation — Query response times on target should meet requirements.

The Cutover Freeze

For CDC-based migrations, establish a 'cutover freeze'—a period where source writes are paused to allow CDC to catch up completely. Even with CDC, there's always some lag. The freeze window should be minimized but cannot be eliminated entirely.

Cutover Planning and Execution

The cutover is the moment when production traffic shifts from on-premises to cloud. This high-stakes operation requires meticulous planning, rehearsal, and contingency preparation.

Cutover Planning Checklist

•Runbook — Detailed, step-by-step instructions. Include commands, expected outputs, validation steps. Automate where possible.
•Communication Plan — Who needs to know, when, and how. Include stakeholders, users, support teams, executives.
•Maintenance Window — Coordinate with business. Choose low-traffic periods. Consider global users if applicable.
•Go/No-Go Criteria — Define conditions that must be true before cutover proceeds. Data sync complete, health checks passing, team availability confirmed.
•Rollback Plan — How to revert if cutover fails. Test the rollback procedure. Know the rollback decision triggers and time limits.
•War Room — Central communication channel (Slack room, bridge line). All relevant personnel available during cutover window.
•Rehearsal — Practice cutover in non-production environment. Time the process. Identify gaps in runbook.

Cutover Patterns:

DNS Cutover — Change DNS records to point to cloud endpoints. Simple but TTL delays propagation. Reduce TTL in advance.
Load Balancer Cutover — Add cloud targets to existing load balancer, drain on-prem targets. Faster than DNS; more control over traffic split.
Feature Flag Cutover — Application-level routing based on feature flags. Enables user-by-user or percentage-based migration. Requires code changes.
Blue-Green Cutover — Two complete environments; switch traffic atomically. Fastest rollback but most expensive (double infrastructure during transition).
Canary Cutover — Migrate small percentage of traffic first. Monitor for issues. Gradually increase until 100%. Safest but slowest.

cutover-runbook-excerpt.md
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
# Production Cutover Runbook
## Application: Order Processing System
## Date: 2024-03-15 02:00 UTC
## Maintenance Window: 4 hours
 
### Pre-Cutover (T-1 hour)
- [ ] Confirm CDC lag < 30 seconds
- [ ] Verify cloud application health checks passing
- [ ] Confirm all team members in war room
- [ ] Notify stakeholders: cutover beginning
 
### Phase 1: Stop Source Writes (T+0)
- [ ] Enable maintenance mode on on-prem application
  ```bash
  ssh admin@onprem-app "sudo systemctl stop order-processor"
  ```
- [ ] Verify no new orders in queue
  ```sql
  SELECT COUNT(*) FROM orders WHERE created_at > NOW() - INTERVAL '5 minutes';
  -- Expected: 0
  ```
 
### Phase 2: Final Data Sync (T+10min)
- [ ] Wait for CDC lag = 0
  ```bash
  aws dms describe-replication-tasks --query 'ReplicationTasks[].ReplicationTaskStats'
  ```
- [ ] Run data validation
  ```bash
  ./validate-data.sh --source onprem --target rds --tables orders,customers
  ```
- [ ] **GO/NO-GO CHECKPOINT** - All validations passed?
 
### Phase 3: DNS Cutover (T+30min)
- [ ] Update Route53 record
  ```bash
  aws route53 change-resource-record-sets --hosted-zone-id Z123 \
    --change-batch file://dns-cutover.json
  ```
- [ ] Wait for propagation (TTL: 60 seconds)
- [ ] Verify new traffic hitting cloud ALB
 
### Phase 4: Validation (T+45min)
- [ ] Place test order
- [ ] Monitor error rates in CloudWatch
- [ ] Confirm order appears in RDS
 
### Rollback Triggers
- Error rate > 5% for 5 minutes
- Database connectivity failures
- Data corruption detected
 
### Rollback Procedure (if needed)
1. Revert DNS to on-prem
2. Re-enable on-prem application
3. Stop CDC replication
4. Post-incident analysis

Always Have a Rollback Plan

No cutover should proceed without a tested rollback plan. Know exactly how to revert, how long it takes, and what data might be lost. If you can't roll back, you can't take the risk of cutting over.

Post-Migration Optimization

Migration success isn't measured at cutover—it's measured in the weeks and months after. Post-migration optimization ensures that the cloud environment delivers the promised benefits and addresses issues that only emerge under production load.

Post-Migration Activities

•Right-Sizing — Monitor actual resource usage. Most initial sizing is over-provisioned. Adjust instance types, storage tiers, and memory allocation based on real metrics.
•Cost Optimization — Analyze cloud spend. Identify waste (unused instances, over-allocated storage). Implement Savings Plans/Reserved Instances for stable workloads.
•Performance Tuning — Optimize for cloud networking (latency patterns differ from on-prem). Tune database parameters for cloud storage characteristics.
•Security Hardening — Review security groups, IAM policies, encryption settings. Implement cloud-native security tooling (GuardDuty, Security Center, Cloud Armor).
•Operational Maturity — Establish monitoring, alerting, and runbooks. Train operations team on cloud-specific tools. Document architecture for future maintenance.
•Decommission Source — After validation period, formally decommission on-premises infrastructure. Capture lessons learned.

Post-Migration Optimization Timeline
Timeframe	Focus Area	Key Activities
Week 1-2	Stabilization	Monitor for issues, performance baseline, bug fixes
Week 3-4	Right-Sizing	Adjust instance sizes, storage tiers based on real usage
Month 2	Cost Analysis	Review first full month bill, identify optimization opportunities
Month 3	Automation	Implement IaC, CI/CD, automated scaling policies
Month 4+	Advanced Optimization	Reserved capacity, spot instances, architectural improvements

Set Optimization Goals Upfront

Define success metrics before migration: target cost reduction, performance SLAs, operational efficiency gains. Track against these metrics post-migration. Without measurable goals, 'optimization' becomes endless tinkering without clear value.

Summary: Migration Patterns

We've covered the complete landscape of cloud migration patterns. Let's consolidate the key principles:

Key Takeaways

•The 6 Rs provide a strategic framework — Rehost, Replatform, Refactor, Repurchase, Retain, Retire. Each workload should be evaluated and assigned an appropriate pattern.
•Rehost is fast but limited — Lift-and-shift enables quick migration but doesn't capture cloud benefits. Suitable for speed over optimization.
•Replatform offers pragmatic optimization — Target high-impact components (databases, queues) for managed services while keeping application code stable.
•Refactor is expensive but transformative — Cloud-native redesign delivers maximum benefits. Use the Strangler Fig pattern for incremental modernization.
•Data migration is the critical path — Initial sync + CDC minimizes downtime. Always validate migrated data before cutover.
•Cutover requires meticulous planning — Runbooks, rehearsals, rollback plans, and war rooms are not optional. Practice makes cutover.
•Optimization continues post-migration — Right-size, cost-optimize, and mature operations in the months following migration.

What's next:

We've explored the technical mechanisms of migration. The final page examines Hybrid Cloud Use Cases—real-world scenarios where organizations successfully maintain hybrid architectures, including disaster recovery, bursting, dev/test, and compliance-driven topologies.

Page Complete

You now have a comprehensive understanding of cloud migration patterns. From lift-and-shift to full re-architecture, you can evaluate workloads, select appropriate strategies, plan data migrations, and execute cutovers with confidence. These patterns are the bridge from on-premises legacy to cloud-native futures.