05 Nov Azure Migrate
Azure migrate is a feature currently in preview in Azure that can help considerably with a transition to Azure. Moving workloads to Azure from on-premises is greatly simplified with this new tool as it helps with the following: –
- Easily discovers all on-premises virtual machines
- Understands app interdependencies
- Right-sizes new cloud resources based on utilisation
- Identifys, assesses and mitigates migration risks
- Provides a cost estimation for IaaS VMs
Azure migrate helps to take some of the guess work out of moving workloads to Azure thus making the process more scientific. Initially due to the name of this tool, Azure Migrate, i assumed this tool was an iteration of Azure Site Recovery (ASR) but using an appliance based approach for IaaS migrations to the Cloud similar to the approach Amazon Web Services uses with the AWS Connector appliance. Rather AM is an appliance that helps with the discovery and triage of your physical or virtual estate when trying to understand what services and workloads can be moved from on-premises to Azure. ASR is the tool thats actually used for the migration process. In essence AM is a complimentary tool to ASR. The ASR configuration server that you need to install on-premises in order to enable ASR is very similar in its requirements as the appliance (.ova) thats used for AM. Hopefully at some point the two will be merged into one tool.
This post covers some of the high level steps i used for enabling AM.
As mentioned AM is currently in preview only. So if you want to use it you need to follow the steps at the end of this article: –
https://azure.microsoft.com/en-gb/campaigns/azure-migrate/
Once enabled AM is available in the portal under ‘Migration Projects’. The first step is to add a project. Once the project is added its essentially a case of following the steps in the portal to download the .ova appliance and register it with Azure. At present i believe AM is only supported with VMware which is what i used for this lab. Although my tenant is based in West Europe i could only create a project in the West Central US location. This may be a limitation of the preview.
Once the appliance is imported it needs to be configured and registered to the new migration project using the unique project ID and key supplied in the Azure portal.
Running the collector is elementary. Once the steps below have been followed and your vCenter server is registered the appliance will do a discovery of your virtual machines. When the discovery is complete the appliance will display the discovered virtual machines in the portal.
With discovery completed the next step is to install the monitoring agent on the required VM. In my case i built a test VM for this purpose. Below shows the agent already installed as under the ‘dependancies’ tab ‘View Dependancys’ is available to select. Again installing the agent is straight forward. When you select ‘Install Agent’ the blade will provide download links to the agent(s).
Once the agent is installed it needs to be registered. The blade with the download link will also provide a ‘workspace key & ID’. I used these to register the VM to the Migration Project in Azure.
Clicking on ‘View Dependancys’ now shows the following. This is a useful breakdown at a service layer as to what the VM is doing what services/workloads it runs and whats communicating with it. In my case because this was a simple test VM you can see i have one client communicating with it via RDP and the health service/agent on the VM communicating with Azure.
My favourite feature in AM is the ability to create an ‘Assessment’. The assessment is essentially a readiness check of the VMs you’ve added in the assessment for their suitablility to move to Azure. Whats really useful also is the cost estimates that the assessment provides which really takes the guess work out of understanding the associated cost if moving to IaaS in Azure. The assessment can be exported to an excel spreadseet and provides a further estimated cost breakdown on compute, storage, the recommended ‘size’ for your VM’s and ultimately if they can even be supported or moved to Azure. In my case 3 of my VM’s were not supported as those VMs were using operating systems that Azure does not support. Again this is really useful rather than having to find out the hard way when using ASR or trawling docs.microsoft.com for supporting information.
As an intitial effort im very impressed with AM. I think it could become a much more complete tool if merged with ASR. That way the same .ova appliance can be used for assessing your enviroment as well as moving VMs to Azure, which also takes the inconvenience of having to build a configuration server for this same purpose.