This post discusses the six cloud migration strategies (Based on Gartner and Amazon Methodologies).
In today’s episode I will cover the 6 fundamental migration strategies that organizations have at their disposal when migrating to the cloud. These strategies are based on Gartner’s research and also on the work that Amazon has done in helping their customers to migrate to the cloud. Both Gartner and Amazon discuss these extensively on their blogs and websites as well. As a technology executive, if you are still in the early phases of your cloud migration journey, a review of these strategies can help you in developing the right mental models that in turn can guide you to develop your own digital transformation journey.
So, let’s get started.
One of the key phases that every organization goes through when considering migrating its legacy systems to the cloud is that of a discovery process. In this phase, the organization essentially takes a detailed inventory of its systems and then decides one by one on the effort and cost required to do the migration. This step is usually done by keeping the overall business case and objectives of the migration in perspective. For each of the applications and systems in its inventory, the organization may decide on a specific migration strategy or approach. We will discuss those strategies next.
Re-hosting – The first strategy is that of re-hosting. This is also referred to as lift and shift and involves migrating a system or application as is to the new cloud environment. The focus is to make as few changes to the underlying system as possible. During the discovery process of the migration planning exercise, systems that qualify for such a migration are usually considered quick-wins as they can be migrated with minimal cost and effort. However, as the application and system usually involves a simple lift and shift, such as system isn’t expected to utilize the cloud native features and thus isn’t optimized to run in a cloud environment. Thus depending on the system, it may even be more expensive to run the new migrated system on the cloud. These types of issues should be considered before categorizing a system for such type of migration.
Refactoring – Refactoring is the second migration strategy and falls on the other extreme of the migration effort because it requires a complete change and reengineering of the system or application logic to fully make use of all the cloud features. When complete, however, this application is fully optimized to utilize cloud native features. So, even though the cost and effort required for this migration can be quite high, in the long run this approach can be efficient and cost effective because the application is reengineered to make use of the cloud native features. A typical example of refactoring is changing a mainframe based monolithic application from its current form to a microservices based architecture. When categorizing an application as refactoring, the business should perform a detailed business case analysis to justify the investment of the cost, effort and a potential business impact and also to ensure that other alternatives are considered as well.
Replatforming – This type of migration is similar to re-hosting but requires few changes to the application. Amazon’s AWS team refers to this approach as lift-tinker-and shift. Even though this approach closely resembles that of re-hosting, it’s categorized differently simply because it requires some changes. For example, in doing such migrations, an organization may plug its application to a new database system that’s on the cloud or change its web server from a proprietary version such as Weblogic to Apache Tomcat, which is an open source based web server. So, for planning purposes it’s important to categorize it as such. Obviously, if a system or application is going to be changed to make even slight changes, it may need to be put through more thorough re-testing processes.
Repurchasing – This migration strategy entails essentially switching the legacy application in favor of a new but similar application on the cloud. Migrating to a SaaS based system would be an example of such a migration where an organization may decide to migrate from its legacy financial system to a SaaS based financial ERP system.
Retire – The fifth strategy is about retiring systems and applications that an organization no longer needs. During the discovery process, an organization may find applications as part of its inventory that are no longer actively used or have limited use. In such cases, those types of applications may be considered for retirement and users of those systems (if any) can be provided other alternatives.
Retain – In some cases, the organization may decide not to touch certain applications and systems and to postpone their migration for later in the future. This may be either that the applications are too critical to be touched at that point in time or require a more thorough business case analysis. Either way, it’s normal for organizations to not touch some applications and systems during their cloud migration efforts. However, in certain cases such as a data center migration, organizations may not have a choice and will have to consider one of the earlier described strategies.
To conclude, although the strategies that I have covered address most of the common cloud migration scenarios, as a technology executive you can devise other categories based on your business needs. Defining these migration categories and their criteria upfront can be a major and helpful step to aid in the migration of one’s legacy systems to the cloud.
Hope this session was useful. Again, to ensure that you don’t miss any future episodes, do subscribe to this channel.
- End
