Cloud Migration Strategy

A cloud migration strategy is the choice you make, workload by workload, about how a single application gets to the cloud. The decision is per application, not per company — the same business can retire one system, rehost another and refactor the next.

Amazon Web Services names the full set of options. Its migration guidance lists seven migration strategies known as the 7 Rs: retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect.

Not every option suits every programme. The same guidance says refactoring is not recommended for large migrations, because rebuilding an application mid-move is the hardest of the seven to manage across hundreds of systems.

The destination has had a settled definition since September 2011, when the National Institute of Standards and Technology described cloud computing as on-demand network access to a shared pool of configurable computing resources.

Key takeaways

• A cloud migration strategy is picked per workload, so one company routinely runs several different strategies at the same time.
• Amazon Web Services groups the options into seven named strategies, widely called the 7 Rs.
• Retire is usually the cheapest outcome, because a switched-off system costs nothing to run in either location.
• Sequencing across waves belongs to the cloud strategy roadmap, while the migration strategy only decides what happens to each application.

How it works

You pick a strategy once per application, not once per company. Each workload gets assessed on its own terms — how it is built, who uses it, what it costs to keep — and the answer for one says nothing about the next.

Three things usually decide the answer: how much the application has to change, how much risk the business will carry, and how long the team has. Cheap and fast pulls toward rehost.

The seven options differ in how much changes during the move.

That assessment is application portfolio management doing its job: a full list of what you run, who owns each item and what it costs to keep alive.

Application rationalization trims the list before anyone migrates. Every application you cut here is an application you never pay to move, test or re-license.

The cheapest strategy on the table is usually application retirement, because a switched-off system costs nothing to run in either place.

Sequencing is not part of this decision. Which wave a workload joins belongs to the cloud strategy roadmap, while the migration strategy only decides what happens when that workload’s turn arrives.

Once the per-workload calls are made, they land in a transition plan that a delivery team works through in order.

Where whole racks of servers move rather than individual applications, the work is usually shaped as infrastructure outsourcing, with a provider taking the hardware layer.

The seven are not a ranking. Refactor is not better than rehost, just more expensive, and a system due for retirement in eighteen months rarely earns that spend.

Review the calls before delivery starts. A strategy chosen during a portfolio assessment can look wrong six months later, once someone has actually opened the application and read its dependencies.

Record the reason, not just the letter. A portfolio that logs rehost without logging why will be re-argued from scratch at the next review, usually by someone new.

Examples

The 7 Rs get easier to hold once you attach each one to a real decision. Amazon Web Services is explicit about which strategies dominate at scale, and the same pattern shows up in commercial data-centre exits.

For large migrations, Amazon Web Services says the common strategies are rehost, replatform, relocate and retire. Refactor is deliberately left off that list.

A finance team running an ageing on-premise reporting tool usually repurchases. Swapping it for a subscription product is cheaper than moving a system nobody wants to maintain.

A logistics firm with a custom warehouse application built in 2012 is a replatform candidate. It moves mostly intact, with the database swapped for a managed service on the way.

A bank running an internal payroll system nobody has touched since 2014 usually relocates it wholesale. The platform underneath moves; the application itself never notices.

A media company facing a data-centre exit deadline rehosts almost everything it keeps. Speed beats elegance when a lease ends in March, and the tuning work happens afterwards.

A government agency swapping a bespoke case-management tool for a commercial platform is repurchasing, even though nobody in the building calls it a migration.

Anything still handling regulated records under a fixed retention clause often gets retained for a cycle. Nothing moves — and the decision is revisited at the next contract break.

Related terms

These five terms surround the per-workload decision. Three describe how you build and trim the candidate list, and two describe the contract shapes that carry the workloads once each strategy is chosen.

• Data Center Outsourcing: the handover of physical facilities that a migration programme is often trying to exit.
• Application Maintenance Outsourcing: ongoing third-party support for applications once they have landed.
• Application Portfolio Management: the running inventory of what you own, who uses it and what it costs.
• Application Rationalization: the cull that removes duplicate or unused systems before a move.
• Application Retirement: the orderly shutdown and archiving of a system nobody needs running.

FAQ

What are the 7 Rs of cloud migration?

Retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect. Amazon Web Services publishes the list as its standard set of migration strategies, and most consultancies now use the same seven labels.

Can one company use more than one strategy?

Yes, and almost every large programme does. The strategy is chosen per application, so a single portfolio commonly carries four or five different answers at once.

Which strategy is fastest?

Rehost is usually the quickest, because the application moves with minimal change. Speed comes at a cost, though: whatever was inefficient on-premise stays inefficient in the cloud, and the cleanup lands on a later budget.

Is a migration strategy the same as a migration plan?

No. The strategy is the per-workload decision, while the plan is the schedule and the runbook that deliver it. You need the decision before the schedule makes sense.

Should an outsourcing provider choose the strategy?

A provider will usually recommend one per workload, but the accountability for the call stays with the client who owns the application.

Compare vetted migration and infrastructure partners in the Outsource Accelerator directory.