This post discusses Cloud migration options for software applications. The post is also available in my podcast. You should combine the review of this article with the following related articles:
- Azure migration design considerations
- Azure pre-migration assessment tools
- Azure app service design considerations (part 1, part 2, part 3)
- Choosing an Azure load balancing service
- Hosting SQL server workloads in Azure
- Azure infrastructure and application testing
It is a common theme in various Cloud migration projects to migrate a number of on-premise apps to a public or hybrid cloud infrastructure. Depending on the application development framework and the dependencies which the application has to run efficiently (e.g. runtime frameworks, database and file storage requirements, user identity management and so forth), a custom choice is made each time regarding how to migrate an application to the Cloud. This article provides a quick overview of viable options for application cloud migration.
Cloud migration options for software applications
The following viable options are available for application cloud migration:
- Rehost. This is the easiest to implement and most common scenario seen in application Cloud migrations. In this scenario, the application is simply hosted in one or more Cloud virtual machines and keeps the architecture and dependencies it has on-premise. This kind of migration is known as the “rehost” option or “migrate as is” or “lift and shift”. When migrating to Azure VMs, it is recommended to use the Microsoft Azure VM Selector tool available at: https://aka.ms/vm-selector. Another useful tool (3rd-party) for helping choose the right Azure VM is https://azureprice.net/.
- Refactor. This increases the cloud factor involvement by migrating one or more of the application components to a cloud-native PaaS component, such as PaaS SQL, PaaS LDAP or a Container service (e.g. Kubernetes cluster). A typical example of this case would be when migrating on-premise SQL Server databases. Useful tools for choosing the proper Azure SQL hosting option are available in the following pages: https://docs.microsoft.com/en-us/azure/azure-sql/azure-sql-iaas-vs-paas-what-is-overview and https://docs.microsoft.com/en-us/data-migration/. Similar guidance for MySQL is available at: https://docs.microsoft.com/en-us/azure/mysql/select-right-deployment-type. Sizing of the target PaaS service should be designed properly as per the following example for Azure SQL SKU: https://docs.microsoft.com/en-us/sql/dma/dma-sku-recommend-sql-db?view=sql-server-ver15. Another typical example of refactoring is converting your code to containerized logic, for example in the case of a classic Web App to be run inside Azure Container Instance service and Azure Kubernetes Cluster (AKS) or inside the containerized option of Azure App Service.
- Rearchitect. This takes the application cloud migration one step further by more extensively re-architecting most of the on-premise app’s components to utilize their cloud-native equivalents. It is essentially very similar to the refactor scenario but includes more extensive changes in the application’s architecture with a definite shift towards public Cloud utilization.
- Redesign/Rebuild. In cases where the application cannot fit into any of the previous re-engineering scenarios, then a total software redesign and rebuild is deemed necessary. This is what renders Cloud-native applications, since the app is now designed from the ground up to be Cloud-native and both the app and all of its dependencies are hosted by a public cloud infrastructure.
- Replace. This is the last resort when an application software vendor or service provider does not want to follow any of the previous options. In this case, the application is simply replaced by an equivalent SaaS application and all users and data are migrated/imported into the new SaaS app.
- https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/migrate/ (Cloud Adoption Framework – CAF)
Before choosing one of the available Cloud migration options for your software application, you will first need to audit/assess your application workloads and understand all the application dependencies. Last but not least, you should also determine your application’s software and compliance requirements before moving to the Cloud.