Prepare on-premises machines for migration to Azure
This article describes how to prepare on-premises machines before you start migrating them to Azure with Azure Migrate Server Migration.
In this article, you:
- Verify migration limitations.
- Check operating system requirements and support limitations.
- Review URL/port access for machines you want to migrate.
- Review changes you might need to make before you begin migration.
- Configure settings so that drive letters are preserved after migration.
- Prepare machines so that you can connect to the Azure VMs after migration.
Verify migration limitations
- You can assess up to 35,000 VMware VMs/Hyper-V VMs in a single Azure Migrate project using Azure Migrate Server Migration. A project can combine both VMware VMs and Hyper-V VMs, up to the limits for each.
- You can select up to 10 VMs at once for migration. If you need to replicate more, replicate in groups of 10.
- For VMware agentless migration, you can run up to 100 replications simultaneously.
Verify operating system requirements
- Verify that your Windows operating systems are supported in Azure.
- Verify that your Linux distributions are supported in Azure.
Check what's supported
- For VMware VMs, Azure Migrate Server Migration supports agentless or agent-based migration. Verify VMware VM requirements/support for agentless and agent-based migrations.
- Verify migration requirements and support for Hyper-V VMs.
- Verify migration requirements and support for on-premises physical machines, or other virtualized servers. These requirements are similar to VMware VM requirements.
Review URL/port access
Machines might need internet access during migration.
- Review URLs that VMware VMs need to access during agentless or agent-based migrations.
- Review URLs that Hyper-V hosts need to access during migration. Hyper-V VMs don't need internet access.
- Review URLs that physical machines or other virtualized servers need to access during migration.
- In agent-based migration of VMware VMs/physical servers, the Mobility service running on the machines needs access to Azure Migrate components. For replication management, the service running on the machine communicates with the on-premises Azure Migrate replication appliance on port HTTPS 443 inbound. The machines send replication data to the Azure Migrate process server on port HTTPS 9443 inbound. This port can be modified.
Verify required changes before migration
Some VMs might require changes so that they can run in Azure. Azure Migrate makes these changes automatically for VMs running these operating systems:
- Red Hat Enterprise Linux 6.5+, 7.0+
- CentOS 6.5+, 7.0+
- SUSE Linux Enterprise Server 12 SP1+
- Ubuntu 14.04LTS, 16.04LTS, 18.04LTS
- Debian 7, 8
For other operating systems, you need to prepare machines manually before migration.
Prepare Windows machines
If you're migrating a Windows machine, then make these changes before migration. If you migrate the VM before you make the changes, the VM might not boot up in Azure.
- Enable Azure serial access console for the Azure VM. This helps with troubleshooting. You don't need to reboot the VM. The Azure VM will boot using the disk image. This is equivalent to a reboot for the new VM.
- If you're migrating machines running Windows Server 2003, install Hyper-V Guest Integration Services on the VM operating system. Learn more.
Prepare Linux machines
- Install Hyper-V Linux Integration Services. Most new versions of Linux distributions include this by default.
- Rebuild the Linux init image so that it contains the necessary Hyper-V drivers. This ensures that the VM will boot in Azure, and is only required on some distributions.
- Enable Azure serial console logging. This helps with troubleshooting. You don't need to reboot the VM. The Azure VM will boot using the disk image. This is equivalent to a reboot for the new VM.
- Update the device map file with the device name to volume associations, so that you use persistent device identifiers.
- Update fstab entries to use persistent volume identifiers.
- Remove any udev rules that reserve interface names based on MAC address etc.
- Update network interfaces to receive an IP address from DHCP.
- Learn more about the steps needed to run a Linux VM on Azure, and get instructions for some of the popular Linux distributions.
Preserve drive letters after migration
When you migrate an on-premises machine to Microsoft Azure, the drive letters of additional data disks might change from their previous values. By default, Azure VMs are assigned drive D for use as temporary storage. This drive assignment causes all other attached storage drive assignments to increment by one letter.
For example, if your on-premises installation uses a data disk that is assigned to drive D for application installations, the assignment for this drive increments to drive E after you migrate the VM to Azure. To prevent this automatic assignment, and to ensure that Azure assigns the next free drive letter to its temporary volume, set the storage area network (SAN) policy to OnlineAll, as follows:
- On the on-premises machine (not the host server) open an elevated command prompt.
- Type diskpart.
- Type SAN. If the drive letter of the guest operating system isn't maintained, Offline All or Offline Shared is returned.
- At the DISKPART prompt, type SANPOLICY=ONLINEALL. This setting ensures that disks are brought online, and are both readable and writeable.
- During the test migration, you can verify that the drive letters are preserved.
Check Azure VM requirements
On-premises machines that you replicate to Azure must comply with Azure VM requirements for operating system and architecture, disks, network settings, and VM naming. Verify the requirements for VMware VMs/physical servers, and Hyper-V VMs before migration.
Prepare to connect after migration
Azure VMs are created during migration to Azure. After migration, you need to be able to connect to the new Azure VMs. There are a number of steps required to connect successfully.
Prepare to connect to Windows Azure VMs
On on-premises Windows machines, do the following:
- Configure Windows settings. These include removing any static persistent routes or WinHTTP proxy.
- Make sure these services are running.
- Enable remote desktop (RDP) to allow remote connections to the on-premises machine. Learn how to enable RDP with PowerShell.
- To access an Azure VM over the internet after migration, in Windows Firewall on the on-premises machine, allow TCP and UDP in the Public profile, and set RDP as an allowed app for all profiles.
- If you want to access an Azure VM over a site-to-site VPN after migration, in Windows Firewall on the on-premises machine, allow RDP for the Domain and Private profiles. Learn how to allow RDP traffic.
- Make sure that there are no Windows updates pending on the on-premises VM when you migrate. If there are, updates might start installing on the Azure VM after migration, and you won't be able to sign into the VM until updates finish.
Prepare to connect with Linux Azure VMs
On on-premises Linux machines, do the following:
- Check that the Secure Shell service is set to start automatically on system boot.
- Check that firewall rules allow an SSH connection.
Configure Azure VMs after migration
After migration, do the following on the Azure VMs that are created.
- To connect to the VM over the internet, assign a public IP address to the VM. You can't use the same public IP address for the Azure VM that you used for your on-premises machine. Learn more.
- Check that network security group (NSG) rules on the VM allow incoming connections to the RDP or SSH port.
- Check Boot diagnostics to view the VM.
The Azure Bastion service offers private RDP and SSH access to Azure VMs. Learn more about this service.