Maybe cloud migration needs more than six Rs

The six Rs of cloud migration (retire, retain, replace, rehost, re-platform, and refactor), have been a staple for many years. I’m not sure where they came from, but you’ll find them listed in one form or another on many cloud migration project slides.

The reason for the six Rs is simple. We have workloads, which are typically applications and coupled data not running on a cloud, and we’re looking to place them into categories as to what will be done with them in the future, in the cloud or not. Here’s the short explanation of the six Rs:

• Retire: Remove a workload entirely or end of life it.
• Retain: Keep it where it is.
• Replace: Find SaaS systems or other analogs for the workload.
• Rehost: Lift and shift it, or just move it to the cloud with few or no modifications. For example, move from Linux on premises to Linux in the cloud. I see this differently than refactoring, in that we’re just changing an application so it runs well on a cloud platform and not specifically leveraging cloud-native services.
• Re-platform: If we can’t find platform analogs on the target cloud, we move to a new platform, such as Linux to Windows. Sometimes new databases and other platforms change as well. Thus, the workload needs to be modified to accommodate the new platform, but we’re not leveraging cloud-native services.
• Refactor: Heavily modify (re-code) the workloads to take advantage of cloud-native features such as cloud security, governance, monitoring, auditing, etc.

Of course, just to confuse things, I’ve seen the six Rs with different terms (such as “repurchase” instead of “replace”) or even different definitions of the Rs. So, don’t get on me if what you’re using does not match the above exactly. For our purposes it really does not matter. 

When we’re looking at hundreds and sometimes thousands of workloads, we are forcing these workloads into one of the R categories. This allows us to commit to a path for those workloads, from simple and cheap (retire, retain, and rehost) to complex and costly (re-platform and refactor).

My problem with the six Rs is that they can limit the paths that cloud architects can take and end up forcing a workload into a specific category that does not really define what should be done to that workload in moving to the cloud. We may decide to rehost an application, but what if it costs $100K to do so, whereas most other methods cost $1K per workload. What’s different?

Although I really have no beef with retire, retain, and replace, it seems to me that many rehosting paths are very different but are still considered rehosting, in that we’re moving to the same platform on the cloud but typically not leveraging cloud-native services. I would subdivide the rehosting R at least three more times. For example:

• Rehosting with no code changes
• Rehosting with some code changes
• Rehosting with many code changes (but not leveraging cloud-native services so it’s not refactoring, or not moving to a new platform or OS, so it’s not re-platforming)

This provides a more accurate path. I know that many teams migrating applications are doing this already. I typically provide metrics such as the number of lines of code that need to be changed and/or testing cycles. Breaking these out would make it easier to understand the level of effort and thus cost and time.

You can do the same with re-platform and refactor. I would break those into several specific categories that would better clarify what needs to be done to those workloads to better target the right migration path. Also, it would more accurately estimate the costs and risks.

This is already underway in ad-hoc, informal uses. I’ve broken some projects down to as many as 20 different Rs, not always enforcing the rule that the category needs to begin with an R. Others are doing the same, perhaps even you.

Am I making things more complex and possibly more difficult to understand? You bet I am. However, the idea is not to add more work to categorizing workloads moving to the cloud, it’s about doing a better job in understanding the true costs and risks of making the migration work the first time.