Today, many organisations are racing to move on premise workloads to the cloud in support of digital transformation, with many adopting a cloud first policy. Some have executed their migration with a great level of success while others have struggled. Having a cloud migration strategy is critical for a successful migration, but also for the ongoing transformation of applications post-migration which is essential to keep the cost of cloud low, and the value derived from cloud high.
The migration strategy consists of multiple stages and the application assessment stage is a critical component of that strategy. Application assessment helps identify which applications to migrate to the cloud and to which cloud service specifically. It dictates whether an application migration is ‘lift and shift’ or more transformational – and crucially it’s a decision which can be revisited post-migration if the cost, or potential use of that application (e.g. to exploit its data for analytics) merits it.
If an application is providing a high business value and has a low Total Cost of Ownership (TCO), then it might make sense to retain the application on premise. This allows you to focus on applications valuable to the business that are suited for the cloud. This assessment may change as that on-premise application or its infrastructure reaches end of life.
If an application is providing low business value with high TCO, retiring it might be the preferred option. The effort to support it and the cost savings can be directed to more valuable applications. On average, organisations retire 10-20% of their applications after assessment phase.
This strategy is also referred to as “Lift & Shift”. This option is suitable for legacy applications that provide a high business value with a high Total Cost of Ownership (TCO). In Re-Hosting scenario, the application is migrated to a cloud IaaS as a virtual machine and retains the same basic functionality with minimal changes.
This strategy is appealing as it makes the application simpler to operate and often less expensive to run on cloud IaaS. The migration itself is the simplest of all options and least risky.
Although this strategy has low risk, it also provides the lowest value/benefit as you will not get the most out of what the cloud capabilities offer. Also, virtual machines that have poor resource utilisation on premise will likely inherit the same deficiencies when migrated “As Is” to the cloud and the benefit of lower cost might not be recognised. We believe it’s an essential part of what we call “Cloud Lifecycle Management” to constantly revisit applications which have simply been re-hosted, to manage these older models out of the cloud architecture over time.
This strategy is the next step up from Re-Hosting and it is also known as Lift, Tweak and Shift. Some applications, in order to migrate to cloud, may require minor re-packaging to make them work on the cloud IaaS. Refactoring (repackaging) activities are primarily focused on replacing some of the application components with cloud native services. It is important to emphasis, there should be minimal re-coding in this strategy, as most changes will be to services.
For example, an application that has a database server on premise, might instead be refactored to use a cloud Database as a Service (DBaaS) for better scalability, built-in intelligence, improved redundancy and easier management. As with re-host, this is a judgement which can be revisited to more ambitiously rearchitect applications as new capabilities come to market
There are certain legacy applications that used to provide high business value, but today, its functionality is constrained and it can no longer address modern day business requirements. Often, Re-Platforming them is just not enough and a complete Re-Factoring is required to take full advantage of cloud native services. This approach redesigns an application and breaks down it into services (often utilising Microservices Architecture) that fully integrate with cloud native technologies (IoT, AI, machine learning, blockchain, automation, resiliency, etc.). Re-Factoring an application in the cloud will often provide the highest business value in comparison to other migration options. Re-Factoring is also likely to be the most expensive, longest and challenging path to cloud.
This is often referred to as drop and shop. If an application is providing high business value with high TCO but a cloud based SaaS application provides a similar business value but with lower TCO, then replacing it might be the sensible approach.
Moving from CRM to Saleforce.com, moving from on HR legacy system to Workday and moving from exchange to O365 are just a few examples of on premise applications being replaced with SAS solutions.
There are many routes to cloud, however, I often see clients focused on short term decisions (i.e. taking the least effort and fastest route to cloud). Re-Hosting and Re-Factoring are good options for quick move to cloud, often to meet aggressive timelines but the price often is inefficiencies. For example, many organisations in their early stages of public cloud adoption, find themselves ill prepared for managing ongoing cloud costs which result in significant value erosion.
A longer-term view would see more refactoring of applications done but at a time which suits the application roadmap rather than an external pressure to get stuff to the cloud quickly. An added benefit of extra time, will enable organisations to establish discipline to manage ongoing cloud costs. This latter view is what we see as the default mode of operation for most organisations who are mature in cloud.
Thank you for reading.