Azure Migrate – Part 3 Migration

This is Part 3 of the Diaxion blog series focusing on the Azure Migrate service to Discover, Assess, Replicate and Migrate workloads from an on-premises location to Azure.

Part 1 was focused on Discovery and Assessment and can be found here – Azure
Migrate – Discovery and Assessment

Part 2 was focused on the Replication component of Azure Migrate and can be found here – Azure Migrate – Replication

As we now have servers replicating from our on-premises environment to our Azure tenancy, we are ready to migrate the selected servers. The migration process is a disruptive, multi-step process that includes the graceful shutdown of the chosen server, the migration itself which replicates the final changed blocks, the creation of the virtual machine in Azure and finally the graceful start-up of the Azure VM. The graceful shutdown of the on-premises server is at an operating system level only, so be careful to shutdown any application specific processes prior to the migration.

Prior to any migrations however, it is highly recommended that you conduct a test migration first. This test migration can be done in a non-disruptive fashion with no impact to the on-premises server that is in scope for test. You should however be cautious of your network settings as the test migration does produce a live, running VM in Azure. If you have the destination network connected to your on-premises environment, you may experience issues with conflicting network addresses for the same server. The test migration is used to ensure the VM can be migrated and to prove the stability of the operating system post-migration, it is not necessarily
intended to prove application stability. After the test migration has been completed successfully, it can be cleaned up through the Azure Migrate settings which will delete the Azure VM. During the test migration, replication of the on-premises server to Azure continues without impact.

The migration process is relatively simple after the test migration. The actual  migration step within the Azure Portal is effectively a “Yes -> OK” click-through. Once the migration is underway, the Azure Portal provides step-by-step updates of the Azure Migration process with a duration per step.

Experience suggests the following timeframe can be expected. 

The variation sits within the “Preparing for failover” and “Start failover” steps. These two steps are dependent on the server that is being migrated and take into consideration how busy or ‘chatty’ the server may be. A database server for example may be doing a lot more work than a static management server so you may experience different timing there.

Post-migration, you will find there are several tasks that should be considered. You should, at a minimum install the Azure Agent, the Azure Log Analytics agent, the Azure Dependency agent, and the Azure Network Watcher extension. There are dependencies that need to be considered such as the .Net Framework version that is installed locally on the server, this may need updating to support the Azure Agent. Again, experience has found that these agents are installed after the standard post-migration testing has been completed. These could include items such as.

• Can you connect to the server via RDP?
• Can you resolve the DNS entry for the migrated server?
• Are the application / services running properly on the migrated server
  
• Application specific testing relevant to the migrated server.

The final steps for the migration are Azure Migrate and on-premises clean-up activities. Although the Azure Migrate process shuts down the running  on-premises instance, there are no other clean-up activities that are built into the process and these should be undertaken manually after the migration has been signed off. These include stopping the replication from on-premises to Azure (there is nothing left to replicate post-migration), the removal of the server from on-premises backups and the eventual deletion of the on-premises server.

There is one other consideration assuming not everything has been successful during the migration. What about failback? What are your options in this scenario? And this is actually something that Azure Migrate doesn’t handle as cleanly as some other tools. Azure Migrate is a one-way journey for servers. You can perform the migration and then re-enable Azure Site Recovery to protect the VM from Azure to on-premises and then perform another migration, but that is clunky and can be lengthy. The simplest failback scenario is that the on-premises server still exists and is just in a shut-down state. You can remove the connection or the entire VM from Azure and power on the on-premises server, perform your checks and you are now back to the beginning. You will have to reset the replication of the on-premises server to Azure to prepare for another migration at a later date.

And that is it for Part 3 of this Azure Migrate blog series. The Migration step is the riskiest and requires the most planning from an ITIL change perspective due to the downtime, but technically from an Azure Migrate perspective, the simplest. The next blog will hopefully provide you a few tips and tricks and gotchas that we have experienced using the Azure Migrate service. Hopefully, this has been helpful and if you have any questions about the migration of workloads to Azure, please contact the team at Diaxion and we’ll be happy to assist with any questions you may have. Stay tuned for Part 4, coming shortly!

Part 1 – Discovery and Assessment

Part 2 – Replication

Part 3 – Migration

Part 4 – Tips, Tricks and Troubleshooting