This article discusses six distinct migration approaches that customers often adopt to move applications to the cloud. These approaches are built on the 5 R’s that Gartner identified in 2011. This piece is the last part of a three-part series on migrations. The first part of this series delves into the concept of mass migration, referred to simply as “migration” throughout the series, and the second part focuses on A Process for Mass Migrations to the Cloud. While each part can stand alone, I believe they are best understood when read together.
Developing a Migration Plan
During the second phase of the “Migration Process” – Portfolio Discovery and Planning, enterprises usually start considering how to migrate an application. This is when they assess their environment, interdependencies, ease and difficulty of migration, and how they will migrate each application.
Armed with this knowledge, organizations can draft a plan (which should remain flexible as they progress through their migration and learn more) on how they will migrate each application in their portfolio and in what sequence.
The complexity of migrating existing applications varies based on the architecture and existing licensing agreements. For instance, a virtualized, service-oriented architecture is at the low end of the complexity spectrum, while a monolithic mainframe is at the high end.
I recommend starting with something at the low-complexity end because it is easier to complete, providing immediate positive reinforcement or “quick wins” as you learn.
6 Application Migration Approaches: “The 6 R’s”
The six most common application migration approaches are:
- Rehosting – Also known as “lift-and-shift.”
Many initial cloud projects lean towards new development using cloud-native capabilities. However, in a large legacy migration scenario where the organization aims to quickly scale its migration to meet a business case, most applications are rehosted. For example, GE Oil & Gas found that even without implementing any cloud optimizations, it could save about 30% of its costs by rehosting.
Rehosting can often be automated with tools (e.g., CloudEndure Migration, AWS VM Import/Export), although some customers prefer to do it manually as they learn how to adapt their legacy systems to the new cloud platform.
We have also found that it is easier to optimize/re-architect applications once they are already running in the cloud. This is partly because your organization will have developed better skills to do so, and partly because the challenging part – migrating the application, data, and traffic – has already been completed.
- Replatforming – Sometimes referred to as “lift-tinker-and-shift.”
In this approach, you might make a few cloud (or other) optimizations to achieve some tangible benefits, but you do not change the core architecture of the application. For example, you may reduce the time spent managing database instances by migrating to a database-as-a-service platform like Amazon Relational Database Service (Amazon RDS), or migrate your application to a fully managed platform like Amazon Elastic Beanstalk.
A large media company we work with migrated hundreds of web servers from on-premises to AWS. In the process, it moved from WebLogic (a Java application container that requires an expensive license) to Apache Tomcat, an open-source equivalent. This company saved millions in licensing costs, in addition to the savings and agility gained by migrating to AWS.
- Repurchasing – Switching to a different product.
Repurchasing usually involves moving to a SaaS platform. For instance, migrating a CRM to Salesforce.com, an HR system to Workday, a CMS to Drupal, etc.
- Refactoring / Re-architecting – Rethinking how the application is designed and developed, typically using cloud-native features.
This is usually driven by a strong business need to add features, scale, or improve performance that is otherwise difficult to achieve in the application’s existing environment.
Are you considering migrating from a monolithic architecture to a service-oriented (or server-less) architecture to increase agility or improve business continuity (I have heard stories of mainframe fan belts being ordered on eBay)? This approach tends to be the most expensive, but if there is a good product-market fit, it can also be the most beneficial.
- Retire – Eliminate.
After discovering everything in your environment, you might ask each functional area who owns each application. We have found that as much as 10% (sometimes even 20%) of an enterprise IT portfolio is no longer useful and can simply be turned off. These savings can strengthen the business case, direct your team’s scarce attention to the things that people use, and reduce the surface area you have to secure.
- Retain – Typically means “revisit” or do nothing (for now).
Perhaps you are still accounting for depreciation, are not ready to prioritize an application that was recently upgraded, or are otherwise not inclined to migrate some applications. You should only migrate what makes sense for the business. As your portfolio shifts from on-premises to the cloud, you will likely have fewer reasons to retain.
