In our recent article “Cloud migration: Which cloud migration strategy is right for you?” we’ve started discussing cloud migration strategies together with their rewards and implications. We continue reviewing the topic and move to the remaining 3R’s which are Repurchase, Retain and Remove.
In terms of cloud migration, the 6R’s are Rehost, Replatform, Refactor, Repurchase, Retain and Remove. The options abound, as there’s no one-fits-all-solution when it comes to migrating your business to the cloud. Applications vary in age, size and complexity, so do the options that best suit their respective migration needs.
Before we move on…
…would you mind revising the first three strategies?
Rehost will be the No. 1 option for large-scale enterprise migration. Rehost is also a way-out when an organization had no cloud migration plans in the short term, however faced an urgent necessity to do so in the view of a compelling event (immediate evacuation of a datacenter or hosting provider, etc.). An application that lacks a well-detailed architecture or a roadmap, or an off-the-shelf application that allows little to no changes also migrate to the cloud quickly and cost-effectively through rehost. Rehost guarantees immediate cost reduction that can make up to an impressive 30%, after all. All without introducing almost any changes to the code!
Replatform is a combination of the simplicity of rehost and cloud-nativeness of refactor. Although rehost ensures a 30% infrastructure-related costs reduction, it is impossible to achieve true optimization here. Rehost introduces no cloud-native features (at least during the relocation phase) into your application, while replatform, on the contrary, brings more innovation into your portfolio. Some on-prem and cloud components, such as load balancers, are swapped during replatform, thus ensuring higher application performance, which is unavailable for rehost-enthusiasts. Replatform is perfect in case your objective is to add a bit of automation to your tasks handling or get rid of some cumbersome infrastructure that holds back your performance and scalability.
Your cloud migration strategy of choice is refactor if you’re ready to invest into an effort and time-consuming endeavor that’ll bring significant rewards in the long run. A refactored application benefits dramatically from cloud-native features from leading cloud providers such as AWS, Microsoft Azure or IBM Cloud, and others. Refactor reduces compute, storage, network, and maintenance costs along with boosting application performance.
Now, as we’ve recalled previously covered options, we proceed with the new ones.
Repurchase (Replace)
Repurchase is basically a replacement of your existing system with some commercial software. This solution most often means discarding a legacy application or application platform, and deploying commercially available software delivered as a service (Imperva). So, you move to cloud-based services to manage your human resources, customer relationship or content. As an example, it can be Salesforce.com as a CRM, Workday as an HR system, or Drupal used instead of your current CMS.
Its huge benefit is in the reduction of development costs. Therefore, scarce customization opportunities will be the implication. Vendor lock-in can also be an issue, for you won’t be up to decide on policies or prices. Beware also of interoperability issues along with disposal, commissioning and decommissioning costs that can be a rather annoying factor. However, after all, you’ll be operating your assets through a first-class SaaS solution from accomplished cloud providers. Moreover, repurchase will minimize the amount of services and applications that you had to manage yourself. Cloud Datastore, Cosmos DB, or Dynamo (known for their scalability and availability) could be nice examples of the managed options that become available through repurchase.
Repurchase is a great option to put an end to sky-high licensing fees as it offers pay-as-you-go capabilities that will boost your cost efficiency, if initial investments do not scare you off. Extra plus of Microsoft Azure, for example, is their billing model. Microsoft Azure billing model is such that you only pay for resources when they are powered on. Application development stages like Dev, test, UAT, etc. in an on-premises workload might require you to purchase a license for each application in that environment. In Microsoft Azure you would only pay for those licenses when those resources are powered on and provisioned (SPR).
Retain
In case businesses choose to retain their assets they leave their portfolio exactly as it is. Why not leverage the power of the cloud if that is exactly what business community is up to today? The thing is, moving to the cloud sometimes can be impractical because of various factors. Firstly, you may have only finished an upgrade of your on-prem elements and now your objective is riding out the depreciation value. Secondly, some applications may be risky to migrate to the cloud as their operation is highly critical or the application is too complex, with multiple severe interdependencies. In the third scenario, moving to the cloud will incur excessive costs for the organization. Finally, why businesses leave their portfolio on premises is that they are simply comfortable with it, having a portion of their portfolio in the cloud. The letter, a hybrid model, is actually a pretty common way-out for those willing to benefit from cloud-nativeness and reluctant to put all their trust (i.e., portfolio) in the cloud.
Retain is also an option when you have ambitious plans to refactor your portfolio later on. Hence, instead of rushing to optimize your applications without proper funding and talents, or with no carefully planned strategy in mind (which is a huge taboo if you opt for refactor), leave the things as they are and put them on a hiatus.
The last but not least, the reason behind the retain strategy may also be a scheduled decommissioning of the portfolio elements. Migrating to-be decommissioned elements is not a well-reasoned move as ROI won’t be high, especially in the case of complex legacy applications.
Remove (Retire)
Although we mention this option as the last available, removing the irrelevant portfolio elements actually is the first thing that organizations do before starting a migration campaign. Irrelevant and useless assets are generally found at the Discovery stage that precedes the real migration fun. As a rule, 10 to 20% of your current portfolio can be removed without sacrificing the overall performance. Additionally, retiring a portion of your portfolio, if done properly, ensures better resource allocation, lower running costs, boosts efficiency and reduces your security efforts only to that needed to ensure the integrity of the in-demand services.
Summary
We have covered the most common migration strategies (Rehost, Replatform, Refactor, Repurchase, Retain and Remove) so that you could plan your cloud adoption wisely and consistently. However, the list of issues that will potentially claim your attention before you start migrating your portfolio to the cloud is very extensive and reaches far beyond the 6R’s. See the bullets below as an example of such issues:
- What portions of your portfolio do you need to move?
- Is your app well-architected and ordered for a safe cloud migration?
- Do you know how to ensure the proper compliance and security of each of your applications once they are in the cloud?
- Did you backup all your data?
- What are the RPO/RTOs of each application?
In other words, safe cloud migration without unwanted “side effects” cries for attention for details and is impossible without adequate answers to many operation-related questions. That’s why cloud migration is preceded by a number of preparatory phases among which are Discovery, Planning and Assessment, Designing and Build, etc. See them all covered in the upcoming posts on Qulix Systems blog.
Also check out our upcoming posts about migration planning, system testing, follow-up and maintenance of your applications in the cloud.
