Cloud migration is rarely one technical move repeated across every application. An estate usually contains easy candidates, fragile legacy systems, commercial products, databases with hard dependencies, workloads that should be retired, and applications that need redesign before they can benefit from cloud services. Treating all of them the same is how migration programs become slow, expensive, and risky.<\/p>\n
A practical planning model is the \u201c7 Rs.\u201d AWS currently describes the seven strategies as retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect. Other providers use similar language with small naming differences. The value of the framework is not the letter count. It forces teams to decide what kind of change each workload actually needs before migration waves are scheduled.<\/p>\n
The right strategy depends on business value, technical constraints, risk tolerance, licensing, deadlines, operational maturity, and what the organization hopes to gain after the move.<\/p>\n
Migration discovery often reveals servers and applications that are barely used, duplicated, replaced by another system, or kept alive because nobody wants to own the shutdown decision. Moving them to the cloud preserves cost and complexity without preserving value.<\/p>\n
Retirement should be evidence-based. Confirm users, integrations, data-retention requirements, regulatory obligations, and downstream dependencies before decommissioning. A system with low CPU utilization may still perform an important monthly or quarterly function.<\/p>\n
When the evidence supports retirement, remove it deliberately. Archive required data, document the decision, update service catalogs, revoke identities, close firewall paths, and stop backups or monitoring that no longer serve a purpose.<\/p>\n
Some workloads should stay where they are for now. They may depend on specialized hardware, be near end of life, have unresolved licensing constraints, or be scheduled for replacement in a year. A rushed migration can consume more effort than the remaining business life of the application.<\/p>\n
Retain does not mean \u201cignore forever.\u201d Record why the workload is staying, which risk or dependency blocks migration, and when the decision will be reviewed. That keeps retained systems from becoming invisible technical debt.<\/p>\n
Hybrid architecture often exists because retain is legitimate. The cloud environment still needs secure connectivity, identity integration, monitoring, and operational procedures that span on-premises and cloud resources.<\/p>\n
Rehosting, often called lift-and-shift, moves a workload to cloud infrastructure while preserving most of its existing architecture. It can be effective when the primary objective is data-center exit, hardware refresh avoidance, or a fast move under a fixed deadline.<\/p>\n
The benefit is speed and lower application-change risk. The weakness is that the workload may carry old assumptions into a new cost model. A server sized for peak demand on purchased hardware may be wasteful when run continuously in the cloud. Manual patching, static capacity, and tightly coupled components remain manual and tightly coupled after the move.<\/p>\n
Rehost is therefore often a first step rather than a final state. Plan a later optimization phase so the organization does not declare victory once the virtual machines are merely running somewhere else.<\/p>\n
Relocate is useful when a whole virtualized or platform environment can move with little change to the individual applications. VMware-based migration patterns are a common example. The organization changes the hosting location while preserving much of the platform and operational model.<\/p>\n
This can reduce migration effort for large estates, but it also postpones some cloud-native benefits. The team should be clear about whether relocation is a long-term operating model or a bridge toward later modernization.<\/p>\n
The strategy is strongest when continuity and speed matter more than immediate architectural improvement.<\/p>\n
Sometimes the most sensible migration is not to migrate the application at all. A legacy CRM, collaboration system, ticketing platform, or analytics product may be better replaced by a SaaS service or newer commercial offering.<\/p>\n
Repurchase shifts work from infrastructure migration to data migration, integration, identity, process change, and user adoption. Those are not trivial concerns. A SaaS replacement can fail if teams underestimate data cleanup, custom workflows, reporting dependencies, or contractual requirements.<\/p>\n
The business case should compare total operating cost and capability, not just the hosting bill. A replacement can reduce infrastructure work while introducing subscription cost and provider dependency.<\/p>\n
Replatforming keeps the application\u2019s basic architecture but swaps some infrastructure for managed cloud services. A database might move from a self-managed VM to a managed relational service. An application may move into a managed container platform. File storage may become object storage.<\/p>\n
This strategy often gives a strong balance between speed and improvement. The application team gets operational benefits without taking on the risk of a full redesign. The challenge is understanding compatibility, performance, backup, monitoring, and provider-specific limits before the migration window.<\/p>\n