Lift & shift servers to Azure with the Azure MigratePosted on: November 15, 2019, by : Aad Lutgert
In July 2019 the (Current Version) of Azure Migrate was released. In the previous version only assessment of on-premises VMware VMs was supported, in the current release support has been added to also migrate Hyper-V VMs and On-Premises Servers (november release). With the release of the Current version Azure Migrate has become a portal where the migration can be centrally managed from A to Z, without the need for using any other 3rd party tools.
Some of the Features of Azure Migrate:
- Agentless migration of VMware VMs to Azure
- Agentless migration of Hyper-V VMs to Azure
- Agent-based migration of physical servers and VMs running on Amazon Web Services or Google Cloud Platform to Azure.
- Virtual Desktop, Web App and Database Migration
- Assessment with Azure Migrate: Server Assessment or using a 3rd Party (ISV) tool like: Movere, Unifycloud and more.
- Migration with Azure Migrate: Server Migration or using a 3rd Party (ISV) tool like: Carbonite Migrate, RackWare: Cloud Migration and more.
If you started using Azure migrate before the release of the Current version of Azure Migrate, you need to create a new Project to upgrade to the Current Version.
For all the information on what’s new in Azure Migrate and the latest functionality go to webpage “What’s new in Azure Migrate”.
Azure Migrate 4 Step onboarding process:
- Create a project – Prepare a Migration Environment
- Discover – Prepare the Host servers and discover the servers
- Assessment – Test the servers for issues (Currently only for VMware and Hyper-V hosts, On-Premises will come available in the November Release)
- Migration – Replicate Server, Test Migration and Migration
In this blog I will demonstrate how to migrate a Windows Server 2019 VM (Migrate01-2019) which runs on an On-Premises Hyper-V Server (Hyp01-2019) to Azure using the current version of Azure Migrate. I will use a setup with an on-premises Hyper-V server which is connected with a site-to-site connection to Azure. The Servers in the Azure VM subnet use the on-premises DNS servers.
1. To start Azure Migrate, Select “All Services” search for “Migrate” and select “Azure Migrate” (Tip: select the Asterisk to add “Azure Migrate” to the portal menu.)
2. Now the Azure Migrate blade opens,
The first step is creating an Azure Migrate Project. This is used to store the discovery, assessment and migration metadata reported by your on-premises environment. Also during the creation of the project, the assessment and migration tooling for the migration is selected.
3. First select the subscription and Resource group where the Project will be created. Enter a name for the Migrate Project and the preferred Geography. The geography specified for the project is only used to store the metadata gathered from on-premises VMs.
4. The next step is adding an assessment tool by selecting the Azure Migrate Server Assessment tool or a tool from an ISV. This step is optional and can be skipped by checking the box “skip adding an assessment tool for now“. In this demo I will be using the “Azure Migrate Server Assessment” tool.
5. Now select the Migration tool which you want to use to perform the Migration. This step is optional and can be skipped by checking the box “skip adding an migration tool for now“. In this demo I will be using the “Azure Migrate Server Migration” tool.
6. Review the settings and press “Add tool(s)” to create the Project
Now we need to setup the appliance on the Hyper-V Server. This appliance is a pre-installed Windows 2016 Server VM which is used for Discovering on-premises Hyper-V VMs and sends metadata and performance data to Azure Migrated, which is used for the assessment of VMs. Unlike the Appliance which is used for VMware, the Hyper-V appliance is only responsible for the Assessment. Read more about the appliance here.
7. In the “Azure Migrate” blade select on the left Migration goals -> Servers and select “Azure Migrate: Server Assessment” -> “Discover”
8. Select the way the VMs are virtualized, in this demonstration I select “Yes, with Hyper-V” because Hyper-V will be used and select “Download” to download the Azure Migrate Appliance which is a 12 GB zip file containing a VHD.
Tip: Download the file to a location from where you can copy it to the Hyper-V Server.
9. Copy the zip file to the Hyper-V Host-server and extract it to a folder. In Hyper-V Manager select “Import Virtual Machine” and locate the folder to which you’ve extracted the files.
10. Select the “Azure Migrate Appliance_v2*****” and choose “Copy the virtual machine (create a new unique ID)” in the next step.
11. Choose the destination folders, storage folders and select the virtual switch with access to the network and internet.
12. Finish the import and start the VM.
13. The Appliance is a Windows Server 2016 VM which needs to be setup before it can be used. Accept the License Terms and enter a password for the administrator account.
14. Now you need to collect the hostname or ip-address of the appliance. This can be done by logging on to the appliance and start command-prompt
15. Now the appliance needs to be configured and connected with Azure and the On-premises environment. Start a browser and browse to http://<appliance name or ip>:44368 and accept the license terms and set up prerequisites:
16. Register the Appliance with Azure Migrate. This will open a popup with a “Microsoft Azure Powershell” notification which you can close to continue.
17. Select the correct Subscription and the Migrate Project which you created earlier. Next step is to enter an Appliance Name, choose a recognizable name because this is used to identify this appliance in Azure Migrate.
18. Enter the credentials to connect to the Hyper-V hosts and clusters. In this demo I’m using the administrator credentials, but this is not required.
19. The last step before discovery can be started is adding the Hyper-V host or cluster which you want to use.
20. After some time the Hyper-V server should pop-up in the Host/Cluster overview with the total amount of VM’s (no matter State of VM) and Status. Press “Save and Discovery” to start the discovery.
21. The discovery will start. This will take some time depending on the amount of hosts.
After the discovery of the Azure Appliance has finished it will take about 15 minutes before the servers show up in the Azure Migrate portal. You need to press “Refresh” to update the portal.
There are two types of assessments which can be run with the Azure Migrate: Server Assessment tool:
- Performance Based – The recommended VM size and disk type will be based on collected performance data
- As on-premises – The recommended VM size and disk type will be based on the on-premises sizing
Let’s setup the assessment:
22. Select the “Assess” button located in Assessment tools.
23. Enter a name for the Assessment and press “View all” to view the Assessment settings to adjust these to your situation
The Assessment properties are divided in three sections:
- Target Properties – The settings about where and how the VM is stored.
- VM Size – The settings for the VM Size calculation.
- Pricing – The settings for the price calculation.
Tip: Adjust these settings to your situation, otherwise you will not see the correct assessment information about Price and Sizing!
24. In this demo I will use the default settings and close the screen by pressing “Assess servers” in the top of the screen.
25. Now we need to create a group which will contain the servers which will be assessed and select the servers which need to be added to the group. Press “create Assessment” to create the Assessment.
26. Wait a while and refresh the Azure Migrate portal. You should see that the assessment has been created. Press “Assessments”
27. Wait till the Status becomes “ready” and Select the generated Assessment to view the details.
In this overview you see an overview of the Assessment. It consists out of 3 categories:
- Azure Readiness – Here you can see if there any issues which need to be solved before the VMs can be migrated
- Storage – Monthly cost estimate – These are the the monthly running costs of storage for all assessed VMs based on the entered Assessment properties
- Monthly cost estimate – These are the total running costs of all the VMs (including storage) based on the entered Assessment properties
28. Now let’s have a look at the Azure Readiness report by clicking on the diagram. To see more details of a specific machine select the VM by selecting the name:
Tip: Increase the performance history in the assessment details to increase the confidence rating of the assessment. (See Orange message in the screenshot)
On the VM Details page the following information can be found:
- Azure VM Size – Advised VM Size
- Monthly Cost Estimate – Total cost estimate including Compute and Storage costs.
- Readiness issues – These are issues which could prevent a successful migration.
- Migration tool – The suggested tool for the migration .
- VM Details – CPU Cores/utilization, Disk type/size, Memory size/utilization, Networkadapters
Before you can start the migration the Readiness issues need to be solved. In this example the issues are automatically solved when Azure Site Recovery is used for the migration.
Before the VM can be migrated to Azure, the data of the VM needs to be replicated to the Recovery Services Vault. To replicate the data unlike VMware VMs an additional tool needs to be installed which is called the Azure Site Recovery Provider.
29. In the Azure Migrate Portal select in the Azure Migrate: Server Migration section -> “Discover“. In the “Discover machines” blade select are your machines virtualized: “Yes, with Hyper-V” and select and confirm the Target region which you want to use. Press “Create resources” to continue.
30. Download the Software (the blue “download” just below “Prepare Hyper-V host servers”) and the registration key file to the Hyper-V host server (the blue “download button”)
31. Install the software on the Hyper-V host server and use the registration key file to register the software in Azure.
32. In the Azure Migrate Portal select in the Azure Migrate: Server Migration section -> “Replicate”
33. On the source settings page you will see a message that the registration is not complete and you need to finalize to continue. Select this “message”
34. Press “Finalize registration” to continue. This will take some time before you can continue. Wait till the Deployment to finish. (see deployment information in notifications)
35. After about 15 minutes try again select in the Azure Migrate: Server Migration section -> “Replicate”
36. The Finalize registration error should not appear. Select “yes, with Hyper-V” and press “Next: Virtual machines”
37. Select the assessment settings you want to use. Select the “Group, Assessment and Virtual Machines” you want to replicate. Press “Next: Target settings” to continue.
38. Enter the target properties for the migration. Here you select the Subscription and the resource group which will be used to store the VM and also the network which will be used.
- Subscription – This is my partner subscription I will use.
- Resource Group – I’ve created a resource group for my Azure VMs
- Replication SA – This is the storage account used for the migration
- Virtual Network – The Virtual Network in Azure is called VNET-DITCOM-01
- Subnet – This is the subnet used for the VMs in Azure
- Hybrid Benefit – Because I’ve got an eligible Windows Server License I can select “Yes“
Press “Next: Compute” to continue.
39. In Compute the VM Size is automatically populated by the assessment information, make adjustments if needed. Select the “OS type” & “OS Disk” press “Next: Disks” to continue.
40. Select the disks you want to replicate by default all disks are replicated. The server in this demo “migrate01-2019” has two disks
- OS-Disk – 127 GB
- Data-Disk – 127 GB
41. Review the settings and press “Replicate” to start the replication of the selected servers to Azure.
42. The replication will take some time to complete depending on speed of the VPN connection and the size of the VM. To view the status of the migration press “Healthy” below “Step 1: Replicate“.
43. An overview with the status of all replicating servers will appear. Select the server you wish to replicate:
44. Because the status is “0% synchronized” a test migration or migration cannot be started (the buttons are greyed out). Wait for the Status to become “Protected”
45. In this screenshot the Status is “Protected” and the buttons “Test migration” and “Migrate” are available. Press “Test migration” to start a test migration.
It’s recommend that you do a test migration for each machine, before you migrate it.
- Running a test migration checks that migration will work as expected, without impacting the on-premises machines, which remain operational, and continue replicating.
- Test migration simulates the migration by creating an Azure test VM using replicated data (usually migrating to a non-production VNet in your Azure subscription).
- The replicated test Azure VM can be used to validate the migration, perform app testing, and address any issues before full migration.
46. Select the network to use for the test-migration. To demonstrate how the vm behaves I will use the default production VNet. (This is not recommended, always use a non-production VNet to perform testing)
47. The status of the Test-Migration can be monitored by selecting the job in notification (top right). Wait for the job to finish:
48. When the job has finished a virtual machine has been created with name: “<vm-name>-test” in this demo it’s “Migrate01-2019-test” it behaves exactly the same as any other virtual machine in Azure.
49. Just like any other VM you can “Connect” to the VM with RDP
50. I’m now connected with rdp connection to the “migrate01-2019-test” VM and I’ve opened a command-prompt to view the host name and IP-address. As you can see the hostname is “Migrate01-2019” and the IP-address is 10.1.0.6.
Because the VM is connected V-Net in Azure which is actually part of the on-premises network. It has overwritten the DNS record of the on-premises “migrate01-2019” VM.
Advice: Always use a test V-NET for a test migration and not the production V-NET to prevent changing the DNS of the production configuration.
51. After testing you need to clean up the test migration before performing the migration. The Cleanup can be performed by selecting “Clean up test migration”
52. Enter any notes about issues, performance or whatever and select the box “Testing is complete. Delete test virtual machine“. Press “Cleanup Test” to start Clean up.
53. In the background the previous created test virtual machine will be deleted. This can be seen when you look at the Virtual machines overview. In this screenshot the “Migrate01-2019-test” is being deleted as part of the Cleanup.
54. After a few minutes the cleanup has completed. Check “notifications” to view the status of the cleanup job
After cleaning up the test-migration everything is back as before. The Test VM in Azure has been deleted during the clean up testmigration. The Replicationdata in the Recovery Services vault is still being updated and the server on the Hyper-V server on-premises is running.
Now it’s time to perform the real migration. During the Migration (planned failover) a few steps are performed:
- Prerequisites check for planned failover
- Shutdown of the virtual machine (on-premises VM)
- Preparation of the failover
- Start failover
- Start the replica virtual machine
55. Go to “Azure Migrate” -> “Servers” select in “Azure Migrate: Server Migration” -> “Replicating Servers” and select the server you want to migrate. In the overview the button “Clean up test migration” has been grayed out and you can now select “Migrate”.
In this screen you are reminded to be sure the replication health is “Healthy” before you start the failover. By default the virtual machines which are migrated will be shutdown. This is to prevent data loss during the failover.
During the migration there will be a downtime between the shutdown and the failover to the replica machine.
56. Press “Migrate” to start migration.
57. If the Pre-requisites check is successful, on the Hyper-V server the VM will be shutdown.
56. During the “Start failover” the VM will be provisioned with a temporary name and disappear.
57. The VM will reappear with the correct name during the last step “Start the replica virtual machine”.
58. The migration is now finished and you should be able to connect with the migrated VM
Now the VM is active in Azure a few final steps need to be performed:
- Stop replication for the migrated server:
- Install the Azure VM agent on the migrated machine. The agent can be downloaded here
- Perform any post-migration app tweaks, such as updating database connection strings, and web server configurations.
- Perform final application and migration acceptance testing on the migrated application now running in Azure.
- Configure Backup (e.g. Azure Backup) and Update management (e.g. Azure Update Management) for the migrated machines.
- Cleanup on-premises environment: remove VM from Hyper-V and remove from Backup/Monitoring tools.
- Update Documentation with the updated location and IP address.