“Moving to the cloud” sounds like one decision. In practice it is one decision per app. The accounting software, the file server, the company website and the old intranet each have a different best route, and treating them all the same is how migrations go over budget.

The cloud industry uses “the 7 Rs” to name the options. Here they are without the jargon, in order from least change to most.

The seven options

Retire: switch it off

Most server rooms have systems nobody uses: an old intranet, a reporting server for a team that no longer exists, a test machine from three years ago. Retiring them is the cheapest migration there is. Keep a backup of the data, agree a date, and turn them off.

Retain: keep it where it is, for now

Some things shouldn’t move yet: a machine controlling equipment on the factory floor, a door attendance system wired into the building, or an app the vendor will only support on site. Retaining is a decision, not a failure. Note why, and look again in a year.

Rehost: lift and shift

Copy the server into the cloud as a virtual machine and run it there unchanged. It is the fastest way to empty a server room and the least risky for the people using the app. The downside: you carry over its inefficiencies, so plan to right-size it after the move. Tally on a cloud server is a typical rehost.

Relocate: move the VMware platform

If you run VMware, you can move whole groups of VMs to a VMware environment hosted by the cloud provider, without converting each one. It is the quickest route for large VMware estates, especially when a renewal deadline is close.

Repurchase: switch to a subscription

Instead of moving the software, replace it with a service that does the same job. The classic example is an office mail server replaced by a subscription email service. You stop running and patching the software; you start paying per user.

Replatform: lift and tune

Move the app, but swap one part for something the cloud runs for you. The most common case: the app stays as it is, but its database moves to a managed database service, so backups, patching and failover are handled. A little more work than rehosting, and usually worth it.

Refactor: rebuild for the cloud

Change the app itself so it can scale up and down, run in containers or use cloud services directly. It takes the most time and money, and pays off for apps that are core to your business and changing often, such as a customer portal or your own software product.

Deciding app by app

Ask these questions in order for each app. The first “yes” usually gives you the answer:

1. Is anyone still using it? No: retire.
2. Does it have to stay on site (hardware, vendor support, rules)? Yes: retain.
3. Is there a good subscription service that does the same job? Yes: consider repurchase.
4. Is it part of a large VMware group you want to move together? Yes: relocate.
5. Does it need to scale or change often? Yes: consider refactor.
6. Would a managed database or similar service save real work? Yes: replatform. Otherwise: rehost.

Common apps and our usual call

These are starting points, not rules. The right answer depends on how the app is built and what it is worth to the business.

Mixing the Rs in one migration

A real migration almost always uses several Rs at once. Picture a company with 16 systems in its server room. After an assessment, the picture often looks something like this:

• 3 are retired, because nobody has opened them in a year.
• 2 are retained on site, because they control equipment.
• 2 are repurchased: mail and file sharing move to subscription services.
• 2 are replatformed: their databases move to a managed service.
• 7 are rehosted as they are.

Only 7 of the 16 move as servers or virtual machines. That is why counting servers alone gives the wrong budget, and why the decision has to be made app by app. (This is an illustration, not a client example.)

Then plan the waves

Once each app has its R, group them into waves. Start with the least critical and simplest, so the team learns the process on systems that can afford a hiccup. Move the core business systems in later waves, each with a tested way back and a switch-over window outside working hours.

Where DevOps TechLab fits

We have run more than 165 migration projects and moved over 1,245 workloads, from a single Tally server in a few days to whole server rooms in about three months. Our free migration assessment gives every app you run an R, with the reason, so you know what moves how before anything is touched.