Cloud Migration Language

Lift-and-shift (also called Rehost) means moving an application to the cloud with no code changes — you simply provision equivalent virtual machines in the cloud and transfer the workload. It is the fastest migration strategy and requires minimal application knowledge, making it appropriate when time-to-cloud is the priority or when the application will be decommissioned shortly after migration. The trade-off is that the application does not take advantage of cloud-native features, so operational costs may remain high.

The 6 Rs are the canonical cloud migration strategy framework: Rehost (lift-and-shift — move without changes), Replatform (make small optimisations, e.g. switch to a managed database service), Refactor/Rearchitect (redesign for cloud-native architecture), Repurchase (replace with a SaaS product), Retire (decommission the application), and Retain (keep on-premises for now). Selecting the right R for each application is the output of a migration assessment.

A migration wave is a batch of applications migrated together in a single phase. Applications are sequenced into waves based on dependency mapping (interdependent apps must be in the same or adjacent waves), business criticality (less critical apps often go first as a learning exercise), and technical complexity (simple stateless applications before stateful or tightly coupled ones). The first wave is typically a pilot with low-risk workloads to validate the migration process before scaling.

Replatforming (also called "lift-tinker-and-shift") involves making modest optimisations while migrating — for example, moving from a self-managed database to a managed cloud database service (Amazon RDS, Azure SQL) without changing application code. Refactoring (Rearchitect) involves significantly redesigning the application to use cloud-native services — breaking a monolith into microservices, adopting serverless functions, or rebuilding on containers. Replatforming is faster and lower risk; refactoring delivers more long-term cloud benefits.

A cutover is the moment when production traffic is switched from the source environment to the target cloud environment. It is typically preceded by a cutover rehearsal (a dry run in a non-production environment to validate the procedure and timing), a cutover window (a scheduled low-traffic period to minimise business impact), and a parallel run (operating both environments simultaneously to validate the cloud system before switching). A rollback plan must be prepared and tested before every cutover.

A Cloud Adoption Framework (CAF) is a structured methodology provided by cloud vendors (AWS CAF, Azure CAF, Google Cloud adoption framework) that guides organisations through cloud migration. It typically covers six perspectives or pillars: Business, People, Governance, Platform, Security, and Operations. The CAF helps organisations assess their migration readiness, design a landing zone (the foundational cloud environment), establish a Cloud Center of Excellence (CCoE), and define a cloud operating model.

Total Cost of Ownership (TCO) analysis compares the full cost of running workloads on-premises versus in the cloud. It accounts for hardware, software licences, power, cooling, facility costs, and staff time on the on-premises side, versus compute, storage, networking, and managed service fees in the cloud. A complete TCO analysis also includes migration costs, training costs, and the timeline to break-even. Outputs typically include a CapEx-to-OpEx shift narrative and a payback period projection.

A landing zone is the pre-configured, security-hardened cloud environment into which migrated workloads are deployed. It establishes foundational infrastructure: account or subscription structure, network topology (VPCs, subnets, peering), identity and access management policies, logging and monitoring baselines, and guardrails. Landing zones are typically deployed using infrastructure-as-code and serve as the standardised target environment for all migration waves.

Hypercare is the intensive support period immediately after a migration cutover, during which the migration and operations teams provide elevated monitoring, rapid incident response, and close collaboration with application owners. It typically lasts two to four weeks. The hypercare period ends when the system has demonstrated stable performance against defined success criteria. Hypercare language is common in migration status reports and stakeholder communications.

A migration factory is a repeatable, industrialised process for migrating large numbers of applications efficiently. It applies assembly-line principles: standardised runbooks, reusable automation scripts, and specialist teams performing the same tasks at scale. Migration factories are used when an organisation needs to migrate hundreds or thousands of applications within a fixed programme timeline. The factory model reduces per-application cost and accelerates delivery compared to treating each migration as a bespoke project.