Perhaps cloud migration wants greater than six Rs

The six Rs of cloud migration (retire, retain, exchange, 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 venture slides.

The explanation for the six Rs is straightforward. Now we have workloads, that are sometimes functions and matched information not working on a cloud, and we’re trying to place them into classes as to what will likely be accomplished with them sooner or later, within the cloud or not. Right here’s the brief clarification of the six Rs:

• Retire: Take away a workload solely or finish of life it.
• Retain: Preserve it the place it’s.
• Exchange: 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 in a different way than refactoring, in that we’re simply altering an utility so it runs properly 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, equivalent to Linux to Home windows. Generally new databases and different platforms change as properly. 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 make the most of cloud-native options equivalent to cloud safety, governance, monitoring, auditing, and so forth.

After all, simply to confuse issues, I’ve seen the six Rs with completely different phrases (equivalent to “repurchase” as a substitute of “exchange”) and even completely 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. 

After we’re taking a look at a whole bunch and generally hundreds of workloads, we’re forcing these workloads into one of many R classes. This enables 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 selected class that doesn’t actually outline what needs to be accomplished to that workload in shifting to the cloud. We could resolve to rehost an utility, however what if it prices $100K to take action, whereas most different strategies price $1K per workload. What’s completely different?

Though I actually don’t have any beef with retire, retain, and exchange, it appears to me that many rehosting paths are very completely different however are nonetheless thought-about rehosting, in that we’re shifting to the identical platform on the cloud however sometimes not leveraging cloud-native providers. I might subdivide the rehosting R no less than 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 shifting to a brand new platform or OS, so it’s not re-platforming)

This supplies a extra correct path. I do know that many groups migrating functions are doing this already. I sometimes present metrics such because the variety of traces of code that should 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 may higher make clear what must be accomplished to these workloads to higher goal the fitting 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 initiatives all the way down to as many as 20 completely different Rs, not at all times imposing the rule that the class wants to start with an R. Others are doing the identical, maybe even you.

Am I making issues extra complicated and probably extra obscure? You guess I’m. Nevertheless, the thought is to not add extra work to categorizing workloads shifting 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.