4.1 Cloud Migration Strategies (The 6/7 Rs)

Cloud Migration Strategies (The 6/7 Rs)

Migrating enterprise workloads to the public cloud is not a one-size-fits-all endeavor. Organizations manage diverse application portfolios ranging from modern web applications and proprietary commercial off-the-shelf (COTS) software to decades-old legacy monoliths and mainframe-backed systems. To structure and execute cloud migration initiatives systematically, cloud architects rely on the 7 Rs Migration Framework (originally established by Gartner as the 5 Rs and subsequently expanded by Amazon Web Services and the broader cloud industry to 6 and 7 Rs).

For the CompTIA Cloud+ (CV0-004) examination, engineers must master the technical mechanics, Total Cost of Ownership (TCO) drivers, implementation risks, and architectural trade-offs across all seven migration pathways.

---

1. The 7 Rs Migration Framework Breakdown

+---------------------------------------------------------------------------------------------------------+
|                                 THE 7 Rs CLOUD MIGRATION SPECTRUM                                       |
|                                                                                                         |
|   LOW COMPLEXITY / FAST VELOCITY                                       HIGH COMPLEXITY / MAXIMUM VALUE  |
|   <------------------------------------------------------------------------------------------------->   |
|                                                                                                         |
|   +------------+   +------------+   +--------------+   +--------------+   +---------------+             |
|   |  RELOCATE  |   |   REHOST   |   |  REPLATFORM  |   |  REPURCHASE  |   |   REFACTOR    |             |
|   | (Hypervisor|   |  (Lift &   |   | (Lift,Tinker |   | (Drop & Shop |   | (Re-Architect |             |
|   |   vMotion) |   |   Shift)   |   |   & Shift)   |   |    SaaS)     |   | Cloud-Native) |             |
|   +------------+   +------------+   +--------------+   +--------------+   +---------------+             |
|                                                                                                         |
|   GOVERNANCE / PORTFOLIO DECISIONS:                                                                     |
|   +---------------------------------------+     +---------------------------------------------------+   |
|   |  RETAIN (Revisit / Keep On-Premises)  |     |  RETIRE (Decommission / Archive & Purge)         |   |
|   +---------------------------------------+     +---------------------------------------------------+   |
+---------------------------------------------------------------------------------------------------------+

1. Rehost (Lift-and-Shift)

• Technical Definition: Moving physical servers or virtual machines (VMs) directly from on-premises environments to cloud Infrastructure as a Service (IaaS) virtual instances (e.g., AWS EC2, Azure Virtual Machines, Google Compute Engine) with zero modifications to application code or operating system binaries.
• Implementation Mechanics: Performed using block-level continuous replication agents or hypervisor snapshot appliances (e.g., AWS Application Migration Service [AWS MGN], Azure Migrate Server Migration). Storage volumes (VMDK, VHD) are converted into native cloud Elastic Block Store (EBS) or Managed Disks.
• Primary Strategic Drivers:
  • Impending data center lease expirations or colocation contract terminations.
  • Hardware end-of-life (EOL) refresh avoidance.
  • Rapid exit requirements during mergers, acquisitions, or corporate divestitures.
• Advantages: Fastest time-to-value, minimal migration disruption, lowest required cloud-native skill level, preserves legacy operating configurations.
• Disadvantages & Risks: Carries forward legacy technical debt, suboptimal resource utilization (over-provisioned VMs), fails to leverage cloud elasticity, potential licensing penalties, and higher long-term compute run costs.

2. Replatform (Lift-Tinker-and-Shift)

• Technical Definition: Migrating core applications to the cloud while making a targeted set of cloud optimizations to replace undifferentiated infrastructure components without changing core application business logic or software architecture.
• Implementation Mechanics:
  • Replacing self-managed database servers (e.g., Microsoft SQL Server or PostgreSQL running on VMs) with managed Database as a Service (DBaaS) solutions such as Amazon RDS, Azure SQL Managed Instance, or Google Cloud SQL.
  • Packaging existing applications into containers managed by AWS Elastic Container Service (ECS), Elastic Kubernetes Service (EKS), or Azure Kubernetes Service (AKS).
  • Shifting static file systems to managed cloud storage services (e.g., Amazon S3, Azure Blob Storage, AWS EFS).
  • Upgrading underlying operating system versions (e.g., migrating from Windows Server 2012 R2 to 2022 during transit).
• Primary Strategic Drivers: Eliminating administrative database patching and backup burdens, reducing OS management overhead, and introducing automated horizontal scaling.
• Advantages: Immediate reduction in maintenance overhead, automated high availability and multi-AZ failover, moderate cost optimization without code refactoring.
• Disadvantages & Risks: Potential driver or database version incompatibilities, schema adjustments may be necessary, testing required for managed service integrations.

3. Refactor / Re-architect (Cloud-Native Transformation)

• Technical Definition: Completely reimagining, rewriting, and restructuring application code and software architecture to leverage cloud-native, distributed, and serverless design paradigms.
• Implementation Mechanics:
  • Deconstructing monolithic application architectures into loosely coupled microservices.
  • Implementing event-driven architectures utilizing message queues and event buses (e.g., Amazon SQS, SNS, EventBridge, Azure Event Grid, Apache Kafka).
  • Adopting Function as a Service (FaaS) serverless computing (e.g., AWS Lambda, Azure Functions, Google Cloud Functions).
  • Transitioning from relational ACID databases to globally distributed NoSQL or multi-model engines (e.g., Amazon DynamoDB, Azure Cosmos DB, Google Cloud Spanner).
  • Enforcing 12-Factor App methodology, immutable container deployments, and GitOps CI/CD pipelines.
• Primary Strategic Drivers: Business demands for extreme scalability, continuous deployment velocity, global low-latency distribution, and high operational resilience.
• Advantages: Maximum scalability, optimal auto-scaling granularity, zero server operating system maintenance, lowest run-time cost per transaction at high scale, rapid feature delivery.
• Disadvantages & Risks: Highest upfront financial and engineering investment, longest implementation timeline, substantial organizational change management, high architectural complexity, and risk of vendor lock-in.

4. Repurchase (Drop-and-Shop / SaaS Replacement)

• Technical Definition: Decommissioning a custom or self-hosted commercial off-the-shelf (COTS) application and replacing it entirely with a vendor-managed Software as a Service (SaaS) platform.
• Implementation Mechanics:
  • Replacing on-premises Microsoft Exchange and file shares with Microsoft 365 / Google Workspace.
  • Migrating on-premises customer relationship management (CRM) software (e.g., Siebel) to Salesforce.
  • Migrating on-premises ERP systems (e.g., legacy SAP) to Workday, NetSuite, or SAP S/4HANA Cloud.
• Primary Strategic Drivers: Shifting all infrastructure, maintenance, patching, feature development, and security responsibilities to a dedicated software vendor.
• Advantages: Instant feature upgrades, zero underlying infrastructure management, predictable per-user licensing costs.
• Disadvantages & Risks: Complex historical data extraction and ingestion, potential business workflow disruption, user retraining requirements, and custom integration rebuilding via vendor REST APIs.

5. Retain (Revisit / Keep On-Premises)

• Technical Definition: Explicitly deciding to keep specific applications and infrastructure in their current on-premises or colocation environment during the current migration wave.
• Implementation Mechanics: The workload is excluded from the migration scope, maintaining existing on-premises monitoring, security baselines, and operational runbooks.
• Primary Strategic Drivers:
  • Strict data sovereignty, air-gapped isolation, or regulatory mandates prohibiting public cloud hosting.
  • Workloads operating on specialized hardware (e.g., mainframe architectures, hardware dongles, legacy AS/400 systems).
  • Low-latency industrial control systems (ICS/SCADA) requiring sub-millisecond local network response times.
  • Heavy recent capital investments in on-premises hardware that have not completed depreciation cycles.
  • Workloads planned for retirement in the immediate future (e.g., within 6-12 months).

6. Retire (Decommission & Archive)

• Technical Definition: Identifying applications, environments, or infrastructure components that provide no ongoing business value and shutting them down permanently.
• Implementation Mechanics: During the discovery phase, discovery agents detect orphan servers, abandoned development/testing environments, or redundant software stacks. Data is archived to cold object storage (e.g., AWS S3 Glacier Flexible/Deep Archive, Azure Archive Storage) to satisfy compliance and legal hold requirements, followed by server de-provisioning and storage zeroization.
• Primary Strategic Drivers: Cost reduction, reducing the enterprise attack surface, and eliminating software licensing waste.
• Business Impact: Typical enterprise discovery assessments reveal that 10% to 20% of on-premises IT portfolios can be retired immediately, yielding instant cost savings.

7. Relocate (Hypervisor-Level Lift-and-Shift)

• Technical Definition: Transferring virtual machines directly from on-premises hypervisors to cloud-hosted dedicated bare-metal hypervisor environments without converting disk formats, altering VM configurations, or rewriting network rules.
• Implementation Mechanics: Deploying solutions like VMware Cloud on AWS, Azure VMware Solution (AVS), or Google Cloud VMware Engine (GCVE). Leveraging VMware HCX (Hybrid Cloud Extension) to establish Layer 2 network extensions between the data center and cloud, enabling live, zero-downtime cross-data-center vMotion.
• Primary Strategic Drivers: Workloads with deep hypervisor-level dependencies, strict OS version requirements that public cloud IaaS does not support, or teams wanting to retain existing VMware administrative toolsets (vCenter, vRealize).
• Advantages: Zero VM conversion risk, live zero-downtime migration, retention of existing operational tooling and IP addressing.
• Disadvantages & Risks: Requires dedicated bare-metal cloud infrastructure contracts (higher baseline cost than multi-tenant IaaS), does not provide direct access to native cloud API constructs.

---

2. Strategic Comparison: The 7 Rs Decision Matrix

---

3. Total Cost of Ownership (TCO) & Value Trade-Offs

Understanding the financial dynamics of each strategy is critical for business alignment and certification mastery.

+-----------------------------------------------------------------------------------------+
|                         TCO TRAJECTORY: REHOST VS. REFACTOR                             |
|                                                                                         |
|   COST ($)                                                                              |
|      ^                                                                                  |
|      |         /------------------ [ REHOST: Fast initial drop, then flat line ]        |
|      |        /                                                                         |
|      |       /     /-------------- [ REFACTOR: High initial build cost, then drops ]    |
|      |      /     /                                                                     |
|      |     /     /                                                                      |
|      |    /     /                                                                       |
|      |   /     /                                                                        |
|      |  /     /                                                                         |
|      | /     /                                                                          |
|      +----------------------------------------------------------------------------->    |
|        T0 (Assessment)   T1 (Cutover)      T2 (Year 1)       T3 (Year 3+)      TIME     |
+-----------------------------------------------------------------------------------------+

1. Rehost Financial Profile:
   • Capital Expenditure (CAPEX) to Operating Expenditure (OPEX): Eliminates server hardware purchases, but running unoptimized, over-provisioned VMs 24/7 on multi-tenant IaaS can result in cloud bills exceeding optimized on-premises run rates if right-sizing is omitted.
2. Replatform Financial Profile:
   • Lowers operating costs by offloading database administrative labor, automated snapshot management, and operating system patching to cloud service providers.
3. Refactor Financial Profile:
   • Incurs high initial development, testing, and migration consulting expenses. However, once deployed, serverless auto-scaling (scaling to zero when idle) and microservice resource density deliver the lowest possible unit cost per customer transaction at scale.

---

4. CompTIA Cloud+ Exam Traps & Real-World Guidance

[!CAUTION] Exam Trap 1: The "All-or-Nothing" Refactoring Fallacy
When an exam scenario presents an organization facing an urgent, hard deadline (such as a 60-day data center lease expiration), Refactoring is always the wrong answer. Even if the end-state vision is a serverless microservices architecture, the correct strategy is to Rehost or Relocate first to beat the physical eviction deadline, and subsequently Refactor within the cloud.

[!WARNING] Exam Trap 2: Replatforming vs. Refactoring Distinctions
If an application's underlying code remains identical, but its backend database is shifted from an EC2/VM-hosted SQL instance to AWS RDS or Azure SQL, or its binary is wrapped into a Docker container on ECS/AKS without core logic modifications, this is Replatforming, NOT Refactoring. Refactoring strictly mandates architectural code modifications.

[!IMPORTANT] Exam Trap 3: Retain vs. Retire Nuances
Retain means the workload continues to run on-premises because it is critical but unsuitable for the cloud right now. Retire means the workload is identified as obsolete, orphaned, or unneeded, and is permanently decommissioned after necessary data archiving.