The six Rs of cloud migration (retire, retain, change, rehost, re-platform, and refactor), have been a staple for a few years. I’m undecided the place they got here from, however you’ll discover them listed in a single type or one other on many cloud migration mission slides.

The rationale for the six Rs is straightforward. Now we have workloads, that are sometimes purposes and paired information not operating on a cloud, and we’re trying to place them into classes as to what will likely be performed with them sooner or later, within the cloud or not. Right here’s the quick clarification of the six Rs:

• Retire: Take away a workload totally or finish of life it.
• Retain: Hold it the place it’s.
• Change: Discover SaaS techniques or different analogs for the workload.
• Rehost: Raise and shift it, or simply transfer it to the cloud with few or no modifications. For instance, transfer from Linux on premises to Linux within the cloud. I see this otherwise than refactoring, in that we’re simply altering an utility so it runs nicely on a cloud platform and never particularly leveraging cloud-native providers.
• Re-platform: If we will’t discover platform analogs on the goal cloud, we transfer to a brand new platform, resembling Linux to Home windows. Generally new databases and different platforms change as nicely. Thus, the workload must be modified to accommodate the brand new platform, however we’re not leveraging cloud-native providers.
• Refactor: Closely modify (re-code) the workloads to benefit from cloud-native options resembling cloud safety, governance, monitoring, auditing, and so on.

After all, simply to confuse issues, I’ve seen the six Rs with totally different phrases (resembling “repurchase” as a substitute of “change”) and even totally different definitions of the Rs. So, don’t get on me if what you’re utilizing doesn’t match the above precisely. For our functions it actually doesn’t matter. 

Once we’re a whole bunch and typically hundreds of workloads, we’re forcing these workloads into one of many R classes. This permits us to decide to a path for these workloads, from easy and low cost (retire, retain, and rehost) to complicated and expensive (re-platform and refactor).

My drawback with the six Rs is that they will restrict the paths that cloud architects can take and find yourself forcing a workload into a particular class that doesn’t actually outline what needs to be performed to that workload in transferring to the cloud. We might determine to rehost an utility, however what if it prices $100K to take action, whereas most different strategies price $1K per workload. What’s totally different?

Though I actually haven’t any beef with retire, retain, and change, it appears to me that many rehosting paths are very totally different however are nonetheless thought-about rehosting, in that we’re transferring to the identical platform on the cloud however sometimes not leveraging cloud-native providers. I might subdivide the rehosting R at the least three extra instances. For instance:

• Rehosting with no code adjustments
• Rehosting with some code adjustments
• Rehosting with many code adjustments (however not leveraging cloud-native providers so it’s not refactoring, or not transferring to a brand new platform or OS, so it’s not re-platforming)

This gives a extra correct path. I do know that many groups migrating purposes are doing this already. I sometimes present metrics such because the variety of traces of code that have to be modified and/or testing cycles. Breaking these out would make it simpler to grasp the extent of effort and thus price and time.

You are able to do the identical with re-platform and refactor. I might break these into a number of particular classes that might higher make clear what must be performed to these workloads to higher goal the correct migration path. Additionally, it might extra precisely estimate the prices and dangers.

That is already underway in ad-hoc, casual makes use of. I’ve damaged some tasks right down to as many as 20 totally different Rs, not at all times implementing the rule that the class wants to start with an R. Others are doing the identical, even perhaps you.

Am I making issues extra complicated and presumably extra obscure? You guess I’m. Nevertheless, the concept is to not add extra work to categorizing workloads transferring to the cloud, it’s about doing a greater job in understanding the true prices and dangers of constructing the migration work the primary time.