Azure Migrate Checklist

How To

Microsoft provides comprehensive guidance on how to deploy and configure Azure Migrate on the Microsoft Learn portal.

This page brings together Dr Migrate recommendations and Microsoft best-practice guidance in a single place. Use it as a quick reference before you roll out Azure Migrate and start collecting data.

ℹ️

The detailed, step-by-step discovery checklists for each infrastructure type (VMware, Hyper-V and Physical) are linked further down this page.

Deployment Checklist

Networking

💡 Do you have an Azure Migrate appliance inside every network-security boundary?

A security boundary is a discrete segment of the estate (for example, Production, DMZ or Test). Deploy one appliance per boundary and scope its discovery to that segment.

ℹ️

Where possible, join the appliance to the domain – this simplifies authentication during discovery.

💡 Have you opened the required ports between the appliance and the estate?

Appliance access: inbound TCP 3389 for RDP.
Server discovery (Windows / Linux): outbound 443 (HTTPS) & 5985 (WinRM). Linux also requires 22 (SSH).
Windows servers – WinRM enabled (PowerShell ≥ 2.0) and WMI accessible.
Linux servers – SSH enabled and the following commands available so the appliance can collect application data: list, tail, awk, grep, locate, head, sed, ps, print, sort, uniq.

Depending on the OS / package manager you may also need access to: rpm, snap, dpkg, yum, apt-cache, mssql-server.

Required Credentials

💡

Where possible use the same account for Hypervisor, OS and SQL discovery – it reduces overhead and avoids missed hosts.

Hypervisor

💡 Have you supplied credentials for the hypervisor fabric?

VMware: the account must have Guest Operations rights. [Microsoft guidance][L2] explains how to assign them.

Hyper-V: either:

An account with Administrator access on every Hyper-V host, or
A Local/Domain account that is a member of Remote Management Users, Hyper-V Administrators, and Performance Monitor Users.

Operating System

💡 Have you provided credentials for the servers themselves?

Windows: a (local or domain) account that is a member of Local Admins (Domain Admins also works).

Linux: a sudo user able to run ls and netstat or a user with CAP_DAC_READ_SEARCH & CAP_SYS_PTRACE on /bin/netstat and /bin/ls. If you use sudo, configure NOPASSWD so the commands run non-interactively.