Cloud Migration Strategies#

A company does not “migrate to the cloud” – it migrates dozens or hundreds of applications, each with different characteristics, dependencies, and risk profiles. The 7 Rs framework provides vocabulary for per-workload decisions, but selecting the right R requires understanding the application, its dependencies, and the organization’s tolerance for change.

The 7 Rs#

Rehost (Lift and Shift)#

Move the application to cloud infrastructure with minimal changes. A VM on-premises becomes an EC2 instance. OS, application code, and configuration remain the same.

When to rehost: the application works and the business will not invest in changing it; you face a hard deadline (data center lease expiring, hardware EOL); the application will be retired within 1-2 years.

# AWS Application Migration Service workflow
# 1. Install replication agent on source server
sudo python3 aws-replication-installer-init --region us-east-1

# 2. Agent continuously replicates disk (block-level) to AWS
# 3. Launch test instance from replicated data
# 4. Validate, then perform cutover: launch final instance, update DNS

Cost of rehosting: you bring your inefficiencies. An oversized on-premises server becomes an oversized EC2 instance. Plan a right-sizing exercise 3-6 months after rehosting.

Replatform (Lift, Tinker, and Shift)#

Make targeted optimizations during migration without changing core architecture. Replace self-managed components with managed services.

When to replatform: the application is mostly fine but self-managed infrastructure is painful. Moving PostgreSQL to RDS eliminates patching, backup management, and failover configuration.

Repurchase (Drop and Shop)#

Replace the application with a SaaS product. Custom-built HR systems, CRM tools, and ticketing systems are rarely competitive with purpose-built SaaS. The main challenge is data migration – extracting data from the old system and mapping it to the new one’s data model.

Refactor (Re-architect)#

Redesign to take full advantage of cloud-native capabilities: auto-scaling, serverless, event-driven architecture.

When to refactor: the application has a strong business case for cloud-native features and is a core differentiator worth the investment. The critical mistake: refactoring everything. Teams adopt “if we are migrating, let us do it right” and try to refactor every application simultaneously, multiplying risk and extending timelines. Refactor selectively. Rehost the majority.

Retire#

Turn off the application. Discovery during assessment frequently reveals applications that are unused, superseded, or serve negligible traffic. Every retired application is one fewer thing to migrate and maintain.

Retain (Revisit Later)#

Keep the application where it is. Hard dependencies on specialized hardware, regulatory requirements for on-premises data, or mid-project risk. Document why and set a review date.

Relocate (Hypervisor-Level Lift and Shift)#

Move VMware workloads to cloud-hosted VMware environments (VMware Cloud on AWS, Azure VMware Solution, Google Cloud VMware Engine) without modifying any VMs or their configurations.

Migration Assessment#

Application Portfolio Discovery#

Cloud providers offer discovery tools: AWS Application Discovery Service, Azure Migrate, and Google Cloud Migrate. These collect CPU, memory, disk, and network utilization over weeks for right-sizing decisions.

Assessment Criteria#

Dependency Mapping#

Applications do not exist in isolation. Migrating application A without its dependency on database B and messaging system C means A does not work in the cloud.

Organize dependencies into migration groups – sets of applications that must migrate together due to latency-sensitive connections. Applications communicating only via APIs (tolerant of 10-50ms latency increases) can migrate independently with temporary cross-network connectivity.

Cutover Planning#

The cutover is the highest-risk moment. Everything before it is preparation.

Blue-Green Cutover#

Run old and new environments simultaneously, then switch traffic:

Phase 1: Both running, traffic on old
Phase 2: DNS cutover to new (TTL: 60s, reduced 48h prior)
Phase 3: Validation period (hours to days), monitor error rates
Phase 4: Decommission old after validation

Cutover Checklist#

## Pre-Cutover
- [ ] Final data sync verified (replication lag < 1s)
- [ ] DNS TTLs reduced to 60 seconds (48h ago)
- [ ] Rollback procedure documented and reviewed
- [ ] Monitoring dashboards ready for both environments

## Cutover
- [ ] Stop writes to old environment
- [ ] Verify final sync completes
- [ ] Switch DNS to new environment
- [ ] Run smoke tests, monitor error rates 15 minutes
- [ ] Decision: proceed or rollback

## Post-Cutover
- [ ] Monitor performance vs baseline for 7 days
- [ ] Verify integrations and scheduled jobs
- [ ] Confirm backups running on new environment

Data Cutover#

Zero-downtime: set up replication from old to new database. At cutover, pause briefly, verify sync, switch connection string. Seconds of downtime.

Maintenance window: schedule downtime, dump database, restore to new environment, switch connection. Minutes to hours depending on volume.

Dual-write: application writes to both databases during transition. Eliminates downtime but introduces consistency risks. Use only when zero downtime is mandatory and replication is not feasible.

Rollback Strategies#

Every cutover needs a rollback plan with pre-defined triggers.

DNS rollback: change DNS back to the old environment. With 60-second TTLs, clients switch in 2-3 minutes. Keep the old environment warm for the entire validation period.

Database rollback complication: if the new environment accepted writes after cutover, those writes exist only in the new database. Mitigate by continuing reverse replication during validation, or implementing a write log for replay.

Rollback Triggers#

Define before cutover, not during the crisis:

• Error rate exceeds 5% above pre-cutover baseline
• P99 latency exceeds 3x baseline
• Any data integrity check fails
• Payment processing failure rate exceeds 0.1%

Migration Wave Planning#

Execute large migrations in waves ordered by risk:

Wave 1 (low risk): internal tools, dev environments, static sites. Proves the process without business impact.

Wave 2 (medium risk): standard web applications, APIs with clear dependency maps, good test coverage.

Wave 3 (high complexity): core business applications, databases with complex replication, many dependencies.

Wave 4 (deferred): retained applications requiring further analysis.

Each wave should take 2-4 weeks including planning, execution, and validation. The pattern across all successful migrations: start small, prove the process, build confidence, then accelerate. Teams that attempt a big-bang migration of all workloads simultaneously discover their unknowns in production, at scale, with no fallback.