Cloud Migration Authority - Cloud Transition Services Reference
Cloud migration encompasses the full lifecycle of moving an organization's digital assets — applications, data, workloads, and infrastructure — from on-premises environments or legacy hosting into cloud-based platforms. This reference covers the classification frameworks, operational mechanisms, common migration scenarios, and decision criteria that inform cloud transition planning. Understanding these structures is foundational to any cloud adoption in digital transformation program, where infrastructure choices shape the pace and cost of the broader change.
Definition and scope
Cloud migration is defined by the National Institute of Standards and Technology (NIST) in Special Publication 500-292 as the process of transitioning computing services — including storage, processing, and applications — to cloud environments characterized by on-demand access, resource pooling, and measured service delivery. The scope spans three deployment model targets: public cloud (shared infrastructure operated by a third-party provider), private cloud (dedicated infrastructure operated for a single organization), and hybrid cloud (integrated operation across both).
Migration scope typically includes four asset classes:
- Application workloads — business logic, APIs, and user-facing software
- Data repositories — structured databases, unstructured object stores, and archive data
- Infrastructure components — virtual machines, networking configurations, and identity systems
- Operational tooling — monitoring, logging, backup, and CI/CD pipelines
The breadth of a migration program is categorized in the widely referenced Gartner "5 Rs" framework — Rehost, Refactor, Revise, Rebuild, Replace — which has been expanded by AWS and other major providers into a "6 Rs" or "7 Rs" taxonomy that adds Retire and Retain as explicit disposition options. These taxonomies establish formal classification boundaries for migration planning, distinguishing lift-and-shift operations from architectural transformation efforts. Organizations planning workload disposition should align these classifications to their digital transformation strategy framework before scoping contracts with vendors.
How it works
A cloud migration follows a phased operational structure. The Cloud Migration Factory model, documented by AWS Professional Services and referenced by the Cloud Security Alliance, identifies five discrete phases:
- Assess — Inventory all workloads, assign 6 Rs disposition codes, quantify dependencies, and establish a Total Cost of Ownership (TCO) baseline.
- Mobilize — Establish the landing zone (network topology, identity federation, security guardrails), train teams, and validate tooling chains.
- Migrate — Execute workload migrations in prioritized waves, typically starting with low-complexity Rehost candidates before addressing Refactor workloads.
- Operate — Transition operational ownership to cloud-native toolsets; decommission source infrastructure.
- Optimize — Apply rightsizing, reserved-instance pricing, autoscaling, and architectural improvements to reduce unit costs and improve resilience.
Dependency mapping is the highest-risk step in the Assess phase. The NIST Cloud Computing Reference Architecture (SP 500-292) identifies inter-service dependencies as a primary driver of unplanned outages during migration cutover windows. Organizations migrating more than 200 distinct workloads typically require automated discovery tooling — such as AWS Application Discovery Service or Microsoft Azure Migrate — to produce accurate dependency graphs before sequencing migration waves.
Security posture must be established before the first workload moves. The Center for Internet Security (CIS) publishes benchmark controls for major cloud platforms at cisecurity.org, providing configuration baselines for identity access management, encryption at rest, and network segmentation. These baselines integrate directly with cybersecurity in digital transformation governance requirements.
Common scenarios
Three migration patterns account for the majority of enterprise cloud transitions:
Datacenter Exit (Full Rehost): An organization decommissions physical datacenter capacity by moving virtual machines directly to cloud equivalents — typically IaaS (Infrastructure as a Service) resources. This approach minimizes application-layer changes but carries the highest long-term cost due to over-provisioned VM sizing and licensing carryover. Datacenter exit programs are time-bound by lease expiration or hardware end-of-life cycles.
Application Modernization (Refactor/Rebuild): Monolithic applications are decomposed into microservices or containerized workloads targeting PaaS (Platform as a Service) or serverless runtimes. This pattern delivers the greatest operational efficiency gains but requires 40–60% more engineering effort than Rehost equivalents, according to McKinsey's 2023 analysis of enterprise cloud programs. The digital transformation legacy systems challenge is most acute in this scenario, where technical debt accumulated over 10–20 year application lifespans must be resolved during migration.
SaaS Displacement (Replace): On-premises software instances — ERP, CRM, collaboration platforms — are retired in favor of equivalent SaaS subscriptions. This eliminates infrastructure management overhead entirely. Microsoft 365 displacement of on-premises Exchange Server deployments represents the highest-volume example of this pattern across US enterprise organizations.
Hybrid cloud migration scenarios, where regulated data workloads remain on-premises while unregulated compute migrates to public cloud, are common in healthcare, financial services, and federal contexts — each governed by sector-specific compliance frameworks including HIPAA, SOC 2, and FedRAMP respectively.
Decision boundaries
Migration strategy decisions hinge on four primary variables: regulatory residency requirements, application architecture suitability, total cost trajectory, and organizational change capacity.
Rehost vs. Refactor: Rehost is appropriate when time-to-cloud is the primary constraint and the application lifecycle is under 36 months. Refactor is appropriate when the application will run for more than 5 years and operational cost reduction is a priority — the longer-term savings from cloud-native architecture typically offset the higher upfront engineering investment beyond a 24–36 month horizon.
Public vs. Private vs. Hybrid: FedRAMP authorization requirements mandate government agencies use FedRAMP-authorized cloud offerings, documented at fedramp.gov. Healthcare organizations subject to HIPAA must execute Business Associate Agreements (BAAs) with cloud providers before placing protected health information in any cloud environment. These regulatory constraints often force hybrid architectures regardless of cost optimization preferences.
Build vs. Buy migration tooling: Organizations migrating fewer than 50 workloads can typically operate with native provider migration toolsets at no additional licensing cost. Migrations exceeding 500 workloads present a business case for commercial migration orchestration platforms, which integrate with digital transformation governance frameworks for change-control and rollback management.
Sequencing decisions — which workload moves first — should be governed by a risk-complexity matrix. Low-risk, low-complexity workloads (development environments, static web content, batch processing jobs) are standard first-wave candidates. High-complexity, high-dependency workloads (core transactional databases, real-time integration hubs) are deferred until the landing zone and operational model are validated through earlier waves. This sequencing logic should be embedded in the digital transformation roadmap phases before migration execution begins.