7 Rs of Migration

The 7 Rs of Migration are a workload-level decision framework, not seven sequential migration phases. Each application or component receives an appropriate strategy based on its business purpose, dependencies, technical constraints, and expected benefits. A portfolio can use all seven strategies, and different components of one application can follow different paths.

Rehost, often called lift and shift, moves a workload to cloud infrastructure with minimal application changes. For example, an organization might migrate a virtual machine running an internal reporting application to a cloud virtual machine. This can reduce migration time and avoid immediate code changes, but it usually preserves existing architectural limitations. Rehosting does not automatically deliver elasticity, high availability, or lower costs; engineers still need suitable instance sizing, security controls, backups, and operational processes.

Relocate moves an existing infrastructure environment to a compatible cloud environment without redesigning the applications within it. A typical example is moving a collection of virtual machines at the hypervisor or infrastructure-platform level while preserving their execution environment. Unlike rehosting individual servers onto cloud-native virtual machines, relocation emphasizes continuity of the existing platform. Compatibility, licensing, available destinations, and continued platform administration influence whether it is practical.

Replatform, sometimes called lift, tinker, and shift, introduces targeted platform changes without fundamentally redesigning the application. Moving a self-managed database to a compatible managed database service is a common example. The provider takes over some infrastructure administration, but engineers must still check database features, extensions, permissions, connection behavior, and performance. A managed destination does not make application compatibility automatic.

Repurchase replaces an existing application with another product, commonly software as a service. Replacing a custom customer-management system with a subscription application can reduce maintenance responsibilities, but requires evaluating functionality, integrations, data export, user training, and recurring charges. Refactor or re-architect instead changes the application's design to meet business requirements, such as separating independently scaling components or adopting event-driven processing. This can improve agility and resilience, but usually requires more development effort, testing, and organizational change.

Retain means keeping a workload in its current environment, at least for now. Regulatory constraints, latency dependencies, unsupported software, or an unfavorable business case can justify this choice. Retire means decommissioning a workload that no longer provides sufficient value. Before retirement, confirm ownership, dependencies, retention obligations, and any need to preserve historical data. Neither strategy is a failed migration decision.

Apply the framework after collecting an inventory and mapping application dependencies. Evaluate downtime tolerance, data volume, licensing, skills, security requirements, and total cost, including the temporary expense of running source and destination environments together. Group tightly connected components into migration waves where necessary, and define validation, cutover, and rollback criteria before execution.

Database replication is a migration technique, not an eighth R. An initial data load followed by ongoing change replication can support a rehost or replatform approach while reducing the final outage window. For example, replicate a database into a compatible managed destination, validate data and application behavior, pause source writes, allow replication to catch up, and switch connections. Replication alone does not convert incompatible schemas or guarantee zero downtime. For exam scenarios, distinguish the desired workload strategy from the tools and data-transfer mechanisms used to implement it.