AZURE MIGRATION – A CASE STUDY

Recently I was assigned a consultancy project by one of my clients with a mandate to address their ever-increasing IT costs. With a pretty huge IT estate and a substantial legacy server footprint, the client had also accumulated new servers and services over time without thinking about their existing infrastructure. Their infrastructure included Windows Servers including both x32 and x64 hardware running Windows Server 2016. Linux Servers running RHEL 7 series and Ubuntu 16.04. Also, the aforementioned servers comprised both physical machines as well as VMs hosted on VMware infrastructure managed by vCenter 6.5. They also had multiple database engines which included PostgreSQL and Microsoft SQL Server.

 

In total, I identified 63 servers distribute over 2 locations in the state. Those servers had a complex web of dependencies between them and almost no one had a clear view of their entire IT estate. The client feared of breaking an existing system. I suggested them to migrate as much of their existing IT infrastructure as possible to the cloud. I presented the idea to their board and they agreed to select Microsoft Azure as the cloud provider.

 

There were a few needs by the client that were to be kept in mind. I had to identify which servers could be migrated to Azure and what modifications would they require. I had to create a road map of prioritized migrations which would in turn create an ease of migration and its dependencies. The client had specifically asked to migrate existing servers and databases to Azure as efficiently as possible, wherever suitable. On top of that, where existing servers could not be migrated, the client wanted to identify alternative migration strategies like refactoring and re-architecting along with their pros and cons. Most importantly, prior to the migration, the client wanted an accurate report of forecast of the costs associated with each migrated workload along with any third-party licensing costs. And lastly, after the migration, the client wanted to be able to track costs, control usage and identify as many cost saving opportunities as possible.

 

However, along with all this the client had a few objections as well. The client had negotiated an Enterprise Agreement with Microsoft for their Azure consumption. So, they wanted any kind of cost estimates to reflect their EA discount. A lot of applications comprised multiple components or tiers. The client had doubts regarding the how the migrations would be appropriately orchestrated? Also, to reduce their business impact, each migration had to be designed to minimize application downtime. There had to be an option to fail-back should the migration experienced an unexpected problem. The client also wanted to confirm all the savings that they could expect once the process of migration was completed.

 

Following solution is what I had given to them.

For Migration Assessment:

  • For their VMware VMs: I suggested them to use Azure Migrate
  • For their Physical Servers: I suggested them to use some third-party tools
  • For their Databases: For the SQL Server, I suggested SQL Server Data Migration Assistant (DMA) and for the PostgreSQL, I suggested some third-party tools where available

For Migration Execution:

  • For their VMware VMs: Azure Site Recovery (ASR)
  • For their Physical Servers: ASR, port disks or third-party tools
  • For their Databases: For both SQL Server and PostgreSQL, I suggested them Azure Database Migration Service (DMS)
  • I also suggested the client some other approaches where needed. Approaches like re-install, refactor, re-architect and rebuild.

 

Azure Migrate assesses the suitability for migration. It also visualizes dependencies and provides sizing recommendations. Along with that, it provides cost estimates in order to manage spending and forecast on how the money is going to be spent. Below attached is a sample screenshot of Azure Migrate.

Azure Site Recovery helps in migration and disaster recovery. It does incremental data transfer on all types of workloads including physical machines, Hyper-V machines, VMware and on all platforms like Windows, Linux, etc. Along with all this, it also supports test failover should there be a need of it.

Then for their Database Migration, I suggested them to use Azure Database Migration Service. It uses Database Migration Assistant (DMA) for SQL assessment and the schema migration. It supports migration to both Azure SQL Database services and SQL on Azure VMs.

There are two migration modes that can be used:

  • Offline mode which is simple easy
  • Online mode which minimizes downtime

It supports SQL Server, MySQL and PostgreSQL. In cases where the you have Cassandra database, you can use Cassandra tools or some 3rd party tools. However, this client only had SQL Databases and PostgreSQL.

Below is a sample screenshot of the Azure Migrate Readiness Report that show VM readiness with recommended size and a suggested migration tool.

And here are some sample screenshots of the Azure Migrate Cost Estimate. You can configure the target environment parameters to tune your pricing estimates.

            

 

 

The Azure Migrate Dependency Visualization creates a map of VM network dependencies. It identifies related to plan migration groups and its dependencies. Below is a sample screenshot of one such Azure Migrate Dependency Visualization.

In the cases where lift-and-shift migration to Azure was not suitable, different approaches with a few options were suggested. In the case where an application had few users and their needs could have been met in other ways, the workload had to be simply retired. Another consideration of an existing application being replaced by an off-the-shelf SaaS service was also suggested. It is important to note that the above stated options should always be considered, even for applications that are suitable for life-and-shift.

 

After the migration was performed successfully, the client was more than happy with everything that was suggested and implemented during the process. The migration process was completed in around one and a half months. According to the client, their applications have now become faster and more reliable along with being cheap and easier to operate and maintain.