Cloud Migration Patterns | The Garnet Wiki

Cloud migration is the most impactful infrastructure decision most organizations make. It determines years of operational patterns, costs, and capabilities. Done well, it unlocks agility and scale. Done poorly, it creates a more expensive version of the same problems.

The 7 Rs

Strategy	Description	When to Use
Rehost	Lift-and-shift (same architecture, cloud VMs)	Quick migration, low risk
Replatform	Lift-and-shift with minor optimization (managed DB, containers)	Moderate improvement, moderate effort
Refactor	Re-architect for cloud-native (serverless, microservices)	Maximum cloud benefit, high effort
Repurchase	Replace with SaaS (e.g., on-prem CRM → Salesforce)	Better alternative exists
Retire	Decommission (unused applications)	No business value
Retain	Keep on-premises (for now)	Compliance, cost, or dependency reasons
Relocate	Move to cloud without changes (VMware Cloud on AWS)	VMware-heavy environments

Migration Phases

Phase 1: Assess (4-8 weeks)

Inventory:
  - Catalog all applications and infrastructure
  - Map dependencies (what talks to what)
  - Classify by migration strategy (7 Rs)
  - Identify blockers (compliance, licensing, architecture)

Prioritize:
  - Start with low-risk, low-dependency applications
  - Build team expertise before tackling critical systems
  - Group tightly-coupled applications together

Phase 2: Plan (4-6 weeks)

For each application wave:
  - Target architecture on cloud
  - Data migration strategy
  - Networking (VPN, Direct Connect)
  - Security and compliance mapping
  - Rollback plan
  - Success criteria
  - Timeline and resource allocation

Phase 3: Migrate (ongoing)

Wave-based migration:
  Wave 1: Dev/test environments (low risk, build confidence)
  Wave 2: Non-critical production (validate patterns)
  Wave 3: Critical applications (proven process)
  Wave 4: Databases and stateful services (highest risk)

Phase 4: Optimize (post-migration)

After migration:
  - Right-size instances (most are over-provisioned)
  - Implement auto-scaling
  - Evaluate managed services (RDS vs self-managed DB)
  - Set up cost monitoring
  - Establish cloud governance

Database Migration

Strategies

Offline Migration:
  1. Stop application writes
  2. Export database
  3. Import to cloud database
  4. Update application connection strings
  5. Restart application
  Downtime: Hours to days depending on size

Online Migration (CDC):
  1. Set up CDC replication (DMS, Debezium)
  2. Replicate existing data to cloud
  3. Enable continuous replication
  4. Verify data consistency
  5. Cutover: switch application to cloud database
  Downtime: Minutes

Dual-Write:
  1. Application writes to both databases
  2. Read from on-prem until cloud verified
  3. Switch reads to cloud
  4. Stop writing to on-prem
  Downtime: Zero (but complex, risk of inconsistency)

Cutover Planning

cutover_plan:
  pre_cutover:
    - Verify cloud environment matches specifications
    - Complete data migration verification
    - Update DNS TTL to 60 seconds (48 hours before)
    - Notify stakeholders
    - Prepare rollback procedures
    
  cutover_window: "Saturday 11 PM - Sunday 5 AM"
    
  execution:
    - Step 1: Stop on-prem applications
    - Step 2: Final data sync (delta)
    - Step 3: Verify data integrity checksums
    - Step 4: Update DNS / load balancer
    - Step 5: Start cloud applications
    - Step 6: Smoke test (automated + manual)
    - Step 7: Monitor for 2 hours
    
  rollback_trigger:
    - Error rate > 5% for 15 minutes
    - Data integrity check fails
    - Critical functionality broken
    
  rollback_procedure:
    - Revert DNS / load balancer
    - Start on-prem applications
    - Sync any cloud-written data back
    - Post-mortem

Anti-Patterns

Anti-Pattern	Consequence	Fix
”Big bang” migration	Single point of failure, extended downtime	Wave-based, incremental migration
Lift-and-shift everything	Cloud costs higher than on-prem	Evaluate replatform/refactor for key workloads
No dependency mapping	Break dependent systems	Map all dependencies before migrating
Skip optimization phase	Over-provisioned cloud, wasted spend	Right-size within 90 days of migration
No rollback plan	Stuck with broken migration	Test rollback before cutover

Cloud migration is not a project — it is a transformation. The technical migration is the easy part. Changing operational practices, building cloud skills, and establishing governance are what determine long-term success.