Cloud Migration: Planning, Strategies, and Execution

Cloud migration encompasses the processes, frameworks, and technical decisions involved in moving workloads, data, and applications from on-premises infrastructure — or between cloud environments — to a target cloud platform. The scope spans initial assessment through cutover and post-migration validation, and the choices made at each phase have direct consequences for cost, security posture, and operational continuity. This page covers the structured mechanics of cloud migration, the classification of migration strategies, causal drivers, contested tradeoffs, and the reference frameworks published by recognized standards bodies including NIST and the Cloud Security Alliance.

• Definition and scope
• Core mechanics or structure
• Causal relationships or drivers
• Classification boundaries
• Tradeoffs and tensions
• Common misconceptions
• Checklist or steps (non-advisory)
• Reference table or matrix
• References

Definition and scope

Cloud migration is the planned, systematic transfer of digital assets — applications, data stores, virtual machines, and associated configurations — from a source environment to a destination cloud environment. NIST defines cloud computing through five essential characteristics (on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service) in NIST SP 800-145, and any migration program must account for how the target environment satisfies or changes each of those characteristics relative to the source.

Migration scope typically includes three asset categories: application workloads (operating systems, middleware, runtimes), data (structured databases, unstructured file stores, object storage), and dependent services (identity providers, DNS, monitoring agents, and secrets management systems). Migrations that address only application code while deferring data or identity systems consistently produce integration failures during cutover.

The destination environment may be a public cloud, a private cloud operated by the organization, or a hybrid architecture. Migrations may also occur between cloud providers — a pattern known as cloud-to-cloud migration — which introduces provider-specific API incompatibilities as a distinct technical constraint. The cloud deployment models reference covers the structural distinctions between public, private, hybrid, and multi-cloud architectures that determine migration scope and complexity.

Core mechanics or structure

Cloud migration proceeds through five operationally distinct phases regardless of the strategy selected.

Discovery and inventory. The source environment is catalogued to produce a complete asset inventory: server count, operating system versions, application dependencies, network topology, and data classification. Dependency mapping at this phase determines which workloads must move together and which can be migrated independently. Incomplete discovery is the primary cause of post-migration outages.

Assessment and prioritization. Each asset is evaluated against migration readiness criteria: licensing portability, network latency sensitivity, regulatory data residency requirements, and technical compatibility with the target platform. Assets are scored and assigned a migration wave — typically Wave 1 (low-risk, low-dependency), Wave 2 (moderate complexity), and Wave 3 (high-dependency or compliance-constrained).

Migration execution. The selected migration strategy (see Classification boundaries) is applied to move workloads. Execution tooling includes cloud-native migration services, agent-based replication tools, and database migration utilities. Execution for large estates is parallelized across migration waves.

Testing and validation. Post-migration testing covers functional correctness, performance benchmarks against pre-migration baselines, security control verification, and data integrity checks. The cloud monitoring and observability reference describes the instrumentation frameworks applied during this phase.

Cutover and decommission. Traffic is redirected to the migrated environment, rollback procedures are validated, and the source environment is decommissioned after a defined stabilization period. Decommission is frequently delayed, creating parallel-running cost overhead.

Causal relationships or drivers

Organizations migrate to cloud environments under pressure from three primary driver categories: economic, operational, and regulatory.

Economic drivers. On-premises data center contracts, hardware refresh cycles, and colocation lease renewals create forcing functions that require a cloud destination decision on a fixed timeline. The US federal government's cloud-first policy, formalized through the Federal Cloud Computing Strategy (Cloud Smart) published by the Office of Management and Budget, establishes cost reduction and IT modernization as explicit mandates for civilian agencies — creating procurement-driven migration pressure across the public sector.

Operational drivers. Legacy infrastructure constrains the adoption of container orchestration, serverless computing, and CI/CD pipeline automation. On-premises hardware imposes fixed capacity ceilings, while cloud platforms provide the scalability and elasticity required for variable workload patterns.

Regulatory drivers. Frameworks including FedRAMP, HIPAA, and PCI DSS have developed cloud-compatible compliance paths. The Federal Risk and Authorization Management Program (FedRAMP) requires federal agencies to use FedRAMP-authorized cloud services, directly mandating migration away from non-authorized on-premises or legacy hosting arrangements for regulated workloads. Cloud compliance and regulations covers the full regulatory landscape affecting cloud-hosted workloads.

Classification boundaries

Migration strategies are classified by the degree of architectural change applied to the workload during migration. The most widely referenced taxonomy uses six categories, commonly called the "6 Rs," originating from Gartner research and subsequently adopted in AWS and Google Cloud migration frameworks.

Rehost (Lift-and-Shift). The workload is moved to cloud infrastructure without code or architectural modification. The fastest strategy with the lowest immediate technical risk, but produces no cloud-native optimization. Applications running on virtual machines are cloned or replicated to equivalent cloud VM instances.

Replatform (Lift-Tinker-and-Shift). Minor configuration changes are applied without full re-architecture — for example, migrating a database from a self-managed instance to a managed database service while retaining the same database engine. Performance and operational overhead improvements are achieved without application code changes.

Repurchase (Drop-and-Shop). The existing application is replaced by a SaaS alternative. On-premises CRM or ERP installations are decommissioned and replaced with cloud-delivered equivalents. Data migration and user retraining are the primary execution costs.

Refactor / Re-architect. Application code is restructured to leverage cloud-native services — event-driven architectures, managed Kubernetes clusters, or serverless functions. The highest implementation cost and longest timeline, but produces the greatest long-term operational efficiency.

Retire. Workloads that are no longer business-critical are decommissioned without migration. Discovery phases typically identify between 10% and 20% of inventory as retirement candidates (Gartner, Cloud Migration Strategy, 2022).

Retain. Workloads that cannot be migrated within the planning horizon — due to regulatory constraints, hardware dependencies, or technical blockers — remain in place. Retain is a formal classification, not a default outcome of failed migration planning.

Tradeoffs and tensions

Speed versus optimization. Rehost migrations can be completed at the fastest pace but produce cloud bills equivalent to or higher than on-premises costs because workloads are not sized or architected for elastic pricing models. Refactoring reduces long-term cost but requires 6–18 month timelines for complex applications.

Centralized versus wave-based execution. Migrating all workloads simultaneously reduces the duration of parallel-running environments but concentrates risk. Wave-based migration distributes risk but extends the period during which duplicate infrastructure costs accumulate across both source and destination environments. Cloud cost management frameworks address the financial modeling required to evaluate these tradeoffs.

Security posture continuity. Security controls designed for perimeter-based on-premises architectures do not translate directly to cloud environments. The cloud shared responsibility model redistributes control between the provider and the customer differently across IaaS, PaaS, and SaaS tiers — and migrations that fail to remap security controls to the new model produce compliance gaps. The Cloud Security Alliance (CSA) Cloud Controls Matrix (CCM) provides 197 control objectives mapped to cloud service types and is used to audit security continuity during migration programs.

Data residency and latency. Selecting a cloud region for proximity to users reduces latency but may conflict with data residency requirements under state privacy statutes or sector-specific regulations. Organizations operating in multiple jurisdictions must resolve these constraints before target region selection is finalized.

Common misconceptions

Misconception: Cloud migration automatically reduces infrastructure costs. Rehost migrations without rightsizing typically produce cloud costs that match or exceed on-premises spend because cloud VM pricing is based on reserved or on-demand rates that do not account for actual utilization. Cost reduction requires workload rightsizing, reserved instance commitments, and architectural changes — none of which are inherent to the act of migration itself.

Misconception: Migration is a one-time project. Cloud environments require continuous optimization, monitoring, and security management after migration. The migration program concludes; the operational model does not revert to a steady state. Post-migration activities including disaster recovery testing and backup validation are ongoing operational requirements.

Misconception: Lift-and-shift preserves all licensing terms. Software vendor licenses for on-premises deployments frequently do not permit cloud deployment, or require separate cloud licensing SKUs. Microsoft, Oracle, and IBM publish specific cloud licensing policies that differ materially from perpetual on-premises terms. Assuming license portability without vendor confirmation is a documented source of audit exposure.

Misconception: Data migration is a subset of application migration. Data migration carries independent constraints: transformation requirements, validation at landing, regulatory retention schedules, and encryption-in-transit obligations. Treating data migration as secondary to application migration produces data integrity issues that are costly to remediate post-cutover.

Checklist or steps (non-advisory)

The following phase sequence reflects the standard migration lifecycle as documented in NIST SP 500-322 (Evaluation of Cloud Computing Services Based on NIST SP 800-145) and the AWS Migration Acceleration Program framework.

1. Asset discovery — catalog all servers, applications, databases, and network dependencies in the source environment.
2. Dependency mapping — document inter-application communication paths, shared services, and external integrations.
3. Data classification — identify regulated, sensitive, and public data assets subject to residency or handling constraints.
4. Target architecture definition — select cloud deployment model, region(s), and service tiers aligned to workload requirements and cloud service models.
5. Migration strategy assignment — classify each workload using the 6-R taxonomy and assign to a migration wave.
6. Security and compliance mapping — remap on-premises controls to cloud equivalents using CSA CCM or NIST SP 800-53 control families; identify gaps. Reference cloud identity and access management for IAM control continuity.
7. Network architecture configuration — provision virtual networks, subnets, firewalls, and connectivity (VPN or direct connect) in the target environment. See cloud networking.
8. Pilot migration execution — migrate a low-risk Wave 1 workload, validate, and document lessons learned before broader execution.
9. Staged migration execution — execute migration waves sequentially, applying rollback procedures at each wave boundary.
10. Post-migration validation — run functional tests, performance benchmarks, security scans, and data integrity checks.
11. Cutover and traffic redirection — redirect production traffic, maintain rollback capability for a defined stabilization window.
12. Source environment decommission — terminate source resources after stabilization; document decommission in cloud cost management records.

Reference table or matrix

Migration phase risk and dependency matrix:

For a broader context of how migration fits within the full cloud technology landscape, the Cloud Computing Authority index provides the structured reference map across cloud service domains, from cloud architecture design to cloud vendor lock-in risk management.