Skip to main content

Demystifying cloud migration strategies

One of the most common cloud projects time nowadays is cloud migrations. I found challenging when I start a discussion related to migrations because each person has a different understanding of each migration strategy. 
The main six types of migration strategies are:
  • Rehosting
  • Replatforming
  • Repurchasing 
  • Refactoring
  • Retire 
  • Retain
On paper, things sound easy, but once you start to dig into the problem, you realize that most of the people say that they are doing all of them at the same time on all the projects without knowing the differences between them.

In this article, we cover 3 main things related to cloud migration (1) Definition (2) Examples and (3) Comparison between different strategies.

You are in the phase when you are not ready to do the migration. You might identify other pains inside the current business or inside your IT landscape that have a higher priority. In this case, you cancel the migration for now and focus on another area. Take into account that migration should happen when from the business point of view you bring enough value at the table. 

Imagine that you are working for a company that just renewed its hardware solution. The lifecycle is 6 years and they don't foresee a grow or consumed resources or a change. From the business point of view migrating to the cloud, might not be the top priority. Improving customer service might be more important in this case.

It's a strange case, that is common for a large organization. There are systems that are not used anymore or a part of their responsibility was already taken by other systems. They still run because nobody decided to retire them or do an analysis to see if they are still used and the extra business value added by them. 

Imagine that you have an FTP server that is used to upload content to the backend system. In the last 4 years, it was replaced by Office 365 services. The only people that still use FTP are using it because they are more comfortable with it, but not because they cannot use the new available solution. In this situation, retiring the FTP server has no negative impact on the business, just additional cost optimization.

It is the migration strategy where you take your current on-premises systems and deploy them inside the cloud. In most cases, it is a pure infrastructure migration project, where you recreate the environment inside the cloud using virtual machines. Not to many cloud PaaS or SaaS serviced are used. Even so, RTO, RPO, DR SLA together with running costs can be improved. 
It is a good solution when you need to migrate a large system to the cloud and you want to do it cheap and fast. After rehosting many companies start a cloud program where they identify parts of the migrated system that can be optimized or re-architect. 
This kind of migration can be done manually or automatically using different migration tools. In general, it is a hybrid strategy where most of the things are done automatically except some parts where each step is done manually including configuration and setup.

We have a big on-premises CRM system, that was not upgraded in the last 5 years. It runs on Linux and uses an old version of Java. Migrating to a new CRM solution it is too expensive and full of business risks. The decision is to migrate the solution as is on Microsoft Azure on top of Azure VMs. Once the migration is done with success and the system is stable, an optimization project will start. Depending on the output, the organization might decide to migrate to a new CRM solution or keep the old one on top of Azure VMs (IaaS).

Similar to rehosting, but with optimization steps included. The migration from on-premises to the cloud involves identified services where the current payload and data can run. The cloud infrastructure that it is used involves more than just some VMs. Without having to change the application logic, PaaS and SaaS services can be used to improve the platform. 

Migrating a system to Microsoft Azure that involves MSSQL and web applications hosted inside IIS, can use Azure SQL Databases, Azure Web Apps, and Azure Container Instances. Such a migration does not affect the flow of data and how the business logic is implemented. Even so, the new platform is using more PaaS services in comparison with pure Azure VMs. 

This type of migration involves data movement and full retiring of current on-premises systems. The on-premises systems are replaced by SaaS solutions that take full responsibility for the original system. 

Imagine that you have a custom CRM solution on-premises and you decide to do a migration to a CRM vendor that is offering a full SaaS solution. In this case, you replace your current CRM with Microsoft Dynamics 365. The key step here is customization and data migration. There are no custom VMs or any other things involved. 

The type of migration loved by developers and architects. Involves redesign of the solution with cloud-native in mind. The purpose is to identify the best cloud services that feet the need and rewriting partially or fully the current system is acceptable. 
When an organization device to do such a migration, there are performance, scaling, or features issues that need to be solved. The business has a strong incentive to do such an investment. It is not uncommon to start from an old monolith system and up with a new re-architected system that runs on Kubernetes, Azure Functions and use Azure Cosmos DB as main storage. 

An organization could have a 10 years old system used as the backend solution to process documents, including OCR and notification system. A refactoring of such a system can include a lot of SaaS services, especially from Azure Cognitive Services catalog, together with Azure Functions, Azure Service Bus, and Azure Data Factory.

Comparing cloud migration strategies

Replatforming OR Repurchasing
Imagine that you are working on an on-premises CRM system build on top of Drupal that needs to be migrated to Microsoft Azure. At this moment in time, there is no Drupa offer inside Microsoft Azure as SaaS. The available option available are:
  • Repurchasing: Cannot be done because there is no SaaS offer inside Microsoft Azure for Drupal
  • Replatforming: Can be done with success to Office 365 and Sharepoint. In this case, we migrate to a full SaaS solution.
  • Rehosting: The solution involves some Azure VMs or Azure Web Apps that would become the core of the system that would use Azure SQL Managed Instances of Azure SQL Database to store data in combination with Azure CDN. 

Refactoring OR Replatforming
We are working with an on-premises monolithic solution that needs to be migrated to the cloud. In most of the cases, such a migration can be done using one of the following approaches:
  • Replatforming: Where we try to identify the cloud services that have no impact on the architecture (SQL Managed Instances, Azure VMs, Azure Web Apps). Once we have the system migrated, we can have multiple iterations to redesign part of the monolith.
  • Refactoring: In this case, we decide to change the architecture and redesign the solution. The cost are much higher, but the long term benefits are 10x more. 
Refactoring OR Replatforming
The custom code that is running on top of on-premises VMs is migrated to AWS Lambda or Azure Functions. You might say that it is 
  • Replatforming because you don't change the code, you just run it inside a serverless sandbox. 
  • This is more a refactoring because you redesign the application, you split the code into multiple components and change the way how the system is running. 

Rehosting OR Replatforming
A global system that is running on top of on-premises VMs. The mission is to take the system and migrated it to Microsoft Azure. There is no need to do any changes to the current system, but the on-premises hardware needs to be retired.
  • Replatforming: It should not require to identify new services where the data or payload can be stored and run. It is a pure lift and shift projects
  • Rehosting: is the best match in this case. The VMs with the payload and storage is migrated to one or multiple clusters. This such migration can be done without any business interruption using the migration tools offered by Microsoft Azure
Replatforming OR Rehosting
Imagine that you have a solution deployed on Pivotal on top of an on-premises cluster. You need to migrate it to Microsoft Azure. 
  • Rehosting: Involves building an Azure VM cluster where Pivotal is fully managed by your operation team. The environment is similar to the on-premises system.
  • Rehosting: It is based on Azure Spring Cloud or Azure PCF, where the operation and management part is taken partially by Microsoft Azure. In this case, you identify cloud services like Azure PCF that are a better fit in comparison with managing a Pivotal cluster by yourself.  

In most of the cases, for large migration, there is a blend between multiple migration strategies, Keep in mind that even at the program level there is a mix between different migration strategies, at product or service level you shall have all the time the main migration strategy. 


Popular posts from this blog

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine:
threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration:

TeamCity.NET 4.51EF 6.0.2VS2013
It seems that there …

Entity Framework (EF) TransactionScope vs Database.BeginTransaction

In today blog post we will talk a little about a new feature that is available on EF6+ related to Transactions.
Until now, when we had to use transaction we used ‘TransactionScope’. It works great and I would say that is something that is now in our blood.
using (var scope = new TransactionScope(TransactionScopeOption.Required)) { using (SqlConnection conn = new SqlConnection("...")) { conn.Open(); SqlCommand sqlCommand = new SqlCommand(); sqlCommand.Connection = conn; sqlCommand.CommandText = ... sqlCommand.ExecuteNonQuery(); ... } scope.Complete(); } Starting with EF6.0 we have a new way to work with transactions. The new approach is based on Database.BeginTransaction(), Database.Rollback(), Database.Commit(). Yes, no more TransactionScope.
In the followi…

GET call of REST API that contains '/'-slash character in the value of a parameter

Let’s assume that we have the following scenario: I have a public HTTP endpoint and I need to post some content using GET command. One of the parameters contains special characters like “\” and “/”. If the endpoint is an ApiController than you may have problems if you encode the parameter using the http encoder.
using (var httpClient = new HttpClient()) { httpClient.BaseAddress = baseUrl; Task<HttpResponseMessage> response = httpClient.GetAsync(string.Format("api/foo/{0}", "qwert/qwerqwer"))); response.Wait(); response.Result.EnsureSuccessStatusCode(); } One possible solution would be to encode the query parameter using UrlTokenEncode method of HttpServerUtility class and GetBytes method ofUTF8. In this way you would get the array of bytes of the parameter and encode them as a url token.
The following code show to you how you could write the encode and decode methods.