DevOps Blog

Stay in the know with in-depth articles about DevOps, micro-services and cloud native topics, delivered to you weekly.

6 Strategies for Migrating Applications to the Cloud

Written by Marius Rimkus
on April 07, 2020

The infrastructure that you choose for your application will determine many aspects of your operations. A hosting cloud determines the computing capacity your app is getting, as well as the security controls you are allowed, and the privacy level your data can achieve. 

The same principle applies to cloud migration. The type of migration strategy you implement will determine the viability of your application. In this article, you will learn about six types of strategies you can use when migrating your app to the cloud.

 

What Is Cloud Migration?

Cloud migration is the process of moving data, workloads, and applications to the cloud. It can involve moving only portions of your operations or entire systems. The target cloud can be a public, private, or hybrid cloud. A hybrid cloud is some combination of public cloud, private cloud, or on-premises resources.

There are three types of cloud migration you can perform:

  • On-premises to cloud—involves migrating assets from on-premises resources to cloud resources. This is the most common type of migration.
  • Cloud-to-cloud—involves migrating assets from one cloud vendor or type to another.
  • Reverse cloud—involves migrating assets in the cloud to on-premises resources. 

 

6 Strategies for Migrating Applications to the Cloud

When migrating to the cloud, there are several strategies you can choose from. The specific migration strategy you choose depends on what kind of assets you’re moving, what your goals for migration are, and what level of expertise is available to you. Frequently, organizations will use a combination of strategies throughout the migration process. 

 

  • 1. Rehosting

Rehosting, also known as lift and shift, is the fastest and easiest way to migrate assets to the cloud. With rehosting, data and assets are moved as is with little to no modification. Because assets are not altered, this strategy does not enable you to take full advantage of the benefits of the cloud. For example, scalability or the resilience created by microservices. 

This strategy is often used in the first stage of migration to move simple assets and help operations and IT teams become familiar with deploying cloud resources. It is a good option for legacy applications that you want to move but can’t or don't want to modify. It is also useful for moving applications that you plan to modify later since many applications are easier to adapt once data is already in the cloud. 

 

  • 2. Replatforming or refactoring

Replatforming or refactoring is a strategy that adapts applications and data to better suit cloud environments. For example, changing the format of data to one supported by cloud storage or databases. 

More commonly, replatforming refers to making changes to legacy applications, such as containerizing applications. These changes can allow you to move highly structured applications or those with many dependencies to the cloud without sacrificing core functionality. Ideally, refactoring also enables applications to access some of the benefits of cloud-nativity

Although replatforming has multiple benefits, it is not a simple process and requires more expertise and familiarity with applications than rehosting. It also takes more time and testing to ensure that applications are adapted properly. 

 

  • 3. Rearchitecting 

Rearchitecting is the best way to ensure that legacy applications can benefit fully from being moved to the cloud. It does this by transforming legacy applications into cloud-native ones, composed of microservices and containerized workloads. Unfortunately, to accomplish this, rearchitecting requires completely or almost completely reworking application code and architecture.

Rearchitecting is an expensive and slow process and demands significant programming expertise and familiarity with applications. This makes it best suited for legacy applications that are mission-critical and not possible to replace. Alternatively, it may be an option you consider after the rest of your assets are fully migrated and you need to further improve cloud performance.

 

  • 4. Repurchasing

Repurchasing involves replacing your legacy applications with cloud-native versions. For example, replacing Microsoft Exchange with Office 365. Repurchasing enables you to retain the functionality that you need in applications without requiring you to make any modifications.

In the best-case scenario, you can replace legacy apps with cloud-native ones available from the same vendor. In this situation, you may be able to export data from the old application and into the new one. You may even be able to convert your existing licenses, reducing technical debt. 

If a cloud version of your application is not available, however, you can also find an alternative vendor. While this is a more expensive option, many cloud-native services provide assistance importing data making this a simpler process than refactoring

 

  • 5. Retaining

Retaining applications and data involves simply leaving it on-premises. Some applications are mission-critical but cannot be altered for one reason or another and a suitable replacement isn’t available. Or, the technical debt attributed to the application is just too high and needs to be spent down before the application can be eliminated. 

In these cases, maintaining an application on-premises and connecting it to cloud resources via a hybrid cloud may be your best option. You also may want to use the application independently, leaving it completely disconnected from the cloud. 

Likewise, retaining data on-premises is a popular option for high-priority or sensitive data. For example, if you have to meet strict compliance standards for data. It may be easier to keep data on-premises where you have greater control over access. 

 

  • 6. Retiring

Retiring is the strategic elimination of applications and data. Frequently, when doing an inventory for migration, organizations find legacy applications and data that are no longer in use. Rather than keeping these now useless items, you may wish to retire assets. 

Retiring assets reduces the work needed for migration. It can also reduce storage requirements on-premises and your liability. Data that you don’t have cannot be stolen or held against you. 

 

Conclusion

Hopefully, this article has helped you understand these six strategies of migrating applications to the cloud. The main difference between the strategies lies in one question, “How much work, time, and energy are you willing and able to allocate for the migration process.” If the answer is, “I am not interested in doing much work,” then you are better served using the rehosting strategy. 

If your app is, unfortunately, not compatible with the target cloud, then you will need to do refactoring or rearchitecting. Repurchasing is reserved for those situations when the application cannot be moved at all, but can be replaced with similar cloud-native alternatives. If you decide to hold some of the data on-premises, that is called retaining. There is also the alternative of cutting loose and eliminating data that can’t be moved. Of course, you can also mix and match strategies, but do this cautiously and with careful planning.