Prepare on-premises machines for migration to Azure
Article
This article describes how to prepare on-premises machines before you migrate them to Azure using the Migration and modernization tool.
In this article, you:
Review migration limitations.
Select a method for migrating VMware vSphere VMs.
Check hypervisor and operating system requirements for machines you want to migrate.
Review URL and port access for machines you want to migrate.
Review changes you might need to make before you begin migration.
Check Azure VMs requirements for migrated machines.
Prepare machines so you can connect to the Azure VMs after migration.
Verify migration limitations
The table summarizes discovery, assessment, and migration limits for Azure Migrate. We recommend that you assess machines before migration, but you don't have to.
Scenario
Project
Discovery/Assessment
Migration
VMware vSphere VMs
Discover and assess up to 35,000 VMs in a single Azure Migrate project.
Discover up to 10,000 VMware vSphere VMs with a single Azure Migrate appliance for VMware vSphere. The appliance supports adding multiple vCenter Servers. You can add up to 10 vCenter Servers per appliance.
Agentless migration: you can simultaneously replicate a maximum of 500 VMs across multiple vCenter Servers (discovered from one appliance) using a scale-out appliance. Agent-based migration: you can scale out the replication appliance to replicate large numbers of VMs.
In the portal, you can select up to 10 machines at once for replication. To replicate more machines, add in batches of 10.
Hyper-V VMs
Discover and assess up to 35,000 VMs in a single Azure Migrate project.
Discover up to 5,000 Hyper-V VMs with a single Azure Migrate appliance
An appliance isn't used for Hyper-V migration. Instead, the Hyper-V Replication Provider runs on each Hyper-V host.
Replication capacity is influenced by performance factors such as VM churn, and upload bandwidth for replication data.
In the portal, you can select up to 10 machines at once for replication. To replicate more machines, add in batches of 10.
Physical machines
Discover and assess up to 35,000 machines in a single Azure Migrate project.
Discover up to 1000 physical servers with a single Azure Migrate appliance for physical servers.
If you're migrating VMware vSphere VMs or Hyper-V VMs, verify VMware vSphere VM requirements for agentless, and agent-based migration, and requirements for Hyper-V VMs.
There are some changes needed on VMs before you migrate them to Azure.
For some operating systems, Azure Migrate makes changes automatically during the replication/migration process.
For other operating systems, you need to configure settings manually.
It's important to configure settings manually before you begin migration. Some of the changes may affect VM boot up, or connectivity to the VM may not be established. If you migrate the VM before you make the change, the VM might not boot up in Azure.
Review the tables to identify the changes you need to make.
Windows machines
Changes performed are summarized in the table.
Action
VMware vSphere (agentless migration)
VMware vSphere (agent-based)/physical machines
Windows on Hyper-V
Configure the SAN policy as Online All
Set automatically for machines running Windows Server 2008 R2 or later.
Configure manually for earlier operating systems.
Set automatically in most cases.
Set automatically for machines running Windows Server 2008 R2 or later.
Enable the console on Azure VMs to help with troubleshooting. You don't need to reboot the VM. The Azure VM will boot by using the disk image. The disk image boot is equivalent to a reboot for the new VM.
Enable manually
Enable manually
Enable manually
Install the Windows Azure Guest Agent
The Virtual Machine Agent (VM Agent) is a secure, lightweight process that manages virtual machine (VM) interaction with the Azure Fabric Controller. The VM Agent has a primary role in enabling and executing Azure virtual machine extensions that enable post-deployment configuration of VM, such as installing and configuring software.
Set automatically for machines running Windows Server 2008 R2 or later. Configure manually for earlier operating systems.
Set automatically for machines running Windows Server 2008 R2 or later.
Set automatically for machines running Windows Server 2008 R2 or later.
Connect after migration
To connect after migration, there are a number of steps to take before you migrate.
Learn more on the changes performed on Windows servers for agentless VMware vSphere migrations.
Configure SAN policy
By default, Azure VMs are assigned drive D: to 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:
Configure this setting manually as follows:
On the on-premises machine (not the host server), open an elevated command prompt.
Enter diskpart.
Enter SAN. If the drive letter of the guest operating system isn't maintained, Offline All or Offline Shared is returned.
At the DISKPART prompt, enter SAN Policy=OnlineAll. This setting ensures that disks are brought online, and it ensures that you can read and write to both disks.
During the test migration, you can verify that the drive letters are preserved.
Linux machines
Azure Migrate completes these actions automatically for these versions
Red Hat Enterprise Linux 9.x, 8.x, 7.9, 7.8, 7.7, 7.6, 7.5, 7.4, 7.3, 7.2, 7.1, 7.0, 6.x (Azure Linux VM agent is also installed automatically during migration)
CentOS Stream (Azure Linux VM agent is also installed automatically during migration)
SUSE Linux Enterprise Server 15 SP4, 15 SP3, 15 SP2, 15 SP1, 15 SP0, 12, 11 SP4, 11 SP3
Ubuntu 22.04, 21.04, 20.04, 19.04, 19.10, 18.04LTS, 16.04LTS, 14.04LTS (Azure Linux VM agent is also installed automatically during migration)
Debian 11, 10, 9, 8, 7
Oracle Linux 9, 8, 7.7-CI, 7.7, 6
For other versions, prepare machines as summarized in the table.
Note
Some changes may affect the VM boot up, or connectivity to the VM may not be established.
Action
Details
Linux version
Install Hyper-V Linux Integration Services
Rebuild the Linux init image so it contains the necessary Hyper-V drivers. Rebuilding the init image ensures that the VM will boot in Azure.
Most new versions of Linux distributions have this included by default.
If not included, install manually for all versions except those called out above.
Enable Azure Serial Console logging
Enabling console logging helps you troubleshoot. You don't need to reboot the VM. The Azure VM will boot by using the disk image. The disk image boot is equivalent to a reboot for the new VM.
Update the device map file with the device name-to-volume associations, so you use persistent device identifiers.
Install manually for all versions except those called out above. (Only applicable in agent-based VMware scenario)
Update fstab entries
Update entries to use persistent volume identifiers.
Update manually for all versions except those called out above.
Remove udev rule
Remove any udev rules that reserves interface names based on mac address etc.
Remove manually for all versions except those called out above.
Update network interfaces
Update network interfaces to receive IP address based on DHCP.nst
Update manually for all versions except those called out above.
Enable ssh
Ensure ssh is enabled and the sshd service is set to start automatically on reboot.
Ensure that incoming ssh connection requests are not blocked by the OS firewall or scriptable rules.
Enable manually for all versions except those called out above.
Install the Linux Azure Guest Agent
The Microsoft Azure Linux Agent (waagent) is a secure, lightweight process that manages Linux & FreeBSD provisioning, and VM interaction with the Azure Fabric Controller.
Enable manually for all versions except those called out above. Follow instructions to install the Linux Agent manually for other OS versions. Review the list of required packages to install Linux VM agent.
Learn more on the changes performed on Linux servers for agentless VMware vSphere migrations.
The following table summarizes the steps performed automatically for the operating systems listed above.
Action
Agent-based VMware vSphere Migration
Agentless VMware vSphere Migration
Agentless Hyper-V Migration
Update kernel image with Hyper-V Linux Integration Services. (The LIS drivers should be present on the kernel.)
Yes
Yes
Yes
Enable Azure Serial Console logging
Yes
Yes
Yes
Update device map file
Yes
No
No
Update fstab entries
Yes
Yes
Yes
Remove udev rule
Yes
Yes
Yes
Update network interfaces
Yes
Yes
Yes
Enable ssh
No
No
No
Install Azure VM Linux agent
Yes
Yes
Yes
Learn more about steps for running a Linux VM on Azure, and get instructions for some of the popular Linux distributions.
Review the list of required packages to install Linux VM agent. Azure Migrate installs the Linux VM agent automatically for RHEL 8.x, Ubuntu 20.04, SUSE 15 and Oracle 7 when using the agentless method of VMware migration.
Check Azure VM requirements
On-premises machines that you replicate to Azure must comply with Azure VM requirements for the operating system and architecture, the disks, network settings, and VM naming.
Azure VMs are created during migration to Azure. After migration, you must be able to connect to the new Azure VMs. Multiple steps are required to connect successfully.
Prepare to connect to Azure Windows VMs
On on-premises Windows machines:
Configure Windows settings. Settings include removing any static persistent routes or WinHTTP proxy.
Enable remote desktop (RDP) to allow remote connections to the on-premises machine. Learn how to use PowerShell to enable RDP.
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 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:
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, complete these steps on the Azure VMs that are created:
To connect to the VM over the internet, assign a public IP address to the VM. You must use a different public IP address for the Azure VM than 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.