Azure Migrate

Tell us about your PDF experience.
Azure Migrate documentation

Find articles to help you discover, assess, and migrate your on-premises environment
using tools in the Azure Migrate hub.
About Azure Migrate
ｅ OVERVIEW
What is Azure Migrate?
What's new in Azure Migrate?
Common questions
Get started
ｇ TUTORIAL
Assess VMware VMs with Server Assessment
Assess Hyper-V VMs with Server Assessment
Assess physical servers with Server Assessment
Assess servers using imported data
Assess SQL instances for migration to Azure SQL
Migrate VMware VMs with Migration and modernization
Migrate Hyper-V VMs with Migration and modernization
Migrate physical servers/VMs with Migration and modernization
Modernize ASP.NET web apps to Azure Kubernetes Service (AKS)
Start deployment
｀ DEPLOY
Review best practices for Server Assessment
Learn about Azure Migrate appliance deployment
Review the Azure Migrate support matrix

e e t e ue g ate suppo t at
Review the VMware support matrix
Review the Hyper-V support matrix
Review the physical server support matrix
Manage
ｃ HOW-TO GUIDE
Business case
Add assessment tools
Discover application inventory
Add migration tools
Scale VMware assessment
Automate and scale migration
Troubleshoot assessment and migration
Learn more
ｄ TRAINING
Learn about VMware/physical agent-based migration
Learn about Hyper-V migration
Learn about assessments
Learn about dependency visualization
Get involved
ｂ GET STARTED
Request a service feature
Ask a forum question
Azure Tech Community

About Azure Migrate
Article • 03/21/2023 • 6 minutes to read
This article provides a quick overview of the Azure Migrate service.
Azure Migrate provides a simplified migration, modernization, and optimization service

for Azure. All pre-migration steps such as discovery, assessments, and right-sizing of on-
premises resources are included for infrastructure, data, and applications. Azure
Migrate’s extensible framework allows for integration of third-party tools, thus
expanding the scope of supported use-cases. It provides the following:
Unified migration platform: A single portal to start, run, and track your migration
to Azure.
Range of tools: A range of tools for assessment and migration. Azure Migrate
tools include Azure Migrate: Discovery and assessment and Migration and
modernization. Azure Migrate also integrates with other Azure services and tools,
and with independent software vendor (ISV) offerings.
Assessment, migration, and modernization: In the Azure Migrate hub, you can
assess, migrate, and modernize:
Servers, databases and web apps: Assess on-premises servers including web
apps and SQL Server instances and migrate them to Azure.
Databases: Assess on-premises SQL Server instances and databases to migrate
them to an SQL Server on an Azure VM or an Azure SQL Managed Instance or
to an Azure SQL Database.
Web applications: Assess on-premises web applications and migrate them to
Azure App Service and Azure Kubernetes Service.
Virtual desktops: Assess your on-premises virtual desktop infrastructure (VDI)
and migrate it to Azure Virtual Desktop.
Data: Migrate large amounts of data to Azure quickly and cost-effectively using
Azure Data Box products.
Integrated tools
The Azure Migrate hub includes these tools:
Tool Assess and migrate Details
Azure Discover and assess Discover and assess on-premises servers running on
Migrate: servers including SQL VMware, Hyper-V, and physical servers in
Discovery and and web apps preparation for migration to Azure.
assessment
Tool Assess and migrate Details
Migration and Migrate servers Migrate VMware VMs, Hyper-V VMs, physical
modernization servers, other virtualized servers, and public cloud
VMs to Azure.
Data Assess SQL Server Data Migration Assistant is a stand-alone tool to

Migration databases for migration assess SQL Servers. It helps pinpoint potential
Assistant to Azure SQL Database, problems blocking migration. It identifies
Azure SQL Managed unsupported features, new features that can benefit
Instance, or Azure VMs you after migration, and the right path for database
running SQL Server. migration. Learn more.
Azure Migrate on-premises Learn more about Database Migration Service.

Database databases to Azure VMs
Migration running SQL Server,
Service Azure SQL Database, or
SQL Managed Instances
Movere Assess servers Learn more about Movere.
Web app Assess on-premises web Azure App Service Migration Assistant is a
migration apps and migrate them standalone tool to assess on-premises websites for
assistant to Azure. migration to Azure App Service.
Use Migration Assistant to migrate .NET and PHP

web apps to Azure. Learn more about Azure App
Service Migration Assistant.
Azure Data Migrate offline data Use Azure Data Box products to move large
Box amounts of offline data to Azure. Learn more.
７ Note
If you're in Azure Government, external integrated tools and ISV offerings can't
send data to Azure Migrate. You can use tools independently.
ISV integration
Azure Migrate integrates with several ISV offerings.
ISV Feature
Carbonite Migrate servers.
Cloudamize Assess servers.

ISV Feature
CloudSphere Assess servers.
Corent Technology Assess and migrate servers.
Device42 Assess servers.
Lakeside Assess VDI.
RackWare Migrate servers.
Turbonomic Assess servers.
UnifyCloud Assess servers and databases.
Zerto Migrate servers.
Azure Migrate: Discovery and assessment tool

The Azure Migrate: Discovery and assessment tool discovers and assesses on-premises
VMware VMs, Hyper-V VMs, and physical servers for migration to Azure.
Here's what the tool does:
Azure readiness: Assesses whether on-premises servers, SQL Servers and web apps
are ready for migration to Azure.
Azure sizing: Estimates the size of Azure VMs/Azure SQL configuration/number of
Azure VMware Solution nodes after migration.
Azure cost estimation: Estimates costs for running on-premises servers in Azure.
Dependency analysis: Identifies cross-server dependencies and optimization
strategies for moving interdependent servers to Azure. Learn more about
Discovery and assessment with dependency analysis.
The Discovery and assessment tool uses a lightweight Azure Migrate appliance that you
deploy on-premises.
The appliance runs on a VM or physical server. You can install it easily using a
downloaded template.
The appliance discovers on-premises servers. It also continually sends server
metadata and performance data to Azure Migrate.
Appliance discovery is agentless. Nothing is installed on discovered servers.
After appliance discovery, you can gather discovered servers into groups and run
assessments for each group.
Migration and modernization tool
The Migration and modernization tool helps in migrating servers to Azure:
Migrate Details
On-premises Migrate VMs to Azure using agentless or agent-based migration.

VMware VMs
For agentless migration, the Migration and modernization tool uses the same
appliance that is used by Discovery and assessment tool for discovery and
assessment of servers.
For agent-based migration, the Migration and modernization tool uses a

replication appliance.
On-premises Migrate VMs to Azure.

Hyper-V VMs
The Migration and modernization tool uses provider agents installed on
Hyper-V host for the migration.
On-premises You can migrate physical servers to Azure. You can also migrate other
physical servers virtualized servers, and VMs from other public clouds, by treating them as
or servers physical servers for the purpose of migration. The Migration and
hosted on other modernization tool uses a replication appliance for the migration.
clouds
Web apps You can perform agentless migration of ASP.NET web apps at-scale to Azure
hosted on App Service using Azure Migrate.
Windows OS in
a VMware
environment
Selecting assessment and migration tools

In the Azure Migrate hub, you select the tool you want to use for assessment or
migration and add it to a project. If you add an ISV tool or Movere:
To get started, obtain a license or sign up for a free trial by following the tool
instructions. Each ISV or tool specifies tool licensing.
Each tool has an option to connect to Azure Migrate. Follow the tool instructions
to connect.
Track your migration across all tools from within the project.
Movere
Movere is a Software as a Service (SaaS) platform. It increases business intelligence by
accurately presenting entire IT environments within a single day. Organizations and
enterprises grow, change, and digitally optimize. As they do so, Movere provides them
with the needed confidence to see and control their environments, whatever the
platform, application, or geography.
Microsoft acquired Movere, and it's no longer sold as a standalone offer. Movere is
available through Microsoft Solution Assessment and Microsoft Cloud Economics
Program. Learn more about Movere.
We encourage you to also look at Azure Migrate, our built-in migration service. Azure
Migrate provides a central hub to simplify your cloud migration. The hub
comprehensively supports workloads like physical and virtual servers, databases, and
applications. End-to-end visibility lets you easily track progress throughout discovery,
assessment, and migration.
With both Azure and partner ISV tools built in, Azure Migrate has an extensive range of
features, including:
Discovery of virtual and physical servers.

Performance-based rightsizing.
Cost planning.
Import-based assessments.
Dependency analysis of agentless applications.
If you're looking for expert help to get started, Microsoft has skilled Azure Expert
Managed Service Providers to guide you. Check out the Azure Migrate website .
Azure Migrate versions

There are two versions of the Azure Migrate service.
Current version: Use this version to create projects, discover on-premises servers,
and orchestrate assessments and migrations. Learn more about what's new in this
version.
Previous version: The previous version of Azure Migrate, also known as classic
Azure Migrate, supports only assessment of on-premises servers running on
VMware. Classic Azure Migrate is retiring in Feb 2024. After Feb 2024, classic
version of Azure Migrate will no longer be supported and the inventory metadata
in classic projects will be deleted. You can't upgrade projects or components in the
previous version to the new version. You need to create a new project, and add
assessment and migration tools to it. Use the tutorials to understand how to use
the assessment and migration tools available. If you had a Log Analytics workspace
attached to a classic project, you can attach it to a project of current version after
you delete the classic project.
To access existing projects in the Azure portal, search for and select Azure Migrate.
The Azure Migrate dashboard has a notification and a link to access old projects.
Next steps
Try our tutorials to assess VMware VMs, Hyper-V VMs, or physical servers.
Review frequently asked questions about Azure Migrate.
What's new in Azure Migrate
Article • 05/15/2023
Azure Migrate helps you to discover, assess, and migrate on-premises servers, apps, and
data to the Microsoft Azure cloud. This article summarizes new releases and features in
Azure Migrate.
Update (May 2023)

SQL Server discovery and assessment in Azure Migrate is now Generally Available
(GA). Learn more.
Update (April 2023)

Build a quick business case for servers imported via a .csv file. Learn more
Build business case using Azure Migrate for:
Servers and workloads running in your Microsoft Hyper-V and Physical/ Bare-
metal environments as well as IaaS services of other public cloud.
SQL Server Always On Failover Cluster Instances and Always On Availability
Groups. Learn more.
Update (March 2023)

Support for discovery and assessment of web apps for Azure app service for
Hyper-V and Physical servers. Learn more.
Update (February 2023)

Discovery and assessment of SQL Server Always On Failover Cluster Instances and
Always On Availability Groups is now supported. Learn more.
Public Preview: Modernize your ASP.NET web apps onto Azure Kubernetes Service
(AKS) directly through Azure Migrate. Learn more.
Update (January 2023)

Envision savings with Azure Savings Plan for compute (ASP) savings option with
Azure Migrate business case and assessments. ASP as a savings option
assumption/setting is now available for business case, Azure VM assessment, Azure
SQL assessment, and Azure App Service assessment.
Support for export of business case report into an .xlsx workbook from the portal.
Learn more.
Azure Migrate is now supported in Sweden geography. Learn more.
Update (December 2022)

General Availability: Perform software inventory and agentless dependency analysis
at-scale for Hyper-V virtual machines and bare metal servers or servers running on
other clouds like AWS, GCP etc. Learn more on how to perform software inventory
and agentless dependency analysis.
Public Preview: Build business case using Azure Migrate for servers and workloads
running in your VMware environment. It helps you eliminate guess work in your
cost planning process and adds data driven insights to understand how Azure can
bring the most value to your business.
Key highlights:
On-premises vs Azure total cost of ownership.
Year on year cashflow analysis.
Resource utilization based insights to identify servers and workloads that are
ideal for cloud.
Quick wins for migration and modernization including end of support Windows
OS and SQL versions.
Long term cost savings by moving from a capital expenditure model to an
Operating expenditure model, by paying for only what you use.
General availability: Discover, assess, and migrate servers over a private network
using Azure Private Link. Learn more.
Update (November 2022)

Support for providing a sudo user account to perform agentless dependency
analysis on Linux servers running in VMware, Hyper-V, and Physical/other cloud
environments.
Support for selecting VNet and Subnet during test migration using PowerShell for
agentless VMware scenario.
Support for OS disk swap using the Azure portal and PowerShell for agentless
VMware scenario.
Support for pausing and resuming replications using PowerShell for agentless
VMware scenario.
Update (October 2022)

Support for export of errors and notifications from the portal for software
inventory and agentless dependency.
Private preview: Plan replication. This is a new feature added to the Migration and
Modernization tool of Azure Migrate. It helps to estimate the time and resources
required for replication and migration of the discovered servers. This feature will
help in planning the replication and migration schedule. Currently, the feature is
available for VMware agentless migrations. To enroll for private preview, please fill
this form .
Update (September 2022)

Support for pausing and resuming ongoing replications without having to do a
complete replication again. You can also retry VM migrations without the need to
do a full initial replication again.
Enhanced notifications for test migration and migration completion status.
Java web apps discovery on Apache Tomcat running on Linux servers hosted in
VMware environment.
Enhanced discovery data collection including detection of database connecting
strings, application directories, and authentication mechanisms for ASP.NET web
apps.
General availability: Discover, assess, and migrate servers over a private network
using Azure Private Link. Learn more.
Update (August 2022)

SQL discovery and assessment for Microsoft Hyper-V and Physical/ Bare-metal
environments as well as IaaS services of other public cloud.
Update (June 2022)

Perform at-scale agentless migration of ASP.NET web apps running on IIS web
servers hosted on a Windows OS in a VMware environment. Learn more.
Update (May 2022)
Upgraded the Azure SQL assessment experience to identify the ideal migration
target for your SQL deployments across Azure SQL MI, SQL Server on Azure VM,
and Azure SQL DB:
We recommended migrating instances to SQL Server on Azure VM as per the
Azure best practices.
Right sized Lift and Shift - Server to SQL Server on Azure VM. We recommend
this when SQL Server credentials aren't available.
Enhanced user-experience that covers readiness and cost estimates for multiple
migration targets for SQL deployments in one assessment.
Support for Storage vMotion during replication for agentless VMware VM
migrations.
Update (March 2022)

Perform agentless VMware VM discovery, assessments, and migrations over a
private network using Azure Private Link. Learn more.
General Availability: Support to select subnets for each Network Interface Card of a
replicating virtual machine in VMware agentless migration scenario.
Update (February 2022)

General Availability: Migrate Windows and Linux Hyper-V virtual machines with
large data disks (up to 32 TB in size).
Azure Migrate is now supported in Azure China. Learn more.
Public preview of at-scale, software inventory, and agentless dependency analysis
for Hyper-V virtual machines and bare metal servers or servers running on other
clouds like AWS, GCP etc.

Support to discover, assess, and migrate VMs from multiple vCenter Servers using
a single Azure Migrate appliance. Learn more.
Simplified Azure VMware Solution assessment experience to understand sizing
assumptions, resource utilization and limiting factor for migrating on-premises
VMware VMs to Azure VMware Solution. Other enhancements added:
Support for two new target assessment regions: Central US and Canada East
Support for Reserved Instances in assessment properties for more accurate cost
estimates
New readiness condition to highlight Operating Systems deprecated by VMware
Support for storage utilization parameter in storage sizing logic (only for
discovery via a .csv file)
Update (October 2021)

Azure Migrate now supports new public cloud geographies and regions. Learn
more.

Discover, assess, and migrate servers over a private network using Azure Private
Link. is now in preview in supported government cloud geographies. Learn more
Support to tag and add custom names to resources for agentless VMware VM
migrations using PowerShell.
Azure Migrate appliance: Option to remove servers from the physical servers
discovery list.

At-scale discovery and assessment of ASP.NET web apps running on IIS servers in
your VMware environment, is now in preview. Learn More. Refer to the Discovery
and assessment tutorials to get started.
Support for Azure ultra disks in Azure VM assessment recommendation.
General Availability of at-scale, software inventory and agentless dependency
analysis for VMware virtual machines.
Azure Migrate appliance updates:
‘Diagnose and solve’ on appliance to help users identify and self-assess any
issues with the appliance.
Unified installer script- common script where users need to select from the
scenario, cloud, and connectivity options to deploy an appliance with the
desired configuration.
Support to add a user account with ‘sudo’ access on appliance configuration
manager to perform discovery of Linux servers (as an alternative to providing
root account or enabling setcap permissions).
Support to edit the SQL Server connection properties on the appliance
configuration manager.
Update (July 2021)
Azure Migrate: App Containerization tool now lets you package applications
running on servers into a container image and deploy the containerized
application to Azure App Service containers, in addition to Azure Kubernetes
Service. You can also automatically integrate application monitoring for Java apps
with Azure Application Insights and use Azure Key Vault to manage application
secrets such as certificates and parameterized configurations. For more
information, see ASP.NET app containerization and migration to Azure App Service
and Java web app containerization and migration to Azure App Service tutorials to
get started.
Update (June 2021)

Azure Migrate now supports new public cloud geographies and regions. Learn
more
Azure Migrate allows you to register servers running SQL server with SQL VM RP
during replication to automatically install SQL IaaS Agent Extension. This feature is
available for agentless VMware, agentless Hyper-V, and agent-based migrations.
Import CSV file for assessment now supports up to 20 disks. Earlier it was limited
to eight disks per server.
Update (May 2021)

Migration of VMs and physical servers with OS disks up to 4 TB is now supported
using the agent-based migration method.
Update (March 2021)

Support to provide multiple server credentials on Azure Migrate appliance to
discover installed applications (software inventory), agentless dependency analysis
and discover SQL Server instances and databases in your VMware environment.
Learn more
Discovery and assessment of SQL Server instances and databases running in your
VMware environment is now in preview. Learn More Refer to the Discovery and
assessment tutorials to get started.
Agentless VMware migration now supports concurrent replication of 500 VMs per
vCenter.
Azure Migrate: App Containerization tool now lets you package applications
running on servers into a container image and deploy the containerized
application to Azure Kubernetes Service.
For more information, see ASP.NET app containerization and migration to Azure
Kubernetes Service and Java web app containerization and migration to Azure
Kubernetes Service tutorials to get started.
Update (January 2021)

Migration and modernization tool now lets you migrate VMware virtual machines,
physical servers, and virtual machines from other clouds to Azure virtual machines
with disks encrypted with server-side encryption with customer-managed keys
(CMK).

Azure Migrate now automatically installs the Azure VM agent on the VMware VMs
while migrating them to Azure using the agentless method of VMware migration.
(Windows Server 2008 R2 and later)
Migration of VMware VMs to Azure virtual machines with disks encrypted using
server-side encryption (SSE) with customer-managed keys (CMK), using the
Migration and modernization (agentless replication) tool is now available through
the Azure portal.

Migration of servers to Availability Zones is now supported.
Migration of UEFI-based VMs and physical servers to Azure generation 2 VMs is
now supported. With this release, Migration and modernization tool won't perform
the conversion from Gen 2 VM to Gen 1 VM during migration.
A new Azure Migrate Power BI assessment dashboard is available to help you
compare costs across different assessment settings. The dashboard comes with a
PowerShell utility that automatically creates the assessments that plug into the
Power BI dashboard. Learn more.
Dependency analysis (agentless) can now be run concurrently on a 1000 VMs.
Dependency analysis (agentless) can now be enabled or disabled at scale using
PowerShell scripts. Learn more.
Visualize network connections in Power BI using the data collected using
dependency analysis (agentless) Learn more.
Migration of VMware VMs with data disk size of up to 32 TB is now supported
using the Migration and modernization agentless VMware migration method.

Improved onboarding experience where an Azure Migrate project key is generated
from the portal and is used to complete the appliance registration.
Option to download either OVA/VHD files or the installer scripts from the portal to
set up the VMware and Hyper-V appliances respectively.
Refreshed appliance configuration manager with enhanced user experience.
Multiple credentials support for Hyper-V VMs discovery.
Update (July 2020)

Agentless VMware migration now supports concurrent replication of 300 VMs per
vCenter.
Update (June 2020)

Assessments for migrating on-premises VMware VMs to Azure VMware Solution
(AVS) are now supported. Learn more
Support for multiple credentials on appliance for physical server discovery.
Support to allow Azure sign-in from appliance for tenant where tenant restriction
has been configured.
Update (April 2020)

Azure Migrate supports deployments in Azure Government.
You can discover and assess VMware VMs, Hyper-V VMs, and physical servers.
You can migrate VMware VMs, Hyper-V VMs, and physical servers to Azure.
For VMware migration, you can use agentless or agent-based migration. Learn
more.
Review supported geographies and regions for Azure Government.
Agent-based dependency analysis isn't supported in Azure Government.
Features in preview are supported in Azure Government, agentless dependency
analysis, and application discovery.
Update (March 2020)

A script-based installation is now available to set up the Azure Migrate appliance:
The script-based installation is an alternative to the .OVA (VMware)/VHD (Hyper-V)

installation of the appliance.
It provides a PowerShell installer script that can be used to set up the appliance for
VMware/Hyper-V on an existing machine running Windows Server 2016.
Update (November 2019)

Many new features were added to Azure Migrate:
Physical server assessment. Assessment of on-premises physical servers is now

supported, in addition to physical server migration that is already supported.
Import-based assessment. Assessment of machines using metadata and
performance data provided in a CSV file is now supported.
Application discovery: Azure Migrate now supports application-level discovery of
apps, roles, and features using the Azure Migrate appliance. This is currently
supported for VMware VMs only, and is limited to discovery only (assessment isn't
currently supported). Learn more
Agentless dependency visualization: You no longer need to explicitly install agents
for dependency visualization. Both agentless and agent-based are now supported.
Virtual Desktop: Use ISV tools to assess and migrate on-premises virtual desktop
infrastructure (VDI) to Windows Virtual Desktop in Azure.
Web app: The Azure App Service Migration Assistant, used for assessing and
migration web apps, is now integrated into Azure Migrate.
New assessment and migration tools were added to Azure Migrate:
RackWare: Offering cloud migration.

Movere: Offering assessment.
Learn more about using tools and ISV offerings for assessment and migration in Azure
Migrate.
Azure Migrate current version

The current version of Azure Migrate (released in July 2019) provides many new
features:
Unified migration platform: Azure Migrate now provides a single portal to

centralize, manage, and track your migration journey to Azure, with an improved
deployment flow and portal experience.
Assessment and migration tools: Azure Migrate provides native tools, and
integrates with other Azure services, and with independent software vendor (ISV)
tools. Learn more about ISV integration.
Azure Migrate assessment: Using the Azure Migrate Server Assessment tool, you
can assess VMware VMs and Hyper-V VMs for migration to Azure. You can also
assess for migration using other Azure services, and ISV tools.
Azure Migrate migration: Using the Migration and modernization tool, you can
migrate on-premises VMware VMs and Hyper-V VMs to Azure, as well as physical
servers, other virtualized servers, and private/public cloud VMs. In addition, you
can migrate to Azure using ISV tools.
Azure Migrate appliance: Azure Migrate deploys a lightweight appliance for
discovery and assessment of on-premises VMware VMs and Hyper-V VMs.
This appliance is used by Azure Migrate Server Assessment, and the Migration
and modernization tool for agentless migration.
The appliance continuously discovers server metadata and performance data,
for the purposes of assessment and migration.
VMware VM migration: The Migration and modernization tool provides a couple
of methods for migrating on-premises VMware VMs to Azure. An agentless
migration using the Azure Migrate appliance, and an agent-based migration that
uses a replication appliance, and deploys an agent on each VM you want to
migrate. Learn more
Database assessment and migration: From Azure Migrate, you can assess on-
premises databases for migration to Azure using the Azure Database Migration
Assistant. You can migrate databases using the Azure Database Migration Service.
Web app migration: You can assess web apps using a public endpoint URL with
the Azure App Service. For migration of internal .NET apps, you can download and
run the App Service Migration Assistant.
Data Box: Import large amounts offline data into Azure using Azure Data Box in
Azure Migrate.
Azure Migrate previous version

If you're using the previous version of Azure Migrate (only assessment of on-premises
VMware VMs was supported), you should now use the current version. In the previous
version, you can no longer create new Azure Migrate projects, or perform new
discoveries. You can still access existing projects. To do this in the Azure portal, go to All
services, search for Azure Migrate. In the Azure Migrate notifications, there's a link to
access old Azure Migrate projects.
Next steps
Learn more about Azure Migrate pricing.
Review frequently asked questions about Azure Migrate.
Try out our tutorials to assess VMware VMs and Hyper-V VMs.
Azure Migrate: Common questions
This article answers common questions about Azure Migrate. If you've questions after
you read this article, you can post them in the Azure Migrate forum . You also can
review these articles:
Questions about the Azure Migrate appliance

Questions about discovery, assessment, and dependency visualization
What is Azure Migrate?

Azure Migrate provides a central hub to track discovery, assessment, and migration of
your on-premises apps and workloads and private and public cloud VMs to Azure. The
hub provides Azure Migrate tools for assessment and migration and third-party ISV
offerings. Learn more.
What can I do with Azure Migrate?

Use Azure Migrate to discover, assess, and migrate on-premises infrastructure,
applications, and data to Azure. Azure Migrate supports assessment and migration of
on-premises VMware VMs, Hyper-V VMs, physical servers, other virtualized VMs,
databases, web apps, and virtual desktops.
What's the difference between Azure Migrate

and Azure Site Recovery?
Azure Migrate provides a centralized hub for assessment and migration to Azure.
Using Azure Migrate provides interoperability and future extensibility with Azure
Migrate tools, other Azure services, and third-party tools.
The Migration and modernization tool is purpose-built for server migration to
Azure. It's optimized for migration. You don't need to learn about concepts and
scenarios that aren't directly relevant to migration.
There are no tool usage charges for migration for 180 days, from the time
replication is started for a VM. It gives you time to complete migration. You only
pay for the storage and network resources used in replication, and for compute
charges consumed during test migrations.
Azure Migrate supports all migration scenarios supported by Site Recovery. Also,
for VMware VMs, Azure Migrate provides an agentless migration option.
We're prioritizing new migration features for the Migration and modernization tool
only. These features aren't targeted for Site Recovery.
Azure Site Recovery should be used for disaster recovery only.
The Migration and modernization tool uses some back-end Site Recovery functionality
for lift-and-shift migration of some on-premises machines.
I have a project with the previous classic

experience of Azure Migrate. How do I start
using the new version?
Classic Azure Migrate is retiring in Feb 2024. After Feb 2024, classic version of Azure
Migrate will no longer be supported, and the inventory metadata in the classic project
will be deleted. You can't upgrade projects or components in the previous version to the
new version. You need to create a new Azure Migrate project, and add assessment and
migration tools to it. Use the tutorials to understand how to use the assessment and
migration tools available. If you had a Log Analytics workspace attached to a classic
project, you can attach it to a project of current version after you delete the classic
project.
What's the difference between Azure Migrate:

Discovery and assessment and the MAP
Toolkit?
Server Assessment provides assessment to help with migration readiness, and
evaluation of workloads for migration to Azure. The Microsoft Assessment and Planning
(MAP) Toolkit helps with other tasks, including migration planning for newer versions
of Windows client and server operating systems, and software usage tracking. For these
scenarios, continue to use the MAP Toolkit.
What's the difference between Server

Assessment and the Site Recovery Deployment
Planner?
Server Assessment is a migration planning tool. The Site Recovery Deployment Planner
is a disaster recovery planning tool.
Choose your tool based on what you want to do:
Plan on-premises migration to Azure: If you plan to migrate your on-premises

servers to Azure, use Server Assessment for migration planning. Server Assessment
assesses on-premises workloads and provides guidance and tools to help you
migrate. After the migration plan is in place, you can use tools like the Migration
and modernization tool to migrate the machines to Azure.
Plan disaster recovery to Azure: If you plan to set up disaster recovery from on-
premises to Azure with Site Recovery, use the Site Recovery Deployment Planner.
The Deployment Planner provides a deep, Site Recovery-specific assessment of
your on-premises environment for the purpose of disaster recovery. It provides
recommendations related to disaster recovery, such as replication and failover.
How does the Migration and modernization

tool work with Site Recovery?
If you use the Migration and modernization tool to perform an agentless migration
of on-premises VMware VMs, migration is native to Azure Migrate and Site
Recovery isn't used.
If you use the Migration and modernization tool to perform an agent-based
migration of VMware VMs, or if you migrate Hyper-V VMs or physical servers, the
Migration and modernization tool uses the Azure Site Recovery replication engine.
Which geographies are supported?

Review the supported geographies for public and government clouds.
What does Azure Migrate do to ensure data

residency?
When you create a project, you select a geography of your choice. The project and
related resources are created in one of the regions in the geography, as allocated by the
Azure Migrate service. See the metadata storage locations for each geography here.
Azure Migrate doesn't move or store customer data outside of the region allocated,
guaranteeing data residency and resiliency in the same geography.
Does Azure Migrate offer Backup and Disaster
Recovery?
Azure Migrate is classified as customer managed Disaster Recovery, which means Azure
Migrate doesn't offer to recover data from an alternate region and offer it to customers
when the project region isn't available.
While using different capabilities, it's recommended that you export the software
inventory, dependency analysis, and assessment report for an offline backup.
In the event of a regional failure or outage in the Azure region that your project is
created in:
You may not be able to access your Azure Migrate projects, assessments, and other
reports for the duration of the outage. However, you can use the offline copies
that you've exported.
Any in-progress replication and/or migration will be paused and you might have to
restart it post the outage.
How do I get started?

Identify the tool you need, and then add the tool to an Azure Migrate project.
To add an ISV tool or Movere:
1. Get started by obtaining a license, or sign up for a free trial, in accordance with the
tool policy. Licensing for tools is in accordance with the ISV or tool licensing
model.
2. In each tool, there's an option to connect to Azure Migrate. Follow the tool
instructions and documentation to connect the tool with Azure Migrate.
You can track your migration journey from within the Azure Migrate project, across
Azure, and in other tools.
How do I delete a project?

Learn how to delete a project.
Can an Azure Migrate resource be moved?

No, Azure Migrate does not support moving resources. To move resources created by
Azure Migrate, consider creating a new project in the desired region.
Next steps
Read the Azure Migrate overview.
Azure Migrate appliance: Common
questions
This article answers common questions about the Azure Migrate appliance. If you have
other questions, check these resources:
General questions about Azure Migrate

Questions about Migration and modernization
Get questions answered in the Azure Migrate forum
What is the Azure Migrate appliance?

The Azure Migrate appliance is a lightweight appliance that the Azure Migrate:
Discovery and assessment tool uses to discover and assess physical or virtual servers
from on-premises or any cloud. The Migration and modernization tool also uses the
appliance for agentless migration of on-premises servers running in VMware
environment.
Here's more information about the Azure Migrate appliance:
The appliance is deployed on-premises as a physical server or a virtualized server.

The appliance discovers on-premises servers and continually sends server
Appliance discovery is agentless. Nothing is installed on the discovered servers.
Learn more about the appliance.
How can I deploy the appliance?

The appliance can be deployed using a couple of methods:
The appliance can be deployed using a template for servers running in VMware or
Hyper-V environment (OVA template for VMware or VHD for Hyper-V).
If you don't want to use a template, you can deploy the appliance for VMware or
Hyper-V environment using a PowerShell installer script.
In Azure Government, you should deploy the appliance using a PowerShell installer
script. Refer to the steps of deployment here.
For physical or virtualized servers on-premises or any other cloud, you always
deploy the appliance using a PowerShell installer script.Refer to the steps of
deployment here.
How does the appliance connect to Azure?

The appliance can connect to Azure using public or private networks or using Azure
ExpressRoute.
Make sure the appliance can connect to these Azure URLs.

You can use ExpressRoute with Microsoft peering. Public peering is deprecated,
and isn't available for new ExpressRoute circuits.
Does appliance analysis affect performance?

The Azure Migrate appliance profiles on-premises servers continuously to measure
performance data. This profiling has almost no performance impact on profiled servers.
Can I harden the appliance?

When you use the downloaded template to create the appliance, you can add
components (antivirus, for example) to the template. Ensure that you have allowed
access to the correct URLs through Azure Firewall and that the
%ProgramData%\Microsoft Azure folder is excluded from antivirus scanning.
What network connectivity is required?

The appliance needs access to Azure URLs. Review the URL list.
What data does the appliance collect?

See the following articles for information about data that the Azure Migrate appliance
collects on servers:
Servers in VMware environment: Review collected data.

Servers in Hyper-V environment: Review collected data.
Physical or virtual servers: Review collected data.
How is data stored?

Data that's collected by the Azure Migrate appliance is stored in the Azure location
where you created the project.
Here's more information about how data is stored:
The collected data is securely stored in Azure Cosmos DB in a Microsoft

subscription. The data is deleted when you delete the project. Storage is handled
by Azure Migrate. You can't specifically choose a storage account for collected
data.
If you use dependency visualization, the data that's collected is stored in an Azure
Log Analytics workspace created in your Azure subscription. The data is deleted
when you delete the Log Analytics workspace in your subscription.
How much data is uploaded during continuous

profiling?
The volume of data that's sent to Azure Migrate depends on multiple parameters. As an
example, a project that has 10 servers (each with one disk and one NIC) sends
approximately 50 MB of data per day. This value is approximate; the actual value varies
depending on the number of data points for the disks and NICs. If the number of
servers, disks, or NICs increases, the increase in data that's sent is nonlinear.
Is data encrypted at rest and in transit?

Yes, for both:
Metadata is securely sent to the Azure Migrate service over the internet via HTTPS.
Metadata is stored in an Azure Cosmos DB database and in Azure Blob storage in a
Microsoft subscription. The metadata is encrypted at rest for storage.
The data for dependency analysis also is encrypted in transit (by secure HTTPS). It's
stored in a Log Analytics workspace in your subscription. The data is encrypted at
rest for dependency analysis.
How does the appliance connect to vCenter

Server?
These steps describe how the appliance connects to VMware vCenter Server:
1. The appliance connects to vCenter Server (port 443) by using the credentials you
provided when you set up the appliance.
2. The appliance uses VMware PowerCLI to query vCenter Server to collect metadata
about the servers that are managed by vCenter Server.
3. The appliance collects configuration data about servers (cores, memory, disks,
NICs) and the performance history of each server for the past month.
4. The collected metadata is sent to the Azure Migrate: Discovery and assessment
tool (over the internet via HTTPS) for assessment.
Can the Azure Migrate appliance connect to

multiple vCenter Servers?
Yes. If the version of appliance configuration manager is 6.1.265.1 or above, you can
connect to up to 10 vCenter Servers and perform discovery, assessment, and migration
of servers running across multiple vCenter Servers using a single Azure Migrate
appliance. Learn more.
Can a project have multiple appliances?

A project can have multiple appliances registered to it. However, one appliance can only
be registered with one project.
How do I find the Azure Migrate appliances

registered to the project?
1. From the Azure portal, navigate to Azure Migrate homepage and from the left
menu, select Servers, databases and web apps.
2. Select Change in the upper-right corner to choose your project.
3. In the Azure Migrate project, select Overview from the Azure Migrate: Discovery &
assessment.
4. In Overview, select Appliances in left menu to see the appliances registered with
the project and the connectivity status of the agents on the appliance.
Can the Azure Migrate appliance/Replication

appliance connect to the same vCenter?
Yes. You can add both the Azure Migrate appliance (used for assessment and agentless
VMware migration), and the replication appliance (used for agent-based migration of
servers running in VMware) to the same vCenter server. But make sure that you are not
setting up both appliances on the same server and that is currently not supported.
How many servers can I discover with an
appliance?
You can discover up to 10,000 servers in VMware environment, up to 5,000 servers in
Hyper-V environment, and up to 1000 physical servers with a single appliance. If you
have more servers in your on-premises environment, read about scaling a Hyper-V
assessment, scaling a VMware assessment, and scaling a physical server assessment.
Can I delete an appliance?

Currently, deleting an appliance from the project isn't supported.
The only way to delete the appliance is to delete the resource group that contains the
project that's associated with the appliance.
However, deleting the resource group also deletes other registered appliances, the
discovered inventory, assessments, and all other Azure components in the resource
group that are associated with the project.
Can I use the appliance with a different

subscription or project?
To use the appliance with a different subscription or project, you would need to
reconfigure the existing appliance by running the PowerShell installer script for the
specific scenario (VMware/Hyper-V/Physical) on the appliance. The script will clean up
the existing appliance components and settings to deploy a fresh appliance. Ensure to
clear the browser cache before you start using the newly deployed appliance
configuration manager.
Also, you cannot reuse an existing project key on a reconfigured appliance. Make sure
you generate a new key from the desired subscription/project to complete the appliance
registration.
Can I set up the appliance on an Azure VM?

No. Currently, this option isn't supported.
Can I discover on an ESXi host?

No. To discover servers in VMware environment, you must have vCenter Server.
How do I update the appliance?

By default, the appliance and its installed agents are updated automatically. The
appliance checks for updates every 24 hours. Updates that fail are retried.
Only the appliance and the appliance agents are updated by these automatic updates.
The operating system is not updated by Azure Migrate automatic updates. Use
Windows Updates to keep the operating system up to date.
Can I check agent health?

Yes. In the portal, go the Agent health page of the Azure Migrate: Discovery and
assessment tool or the Migration and modernization tool. There, you can check the
connection status between Azure and the discovery and assessment agents on the
appliance.
Can I add multiple server credentials on

appliance?
Yes, we now support multiple server credentials to perform software inventory
(discovery of installed applications), agentless dependency analysis, and discovery of
SQL Server instances and databases. Learn more on how to provide credentials on the
appliance configuration manager.
What type of server credentials can I add on

the appliance?
You can provide domain/ Windows(non-domain)/ Linux(non-domain)/ SQL Server
authentication credentials on the appliance configuration manager. Learn more about
how to provide credentials and how we handle them.
What type of SQL Server connection properties

are supported by Azure Migrate for SQL
discovery?
Azure Migrate will encrypt the communication between Azure Migrate appliance and
source SQL Server instances (with Encrypt connection property set to TRUE). These
connections are encrypted with TrustServerCertificate (set to TRUE); the transport layer
will use SSL to encrypt the channel and bypass the certificate chain to validate trust. The
appliance server must be set up to trust the certificate's root authority.
If no certificate has been provisioned on the server when it starts up, SQL Server
generates a self-signed certificate that is used to encrypt login packets. Learn more.
Next steps
Discovery and dependency analysis -
Common questions
This article answers common questions about discovery and dependency analysis in
Azure Migrate. If you've other questions, check these resources:

What is dependency visualization?

Dependency visualization can help you assess groups of servers to migrate with greater
confidence. Dependency visualization cross-checks machine dependencies before you
run an assessment. It helps ensure that nothing is left behind, and it helps avoid
unexpected outages when you migrate to Azure. Azure Migrate uses the Service Map
solution in Azure Monitor to enable dependency visualization. Learn more.
７ Note
Agent-based dependency analysis isn't available in Azure Government. You can use
agentless dependency analysis
What's the difference between agent-based

and agentless?
The differences between agentless visualization and agent-based visualization are
summarized in the table.
Requirement Agentless Agent-based
Support Generally available for VMware VMs, In General Availability (GA).

Hyper-V VMs, bare-metal servers, and
servers running on other public clouds
like AWS, GCP etc.
Agent No need to install agents on machines Agents to be installed on each on-

you want to cross-check. premises machine that you want to
analyze: The Microsoft Monitoring agent
(MMA), and the Dependency agent.
Prerequisites Review the prerequisites and Review the prerequisites and

deployment requirements. deployment requirements.
Log Analytics Not required. Azure Migrate uses the Service Map
solution in Azure Monitor logs for
dependency visualization. Learn more.
How it works Captures TCP connection data on Service Map agents installed on a
machines enabled for dependency machine gather data about TCP
visualization. After discovery, it processes and inbound/outbound
gathers data at intervals of five connections for each process.
minutes.
Data Source machine server name, process, Source machine server name, process,
application name. application name.
Destination machine server name, Destination machine server name,

process, application name, and port. process, application name, and port.
Number of connections, latency, and

data transfer information are gathered
and available for Log Analytics queries.
Visualization Dependency map of single server can Dependency map of a single server.
be viewed over a duration of one hour
to 30 days. Map can be viewed over an hour only.
Dependency map of a group of servers.
Add and remove servers in a group from

the map view.
Data export Last 30 days data can be downloaded Data can be queried with Log Analytics.
in a CSV format.
Do I need to deploy the appliance for agentless

dependency analysis?
Yes, the Azure Migrate appliance must be deployed.
Do I pay for dependency visualization?
No. Learn more about Azure Migrate pricing .
What do I install for agent-based dependency

visualization?
To use agent-based dependency visualization, download and install agents on each on-
premises machine that you want to evaluate:
Microsoft Monitoring Agent (MMA)

Dependency agent
If you've machines that don't have internet connectivity, download and install the
Log Analytics gateway on them.
You need these agents only if you use agent-based dependency visualization.
Can I use an existing workspace?

Yes, for agent-based dependency visualization you can attach an existing workspace to
the migration project and use it for dependency visualization.
Can I export the dependency visualization

report?
No, the dependency visualization report in agent-based visualization can't be exported.
However, Azure Migrate uses Service Map, and you can use the Service Map REST API to
retrieve the dependencies in JSON format.
Can I automate agent installation?

For agent-based dependency visualization:
Use a script to install the Dependency agent.

For MMA, use the command line or automation, or use a script .
In addition to scripts, you can use deployment tools like Microsoft Configuration
Manager and Intigua to deploy the agents.
What operating systems does MMA support?

View the list of Windows operating systems that MMA supports.
View the list of Linux operating systems that MMA supports.
Can I visualize dependencies for more than one

hour?
For agent-based visualization, you can visualize dependencies for up to one hour. You
can go back as far as one month to a specific date in history, but the maximum duration
for visualization is one hour. For example, you can use the time duration in the
dependency map to view dependencies for yesterday, but you can view dependencies
only for a one-hour window. However, you can use Azure Monitor logs to query
dependency data for a longer duration.
For agentless visualization, you can view the dependency map of a single server from a
duration of between an hour and 30 days.
Can I visualize dependencies for groups of

more than 10 servers?
You can visualize dependencies for groups that have up to 10 servers. If you've a group
that has more than 10 servers, we recommend that you split the group into smaller
groups, and then visualize the dependencies.
Next steps
Assessment - Common questions
This article answers common questions about assessments in Azure Migrate. If you've
other questions, check these resources:

What geographies are supported for discovery

and assessment with Azure Migrate?
How many servers can I discover with an

appliance?
You can discover up to 10,000 servers from VMware environment, up to 5,000 servers
from Hyper-V environment, and up to 1000 physical servers by using a single appliance.
If you've more servers, read about scaling a Hyper-V assessment, scaling a VMware
assessment, or scaling a physical server assessment.
How do I choose the assessment type?

Use Azure VM assessments when you want to assess servers from your on-
premises VMware and Hyper-V environment, and physical servers for migration to
Azure VMs. Learn More.
Use assessment type Azure SQL when you want to assess your on-premises SQL
Server in your VMware, Microsoft Hyper-V, and Physical/Bare metal environments
as well as IaaS Servers of other public clouds such as AWS, GCP, etc. for migration
to SQL Server on Azure VM or Azure SQL Database or Azure SQL Managed
Instance. Learn More.
Use assessment type Azure App Service when you want to assess your on-
premises ASP.NET web apps running on IIS web server from your VMware
environment for migration to Azure App Service. Learn More.
Use Azure VMware Solution (AVS) assessments when you want to assess your on-
premises VMware VMs for migration to Azure VMware Solution (AVS) using this
assessment type. Learn more.
You can use a common group with VMware machines only to run both types of
assessments. If you're running AVS assessments in Azure Migrate for the first time,
it's advisable to create a new group of VMware machines.
Why is performance data missing for some/all

servers in my Azure VM and/or AVS assessment
report?
For "Performance-based" assessment, the assessment report export says
'PercentageOfCoresUtilizedMissing' or 'PercentageOfMemoryUtilizedMissing' when the
Azure Migrate appliance can't collect performance data for the on-premises servers.
Check:
If the servers are powered on for the duration for which you're creating the
assessment
If only memory counters are missing and you're trying to assess servers in Hyper-V
environment. In this scenario, enable dynamic memory on the servers and
'Recalculate' the assessment to reflect the latest changes. The appliance can collect
memory utilization values for severs in Hyper-V environment only when the server
has dynamic memory enabled.
If all of the performance counters are missing, ensure that outbound connections
on ports 443 (HTTPS) are allowed.
７ Note
If any of the performance counters are missing, Azure Migrate: Server

Assessment falls back to the allocated cores/memory on-premises and
recommends a VM size accordingly.
Why is performance data missing for some/all

SQL instances/databases in my Azure SQL
assessment?
To ensure performance data is collected, check:
If the SQL Servers are powered on for the duration for which you're creating the
assessment.
If the connection status of the SQL agent in Azure Migrate is 'Connected', and
check the last heartbeat.
If Azure Migrate connection status for all SQL instances is 'Connected' in the
discovered SQL instance section.
If any of the performance counters are missing, Azure SQL assessment recommends the
smallest Azure SQL configuration for that instance/database.
Why is confidence rating not available for

Azure App Service assessments?
Performance data isn't captured for Azure App Service assessment and hence you don't
see confidence rating for this assessment type. Azure App Service assessment takes
configuration data of web apps in to account while performing assessment calculation.
Why is the confidence rating of my assessment

low?
The confidence rating is calculated for "Performance-based" assessments based on the
percentage of available data points needed to compute the assessment. Below are the
reasons why an assessment could get a low confidence rating:
You didn't profile your environment for the duration for which you're creating the
assessment. For example, if you're creating an assessment with performance
duration set to one week, you need to wait for at least a week after you start the
discovery for all the data points to get collected. If you can't wait for the duration,
change the performance duration to a smaller period and Recalculate the
assessment.
Assessment isn't able to collect the performance data for some or all the servers in
the assessment period. For a high confidence rating, ensure that:
Servers are powered on for the duration of the assessment
Outbound connections on ports 443 are allowed
For Hyper-V Servers, dynamic memory is enabled
The connection status of agents in Azure Migrate are 'Connected' and check the
last heartbeat
For Azure SQL assessments, Azure Migrate connection status for all SQL
instances is "Connected" in the discovered SQL instance section.
Recalculate the assessment to reflect the latest changes in confidence rating.
For Azure VM and AVS assessments, few servers were created after discovery had
started. For example, if you're creating an assessment for the performance history
of last one month, but few servers were created in the environment only a week
ago. In this case, the performance data for the new servers won't be available for
the entire duration and the confidence rating would be low. Learn more.
For Azure SQL assessments, few SQL instances or databases were created after
discovery had started. For example, if you're creating an assessment for the
performance history of last one month, but few SQL instances or databases were
created in the environment only a week ago. In this case, the performance data for
the new servers won't be available for the entire duration and the confidence
rating would be low. Learn more.
Why is my RAM utilization greater than 100%?

By design, in Hyper-V if maximum memory provisioned is less than what is required by
the VM, Assessment will show memory utilization to be more than 100%.
I see a banner on my assessment that the

assessment now also considers processor
parameters. What will be the impact of
recalculating the assessment?
The assessment now considers processor parameters such as number of operational
cores, sockets, etc. and calculating its optimal performance over a period in a simulated
environment. This is done to benchmark all processor-based available processor
information. Recalculate your assessments to see the updated recommendations.
The processor benchmark numbers are now considered along with the resource
utilization to ensure, we match the processor performance of your on-premises VMware
environment and recommend the target Azure SKU sizes accordingly. This is a way to
further improve the assessment recommendations to match your performance needs
more closely.
Due to this, the target Azure VM cost can differ from your earlier assessments of the
same target. Also, the number of cores allocated in the target Azure SKU could also vary
if the processor performance of target is a match for your on-premises VMware
environment.
For scenarios where customers choose "as on

premises", is there any impact due to processor
benchmarking?
No, there will be no impact as we don't consider it for as on premises scenario.
I see an increase in my monthly costs after I

recalculate my assessments? Is this the most
optimized cost for me?
If you've selected all available options for your “VM Series” in your assessment settings,
you will get the most optimized cost recommendation for your VMs. However, if you
choose only some of the available options for the VM series, the recommendation might
skip the most optimized option for you while assigning you an Azure VM SKU while
matching your processor performance numbers.
Why can't I see all Azure VM families in the

Azure VM assessment properties?
There could be two reasons:
You've chosen an Azure region where a particular series isn't supported. Azure VM
families shown in Azure VM assessment properties are dependent on the
availability of the VM series in the chosen Azure location, storage type and
Reserved Instance.
The VM series isn't support in the assessment and isn't in the consideration logic
of the assessment. We currently don't support B-series burstable, accelerated and
high performance SKU series. We're trying to keep the VM series updated, and the
ones mentioned are on our roadmap.
The number of Azure VM or AVS assessments
on the Discovery and assessment tool are
incorrect
To remediate this, select the total number of assessments to navigate to all the
assessments and recalculate the Azure VM or AVS assessment. The discovery and
assessment tool will then show the correct count for that assessment type.
I want to try out the new Azure SQL

assessment
Discovery and assessment of SQL Server instances and databases running in your
VMware, Microsoft Hyper-V, and Physical/Bare metal environments as well as IaaS
Servers of other public clouds such as AWS, GCP, etc. is now in preview. Get started with
this tutorial. If you want to try out this feature in an existing project, ensure that you've
completed the prerequisites in this article.
I want to try out the new Azure App Service

assessment
Discovery and assessment of .NET web apps running in your VMware environment is
now in preview. Get started with this tutorial. If you want to try out this feature in an
existing project, ensure that you've completed the prerequisites in this article.
I can't see some servers when I am creating an

Azure SQL assessment
Azure SQL assessment can only be done on servers running where SQL instances
were discovered. If you don't see the servers and SQL instances that you wish to
assess, wait for some time for the discovery, and then create the assessment.
If you're not able to see a previously created group while creating the assessment,
remove any server without a SQL instance from the group.
If you're running Azure SQL assessments in Azure Migrate for the first time, it's
advisable to create a new group of servers.
I can't see some servers when I am creating an
Azure App Service assessment
Azure App Service assessment can only be done on servers running where web
server role was discovered. If you don't see the servers that you wish to assess, wait
for some time for the discovery to get completed, and then create the assessment.
If you're not able to see a previously created group while creating the assessment,
remove any non-VMware server or any server without a web app from the group.
If you're running Azure App Service assessments in Azure Migrate for the first time,
it's advisable to create a new group of servers.
I want to understand how was the readiness for

my instance computed?
The readiness for your SQL instances has been computed after doing a feature
compatibility check with the targeted Azure SQL deployment type (SQL Server on Azure
VM or Azure SQL Managed Instance or Azure SQL Database). Learn more.
I want to understand how was the readiness for

my web apps is computed?
The readiness for your web apps is computed by running series of technical checks to
determine if your web app will run successfully in Azure App service or not. These
checks are documented here .
Why is my web app marked as Ready with

conditions or Not ready in my Azure App
Service assessment?
This can happen when one or more technical checks fail for a given web app. You may
select the readiness status for the web app to find out details and remediation for failed
checks.
Why is the readiness for all my SQL instances

marked as unknown?
If your discovery was started recently and is still in progress, you might see the readiness
for some or all SQL instances as unknown. We recommend that you wait for some time
for the appliance to profile the environment and then recalculate the assessment. The
SQL discovery is performed once every 24 hours and you might need to wait upto a day
for the latest configuration changes to reflect.
Why is the readiness for some of my SQL

instances marked as unknown?
This could happen if:
The discovery is still in progress. We recommend that you wait for some time for
the appliance to profile the environment and then recalculate the assessment.
There are some discovery issues that you need to fix in Errors and notifications.
The SQL discovery is performed once every 24 hours and you might need to wait upto a
day for the latest configuration changes to reflect.
My assessment is in Outdated state
Azure VM/AVS assessment

If there are on-premises changes to servers that are in a group that's been assessed, the
assessment is marked outdated. An assessment can be marked as “Outdated” because
of one or more changes in below properties:
Number of processor cores

Allocated memory
Boot type or firmware
Operating system name, version and architecture
Number of disks
Number of network adaptor
Disk size change(GB Allocated)
Nic properties update. Example: Mac address changes, IP address addition etc.
Recalculate the assessment to reflect the latest changes in the assessment.

If there are changes to on-premises SQL instances and databases that are in a group
that's been assessed, the assessment is marked outdated:
SQL instance was added or removed from a server

SQL database was added or removed from a SQL instance
Total database size in a SQL instance changed by more than 20%
Change in number of processor cores and/or allocated memory
Recalculate the assessment to reflect the latest changes in the assessment.
Why was I recommended a particular target

deployment type?
Azure Migrate recommends a specific Azure SQL deployment type that is compatible
with your SQL instance. Migrating to a Microsoft recommended target reduces your
overall migration effort. This Azure SQL configuration (SKU) has been recommended
after considering the performance characteristics of your SQL instance and the
databases it manages. If multiple Azure SQL configurations are eligible, we recommend
the one, which is the most cost effective. Learn more.
What deployment target should I choose if my

SQL instance is ready for Azure SQL DB and
Azure SQL MI?
If your instance is ready for both Azure SQL DB and Azure SQL MI, we recommend the
target deployment type for which the estimated cost of Azure SQL configuration is
lower.
I can't see some databases in my assessment

even though the instance is part of the
assessment
The Azure SQL assessment only includes databases that are in online status. In case the
database is in any other status, the assessment ignores the readiness, sizing, and cost
calculation for such databases. In case you wish you assess such databases, change the
status of the database and recalculate the assessment in some time.
I want to compare costs for running my SQL
instances on Azure VM vs Azure SQL
Database/Azure SQL Managed Instance
You can create a single Azure SQL assessment consisting of desired SQL servers across
VMware, Microsoft Hyper-V and Physical/Bare metal environments as well as IaaS
Servers of other public clouds such as AWS, GCP, etc. A single assessment covers
readiness, SKUs, estimated costs and migration blockers for all the available SQL
migration targets in Azure - Azure SQL Managed Instance, Azure SQL Database and SQL
Server on Azure VM. You can then compare the assessment output for the desired
targets. Learn More
The storage cost in my Azure SQL assessment is

zero
For Azure SQL Managed Instance, there's no storage cost added for the first 32
GB/instance/month storage and additional storage cost is added for storage in 32 GB
increments. Learn More .
I can't see some groups when I am creating an

Azure VMware Solution (AVS) assessment
AVS assessment can be done on groups that have only VMware machines. Remove
any non-VMware machine from the group if you intend to perform an AVS
assessment.
If you're running AVS assessments in Azure Migrate for the first time, it's advisable
to create a new group of VMware machines.
Queries regarding Ultra disks
Can I migrate my disks to Ultra disk using Azure Migrate?

No. Currently, both Azure Migrate and Azure Site Recovery don't support migration to
Ultra disks. Find steps to deploy Ultra disk here
Why are the provisioned IOPS and throughput in my
Ultra disk more than my on-premises IOPS and
throughput?
As per the official pricing page , Ultra Disk is billed based on the provisioned size,
provisioned IOPS and provisioned throughput. As per an example provided:
If you provisioned a 200 GiB Ultra Disk, with 20,000 IOPS and 1,000 MB/second and
deleted it after 20 hours, it will map to the disk size offer of 256 GiB and you'll be billed
for the 256 GiB, 20,000 IOPS and 1,000 MB/second for 20 hours.
IOPS to be provisioned = (Throughput discovered) *1024/256
Does the Ultra disk recommendation consider latency?

No, currently only disk size, total throughput, and total IOPS are used for sizing and
costing.
I can see M series supports Ultra disk, but in my

assessment where Ultra disk was recommended, it says
“No VM found for this location”?
This is possible as not all VM sizes that support Ultra disk are present in all Ultra disk
supported regions. Change the target assessment region to get the VM size for this
server.
I can't see some VM types and sizes in Azure

Government
VM types and sizes supported for assessment and migration depend on availability in
Azure Government location. You can review and compare VM types in Azure
Government.
The size of my server changed. Can I run an

assessment again?
The Azure Migrate appliance continuously collects information about the on-premises
environment. An assessment is a point-in-time snapshot of on-premises servers. If you
change the settings on a server that you want to assess, use the recalculate option to
update the assessment with the latest changes.
How do I discover servers in a multitenant

environment?
VMware: If an environment is shared across tenants and you don't want to
discover a tenant's servers in another tenant's subscription, create VMware vCenter
Server credentials that can access only the servers you want to discover. Then, use
those credentials when you start discovery in the Azure Migrate appliance.
Hyper-V: Discovery uses Hyper-V host credentials. If servers share the same Hyper-
V host, there's currently no way to separate the discovery.
Do I need vCenter Server?

Yes, Azure Migrate requires vCenter Server in a VMware environment to perform
discovery. Azure Migrate doesn't support discovery of ESXi hosts that aren't managed
by vCenter Server.
What are the sizing options in an Azure VM

assessment?
With as-on-premises sizing, Azure Migrate doesn't consider server performance data for
assessment. Azure Migrate assesses VM sizes based on the on-premises configuration.
With performance-based sizing, sizing is based on utilization data.
For example, if an on-premises server has 4 cores and 8 GB of memory at 50% CPU
utilization and 50% memory utilization:
As-on-premises sizing will recommend an Azure VM SKU that has 4 cores and 8 GB
of memory.
Performance-based sizing will recommend a VM SKU that has 2 cores and 4 GB of
memory because the utilization percentage is considered.
Similarly, disk sizing depends on sizing criteria and storage type:
If the sizing criteria is "performance-based" and the storage type is automatic,

Azure Migrate takes the IOPS and throughput values of the disk into account when
it identifies the target disk type (Standard, Premium or Ultra disk).
If the sizing criteria is "as on premises" and the storage type is Premium, Azure
Migrate recommends a Premium disk SKU based on the size of the on-premises
disk. The same logic is applied to disk sizing when the sizing is as-on-premises and
the storage type is Standard, Premium or Ultra disk.
Does performance history and utilization affect

sizing in an Azure VM assessment?
Yes, performance history and utilization affect sizing in an Azure VM assessment.
Performance history
For performance-based sizing only, Azure Migrate collects the performance history of
on-premises machines, and then uses it to recommend the VM size and disk type in
Azure:
1. The appliance continuously profiles the on-premises environment to gather real-

time utilization data every 20 seconds.
2. The appliance rolls up the collected 20-second samples and uses them to create a
single data point every 15 minutes.
3. To create the data point, the appliance selects the peak value from all 20-second
samples.
4. The appliance sends the data point to Azure.
Utilization
When you create an assessment in Azure, depending on performance duration and the
performance history percentile value that is set, Azure Migrate calculates the effective
utilization value, and then uses it for sizing.
For example, if you set the performance duration to one day and the percentile value to
95th percentile, Azure Migrate sorts the 15-minute sample points sent by the collector
for the past day in ascending order. It picks the 95th percentile value as the effective
utilization.
Using the 95th percentile value ensures that outliers are ignored. Outliers might be
included if your Azure Migrate uses the 99th percentile. To pick the peak usage for the
period without missing any outliers, set Azure Migrate to use the 99th percentile.
How are import-based assessments different
from assessments with discovery source as
appliance?
Import-based Azure VM assessments are assessments created with machines that are
imported into Azure Migrate using a CSV file. Only four fields are mandatory to import:
Server name, cores, memory, and operating system. Here are some things to note:
The readiness criteria is less stringent in import-based assessments on the boot

type parameter. If the boot type isn't provided, it's assumed the machine has BIOS
boot type, and the machine isn't marked as Conditionally Ready. In assessments
with discovery source as appliance, the readiness is marked as Conditionally Ready
if the boot type is missing. This difference in readiness calculation is because users
may not have all information on the machines in the early stages of migration
planning when import-based assessments are done.
Performance-based import assessments use the utilization value provided by the
user for right-sizing calculations. Since the utilization value is provided by the user,
the Performance history and Percentile utilization options are disabled in the
assessment properties. In assessments with discovery source as appliance, the
chosen percentile value is picked from the performance data collected by the
appliance.
Why is the suggested migration tool in import-

based AVS assessment marked as unknown?
For machines imported via a CSV file, the default migration tool in an AVS assessment is
unknown. Though, for VMware machines, it's recommended to use the VMware Hybrid
Cloud Extension (HCX) solution. Learn More.
Next steps
Business case (preview) - Common
questions
Article • 04/25/2023
This article answers common questions about Business case in Azure Migrate. If you
have other questions, check these resources:
General questions about Azure Migrate.

Questions about the Azure Migrate appliance.
General
How can I export the business case?

You can click on export from the Business case to export it in an .xlsx file. If you see the
Export gesture as disabled, you need to recalculate the business case by modifying any
one assumption (Azure or on-premises) in the Business Case and click on Save. For
example:
1. Go to a business case and select Edit assumptions and choose Azure assumptions.
2. Select Reset next to Performance history duration date range is outdated
warning. You could also choose to change any other setting.
3. Select Save.
This will recalculate the business case with the updated assumptions and will enable the
export gesture.
What is the difference between an assessment and a

business case?
An assessment helps you understand the readiness, sizing and Azure cost estimates
(only compute and storage) of a particular source and targets. It's useful in
understanding How to migrate to Azure.
A Business case helps you understand on-premises cost estimates, Azure cost estimates
and potential savings (TCO and YoY). It helps you understand Why Azure? and helps
understand the quick wins and unique Azure Benefits.
Why is my business case in computing status?

Business case creates assessments in the background, which could take some time
depending on the number of servers, SQL servers and web apps present in your project.
It could take somewhere between 15 mins to 3 hours for the Business case to get
computed. If it's still stuck in computing status, create a support request.
Build business case
How do I build a business case?

Currently, you can create a Business case on servers and workloads discovered using a
lightweight Azure Migrate appliance in your VMware, Hyper-V and Physical/Baremetal
environment. The appliance discovers on-premises servers and workloads. It then sends
server metadata and performance data to Azure Migrate.
Why is the Build business case feature disabled?

The Build business case feature will be enabled only when you have discovery
performed using an Azure Migrate appliance for servers and workloads in your VMware,
Hyper-V and Physical/Baremetal environment. The Business case feature is not
supported for servers and/or workloads imported via a .csv file.
Why can’t I build business case from my project?

You will not be able to create a business case if your project is in one of these 3 project
regions:
Germany West Central, East Asia and Switzerland North.
To verify in an existing project:
1. You can use the https://portal.azure.com/ URL to get started
2. In Azure Migrate, go to Servers, databases and webapps > Migration goals.
3. On the Azure Migrate: Discovery and assessment tool, select Overview.
4. Under Project details, select Properties.
5. Check the Project location.
6. The Business case feature is not supported in the following regions:
Germany West Central, East Asia and Switzerland North.

Why can't I change the currency during business case
creation?
Currently, the currency is defaulted to USD.
What does the different migration strategies mean?
Migration Details Assessment insights

Strategy
Azure You can get the most cost efficient For SQL Servers, sizing and cost comes
recommended and compatible target from the Recommended report with
to minimize recommendation in Azure across optimization strategy- minimize cost
cost Azure IaaS and Azure PaaS targets from Azure SQL assessment.
For web apps, sizing and cost comes from

Azure App Service assessment is picked.
For general servers, sizing and cost comes

from Azure VM assessment.
Migrate to all You can get a quick lift and shift For SQL Servers, sizing and cost comes
IaaS recommendation to Azure IaaS. from the Instance to SQL Server on Azure
(Infrastructure VM report.
as a Service)
For general servers and servers hosting
web apps, sizing and cost comes from
Azure VM assessment.
Modernize to You can get a PaaS preferred For SQL Servers, sizing and cost comes
PaaS recommendation that means, the from the Recommended report with
(Platform as a logic identifies workloads best fit optimization strategy - Modernize to PaaS
Service) for PaaS targets. from Azure SQL assessment.
General servers are recommended For web apps, sizing and cost comes from
with a quick lift and shift Azure App Service assessment. For
recommendation to Azure IaaS. general servers, sizing and cost comes
７ Note
Although the Business case picks Azure recommendations from certain

assessments, you won't be able to access the assessments directly. To deep dive
into sizing, readiness and Azure cost estimates, you can create respective
assessments for the servers or workloads.
Business case recommendation
I can't see some servers and SQL instances

There are multiple possibilities for this issue.
Discovery hasn't completed - Wait for the discovery to complete. It is

recommended to wait for at least 24 hours.
Check and resolve any discovery issues.
Changes to discovery happened after creating the Business case.
To fetch latest discovery data, recalculate by selecting the Recalculate button, or

changing the assumptions and selecting Save.
Why are all or some of the servers marked as unknown in

the utilization insights?
We couldn't collect sufficient data points to classify these servers. We recommend that
you wait at least a day after starting discovery so that the Business case has enough
utilization data points. Also, review the notifications/resolve issues blades on Azure
Migrate hub to identify any discovery related issues prior to Business case computation.
Reviewing issues prior to building a Business case will ensure that the IT estate in your
datacenter is represented more accurately.
Was the readiness taken into consideration in the

recommendations?
Yes, but you won't be able to access the assessments directly. To deep dive into sizing,
readiness, and Azure cost estimates, you can create respective assessments for the
servers or workloads.
Why was I recommended this Azure target?

Based on the migration strategy, this was the best recommended target. To understand
detailed readiness and sizing, create an assessment and refer to the details.
How do I get to know details for servers or workloads

that aren't ready for Azure?
To deep dive into sizing, readiness, and Azure cost estimates, you can create respective
Does the Azure SQL recommendation logic include SQL

consolidation?
No, it does not include SQL consolidation.
Next steps
Learn more about how to build a Business case.
Learn more about how to review the Business case reports.
Migration and modernization: Common
questions
This article answers common questions about the Migration and modernization tool. If
you've other questions, check these resources:

General questions
What are the migration options in Migration and

modernization?
The Migration and modernization tool offers two options for migrating your source
servers and virtual machines to Azure: agentless migration and agent-based migration.
Regardless of the migration option chosen, the first step to migrate a server using the
Migration and modernization tool is to start replication for the server. This performs an
initial replication of your VM/server data to Azure. After the initial replication is
completed, an ongoing replication (ongoing delta-sync) is established to migrate
incremental data to Azure. Once the operation reaches the delta-sync stage, you can
choose to migrate to Azure at any time.
Here are some considerations to keep in mind while deciding on the migration option.
Agentless migrations don't require any software (agents) to be deployed on the source
VMs/servers being migrated. The agentless option orchestrates replication by
integrating with the functionality provided by the virtualization provider. The Agentless
replication options are available for VMware VMs and Hyper-V VMs.
Agent-based migrations require Azure Migrate software (agents) to be installed on the

source VMs/machines to be migrated. The agent-based option doesn’t rely on the
virtualization platform for the replication functionality. Therefore, it can be used with any
server running an x86/x64 architecture and a version of an operating system supported
by the agent-based replication method.
Agent-based migration option can be used for VMware VMs, Hyper-V VMs, physical
servers, VMs running on AWS, VMs running on GCP, or VMs running on a different
virtualization provider. The agent-based migration treats your machines as physical
servers for migration.
While the agentless migration offers another convenience and simplicity over the agent-
based replication options for the supported scenarios (VMware and Hyper-V), you may
want to consider using the agent-based scenario for the following use cases:
IOPS constrained environment: Agentless replication uses snapshots and

consumes storage IOPS/bandwidth. We recommend the agent-based migration
method if there are constraints on storage/IOPS in your environment.
If you don't have a vCenter Server, you can treat your VMware VMs as physical
servers and use the agent-based migration workflow.
To learn more, review this article to compare migration options for VMware migrations.
What geographies are supported for migration with

Azure Migrate?
Can I use the same Azure Migrate project to migrate to

multiple regions?
While you can create assessments for multiple regions in an Azure Migrate project, one
Azure Migrate project can be used to migrate servers to one Azure region only. You can
create additional Azure Migrate projects for each region that you need to migrate to.
For agentless VMware migrations, the target region is locked once you enable the
first replication.
For agent-based migrations (VMware, physical servers, and servers from other
clouds), the target region is locked once the “Create Resources” button is selected
on the portal while setting up the replication appliance.
For agentless Hyper-V migrations, the target region is locked once the “Create
Resources” button is selected on the portal while setting up the Hyper-V
replication provider.
Can I use the same Azure Migrate project to migrate to

multiple subscriptions?
Yes, you can migrate to multiple subscriptions (same Azure tenant) in the same target
region for an Azure Migrate project. You can select the target subscription while
enabling replication for a machine or a set of machines. The target region is locked post
first replication for agentless VMware migrations and during the replication appliance
and Hyper-V provider installation for agent-based migrations and agentless Hyper-V
migrations respectively.
How is the data transmitted from on-premises

environment to Azure? Is it encrypted before
transmission?
The Azure Migrate appliance in the agentless replication case compresses data and
encrypts before uploading. Data is transmitted over a secure communication channel
over https and uses TLS 1.2 or later. Additionally, Azure Storage automatically encrypts
your data when it's persisted it to the cloud (encryption-at-rest).
Can I use the recovery services vault created by Azure

Migrate for Disaster Recovery scenarios?
We don't recommend using the recovery services vault created by Azure Migrate for
Disaster Recovery scenarios. Doing so can result in start replication failures in Azure
Migrate.
What is the difference between the Test Migration and

Migrate operations?
Test migration provides a way to test and validate migrations prior to the actual
migration. Test migration works by letting you use a sandbox environment in Azure to
test the virtual machines before actual migration. The sandbox environment is
demarcated by a test virtual network you specify. The test migration operation is non-
disruptive, provided the test VNet is sufficiently isolated. Isolated VNet here means the
inbound and outbound connection rules are designed to avoid unwanted connections.
For example – connection to on-premises machines is restricted.
The applications can continue to run at the source while letting you perform tests on a
cloned copy in an isolated sandbox environment. You can perform multiple tests, as
needed, to validate the migration, perform app testing, and address any issues before
the actual migration.
Is there a Rollback option for Azure Migrate?
You can use the Test Migration option to validate your application functionality and
performance in Azure. You can perform any number of test migrations and can execute
the final migration after establishing confidence through the test migration operation. A
test migration doesn’t affect the on-premises machine, which remains operational and
continues replicating until you perform the actual migration. If there were any errors
during the test migration UAT, you can choose to postpone the final migration and keep
your source VM/server running and replicating to Azure. You can reattempt the final
migration once you resolve the errors. Note: Once you've performed a final migration to
Azure and the on-premises source machine was shut down, you can't perform a rollback
from Azure to your on-premises environment.
Can I select the Virtual Network and subnet to use for

test migrations?
You can select a Virtual Network for test migrations. The subnet is automatically selected
based on the following logic:
If a target subnet (other than default) was specified as an input while enabling
replication, then Azure Migrate prioritizes using a subnet with the same name in
the Virtual Network selected for the test migration.
If the subnet with the same name isn't found, then Azure Migrate selects the first
subnet available alphabetically that isn't a Gateway/Application
Gateway/Firewall/Bastion subnet.
Why is the Test Migration button disabled for my Server?

The test migration button could be in a disabled state in the following scenarios:
You can’t begin a test migration until an initial replication (IR) has been completed
for the VM. The test migration button will be disabled until the IR process is
completed. You can perform a test migration once your VM is in a delta-sync
stage.
The button can be disabled if a test migration was already completed, but a test-
migration cleanup wasn't performed for that VM. Perform a test migration cleanup
and retry the operation.
What happens if I don’t clean up my test migration?

Test migration simulates the actual migration by creating a test Azure VM using
replicated data. The server will be deployed with a point in time copy of the replicated
data to the target Resource Group (selected while enabling replication) with a “-test”
suffix. Test migrations are intended for validating server functionality so that post
migration issues are minimized. If the test migration isn't cleaned up post testing, the
test virtual machine will continue to run in Azure, and will incur charges. To clean up
post a test migration, go to the replicating machines view in the Migration and
modernization tool, and use the 'cleanup test migration' action on the machine.
How do I know if my VM was successfully migrated?

Once you've migrated your VM/server successfully, you can view and manage the VM
from the Virtual Machines page. Connect to the migrated VM to validate. Alternatively,
you can review the ‘Job status’ for the operation to check if the migration was
successfully completed. If you see any errors, resolve them, and retry the migration
operation.
What happens if I don’t stop replication after migration?

When you stop replication, the Migration and modernization tool cleans up the
managed disks in the subscription that was created for replication.
What happens if I don’t complete migration after

migration?
When you complete migration, the Migration and modernization tool cleans up the
managed disks in the subscription that were created for replication. If you don't select
Complete migration after a migration, you will continue to incur charges for these disks.
Complete migration won't affect the disks attached to machines that have already been
migrated.
How can I migrate UEFI-based machines to Azure as
Azure generation 1 VMs?
Migration and modernization tool migrates UEFI-based machines to Azure as Azure
generation 2 VMs. If you want to migrate them to Azure generation 1 VMs, convert the
boot-type to BIOS before starting replication, and then use the Migration and
modernization tool to migrate to Azure.
Does Azure Migrate convert UEFI-based machines to

BIOS-based machines and migrate them to Azure as
Azure generation 1 VMs?
Migration and modernization tool migrates all the UEFI-based machines to Azure as
Azure generation 2 VMs. We no longer support the conversion of UEFI-based VMs to
BIOS-based VMs. All the BIOS-based machines are migrated to Azure as Azure
generation 1 VMs only.
Which operating systems are supported for migration of

UEFI-based machines to Azure?
Operating systems Agentless Agentless Agent-based VMware,

supported for UEFI-based VMware to Hyper-V to physical and other clouds to
machines Azure Azure Azure
Windows Server 2019, 2016, Y Y Y

2012 R2, 2012
Windows 10 Pro, Windows 10 Y Y Y

Enterprise
SUSE Linux Enterprise Server Y Y Y

15 SP1
SUSE Linux Enterprise Server Y Y Y

12 SP4
Ubuntu Server 16.04, 18.04, Y Y Y

19.04, 19.10
RHEL 8.1, 8.0, 7.8, 7.7, 7.6, 7.5, Y Y Y

7.4, 7.0, 6.x
Cent OS 8.1, 8.0, 7.7, 7.6, 7.5, Y Y Y

7.4, 6.x
Operating systems Agentless Agentless Agent-based VMware,
supported for UEFI-based VMware to Hyper-V to physical and other clouds to
machines Azure Azure Azure
Oracle Linux 7.7, 7.7-CI Y Y Y
Can I migrate Active Directory domain-controllers using

Azure Migrate?
The Migration and modernization tool is application agnostic and works for most
applications. When you migrate a server using the Migration and modernization tool, all
the applications installed on the server are migrated along with it. However, for some
applications, alternate migration methods other than Migration and modernization may
be better suited for the migration. For Active Directory, if hybrid environments where
the on-premises site is connected to your Azure environment, you can extend your
Directory into Azure by adding extra domain controllers in Azure and setting up Active
Directory replication. If you're migrating into an isolated environment in Azure requiring
its own domain controllers (or testing applications in a sandbox environment), you can
migrate servers using the Migration and modernization tool.
Can I upgrade my OS while migrating?

The Migration and modernization tool only supports like-for-like migrations currently.
The tool doesn’t support upgrading the OS version during migration. The migrated
machine will have the same OS as the source machine.
Do I need VMware vCenter to migrate VMware VMs?

To migrate VMware VMs using VMware agent-based or agentless migration, ESXi hosts
on which VMs are located must be managed by vCenter Server. If you don't have
vCenter Server, you can migrate VMware VMs by migrating them as physical servers.
Learn more.
Can I consolidate multiple source VMs into one VM while

migrating?
Migration and modernization capabilities support like-for-like migrations currently. We
don't support consolidating servers or upgrading the operating system as part of the
migration.
Will Windows Server 2008 and 2008 R2 be supported in
Azure after migration?
You can migrate your on-premises Windows Server 2008 and 2008 R2 servers to Azure
virtual machines and get Extended Security Updates for three years after the End of
Support dates at no extra charge above the cost of running the virtual machine. You can
use the Migration and modernization tool to migrate your Windows Server 2008 and
2008 R2 workloads.
How do I migrate Windows Server 2003 running on

VMware/Hyper-V to Azure?
Windows Server 2003 extended support ended on July 14, 2015. The Azure support
team continues to help in troubleshooting issues that concern running Windows Server
2003 on Azure. However, this support is limited to issues that don't require OS-level
troubleshooting or patches. Migrating your applications to Azure instances running a
newer version of Windows Server is the recommended approach to ensure that you're
effectively using the flexibility and reliability of the Azure cloud.
However, if you still choose to migrate your Windows Server 2003 to Azure, you can use
the Migration and modernization tool if your Windows Server is a VM running on
VMware or Hyper-V Review this article to prepare your Windows Server 2003 machines
for migration.
Agentless VMware migration
How does agentless migration work?

The Migration and modernization tool provides agentless replication options for the
migration of VMware virtual machines and Hyper-V virtual machines running Windows
or Linux. The tool also provides another agent-based replication option for Windows
and Linux servers that can be used to migrate physical servers, and x86/x64 virtual
machines on VMware, Hyper-V, AWS, GCP, etc. The agent-based replication option
requires the installation of agent software on the server/virtual machine that’s being
migrated, whereas in the agentless option no software needs to be installed on the
virtual machines themselves, thus offering more convenience and simplicity over the
agent-based replication option.
The agentless replication option works by using mechanisms provided by the

virtualization provider (VMware, Hyper-V). In the case of VMware virtual machines, the
agentless replication mechanism uses VMware snapshots and VMware changed block
tracking technology to replicate data from virtual machine disks. This mechanism is
similar to the one used by many backup products. In the case of Hyper-V virtual
machines, the agentless replication mechanism uses VM snapshots and the change
tracking capability of the Hyper-V replica to replicate data from virtual machine disks.
When replication is configured for a virtual machine, it first goes through an initial
replication phase. During initial replication, a VM snapshot is taken, and a full copy of
data from the snapshot disks are replicated to managed disks in your subscription. After
initial replication for the VM is complete, the replication process transitions to an
incremental replication (delta replication) phase. In the incremental replication phase,
data changes that have occurred since the last completed replication cycle are
periodically replicated and applied to the replica managed disks, thus keeping
replication in sync with changes happening on the VM. In the case of VMware virtual
machines, VMware changed block tracking technology is used to keep track of changes
between replication cycles. At the start of the replication cycle, a VM snapshot is taken
and changed block tracking is used to get the changes between the current snapshot
and the last successfully replicated snapshot. That way only data that has changed since
the last completed replication cycle needs to be replicated to keep replication for the
VM in sync. At the end of each replication cycle, the snapshot is released, and snapshot
consolidation is performed for the virtual machine. Similarly, in the case of Hyper-V
virtual machines, the Hyper-V replica change tracking engine is used to keep track of
changes between consecutive replication cycles.
When you perform the migrate operation on a replicating virtual machine, you've the
option to shut down the on-premises virtual machine, and perform one final
incremental replication to ensure zero data loss. On performing the migration, the
replica managed disks corresponding to the virtual machine are used to create the
virtual machine in Azure.
To get started, refer the VMware agentless migration and Hyper-V agentless migration
tutorials.
How do I gauge the bandwidth requirement for my

migrations?
Bandwidth for replication of data to Azure depends on a range of factors and is a
function of how fast the on-premises Azure Migrate appliance can read and replicate
the data to Azure. Replication has two phases: initial replication and delta replication.
When replication starts for a VM, an initial replication cycle occurs in which full copies of
the disks are replicated. After the initial replication is completed, incremental replication
cycles (delta cycles) are scheduled periodically to transfer any changes that have
occurred since the previous replication cycle.
You can work out the bandwidth requirement based on the volume of data needed to
be moved in the wave and time within which you would like initial replication to
complete (ideally you’d want initial replication to have completed at least 3-4 days prior
to the actual migration window to give you sufficient time to perform a test migration
prior to the actual window and to keep downtime to a minimum during the window).
You can estimate the bandwidth or time needed for agentless VMware VM migration
using the following formula:
Time to complete initial replication = {size of disks (or used size if available) * 0.7
(assuming a 30 percent compression average – conservative estimate)}/bandwidth
available for replication.
How do I throttle replication in using Azure Migrate

appliance for agentless VMware replication?
You can throttle using NetQosPolicy. Note that this throttling is applicable only to the
outbound connections from the Azure Migrate appliance. For example:
The AppNamePrefix to use in the NetQosPolicy is "GatewayWindowsService.exe". You

could create a policy on the Azure Migrate appliance to throttle replication traffic from
the appliance by creating a policy such as this one:
PowerShell
New-NetQosPolicy -Name "ThrottleReplication" -AppPathNameMatchCondition

"GatewayWindowsService.exe" -ThrottleRateActionBitsPerSecond 1MB
In order to increase and decrease replication bandwidth based on a schedule, you can
leverage Windows scheduled task to scale the bandwidth as needed. One task will be
used to decrease the bandwidth, and another task will be used to increase the
bandwidth. Note: You need to create the NetQosPolicy, outlined above, prior to
executing the commands below.
PowerShell
#Replace with an account part of the local Administrators group

$User = "localVmName\userName"
#Set the task names

$ThrottleBandwidthTask = "ThrottleBandwidth"
$IncreaseBandwidthTask = "IncreaseBandwidth"
#Create a directory to host PowerShell scaling scripts

if (!(Test-Path "C:\ReplicationBandwidthScripts"))
{
New-Item -Path "C:\" -Name "ReplicationBandwidthScripts" -Type Directory
}
#Set your minimum bandwidth to be used during replication by changing the

ThrottleRateActionBitsPerSecond parameter
#Currently set to 10 MBps
New-Item C:\ReplicationBandwidthScripts\ThrottleBandwidth.ps1
Set-Content C:\ReplicationBandwidthScripts\ThrottleBandwidth.ps1 'Set-
NetQosPolicy -Name "ThrottleReplication" -ThrottleRateActionBitsPerSecond
10MB'
$ThrottleBandwidthScript =
"C:\ReplicationBandwidthScripts\ThrottleBandwidth.ps1"
#Set your maximum bandwidth to be used during replication by changing the

ThrottleRateActionBitsPerSecond parameter
#Currently set to 1000 MBps
New-Item C:\ReplicationBandwidthScripts\IncreaseBandwidth.ps1
Set-Content C:\ReplicationBandwidthScripts\IncreaseBandwidth.ps1 'Set-
NetQosPolicy -Name "ThrottleReplication" -ThrottleRateActionBitsPerSecond
1000MB'
$IncreaseBandwidthScript =
"C:\ReplicationBandwidthScripts\IncreaseBandwidth.ps1"
#Timezone set on the Azure Migrate Appliance (VM) will be used; change the
frequency to meet your needs
#In this example, the bandwidth is being throttled every weekday at 8:00 AM
local time
#The bandwidth is being increased every weekday at 6:00 PM local time
$ThrottleBandwidthTrigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek
Monday,Tuesday,Wednesday,Thursday,Friday -At 8:00am
$IncreaseBandwidthTrigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek
Monday,Tuesday,Wednesday,Thursday,Friday -At 6:00pm
#Setting the task action to execute the scripts

$ThrottleBandwidthAction = New-ScheduledTaskAction -Execute "PowerShell.exe"
-Argument "-executionpolicy bypass -noprofile -file
$ThrottleBandwidthScript"
$IncreaseBandwidthAction = New-ScheduledTaskAction -Execute "PowerShell.exe"
-Argument "-executionpolicy bypass -noprofile -file
$IncreaseBandwidthScript"
#Creating the Scheduled tasks

Register-ScheduledTask -TaskName $ThrottleBandwidthTask -Trigger
$ThrottleBandwidthTrigger -User $User -Action $ThrottleBandwidthAction -
RunLevel Highest -Force
Register-ScheduledTask -TaskName $IncreaseBandwidthTask -Trigger
$IncreaseBandwidthTrigger -User $User -Action $IncreaseBandwidthAction -
RunLevel Highest -Force
How does churn rate affect agentless replication?
Because agentless replication folds in data, the churn pattern is more important than the
churn rate. When a file is written again and again, the rate doesn't have much impact.
However, a pattern in which every other sector is written causes high churn in the next
cycle. Because we minimize the amount of data we transfer, we allow the data to fold as
much as possible before we schedule the next cycle.
How frequently is a replication cycle scheduled?

The formula to schedule the next replication cycle is (previous cycle time / 2) or one
hour, whichever is higher.
For example, if a VM takes four hours for a delta cycle, the next cycle is scheduled in two
hours, and not in the next hour. The process is different immediately after initial
replication, when the first delta cycle is scheduled immediately.
I deployed two (or more) appliances to discover VMs in

my vCenter Server. However, when I try to migrate the
VMs, I only see VMs corresponding to one of the
appliances.
If there are multiple appliances set up, it's required there's no overlap among the VMs
on the vCenter accounts provided. A discovery with such an overlap is an unsupported
scenario.
How does agentless replication affect VMware servers?

Agentless replication results in some performance impact on VMware vCenter Server
and VMware ESXi hosts. Because agentless replication uses snapshots, it consumes IOPS
on storage, so some IOPS storage bandwidth is required. We don't recommend using
agentless replication if you've constraints on storage or IOPs in your environment.
Can I use Azure Migrate to migrate my web apps to Azure

App Service?
You can perform at-scale agentless migration of ASP.NET web apps running on IIS web
servers hosted on a Windows OS in a VMware environment. Learn more.
Agent-based Migration
How can I migrate my AWS EC2 instances to Azure?

Review the article to discover, assess, and migrate your AWS EC2 instances to Azure.
How does agent-based migration work?

In addition to agentless migration options for VMware virtual machines and Hyper-V
virtual machines, the Migration and modernization tool provides an agent-based
migration option to migrate Windows and Linux servers running on physical servers, or
running as x86/x64 virtual machines on VMware, Hyper-V, AWS, Google Cloud Platform,
etc.
The agent-based migration method uses agent software installed on the server being
migrated to replicate server data to Azure. The replication process uses an offload
architecture in which the agent relays replication data to a dedicated replication server
called the replication appliance or Configuration Server (or to a scale-out Process
Server). Learn more about how the agent-based migration option works.
Note: The replication appliance is different from the Azure Migrate discovery appliance
and must be installed on a separate/dedicated machine.
Where should I install the replication appliance for agent-

based migrations?
The replication appliance should be installed on a dedicated machine. The replication
appliance shouldn't be installed on a source machine that you want to replicate or on
the Azure Migrate appliance (used for discovery and assessment) you may have installed
before. Follow the tutorial for more details.
Can I migrate AWS VMs running Amazon Linux Operating

system?
VMs running Amazon Linux can't be migrated as-is as Amazon Linux OS is only
supported on AWS. To migrate workloads running on Amazon Linux, you can spin up a
CentOS/RHEL VM in Azure and migrate the workload running on the AWS Linux
machine using a relevant workload migration approach. For example, depending on the
workload, there may be workload-specific tools to aid the migration – such as for
databases or deployment tools in case of web servers.
migrations?
For an agent-based method of replication, the Deployment Planner can help profile the
environment for the data churn and help predict the necessary bandwidth requirement.
To learn more, view this article
Agentless Hyper-V migration
How does agentless migration work?

The Migration and modernization tool provides agentless replication options for the
migration of VMware virtual machines and Hyper-V virtual machines running Windows
or Linux. The tool also provides an additional agent-based replication option for
Windows and Linux servers that can be used to migrate physical servers, as well as
x86/x64 virtual machines on VMware, Hyper-V, AWS, GCP, etc. The agent-based
replication option requires the installation of agent software on the server/virtual
machine that’s being migrated, whereas in the agentless option no software needs to be
installed on the virtual machines themselves, thus offering additional convenience and
simplicity over the agent-based replication option.
The agentless replication option works by using mechanisms provided by the

virtualization provider (VMware, Hyper-V). In the case of Hyper-V virtual machines, the
agentless replication mechanism uses VM snapshots and the change tracking capability
of the Hyper-V replica to replicate data from virtual machine disks.
data from the snapshot disks are replicated to managed disks in your subscription. After
initial replication for the VM is complete, the replication process transitions to an
data changes that have occurred since the last completed replication cycle are
periodically replicated and applied to the replica managed disks, thus keeping
replication in sync with changes happening on the VM. In the case of VMware virtual
machines, VMware changed block tracking technology is used to keep track of changes
and the last successfully replicated snapshot. That way only data that has changed since
the last completed replication cycle needs to be replicated to keep replication for the
VM in sync. At the end of each replication cycle, the snapshot is released, and snapshot
consolidation is performed for the virtual machine. Similarly, in the case of Hyper-V
virtual machines, the Hyper-V replica change tracking engine is used to keep track of
changes between consecutive replication cycles.
When you perform the migrate operation on a replicating virtual machine, you've the
option to shut down the on-premises virtual machine, and perform one final
incremental replication to ensure zero data loss. On performing the migration, the
replica managed disks corresponding to the virtual machine are used to create the
virtual machine in Azure.
To get started, refer the Hyper-V agentless migration tutorial.

migrations?
You can work out the bandwidth requirement based on the volume of data needed to
be moved in the wave and time within which you would like initial replication to
complete (ideally you’d want initial replication to have completed at least 3-4 days prior
to the actual migration window to give you sufficient time to perform a test migration
prior to the actual window and to keep downtime to a minimum during the window).
Next steps
Quickstart: Create an Azure Migrate
project using an ARM template
Article • 04/13/2023
This quickstart describes how to set up an Azure Migrate project Recovery by using an
Azure Resource Manager template (ARM template). Azure Migrate provides a
centralized hub to assess and migrate to Azure on-premises servers, infrastructure,
applications, and data. Azure Migrate supports assessment and migration of on-
premises VMware VMs, Hyper-V VMs, physical servers, other virtualized VMs, databases,
web apps, and virtual desktops.
This template creates an Azure Migrate project that will be used further for assessing
and migrating your Azure on-premises servers, infrastructure, applications, and data.
A resource manager template is a JavaScript Object Notation (JSON) file that defines the
infrastructure and configuration for your project. The template uses declarative syntax.
In declarative syntax, you describe your intended deployment without writing the
sequence of programming commands to create the deployment.
If your environment meets the prerequisites and you're familiar with using ARM
templates, select the Deploy to Azure button. The template will open in the Azure
portal.
Prerequisites
If you don't have an active Azure subscription, you can create a free account before
you begin.
Review the template

The template used in this quickstart is from Azure Quickstart Templates .
JSON
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-
01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"migrateProjectName": {
"type": "string",
"maxLength": 13,
"metadata": {
"description": "Specifies a name for creating the migrate
project."
}
},
"location": {
"type": "string",
"allowedValues": [
"centralus",
"eastasia",
"northeurope",
"westeurope",
"westus2",
"australiasoutheast",
"uksouth",
"ukwest",
"canadacentral",
"centralindia",
"southindia",
"japaneast",
"japanwest",
"brazilsouth",
"koreasouth",
"koreacentral",
"francecentral",
"switzerlandnorth",
"australiaeast",
"southeastasia",
"centraluseuap",
"eastus2euap",
"canadaeast",
"southcentralus",
"usgovvirginia",
"usgovarizona"
],
"metadata": {
"description": "Specifies the location for all resources."
}
}
},
"resources": [
{
"type": "Microsoft.Migrate/MigrateProjects",
"apiVersion": "2020-05-01",
"name": "[parameters('migrateProjectName')]",
"location": "[parameters('location')]",
"tags": {
"Migrate Project": "[parameters('migrateProjectName')]"
},
"properties": {}
},
{
"type": "Microsoft.Migrate/MigrateProjects/Solutions",
"apiVersion": "2020-05-01",
"name": "[concat(parameters('migrateProjectName'), '/Servers-
Assessment-ServerAssessment')]",
"dependsOn": [
"[resourceId('Microsoft.Migrate/MigrateProjects',
parameters('migrateProjectName'))]"
],
"properties": {
"tool": "ServerAssessment",
"purpose": "Assessment",
"goal": "Servers",
"status": "Active"
}
},
{
"apiVersion": "2020-05-01",
Discovery-ServerDiscovery')]",
"dependsOn": [
],
"properties": {
"tool": "ServerDiscovery",
"purpose": "Discovery",
"goal": "Servers",
"status": "Inactive"
}
},
{
"apiVersion": "2020-05-01",
Migration-ServerMigration')]",
"dependsOn": [
],
"properties": {
"tool": "ServerMigration",
"purpose": "Migration",
"goal": "Servers",
"status": "Active"
}
}
]
}
Deploy the template

To deploy the template, the Subscription, Resource group, Project name, and Location
are required.
1. To sign in to Azure and open the template, select the Deploy to Azure image.
2. Select or enter the following values:
Subscription: Select your Azure subscription.

Resource group: Select an existing group or select Create new to add a
group.
Region: Defaults to the resource group's location and becomes unavailable
after a resource group is selected.
Migrate Project Name: Provide a name for the vault.
Location: Select the location where you want to deploy the Azure Migrate
project and its resources.
3. Click Review + create button to start the deployment.

Validate the deployment
To confirm that the Azure Migrate project was created, use the Azure portal.
1. Navigate to Azure Migrate by searching for Azure Migrate in the search bar on the
Azure portal.
2. Click the Discover, Assess, and Migrate button under the Servers, databases and
web apps tile.
3. Select the Azure subscription and Project as per the values specified in the
deployment.
Next steps
In this quickstart, you created an Azure Migrate project. To learn more about Azure
Migrate and its capabilities, continue to the Azure Migrate overview.
Azure Migrate overview

Tutorial: Discover servers running in a
VMware environment with Azure Migrate
Article • 04/13/2023
As part of your migration journey to Azure, you discover your on-premises inventory and workloads.
This tutorial shows you how to discover the servers that are running in your VMware environment by
using the Azure Migrate: Discovery and assessment tool, a lightweight Azure Migrate appliance. You
deploy the appliance as a server running in your vCenter Server instance, to continuously discover
servers and their performance metadata, applications that are running on servers, server
dependencies, web apps, and SQL Server instances and databases.
In this tutorial, you learn how to:
＂ Set up an Azure account.

＂ Prepare the VMware environment for discovery.
＂ Create a project.
＂ Set up the Azure Migrate appliance.
＂ Start continuous discovery.
７ Note
Tutorials show you the quickest path for trying out a scenario. They use default options where
possible.
If you don't have an Azure subscription, create a free account before you begin.
Prerequisites
Before you begin this tutorial, check that you have these prerequisites in place:
Requirement Details
vCenter You need a server running vCenter Server version 7.0, 6.7, 6.5, 6.0, or 5.5.
Server/ESXi
host Servers must be hosted on an ESXi host running version 5.5 or later.
On the vCenter Server, allow inbound connections on TCP port 443 so that the appliance can
collect configuration and performance metadata.
The appliance connects to vCenter Server on port 443 by default. If the server running vCenter
Server listens on a different port, you can modify the port when you provide the vCenter Server
details in the appliance configuration manager.
On the ESXi hosts, make sure that inbound access is allowed on TCP port 443 for discovery of
installed applications and for agentless dependency analysis on servers.
Requirement Details
Azure vCenter Server must have these resources to allocate to a server that hosts the Azure Migrate
Migrate appliance:
appliance
- 32 GB of RAM, 8 vCPUs, and approximately 80 GB of disk storage.
- An external virtual switch and internet access on the appliance server, directly or via a proxy.
Servers All Windows and Linux OS versions are supported for discovery of configuration and
performance metadata.
For application discovery on servers, all Windows and Linux OS versions are supported. Check
the OS versions supported for agentless dependency analysis.
For discovery of installed applications and for agentless dependency analysis, VMware Tools
(version 10.2.1 or later) must be installed and running on servers. Windows servers must have
PowerShell version 2.0 or later installed.
To discover SQL Server instances and databases, check supported SQL Server and Windows OS
versions and editions and Windows authentication mechanisms.
To discover ASP.NET web apps running on IIS web server, check supported Windows OS and IIS
versions.
To discover Java web apps running on Apache Tomcat web server, check supported Linux OS
and Tomcat versions.
SQL Server To discover SQL Server instances and databases, the Windows or SQL Server account must be a
access member of the sysadmin server role or have these permissions for each SQL Server instance.
Prepare an Azure user account

To create a project and register the Azure Migrate appliance, you must have an Azure account that
has these permissions:
Contributor or Owner permissions in the Azure subscription.

Permissions to register Azure Active Directory (Azure AD) apps.
Owner or Contributor and User Access Administrator permissions at subscription level to create
an instance of Azure Key Vault, which is used during agentless server migration.
If you created a free Azure account, by default, you're the owner of the Azure subscription. If you're
not the subscription owner, work with the owner to assign permissions.
To set Contributor or Owner permissions in the Azure subscription:
1. In the Azure portal, search for "subscriptions." Under Services in the search results, select
Subscriptions.
2. In Subscriptions, select the subscription in which you want to create a project.
3. Select Access control (IAM).
4. Select Add > Add role assignment to open the Add role assignment page.
5. Assign the following role. For detailed steps, see Assign Azure roles using the Azure portal.
Setting Value
Role Contributor or Owner
Assign access to User
Members azmigrateuser
To give the account the required permissions to register Azure AD apps:
1. In the portal, go to Azure Active Directory > Users > User Settings.
2. In User settings, verify that Azure AD users can register applications (set to Yes by default).
3. If App registrations is set to No, request the tenant, or global admin to assign the required
permissions. Alternately, the tenant or global admin can assign the Application Developer role
to an account to allow Azure AD app registration by users. Learn more.
Prepare VMware
On vCenter Server, check that your account has permissions to create a VM by using a VMware Open
Virtualization Appliance (OVA) virtual machine (VM) installation file. You must have these permissions
when you deploy the Azure Migrate appliance as a VMware VM by using an OVA file.
Azure Migrate must have a vCenter Server read-only account to discover and assess servers running
in your VMware environment. If you also want to run discovery of installed applications and
agentless dependency analysis, the account must have permissions enabled in VMware for VM guest
operations.
Create an account to access vCenter Server

In VMware vSphere Web Client, set up a read-only account to use for vCenter Server:
1. From an account that has admin privileges, in vSphere Web Client, on the Home menu, select
Administration.
2. Under Single Sign-On, select Users and Groups.
3. In Users, select New User.
4. Enter the account details, and then select OK.
5. In the menu under Administration, under Access Control, select Global Permissions.
6. Select the user account, and then select Read-only to assign the role to the account. Select OK.
7. To be able to start discovery of installed applications and agentless dependency analysis, in the
menu under Access Control, select Roles. In the Roles pane, under Roles, select Read-only.
Under Privileges, select Guest operations. To propagate the privileges to all objects in the
vCenter Server instance, select the Propagate to children checkbox.
７ Note
You can scope the vCenter Server account to limit discovery to specific vCenter Server
datacenters, clusters, hosts, folders of clusters or hosts, or individual servers. Learn how to scope
the vCenter Server user account.
７ Note
vCenter assets connected via Linked-Mode to the vCenter server specified for discovery will not
be discovered by Azure Migrate.
Create an account to access servers

Your user account on your servers must have the required permissions to initiate discovery of
installed applications, agentless dependency analysis, and discovery of web apps, and SQL Server
instances and databases. You can provide the user account information in the appliance
configuration manager. The appliance doesn't install agents on the servers.
For Windows servers and web apps discovery, create an account (local or domain) that has
administrator permissions on the servers. To discover SQL Server instances and databases, the
Windows or SQL Server account must be a member of the sysadmin server role. Learn how to
assign the required role to the user account.
For Linux servers, provide a sudo user account with permissions to execute ls and netstat
commands or create a user account that has the CAP_DAC_READ_SEARCH and
CAP_SYS_PTRACE permissions on /bin/netstat and /bin/ls files. If you're providing a sudo user
account, ensure that you have enabled NOPASSWD for the account to run the required
commands without prompting for a password every time sudo command is invoked.
７ Note
You can add multiple server credentials in the Azure Migrate appliance configuration manager
to initiate discovery of installed applications, agentless dependency analysis, and discovery of
web apps, and SQL Server instances and databases. You can add multiple domain, Windows
(non-domain), Linux (non-domain), or SQL Server authentication credentials. Learn how to add
server credentials.
Set up a project
To set up a new project:
1. In the Azure portal, select All services, and then search for Azure Migrate.
2. Under Services, select Azure Migrate.

3. In Overview, select one of the following options, depending on your migration goals: Servers,
databases and web apps, SQL Server (only), or Explore more scenarios.
4. Select Create project.
5. In Create project, select your Azure subscription and resource group. Create a resource group if
you don't have one.
6. In Project Details, specify the project name and the geography where you want to create the
project. Review supported geographies for public clouds and supported geographies for
government clouds.
７ Note
Use the Advanced configuration section to create an Azure Migrate project with private
endpoint connectivity. Learn more.
7. Select Create.
8. Wait a few minutes for the project to deploy. The Azure Migrate: Discovery and assessment
tool is added by default to the new project.
７ Note
If you've already created a project, you can use that project to register more appliances to
discover and to assess more servers. Learn how to manage projects.
Set up the appliance

The Azure Migrate: Discovery and assessment tool uses a lightweight Azure Migrate appliance. The
appliance completes server discovery and sends server configuration and performance metadata to
Azure Migrate. Set up the appliance by deploying an OVA template that can be downloaded from
the project.
７ Note
If you can't set up the appliance by using the OVA template, you can set it up by running a
PowerShell script on an existing server running Windows Server 2016. Learn how to use
PowerShell to set up an Azure Migrate appliance.
The option to deploy an appliance using an OVA template isn't supported in Azure Government
cloud. Learn more on how to deploy an appliance for Azure Government cloud.
Deploy by using an OVA template

To set up the appliance by using an OVA template, complete these steps, which are described in
more detail in this section:
1. Provide an appliance name and generate a project key in the portal.

2. Download an OVA template file, and then import it to vCenter Server. Verify that the OVA is
secure.
3. Create the appliance from the OVA file. Verify that the appliance can connect to Azure Migrate.
4. Configure the appliance for the first time.
5. Register the appliance with the project by using the project key.
Generate the project key

1. In Migration goals, select Servers, databases and web apps > Azure Migrate: Discovery and
assessment > Discover.
2. In Discover servers, select Are your servers virtualized? > Yes, with VMware vSphere
hypervisor.
3. In 1:Generate project key, provide a name for the Azure Migrate appliance that you'll set up to
discover servers in your VMware environment. The name should be alphanumeric and 14
characters or fewer.
4. To start creating the required Azure resources, select Generate key. Don't close the Discover
pane while the resources are being created.
5. After the Azure resources are successfully created, a project key is generated.
6. Copy the key. You'll use the key to complete registration of the appliance when you configure
the appliance.
Download the OVA template
In 2: Download Azure Migrate appliance, select the OVA file, and then select Download.
Verify security
Before you deploy the OVA file, verify that the file is secure:
1. On the server on which you downloaded the file, open a Command Prompt window by using
the Run as administrator option.
2. Run the following command to generate the hash for the OVA file:
Bash
C:\>CertUtil -HashFile <file_location> <hashing_agorithm>
Example: C:\>CertUtil -HashFile

C:\Users\Administrator\Desktop\MicrosoftAzureMigration.ova SHA256
3. Verify the latest appliance versions and hash values:
For the Azure public cloud:
Algorithm Download SHA256
VMware Latest 8A64806762A37698E7CFFB1D0DCACA91E9082803B5977F49A0ACE32A281DB8A1

(11.9 GB) version
For Azure Government:
Algorithm Download SHA256
VMware Latest CE63463B3CE07D7500F0A34F9CAFF0AB939368E5DB320F9F05EE45A386A49CDC

(85.8 MB) version
Create the appliance server
Import the downloaded file, and then create a server in the VMware environment:
1. In the vSphere Client console, select File > Deploy OVF Template.
2. In the Deploy OVF Template Wizard, select Source, and then enter the location of the OVA file.
3. In Name, enter a name for the server. In Location, select the inventory object in which the
server will be hosted.
4. In Host/Cluster, select the host or cluster on which the server will run.
5. In Storage, select the storage destination for the server.
6. In Disk Format, select the disk type and size.
7. In Network Mapping, select the network the server will connect to. The network requires
internet connectivity to send metadata to Azure Migrate.
8. Review and confirm the settings, and then select Finish.
Verify appliance access to Azure
Make sure that the appliance server can connect to Azure URLs for public clouds and government
clouds.
Configure the appliance
To set up the appliance for the first time:
７ Note
If you set up the appliance by using a PowerShell script instead of a downloaded OVA template,
you can skip the first two steps.
1. In vSphere Client, right-click the server, and then select Open Console.
2. Select or enter the language, time zone, and password for the appliance.
3. Open a browser on any computer that can connect to the appliance. Then, open the URL of the
appliance configuration manager: https://appliance name or IP address: 44368 .
Or, you can open the configuration manager from the appliance server desktop by selecting
the shortcut for the configuration manager.
4. Accept the license terms and read the third-party information.
Set up prerequisites and register the appliance
In the configuration manager, select Set up prerequisites, and then complete these steps:
1. Connectivity: The appliance checks that the server has internet access. If the server uses a
proxy:
Select Setup proxy to specify the proxy address (in the form http://ProxyIPAddress or
http://ProxyFQDN , where FQDN refers to a fully qualified domain name) and listening port.
Enter credentials if the proxy needs authentication.
If you have added proxy details or disabled the proxy or authentication, select Save to
trigger connectivity and check connectivity again.
Only HTTP proxy is supported.
2. Time sync: Check that the time on the appliance is in sync with internet time for discovery to
work properly.
3. Install updates and register appliance: To run auto-update and register the appliance, follow
these steps:
７ Note
This is a new user experience in Azure Migrate appliance which is available only if you have
set up an appliance using the latest OVA/Installer script downloaded from the portal. The
appliances which have already been registered will continue seeing the older version of
the user experience and will continue to work without any issues.
a. For the appliance to run auto-update, paste the project key that you copied from the portal.
If you don't have the key, go to Azure Migrate: Discovery and assessment > Overview >
Manage existing appliances. Select the appliance name you provided when you generated
the project key, and then copy the key that's shown.
b. The appliance will verify the key and start the auto-update service, which updates all the
services on the appliance to their latest versions. When the auto-update has run, you can
select View appliance services to see the status and versions of the services running on the
appliance server.
c. To register the appliance, you need to select Login. In Continue with Azure Login, select
Copy code & Login to copy the device code (you must have a device code to authenticate
with Azure) and open an Azure sign in prompt in a new browser tab. Make sure you've
disabled the pop-up blocker in the browser to see the prompt.
d. In a new tab in your browser, paste the device code and sign in by using your Azure
username and password. Signing in with a PIN isn't supported.
７ Note
If you close the sign in tab accidentally without logging in, refresh the browser tab of
the appliance configuration manager to display the device code and Copy code &
Login button.
e. After you successfully sign in, return to the browser tab that displays the appliance
configuration manager. If the Azure user account that you used to sign in has the required
permissions for the Azure resources that were created during key generation, appliance
registration starts.
After the appliance is successfully registered, to see the registration details, select View
details.
4. Install the VDDK: The appliance checks that VMware vSphere Virtual Disk Development Kit
(VDDK) is installed. If the VDDK isn't installed, download VDDK 6.7 from VMware. Extract the
downloaded zip file contents to the specified location on the appliance, the default path is
C:\Program Files\VMware\VMware Virtual Disk Development Kit as indicated in the Installation
instructions.
The Migration and modernization tool uses the VDDK to replicate servers during migration to
Azure.
You can rerun prerequisites at any time during appliance configuration to check whether the
appliance meets all the prerequisites.
Start continuous discovery

Complete the setup steps in the appliance configuration manager to prepare for and start discovery.
Provide vCenter Server details

The appliance must connect to vCenter Server to discover the configuration and performance data of
the servers:
1. In Step 1: Provide vCenter Server credentials, select Add credentials to enter a name for the
credentials. Add the username and password for the vCenter Server account that the appliance
will use to discover servers running on vCenter Server.
You should have set up an account with the required permissions as described earlier in
this article.
If you want to scope discovery to specific VMware objects (vCenter Server datacenters,
clusters, hosts, folders of clusters or hosts, or individual servers), review the instructions to
set discovery scope to restrict the account that Azure Migrate uses.
If you want to add multiple credentials at once, select Add more to save and add more
credentials. Multiple credentials are supported for discovery of servers across multiple
vCenter Servers using a single appliance.
2. In Step 2: Provide vCenter Server details, select Add discovery source to add the IP address or
FQDN of a vCenter Server. You can leave the port as the default (443) or specify a custom port
on which vCenter Server listens. Select the friendly name for credentials you would like to map
to the vCenter Server and select Save.
Select Add more to save the previous details and add more vCenter Server details. You can add
up to 10 vCenter Servers per appliance.
3. The appliance attempts to validate the connection to the vCenter Server(s) added by using the
credentials mapped to each vCenter Server. It displays the validation status with the vCenter
Server(s) IP address or FQDN in the sources table.
4. You can revalidate the connectivity to the vCenter Server(s) anytime before starting discovery.
Provide server credentials
In Step 3: Provide server credentials to perform software inventory, agentless dependency
analysis, discovery of SQL Server instances and databases and discovery of web apps in your
VMware environment., you can provide multiple server credentials. If you don't want to use any of
these appliance features, you can skip this step and proceed with vCenter Server discovery. You can
change this option at any time.
If you want to use these features, provide server credentials by completing the following steps. The
appliance attempts to automatically map the credentials to the servers to perform the discovery
features.
To add server credentials:
1. Select Add Credentials.
2. In the dropdown menu, select Credentials type.
You can provide domain, Windows(non-domain), Linux(non-domain), and SQL Server

authentication credentials. Learn how to provide credentials and how we handle them.
3. For each type of credentials, enter:
A friendly name.
A username.
A password. Select Save.
If you choose to use domain credentials, you also must enter the FQDN for the domain. The
FQDN is required to validate the authenticity of the credentials with the Active Directory
instance in that domain.
4. Review the required permissions on the account for discovery of installed applications,
agentless dependency analysis, and discovery of web apps and SQL Server instances and
databases.
5. To add multiple credentials at once, select Add more to save credentials, and then add more
credentials. When you select Save or Add more, the appliance validates the domain credentials
with the domain's Active Directory instance for authentication. Validation is made after each
addition to avoid account lockouts as the appliance iterates to map credentials to respective
servers.
To check validation of the domain credentials:
In the configuration manager, in the credentials table, see the Validation status for domain
credentials. Only domain credentials are validated.
If validation fails, you can select a Failed status to see the validation error. Fix the issue, and then
select Revalidate credentials to reattempt validation of the credentials.
Start discovery
To start vCenter Server discovery, select Start discovery. After the discovery is successfully initiated,
you can check the discovery status by looking at the vCenter Server IP address or FQDN in the
sources table.
How discovery works

It takes approximately 20-25 minutes for the discovery of servers across 10 vCenter Servers
added to a single appliance.
If you have provided server credentials, software inventory (discovery of installed applications)
is automatically initiated when the discovery of servers running on vCenter Server(s) is finished.
Software inventory occurs once every 12 hours.
Software inventory identifies the SQL Server instances that are running on the servers. Using
the information it collects, the appliance attempts to connect to the SQL Server instances
through the Windows authentication credentials or the SQL Server authentication credentials
that are provided on the appliance. Then, it gathers data on SQL Server databases and their
properties. The SQL Server discovery is performed once every 24 hours.
Appliance can connect to only those SQL Server instances to which it has network line of sight,
whereas software inventory by itself may not need network line of sight.
Discovery of installed applications might take longer than 15 minutes. The duration depends on
the number of discovered servers. For 500 servers, it takes approximately one hour for the
discovered inventory to appear in the Azure Migrate project in the portal.
Software inventory identifies web server role existing on discovered servers. If a server is found
to have web server role enabled, Azure Migrate will perform web apps discovery on the server.
Web apps configuration data is updated once every 24 hours.
During software inventory, the added server credentials are iterated against servers and
validated for agentless dependency analysis. When the discovery of servers is finished, in the
portal, you can enable agentless dependency analysis on the servers. Only the servers on which
validation succeeds can be selected to enable agentless dependency analysis.
Web apps and SQL Server instances and databases data begin to appear in the portal within 24
hours after you start discovery.
By default, Azure Migrate uses the most secure way of connecting to SQL instances that is,
Azure Migrate encrypts communication between the Azure Migrate appliance and the source
SQL Server instances by setting the TrustServerCertificate property to true . Additionally, the
transport layer uses TLS to encrypt the channel and bypass the certificate chain to validate
trust. Hence, the appliance server must be set up to trust the certificate's root authority.
However, you can modify the connection settings, by selecting Edit SQL Server connection
properties on the appliance. Learn more to understand what to choose.
To start vCenter Server discovery, select Start discovery. After the discovery is successfully initiated,
you can check the discovery status by looking at the vCenter Server IP address or FQDN in the
sources table.
View discovered data

1. Return to Azure Migrate in the Azure portal.
2. Select Refresh to view discovered data.
3. Select the discovered servers count to review the discovered inventory. You can filter the
inventory by selecting the appliance name and selecting one or more vCenter Servers from the
Source filter.
Next steps
Learn how to assess servers to migrate to Azure VMs.
Learn how to assess servers running SQL Server to migrate to Azure SQL.
Learn how to assess web apps to migrate to Azure App Service.
Review data the Azure Migrate appliance collects during discovery.
Tutorial: Discover servers running on Hyper-V
with Azure Migrate: Discovery and
assessment
Article • 04/13/2023
As part of your migration journey to Azure, you discover your on-premises inventory and
workloads.
This tutorial shows you how to discover the servers that are running in your VMware environment
by using the Azure Migrate: Discovery and assessment tool, a lightweight Azure Migrate appliance.
You deploy the appliance as a server on Hyper-V host, to continuously discover servers and their
performance metadata, applications that are running on servers, server dependencies, web apps,
and SQL Server instances and databases.
＂ Set up an Azure account

＂ Prepare the Hyper-V environment for discovery.
７ Note
Tutorials show the quickest path for trying out a scenario, and use default options.
Prerequisites
Before you start this tutorial, check you have these prerequisites in place.
Requirement Details
Hyper-V Hyper-V hosts on which servers are located can be standalone, or in a cluster.
host
The host must be running Windows Server 2019, Windows Server 2016, or Windows Server
2012 R2.
Verify inbound connections are allowed on WinRM port 5985 (HTTP), so that the appliance can
connect to pull server metadata and performance data, using a Common Information Model
(CIM) session.
Requirement Details
Appliance Hyper-V host needs resources to allocate a server for the appliance:
deployment
- 16 GB of RAM, 8 vCPUs, and around 80 GB of disk storage.
- An external virtual switch, and internet access on the appliance, directly or via a proxy.
Servers All Windows and Linux OS versions are supported for discovery of configuration and
For application discovery on servers, all Windows and Linux OS versions are supported. Check
the OS versions supported for agentless dependency analysis.
To discover ASP.NET web apps running on IIS web server, check supported Windows OS and
IIS versions.For discovery of installed applications and for agentless dependency analysis,
Windows servers must have PowerShell version 2.0 or later installed.
To discover Java web apps running on Apache Tomcat web server, check supported Linux OS
and Tomcat versions.
SQL Server To discover SQL Server instances and databases, the Windows or SQL Server account must be
access a member of the sysadmin server role or have these permissions for each SQL Server instance.

To create a project and register the Azure Migrate appliance, you need an account with:
Contributor or Owner permissions on an Azure subscription.

Permissions to register Azure Active Directory apps.
If you just created a free Azure account, you're the owner of your subscription. If you're not the
subscription owner, work with the owner to assign the permissions as follows:
1. In the Azure portal, search for "subscriptions", and under Services, select Subscriptions.
2. In the Subscriptions page, select the subscription in which you want to create a project.

Setting Value
6. To register the appliance, your Azure account needs permissions to register Azure Active
Directory apps.
7. In the Azure portal, navigate to Azure Active Directory > Users > User Settings.
9. In case the 'App registrations' settings is set to 'No', request the tenant/global admin to
assign the required permission. Alternately, the tenant/global admin can assign the
Application Developer role to an account to allow the registration of Azure Active Directory
App. Learn more.
Prepare Hyper-V hosts

You can prepare Hyper-V hosts manually, or using a script. The preparation steps are summarized
in the table. The script prepares these automatically.
Step Script Manual
Verify host Checks that the host is running a The host must be running Windows Server 2019,
requirements supported version of Hyper-V, and Windows Server 2016, or Windows Server 2012 R2.
the Hyper-V role.
Verify inbound connections are allowed on WinRM
Enables the WinRM service, and port 5985 (HTTP), so that the appliance can
opens ports 5985 (HTTP) and 5986 connect to pull server metadata and performance
(HTTPS) on the host (needed for data, using a Common Information Model (CIM)
metadata collection). session.
The script isn't currently supported on hosts with a

non-English locale.
Verify Checks that you're running the script Check you're running PowerShell version 4.0 or
PowerShell on a supported PowerShell version. later on the Hyper-V host.
version
Step Script Manual
Create an Verifies that you have the correct Option 1: Prepare an account with Administrator
account permissions on the Hyper-V host. access to the Hyper-V host machine.
Allows you to create a local user Option 2: Prepare a Local Admin account, or
account with the correct permissions. Domain Admin account, and add the account to
these groups: Remote Management Users, Hyper-V
Administrators, and Performance Monitor Users.
Enable Enables PowerShell remoting on the To set up, on each host, open a PowerShell console
PowerShell host, so that the Azure Migrate as admin, and run this command: powershell
remoting appliance can run PowerShell Enable-PSRemoting -force
commands on the host, over a
WinRM connection.
Set up Hyper-V Checks that the Hyper-V Integration Enable Hyper-V Integration Services on each server.
integration Services is enabled on all servers
services managed by the host. If you're running Windows Server 2003, follow
these instructions.
Delegate Delegates credentials Run this command to enable CredSSP to delegate

credentials if credentials on hosts running servers with disks on
server disks are SMB shares: powershell Enable-WSManCredSSP -Role
located on Server -Force
remote SMB
shares You can run this command remotely on all Hyper-V
hosts.
If you add new host nodes on a cluster they're

automatically added for discovery, but you need to
enable CredSSP manually.
When you set up the appliance, you finish setting

up CredSSP by enabling it on the appliance.
Run the script

1. Download the script from the Microsoft Download Center . The script is cryptographically
signed by Microsoft.
2. Validate the script integrity using SHA256 hash file. Hashtag value is below. Run this
command to generate the hash for the script:
PowerShell
C:\>CertUtil -HashFile <file_location> [Hashing Algorithm]
Example usage:
PowerShell
C:\>CertUtil -HashFile C:\Users\Administrators\Desktop\ MicrosoftAzureMigrate-
Hyper-V.ps1 SHA256
3. After validating the script integrity, run the script on each Hyper-V host with this PowerShell
command with elevated permissions:
PowerShell
PS C:\Users\Administrators\Desktop> MicrosoftAzureMigrate-Hyper-V.ps1
Hash value is:
Hash Value
SHA256 0ad60e7299925eff4d1ae9f1c7db485dc9316ef45b0964148a3c07c80761ade2

The user account on your servers must have the required permissions to initiate discovery of
installed applications, agentless dependency analysis, and SQL Server instances and databases. You
can provide the user account information in the appliance configuration manager. The appliance
doesn't install agents on the servers.
For Windows servers, create an account (local or domain) that has administrator permissions
on the servers. To discover SQL Server instances and databases, the Windows or SQL Server
account must be a member of the sysadmin server role. Learn how to assign the required role
to the user account.
For Linux servers, provide a sudo user account with permissions to execute ls and netstat
commands or create a user account that has the CAP_DAC_READ_SEARCH and
CAP_SYS_PTRACE permissions on /bin/netstat and /bin/ls files. If you're providing a sudo user
account, ensure that you have enabled NOPASSWD for the account to run the required
commands without prompting for a password every time sudo command is invoked.
７ Note
You can add multiple server credentials in the Azure Migrate appliance configuration manager
to initiate discovery of installed applications, agentless dependency analysis, and SQL Server
instances and databases. You can add multiple domain, Windows (non-domain), Linux (non-
domain), or SQL Server authentication credentials. Learn how to add server credentials.
Set up a project
Set up a new project.
1. In the Azure portal > All services, search for Azure Migrate.
3. In Overview, select Create project.
4. In Create project, select your Azure subscription and resource group. Create a resource group
if you don't have one.
5. In Project Details, specify the project name and the geography in which you want to create
the project. Review supported geographies for public and government clouds.
７ Note
Use the Advanced configuration section to create an Azure Migrate project with private
endpoint connectivity. Learn more.
6. Select Create.
７ Note
If you have already created a project, you can use the same project to register additional
appliances to discover and assess more no of servers.Learn more

Azure Migrate uses a lightweight Azure Migrate appliance. The appliance performs server discovery
and sends server configuration and performance metadata to Azure Migrate. The appliance can be
set up by deploying a VHD file that can be downloaded from the project.
７ Note
If for some reason you can't set up the appliance using the template, you can set it up using a
PowerShell script on an existing Windows Server 2016 server. Learn more.
The option to deploy an appliance using an VHD template isn't supported in Azure
Government cloud. Learn more on how to deploy an appliance for Azure Government cloud.
This tutorial sets up the appliance on a server running in Hyper-V environment, as follows:

2. Download a compressed Hyper-V VHD from the Azure portal.
3. Create the appliance, and check that it can connect to Azure Migrate: Discovery and
assessment.
4. Configure the appliance for the first time, and register it with the project using the project key.
1. Generate the project key

1. In Migration goals > Servers, databases and web apps > Azure Migrate: Discovery and
assessment, select Discover.
2. In Discover Servers > Are your servers virtualized?, select Yes, with Hyper-V.
3. In 1:Generate project key, provide a name for the Azure Migrate appliance that you'll set up
for discovery of servers. The name should be alphanumeric with 14 characters or fewer.
4. Select Generate key to start the creation of the required Azure resources. Don't close the
Discover server page during the creation of resources.
5. After the successful creation of the Azure resources, a project key is generated.
6. Copy the key as you'll need it to complete the registration of the appliance during its
configuration.
2. Download the VHD

In 2: Download Azure Migrate appliance, select the .VHD file and select Download.
Verify security
Check that the zipped file is secure, before you deploy it.
1. On the machine to which you downloaded the file, open an administrator command window.
2. Run the following PowerShell command to generate the hash for the ZIP file
C:\>Get-FileHash -Path <file_location> -Algorithm [Hashing Algorithm]

Example usage: C:\>Get-FileHash -Path ./AzureMigrateAppliance_v3.20.09.25.zip -
Algorithm SHA256
For the Azure public cloud:
Scenario Download SHA256
Hyper-V Latest AE53454E448064839AEBFDE1EE6DBF63222686CFB37B7E2E125D44A8B24EB504

(8.91 version
GB)
Scenario* Download SHA256
Hyper-V Latest CE63463B3CE07D7500F0A34F9CAFF0AB939368E5DB320F9F05EE45A386A49CDC

(85.8 MB) version
3. Create an appliance
Import the downloaded file, and create an appliance.
1. Extract the zipped VHD file to a folder on the Hyper-V host that will host the appliance. Three
folders are extracted.
2. Open Hyper-V Manager. In Actions, click Import Virtual Machine.
3. In the Import Virtual Machine Wizard > Before you begin, click Next.
4. In Locate Folder, specify the folder containing the extracted VHD. Then click Next.
5. In Select Virtual Machine, click Next.
6. In Choose Import Type, click Copy the virtual machine (create a new unique ID). Then click
Next.
7. In Choose Destination, leave the default setting. Click Next.
8. In Storage Folders, leave the default setting. Click Next.
9. In Choose Network, specify the virtual switch that the appliance will use. The switch needs
internet connectivity to send data to Azure.
10. In Summary, review the settings. Then click Finish.
11. In Hyper-V Manager > Virtual Machines, start the appliance.

Make sure that the appliance can connect to Azure URLs public and government clouds.
4. Configure the appliance

Set up the appliance for the first time.
７ Note
If you set up the appliance using a PowerShell script instead of the downloaded VHD, the first
two steps in this procedure aren't relevant.
1. In Hyper-V Manager > Virtual Machines, right-click the appliance > Connect.
2. Provide the language, time zone, and password for the appliance.
3. Open a browser on any machine that can connect to the appliance, and open the URL of the
appliance web app: https://appliance name or IP address: 44368.
Alternately, you can open the app from the appliance desktop by clicking the app shortcut.
4. Accept the license terms, and read the third-party information.
proxy:
http://ProxyFQDN , where FQDN refers to a fully qualified domain name) and listening
port.
work properly.
these steps:
７ Note
This is a new user experience in Azure Migrate appliance which is available only if you
have set up an appliance using the latest OVA/Installer script downloaded from the
portal. The appliances which have already been registered will continue seeing the older
version of the user experience and will continue to work without any issues.
a. For the appliance to run auto-update, paste the project key that you copied from the
portal. If you don't have the key, go to Azure Migrate: Discovery and assessment >
Overview > Manage existing appliances. Select the appliance name you provided when
you generated the project key, and then copy the key that's shown.
appliance server.
with Azure) and open an Azure Login prompt in a new browser tab. Make sure you've
７ Note
If you close the login tab accidentally without logging in, refresh the browser tab of
Login button.
e. After you successfully log in, return to the browser tab that displays the appliance
configuration manager. If the Azure user account that you used to log in has the required
details.
Delegate credentials for SMB VHDs

If you're running VHDs on SMBs, you must enable delegation of credentials from the appliance to
the Hyper-V hosts. To do this from the appliance:
1. On the appliance, run this command. HyperVHost1/HyperVHost2 are example host names.
Enable-WSManCredSSP -Role Client -DelegateComputer HyperVHost1.contoso.com,

HyperVHost2.contoso.com, HyperVHost1, HyperVHost2 -Force
2. Alternatively, do this in the Local Group Policy Editor on the appliance:
In Local Computer Policy > Computer Configuration, click Administrative Templates >
System > Credentials Delegation.
Double-click Allow delegating fresh credentials, and select Enabled.
In Options, click Show, and add each Hyper-V host you want to discover to the list, with
wsman/ as a prefix.
In Credentials Delegation, double-click Allow delegating fresh credentials with NTLM-
only server authentication. Again, add each Hyper-V host you want to discover to the
list, with wsman/ as a prefix.

Connect from the appliance to Hyper-V hosts or clusters, and start server discovery.
Provide Hyper-V host/cluster details

1. In Step 1: Provide Hyper-V host credentials, select Add credentials to specify a friendly name
for credentials, add Username and Password for a Hyper-V host/cluster that the appliance will
use to discover servers. select Save.
2. If you want to add multiple credentials at once, select Add more to save and add more
credentials. Multiple credentials are supported for discovery of servers in Hyper-V
environment.
3. In Step 2: Provide Hyper-V host/cluster details, select Add discovery source to specify the
Hyper-V host/cluster IP address/FQDN and the friendly name for credentials to connect to
the host/cluster.
4. You can either Add single item at a time or Add multiple items in one go. There's also an
option to provide Hyper-V host/cluster details through Import CSV.
If you choose Add single item, you need to specify friendly name for credentials and
Hyper-V host/cluster IP address/FQDN, and select Save.
If you choose Add multiple items (selected by default), you can add multiple records at
once by specifying Hyper-V host/cluster IP address/FQDN with the friendly name for
credentials in the text box. Verify the added records and select Save.
If you choose Import CSV, you can download a CSV template file, populate the file with
the Hyper-V host/cluster IP address/FQDN and friendly name for credentials. You then
import the file into the appliance, verify the records in the file and select Save.
5. On clicking Save, appliance will try validating the connection to the Hyper-V hosts/clusters
added and show the Validation status in the table against each host/cluster.
For successfully validated hosts/clusters, you can view more details by clicking on their IP
address/FQDN.
If validation fails for a host, review the error by clicking on Validation failed in the Status
column of the table. Fix the issue, and validate again.
To remove hosts or clusters, select Delete.
You can't remove a specific host from a cluster. You can only remove the entire cluster.
You can add a cluster, even if there are issues with specific hosts in the cluster.
6. You can revalidate the connectivity to hosts/clusters anytime before starting the discovery.

In Step 3: Provide server credentials to perform software inventory, agentless dependency
analysis, discovery of SQL Server instances and databases in your Microsoft HyperV
environment., you can provide multiple server credentials. If you don't want to use any of these
appliance features, you can disable the slider and proceed with discovery of servers running on
Hyper-V hosts/clusters. You can change this option at any time.
If you want to use these features, provide server credentials by completing the following steps. The
appliance attempts to automatically map the credentials to the servers to perform the discovery
features.

You can provide domain/, Windows(non-domain)/, Linux(non-domain)/, and SQL Server

authentication credentials. Learn how to provide credentials and how we handle them.
A friendly name.
A username.
If you choose to use domain credentials, you also must enter the FQDN for the domain. The
FQDN is required to validate the authenticity of the credentials with the Active Directory
instance in that domain.
4. Review the required permissions on the account for discovery of installed applications,
agentless dependency analysis, and discovery SQL Server instances and databases.
5. To add multiple credentials at once, select Add more to save credentials, and then add more
credentials. When you select Save or Add more, the appliance validates the domain
credentials with the domain's Active Directory instance for authentication. Validation is made
after each addition to avoid account lockouts as the appliance iterates to map credentials to
respective servers.
In the configuration manager, in the credentials table, see the Validation status for domain
credentials. Only domain credentials are validated.
If validation fails, you can select a Failed status to see the validation error. Fix the issue, and then
select Revalidate credentials to reattempt validation of the credentials.
Start discovery
Select Start discovery, to kick off server discovery from the successfully validated host(s)/cluster(s).
After the discovery has been successfully initiated, you can check the discovery status against each
host/cluster in the table.
How discovery works

It takes approximately 2 minutes per host for metadata of discovered servers to appear in the
Azure portal.
If you have provided server credentials, software inventory (discovery of installed applications)
is automatically initiated when the discovery of servers running on Hyper-V host(s)/cluster(s)
is finished.
Appliance can connect to only those SQL Server instances to which it has network line of
sight, whereas software inventory by itself may not need network line of sight.
The time taken for discovery of installed applications depends on the number of discovered
servers. For 500 servers, it takes approximately one hour for the discovered inventory to
appear in the Azure Migrate project in the portal.
Software inventory identifies web server role existing on discovered servers. If a server is
found to have web server role enabled, Azure Migrate will perform web apps discovery on the
server. Web apps configuration data is updated once every 24 hours.
portal, you can enable agentless dependency analysis on the servers. Only the servers on
which validation succeeds can be selected to enable agentless dependency analysis.
SQL Server instances and databases data begin to appear in the portal within 24 hours after
you start discovery.
transport layer uses SSL to encrypt the channel and bypass the certificate chain to validate
Verify servers in the portal

After discovery finishes, you can verify that the servers appear in the portal.
1. Open the Azure Migrate dashboard.

2. In Azure Migrate - Servers > Azure Migrate: Discovery and assessment page, click the icon
that displays the count for Discovered servers.
Next steps
Assess servers on Hyper-V environment for migration to Azure VMs.
Review the data that the appliance collects during discovery.
Tutorial: Discover physical servers with
Azure Migrate: Discovery and
assessment
Article • 04/13/2023
As part of your migration journey to Azure, you discover your servers for assessment
and migration.
This tutorial shows you how to discover on-premises physical servers with the Azure
Migrate: Discovery and assessment tool, using a lightweight Azure Migrate appliance.
You deploy the appliance as a physical server, to continuously discover servers and

＂ Prepare physical servers for discovery.
７ Note
Prerequisites
Before you start this tutorial, ensure you have these prerequisites in place.
Requirement Details
Requirement Details
Appliance You need a server to run the Azure Migrate appliance. The server should have:
- Windows Server 2016 installed.

(Currently the deployment of appliance is only supported on Windows Server 2016.)
- 16-GB RAM, 8 vCPUs, around 80 GB of disk storage
- A static or dynamic IP address, with internet access, either directly or through a

proxy.
- Outbound internet connectivity to the required URLs from the appliance.
Windows Allow inbound connections on WinRM port 5985 (HTTP) for discovery of Windows
servers servers.
To discover ASP.NET web apps running on IIS web server, check supported
Windows OS and IIS versions.
Linux Allow inbound connections on port 22 (TCP) for discovery of Linux servers.
servers
To discover Java web apps running on Apache Tomcat web server, check
supported Linux OS and Tomcat versions.
SQL Server To discover SQL Server instances and databases, the Windows or SQL Server
access account must be a member of the sysadmin server role or have these permissions
for each SQL Server instance.
７ Note
It is unsupported to install the Azure Migrate Appliance on a server that has the
replication appliance or mobility service agent installed. Ensure that the appliance
server has not been previously used to set up the replication appliance or has the
mobility service agent installed on the server.


If you just created a free Azure account, you're the owner of your subscription. If you're
not the subscription owner, work with the owner to assign the permissions as follows:
1. In the Azure portal, search for "subscriptions", and under Services, select
Subscriptions.
4. Assign the following role. For detailed steps, see Assign Azure roles using the
Azure portal.
Setting Value
5. To register the appliance, your Azure account needs permissions to register Azure
Active Directory apps.
6. In Azure portal, navigate to Azure Active Directory > Users > User Settings.
7. In User settings, verify that Azure AD users can register applications (set to Yes by
default).
8. In case the 'App registrations' settings is set to 'No', request the tenant/global
admin to assign the required permission. Alternately, the tenant/global admin can
assign the Application Developer role to an account to allow the registration of
Azure Active Directory App. Learn more.
Prepare Windows server

For Windows servers, use a domain account for domain-joined servers, and a local
account for servers that aren't domain-joined. The user account can be created in one of
the two ways:
Option 1
Create an account that has administrator privileges on the servers. This account
can be used to pull configuration and performance data through CIM connection
and perform software inventory (discovery of installed applications) and enable
agentless dependency analysis using PowerShell remoting.
７ Note
If you want to perform software inventory (discovery of installed applications) and

enable agentless dependency analysis on Windows servers, it recommended to use
Option 1.
Option 2
The user account should be added to these groups: Remote Management Users,
Performance Monitor Users, and Performance Log Users.
If Remote management Users group isn't present, then add the user account to the
group: WinRMRemoteWMIUsers_.
The account needs these permissions for the appliance to create a CIM connection
with the server and pull the required configuration and performance metadata
from the WMI classes listed here.
In some cases, adding the account to these groups may not return the required
data from WMI classes as the account might be filtered by UAC. To overcome the
UAC filtering, user account needs to have necessary permissions on CIMV2
Namespace and sub-namespaces on the target server. You can follow the steps
here to enable the required permissions.
７ Note
For Windows Server 2008 and 2008 R2, ensure that WMF 3.0 is installed on
the servers.
７ Note
To discover SQL Server databases on Windows Servers, both Windows and SQL
Server authentication are supported. You can provide credentials of both
authentication types in the appliance configuration manager. Azure Migrate
requires a Windows user account that is a member of the sysadmin server role.
Prepare Linux server

For Linux servers, you can create a user account in one of two ways:
Option 1
You need a sudo user account on the servers that you want to discover. This
account can be used to pull configuration and performance metadata and perform
software inventory (discovery of installed applications) and enable agentless
dependency analysis using SSH connectivity.
You need to enable sudo access for the commands listed here. In addition to these
commands, the user account also needs to have permissions to execute ls and
netstat commands to perform agentless dependency analysis.
Make sure that you have enabled NOPASSWD for the account to run the required
commands without prompting for a password every time sudo command is
invoked.
The Linux OS distributions that are supported for discovery by Azure Migrate using
an account with sudo access are listed here.
７ Note

enable agentless dependency analysis on Linux servers, it recommended to use
Option 1.
Option 2
If you can't provide user account with sudo access, then you can set 'isSudo'
registry key to value '0' in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AzureAppliance registry on the
appliance server and provide a non-root account with the required capabilities
using the following commands:
Command Purpose
setcap CAP_DAC_READ_SEARCH+eip /usr/sbin/fdisk To collect

disk
setcap CAP_DAC_READ_SEARCH+eip /sbin/fdisk (if /usr/sbin/fdisk is not present) configuration
data
setcap To collect
"cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_setuid, disk
cap_setpcap,cap_net_bind_service,cap_net_admin,cap_sys_chroot,cap_sys_admin, performance
cap_sys_resource,cap_audit_control,cap_setfcap=+eip" /sbin/lvm data
Command Purpose
setcap CAP_DAC_READ_SEARCH+eip /usr/sbin/dmidecode To collect

BIOS serial
number
chmod a+r /sys/class/dmi/id/product_uuid To collect

BIOS GUID
To perform agentless dependency analysis on the server, ensure that you also set
the required permissions on /bin/netstat and /bin/ls files by using the following
commands:
sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep /bin/ls
sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep /bin/netstat

Your user account on your servers must have the required permissions to initiate
discovery of installed applications, agentless dependency analysis, and discovery of web
apps, and SQL Server instances and databases. You can provide the user account
information in the appliance configuration manager. The appliance doesn't install
agents on the servers.
For Windows servers and web apps discovery, create an account (local or domain)
that has administrator permissions on the servers. To discover SQL Server instances
and databases, the Windows or SQL Server account must be a member of the
sysadmin server role. Learn how to assign the required role to the user account.
For Linux servers, provide a sudo user account with permissions to execute ls and
netstat commands or create a user account that has the CAP_DAC_READ_SEARCH
and CAP_SYS_PTRACE permissions on /bin/netstat and /bin/ls files. If you're
providing a sudo user account, ensure that you have enabled NOPASSWD for the
account to run the required commands without prompting for a password every
time sudo command is invoked.
７ Note
You can add multiple server credentials in the Azure Migrate appliance
configuration manager to initiate discovery of installed applications, agentless
dependency analysis, and discovery of web apps, and SQL Server instances and
databases. You can add multiple domain, Windows (non-domain), Linux (non-
domain), or SQL Server authentication credentials. Learn how to add server
credentials.
Set up a project
4. In Create project, select your Azure subscription and resource group. Create a
resource group if you don't have one.
5. In Project Details, specify the project name and the geography in which you want
to create the project. Review supported geographies for public and government
clouds.
７ Note
Use the Advanced configuration section to create an Azure Migrate project

with private endpoint connectivity. Learn more.
6. Select Create.
7. Wait a few minutes for the project to deploy. The Azure Migrate: Discovery and
assessment tool is added by default to the new project.
７ Note
If you have already created a project, you can use the same project to register
additional appliances to discover and assess more no of servers. Learn more.

Azure Migrate appliance performs server discovery and sends server configuration and
performance metadata to Azure Migrate. The appliance can be set up by executing a
PowerShell script that can be downloaded from the project.
To set up the appliance, you:

2. Download a zipped file with the Azure Migrate installer script from the Azure
portal.
3. Extract the contents from the zipped file. Launch the PowerShell console with
administrative privileges.
4. Execute the PowerShell script to launch the appliance configuration manager.
5. Configure the appliance for the first time, and register it with the project using the
project key.

1. In Migration goals > Servers, databases and web apps > Azure Migrate:
Discovery and assessment, select Discover.
2. In Discover servers > Are your servers virtualized?, select Physical or other (AWS,
GCP, Xen, etc.).
3. In 1:Generate project key, provide a name for the Azure Migrate appliance that
you'll set up for discovery of physical or virtual servers. The name should be
alphanumeric with 14 characters or fewer.
4. Select Generate key to start the creation of the required Azure resources. Don't
close the Discover servers page during the creation of resources.
6. Copy the key as you'll need it to complete the registration of the appliance during
its configuration.
2. Download the installer script

In 2: Download Azure Migrate appliance, select Download.
Verify security
1. On the server to which you downloaded the file, open an administrator command
window.
2. Run the following command to generate the hash for the zipped file:
Example usage: C:\>CertUtil -HashFile

C:\Users\administrator\Desktop\AzureMigrateInstaller.zip SHA256
3. Verify the latest appliance version and hash value:
Download Hash value
Latest CE63463B3CE07D7500F0A34F9CAFF0AB939368E5DB320F9F05EE45A386A49CDC
version
７ Note
The same script can be used to set up Physical appliance for either Azure public or
Azure Government cloud with public or private endpoint connectivity.
3. Run the Azure Migrate installer script

1. Extract the zipped file to a folder on the server that will host the appliance. Make
sure you don't run the script on a server with an existing Azure Migrate appliance.
2. Launch PowerShell on the above server with administrative (elevated) privilege.
3. Change the PowerShell directory to the folder where the contents have been
extracted from the downloaded zipped file.
4. Run the script named AzureMigrateInstaller.ps1 by running the following

command:
PS C:\Users\administrator\Desktop\AzureMigrateInstaller>
.\AzureMigrateInstaller.ps1
5. Select from the scenario, cloud, and connectivity options to deploy an appliance
with the desired configuration. For instance, the selection shown below sets up an
appliance to discover and assess physical servers (or servers running on other
clouds like AWS, GCP, Xen etc.) to an Azure Migrate project with default (public
endpoint) connectivity on Azure public cloud.
6. The installer script does the following:
Installs agents and a web application.

Installs Windows roles, including Windows Activation Service, IIS, and
PowerShell ISE.
Downloads and installs an IIS rewritable module.
Updates a registry key (HKLM) with persistent setting details for Azure
Migrate.
Creates the following files under the path:
Config Files: %ProgramData%\Microsoft Azure\Config
Log Files: %ProgramData%\Microsoft Azure\Logs
After the script has executed successfully, the appliance configuration manager will be
launched automatically.
７ Note
If you come across any issues, you can access the script logs at
C:\ProgramData\Microsoft
Azure\Logs\AzureMigrateScenarioInstaller_Timestamp.log for troubleshooting.

Make sure that the appliance can connect to Azure URLs for public and government
clouds.

1. Open a browser on any server that can connect to the appliance, and open the
URL of the appliance web app: https://appliance name or IP address: 44368.
Alternately, you can open the app from the desktop by selecting the app shortcut.
In the configuration manager, select Set up prerequisites, and then complete these
steps:
1. Connectivity: The appliance checks that the server has internet access. If the server
uses a proxy:
Select Setup proxy to specify the proxy address (in the form
http://ProxyIPAddress or http://ProxyFQDN , where FQDN refers to a fully
qualified domain name) and listening port.
If you have added proxy details or disabled the proxy or authentication,

select Save to trigger connectivity and check connectivity again.
2. Time sync: Check that the time on the appliance is in sync with internet time for
discovery to work properly.
3. Install updates and register appliance: To run auto-update and register the
appliance, follow these steps:
７ Note
This is a new user experience in Azure Migrate appliance which is available

only if you have set up an appliance using the latest OVA/Installer script
downloaded from the portal. The appliances which have already been
registered will continue seeing the older version of the user experience and
will continue to work without any issues.
a. For the appliance to run auto-update, paste the project key that you copied
from the portal. If you don't have the key, go to Azure Migrate: Discovery and
assessment > Overview > Manage existing appliances. Select the appliance
name you provided when you generated the project key, and then copy the key
that's shown.
b. The appliance will verify the key and start the auto-update service, which
updates all the services on the appliance to their latest versions. When the auto-
update has run, you can select View appliance services to see the status and
versions of the services running on the appliance server.
c. To register the appliance, you need to select Login. In Continue with Azure
Login, select Copy code & Login to copy the device code (you must have a
device code to authenticate with Azure) and open an Azure Login prompt in a
new browser tab. Make sure you've disabled the pop-up blocker in the browser
to see the prompt.
d. In a new tab in your browser, paste the device code and sign in by using your
Azure username and password. Signing in with a PIN isn't supported.
７ Note
If you close the login tab accidentally without logging in, refresh the
browser tab of the appliance configuration manager to display the device
code and Copy code & Login button.
e. After you successfully sign in, return to the browser tab that displays the
appliance configuration manager. If the Azure user account that you used to
sign in has the required permissions for the Azure resources that were created
during key generation, appliance registration starts.
After the appliance is successfully registered, to see the registration details,
select View details.
You can rerun prerequisites at any time during appliance configuration to check whether
the appliance meets all the prerequisites.

Now, connect from the appliance to the physical servers to be discovered, and start the
discovery.
1. In Step 1: Provide credentials for discovery of Windows and Linux physical or

virtual servers, select Add credentials.
2. For Windows server, select the source type as Windows Server, specify a friendly
name for credentials, add the username and password. Select Save.
3. If you're using password-based authentication for Linux server, select the source
type as Linux Server (Password-based), specify a friendly name for credentials,
add the username and password. Select Save.
4. If you're using SSH key-based authentication for Linux server, you can select
source type as Linux Server (SSH key-based), specify a friendly name for
credentials, add the username, browse and select the SSH private key file. Select
Save.
Azure Migrate supports the SSH private key generated by ssh-keygen

command using RSA, DSA, ECDSA, and ed25519 algorithms.
Currently Azure Migrate doesn't support passphrase-based SSH key. Use an
SSH key without a passphrase.
Currently Azure Migrate doesn't support SSH private key file generated by
PuTTY.
The SSH key file supports CRLF to mark a line break in the text file that you
upload. SSH keys created on Linux systems most commonly have LF as their
newline character so you can convert them to CRLF by opening the file in vim,
typing :set textmode and saving the file.
If your Linux servers support the older version of RSA key, you can generate
the key using the $ ssh-keygen -m PEM -t rsa -b 4096 command.
Azure Migrate supports OpenSSH format of the SSH private key file as shown
below:
5. If you want to add multiple credentials at once, select Add more to save and add
more credentials. Multiple credentials are supported for physical servers discovery.
７ Note
By default, the credentials will be used to gather data about the installed
applications, roles, and features, and also to collect dependency data from
Windows and Linux servers, unless you disable the slider to not perform these
features (as instructed in the last step).
6. In Step 2:Provide physical or virtual server details, select Add discovery source to
specify the server IP address/FQDN and the friendly name for credentials to
connect to the server.
7. You can either Add single item at a time or Add multiple items in one go. There's
also an option to provide server details through Import CSV.
If you choose Add single item, you can choose the OS type, specify friendly
name for credentials, add server IP address/FQDN and select Save.
If you choose Add multiple items, you can add multiple records at once by
specifying server IP address/FQDN with the friendly name for credentials in
the text box. Verify the added records and select Save.
If you choose Import CSV (selected by default), you can download a CSV
template file, populate the file with the server IP address/FQDN and friendly
name for credentials. You then import the file into the appliance, verify the
records in the file and select Save.
8. Select Save. The appliance will try validating the connection to the servers added
and show the Validation status in the table against each server.
If validation fails for a server, review the error by selecting on Validation

failed in the Status column of the table. Fix the issue, and validate again.
To remove a server, select Delete.
9. You can revalidate the connectivity to servers anytime before starting the
discovery.
10. Before initiating discovery, you can choose to disable the slider to not perform
software inventory and agentless dependency analysis on the added servers. You
can change this option at any time.
11. To perform discovery of SQL Server instances and databases, you can add
additional credentials (Windows domain/non-domain, SQL authentication
credentials) and the appliance will attempt to automatically map the credentials to
the SQL servers. If you add domain credentials, the appliance will authenticate the
credentials against Active Directory of the domain to prevent any user accounts
from locking out. To check validation of the domain credentials, follow these steps:
In the configuration manager credentials table, see Validation status for domain
credentials. Only the domain credentials are validated.
If validation fails, you can select a Failed status to see the validation error. Fix the
issue, and then select Revalidate credentials to reattempt validation of the
credentials.
Start discovery
select Start discovery, to kick off discovery of the successfully validated servers. After
the discovery has been successfully initiated, you can check the discovery status against
each server in the table.
How discovery works
It takes approximately 2 minutes to complete discovery of 100 servers and their
metadata to appear in the Azure portal.
Software inventory (discovery of installed applications) is automatically initiated

when the discovery of servers is finished.
Software inventory identifies the SQL Server instances that are running on the
servers. Using the information it collects, the appliance attempts to connect to the
SQL Server instances through the Windows authentication credentials or the SQL
Server authentication credentials that are provided on the appliance. Then, it
gathers data on SQL Server databases and their properties. The SQL Server
discovery is performed once every 24 hours.
Appliance can connect to only those SQL Server instances to which it has network
line of sight, whereas software inventory by itself may not need network line of
sight.
The time taken for discovery of installed applications depends on the number of
discovered servers. For 500 servers, it takes approximately one hour for the
Software inventory identifies web server role existing on discovered servers. If a

server is found to have web server role enabled, Azure Migrate will perform web
apps discovery on the server. Web apps configuration data is updated once every
24 hours.
During software inventory, the added server credentials are iterated against servers
and validated for agentless dependency analysis. When the discovery of servers is
finished, in the portal, you can enable agentless dependency analysis on the
servers. Only the servers on which validation succeeds can be selected to enable
agentless dependency analysis.
SQL Server instances and databases data begin to appear in the portal within 24
hours after you start discovery.
By default, Azure Migrate uses the most secure way of connecting to SQL instances
that is, Azure Migrate encrypts communication between the Azure Migrate
appliance and the source SQL Server instances by setting the TrustServerCertificate
property to true . Additionally, the transport layer uses SSL to encrypt the channel
and bypass the certificate chain to validate trust. Hence, the appliance server must
be set up to trust the certificate's root authority. However, you can modify the
connection settings, by selecting Edit SQL Server connection properties on the
appliance. Learn more to understand what to choose.


2. In Azure Migrate - Servers > Azure Migrate: Discovery and assessment page,
select the icon that displays the count for Discovered servers.
Delete servers
After the discovery has been initiated, you can delete any of the added servers from the
appliance configuration manager by searching for the server name in the Add discovery
source table and by selecting Delete.
７ Note
If you choose to delete a server where discovery has been initiated, it will stop the
ongoing discovery and assessment which may impact the confidence rating of the
assessment that includes this server. Learn more
Next steps
Assess physical servers for migration to Azure VMs.
Tutorial: Discover AWS instances with Azure
Migrate: Discovery and assessment
As part of your migration journey to Azure, you discover your servers for assessment and migration.
This tutorial shows you how to discover Amazon Web Services (AWS) instances with the Azure
Migrate: Discovery and assessment tool, using a lightweight Azure Migrate appliance. You deploy
the appliance as a physical server, to continuously discover machine and performance metadata.

＂ Prepare AWS instances for discovery.
７ Note
Prerequisites
Requirement Details
Appliance You need an EC2 VM on which to run the Azure Migrate appliance. The machine should
have:

Running the appliance on a machine with Windows Server 2019 isn't supported.
- 16-GB RAM, 8 vCPUs, around 80 GB of disk storage, and an external virtual switch.
- A static or dynamic IP address, with internet access, either directly or through a proxy.
Windows Allow inbound connections on WinRM port 5985 (HTTP) for discovery of Windows
instances servers.
Linux instances Allow inbound connections on port 22 (TCP) for discovery of Linux servers.
The instances should use bash as the default shell, otherwise discovery will fail.

Setting Value
6. To register the appliance, your Azure account needs permissions to register Azure Active
Directory apps.
9. In case the 'App registrations' settings is set to 'No', request the tenant/global admin to assign
the required permission. Alternately, the tenant/global admin can assign the Application
Developer role to an account to allow the registration of Azure Active Directory App. Learn
more.
Prepare AWS instances

Set up an account that the appliance can use to access AWS instances.
For Windows servers, set up a local user account on all the Windows servers that you want to
include in the discovery. Add the user account to the following groups: - Remote
Management Users - Performance Monitor Users - Performance Log users.
For Linux servers, you need a root account on the Linux servers that you want to discover.
Refer to the instructions in the support matrix for an alternative.
Azure Migrate uses password authentication when discovering AWS instances. AWS instances
don't support password authentication by default. Before you can discover instance, you need
to enable password authentication.
For Windows servers, allow WinRM port 5985 (HTTP). This allows remote WMI calls.
For Linux servers:
1. Sign into each Linux machine.

2. Open the sshd_config file: vi /etc/ssh/sshd_config
3. In the file, locate the PasswordAuthentication line, and change the value to yes.
4. Save the file and close it. Restart the ssh service.
If you are using a root user to discover your Linux servers, ensure root sign in is allowed on
the servers.
1. Sign into each Linux machine

3. In the file, locate the PermitRootLogin line, and change the value to yes.
Set up a project
4. In Create project, select your Azure subscription and resource group. Create a resource group
if you don't have one.
6. Select Create.
７ Note
appliances to discover and assess more no of servers.Learn more
The Azure Migrate appliance is a lightweight appliance, used by Azure Migrate: Discovery and
assessment to do the following:
Discover on-premises servers.

Send metadata and performance data for discovered servers to Azure Migrate: Discovery and
assessment.
Learn more about the Azure Migrate appliance.
To set up the appliance you:

2. Download a zipped file with Azure Migrate installer script from the Azure portal.
3. Extract the contents from the zipped file. Launch the PowerShell console with administrative
privileges.
4. Execute the PowerShell script to launch the appliance web application.
5. Configure the appliance for the first time, and register it with the project using the project key.

2. In Discover servers > Are your servers virtualized?, select Physical or other (AWS, GCP, Xen,
etc.).
3. In 1:Generate project key, provide a name for the Azure Migrate appliance that you will set up
for discovery of physical or virtual servers. The name should be alphanumeric with 14
4. Select Generate key to start the creation of the required Azure resources. Do not close the
Discover servers page during the creation of resources.
6. Copy the key as you will need it to complete the registration of the appliance during its
configuration.

In 2: Download Azure Migrate appliance, select Download.
Verify security

Example usage for public cloud: C:\>CertUtil -HashFile
C:\Users\administrator\Desktop\AzureMigrateInstaller-Server-Public.zip SHA256
Example usage for government cloud: C:\>CertUtil -HashFile
C:\Users\administrator\Desktop\AzureMigrateInstaller-Server-USGov.zip SHA256
For the public cloud:
Scenario Download* Hash value
Physical Latest CE63463B3CE07D7500F0A34F9CAFF0AB939368E5DB320F9F05EE45A386A49CDC

(85 MB) version
Scenario Download* Hash value

(85 MB) version

The installer script does the following:
Installs agents and a web application for physical server discovery and assessment.
Install Windows roles, including Windows Activation Service, IIS, and PowerShell ISE.
Download and installs an IIS rewritable module.
Updates a registry key (HKLM) with persistent setting details for Azure Migrate.
Config Files: %Programdata%\Microsoft Azure\Config
Log Files: %Programdata%\Microsoft Azure\Logs
Run the script as follows:
1. Extract the zipped file to a folder on the server that will host the appliance. Make sure you
don't run the script on a machine on an existing Azure Migrate appliance.
3. Change the PowerShell directory to the folder where the contents have been extracted from
the downloaded zipped file.
4. Run the script named AzureMigrateInstaller.ps1 by running the following command:
PS C:\Users\administrator\Desktop\AzureMigrateInstaller-Server-Public>
PS C:\Users\Administrators\Desktop\AzureMigrateInstaller-Server-
USGov>.\AzureMigrateInstaller.ps1
The script will launch the appliance web application when it finishes successfully.
If you come across any issues, you can access the script logs at C:\ProgramData\Microsoft

Make sure that the appliance can connect to Azure URLs for public and government clouds.

1. Open a browser on any machine that can connect to the appliance, and open the URL of the

proxy:
port.
work properly.
these steps:
７ Note
appliance server.
７ Note
If you close the sign in tab accidentally without signing in, refresh the browser tab of
Login button.
details.

Now, connect from the appliance to the physical servers to be discovered, and start the discovery.
1. In Step 1: Provide credentials for discovery of Windows and Linux physical or virtual servers,
select Add credentials.
2. For Windows server, select the source type as Windows Server, specify a friendly name for
credentials, add the username and password. Select Save.
3. If you are using password-based authentication for Linux server, select the source type as
Linux Server (Password-based), specify a friendly name for credentials, add the username and
password. Select Save.
4. If you are using SSH key-based authentication for Linux server, you can select source type as
Linux Server (SSH key-based), specify a friendly name for credentials, add the username,
browse, and select the SSH private key file. Select Save.
Azure Migrate supports the SSH private key generated by ssh-keygen command using
RSA, DSA, ECDSA, and ed25519 algorithms.
Currently Azure Migrate does not support passphrase-based SSH key. Use an SSH key
without a passphrase.
Currently Azure Migrate does not support SSH private key file generated by PuTTY.
Azure Migrate supports OpenSSH format of the SSH private key file as shown below:
credentials. Multiple credentials are supported for physical servers discovery.
７ Note
By default, the credentials will be used to gather data about the installed applications,
roles, and features, and also to collect dependency data from Windows and Linux servers,
unless you disable the slider to not perform these features (as instructed in the last step).
6. In Step 2:Provide physical or virtual server details, select Add discovery source to specify the
server IP address/FQDN and the friendly name for credentials to connect to the server.
7. You can either Add single item at a time or Add multiple items in one go. There is also an
option to provide server details through Import CSV.
If you choose Add single item, you can choose the OS type, specify friendly name for
credentials, add server IP address/FQDN, and select Save.
If you choose Add multiple items, you can add multiple records at once by specifying
server IP address/FQDN with the friendly name for credentials in the text box. Verify**
the added records and select Save.
If you choose Import CSV (selected by default), you can download a CSV template file,
populate the file with the server IP address/FQDN and friendly name for credentials. You
then import the file into the appliance, verify the records in the file and select Save.
8. On selecting Save, appliance will try validating the connection to the servers added and show
the Validation status in the table against each server.
If validation fails for a server, review the error by selecting Validation failed in the Status
column of the table. Fix the issue, and validate again.
9. You can revalidate the connectivity to servers anytime before starting the discovery.
10. Before initiating discovery, you can choose to disable the slider to not perform software
inventory and agentless dependency analysis on the added servers. You can change this
option at any time.
11. To perform discovery of SQL Server instances and databases, you can add additional
credentials (Windows domain/non-domain, SQL authentication credentials) and the appliance
will attempt to automatically map the credentials to the SQL servers. If you add domain
credentials, the appliance will authenticate the credentials against Active Directory of the
domain to prevent any user accounts from locking out. To check validation of the domain
credentials, follow these steps:
In the configuration manager credentials table, see Validation status for domain credentials.
Only the domain credentials are validated.
If validation fails, you can select a Failed status to see the validation error. Fix the issue, and
then select Revalidate credentials to reattempt validation of the credentials.
Start discovery
Select Start discovery, to kick off discovery of the successfully validated servers. After the discovery
has been successfully initiated, you can check the discovery status against each server in the table.
How discovery works

It takes approximately 2 minutes to complete discovery of 100 servers and their metadata to
appear in the Azure portal.
Software inventory (discovery of installed applications) is automatically initiated when the
discovery of servers is finished.

2. In Servers, databases and web apps > Azure Migrate: Discovery and assessment page, select
the icon that displays the count for Discovered servers.
Next steps
Assess physical servers for migration to Azure VMs.
Additional resources
 Documentation
Questions about discovery and dependency analysis in Azure Migrate - Azure Migrate
Get answers to common questions about discovery and dependency analysis in Azure Migrate.
Questions about Business case in Azure Migrate - Azure Migrate

Get answers to common questions about Business case in Azure Migrate.
Discovered metadata - Azure Migrate

Provides details of the metadata discovered by Azure Migrate appliance.
Azure Migrate FAQ - Azure Migrate

Get answers to common questions about the Azure Migrate service.
Group servers for assessment with Azure Migrate - Azure Migrate

Describes how to group servers before you run an assessment with the Azure Migrate service.
Questions about assessments in Azure Migrate - Azure Migrate

Get answers to common questions about assessments in Azure Migrate.
Migrate VMware virtual machines to Azure with server-side encryption(SSE) and customer-
managed keys(CMK) using the Migration and modernization tool - Azure Migrate
Learn how to migrate VMware VMs to Azure with server-side encryption(SSE) and customer-managed keys(CMK)
using the Migration and modernization tool
Set up agentless dependency analysis in Azure Migrate - Azure Migrate

Set up agentless dependency analysis in Azure Migrate.
Show 5 more
Tutorial: Discover Google Cloud Platform
(GCP) instances with Azure Migrate:
Discovery and assessment
As part of your migration journey to Azure, you discover your servers for assessment and
migration.
This tutorial shows you how to discover Google Cloud Platform (GCP) instances with the Azure
Migrate: Discovery and assessment tool, using a lightweight Azure Migrate appliance. You deploy
the appliance on a server on GCP, to continuously discover machine and performance metadata.

＂ Prepare server on GCP for discovery.
７ Note
Tutorials show the quickest path for trying out a scenario and using default options.
Prerequisites
Requirement Details
Appliance You need a server on GCP on which to run the Azure Migrate appliance. The
machine should have:

Running the appliance on a machine with Windows Server 2019 isn't supported.
- 16-GB RAM, 8 vCPUs, around 80 GB of disk storage, and an external virtual switch.
- A static or dynamic IP address, with internet access, either directly or through a

proxy.
Windows server Allow inbound connections on WinRM port 5985 (HTTP) for discovery of Windows
instances servers.
Requirement Details
Linux server instances Allow inbound connections on port 22 (TCP) for discovery of Linux servers.


Setting Value
To register the appliance, your Azure account needs permissions to register Azure Active
Directory apps.
1. In the Azure portal, navigate to Azure Active Directory > Users > User Settings.
3. In case the 'App registrations' setting is set to 'No', request the tenant/global admin to
assign the required permission. Alternately, the tenant/global admin can assign the
Application Developer role to an account to allow the registration of Azure Active Directory
App. Learn more.
Prepare GCP instances

Set up an account that the appliance can use to access servers on GCP.
For Windows servers:

Set up a local user account on non-domain joined servers, and a domain account on
domain joined servers that you want to include in the discovery. Add the user account to
the following groups:
Remote Management Users
Performance Monitor Users
Performance Log users.
For Linux servers:
You need a root account on the Linux servers that you want to discover. If you aren't able
to provide a root account, refer to the instructions in the support matrix for an alternative.
Azure Migrate uses password authentication when discovering GCP instances. GCP
instances don't support password authentication by default. Before you can discover
instance, you need to enable password authentication.
1. Sign into each Linux machine.

3. In the file, locate the PasswordAuthentication line, and change the value to yes.
If you're using a root user to discover your Linux servers, ensure root login is allowed on
the servers.
1. Sign into each Linux machine

3. In the file, locate the PermitRootLogin line, and change the value to yes.
Set up a project
4. In Create project, select your Azure subscription and resource group. Create a resource
group if you don't have one.
6. Select Create.
７ Note
appliances to discover and assess more no of servers.Learn more.

The Azure Migrate appliance is a lightweight appliance, used by Azure Migrate: Discovery and
assessment to do the following:

Send metadata and performance data for discovered servers to Azure Migrate: Discovery and
assessment.
To set up the appliance, you:

3. Extract the contents from the zipped file. Launch the PowerShell console with administrative
privileges.
4. Execute the PowerShell script to launch the appliance web application.
5. Configure the appliance for the first time and register it with the project using the project
key.

2. In Discover servers > Are your servers virtualized?, select Physical or other (AWS, GCP, Xen,
etc.).
3. In 1:Generate project key, provide a name for the Azure Migrate appliance that you'll set up
for discovery of your GCP virtual servers. The name should be alphanumeric with 14
4. Click Generate key to start the creation of the required Azure resources. Don't close the
Discover servers page during the creation of resources.
6. Copy the key as you'll need it to complete the registration of the appliance during its
configuration.

In 2: Download Azure Migrate appliance, click Download.
Verify security
Check that the zipped file is secure before you deploy it.

Example usage for public cloud: C:\>CertUtil -HashFile
C:\Users\administrator\Desktop\AzureMigrateInstaller-Server-Public.zip SHA256
Example usage for government cloud: C:\>CertUtil -HashFile

C:\Users\administrator\Desktop\AzureMigrateInstaller-Server-USGov.zip SHA256
Scenario Download Hash value

(85 MB) version
Scenario Download Hash value

(85 MB) version

The installer script does the following:
Installs agents and a web application for GCP server discovery and assessment.
Install Windows roles, including Windows Activation Service, IIS, and PowerShell ISE.
Run the script as follows:
1. Extract the zipped file to a folder on the server that will host the appliance. Make sure you
don't run the script on a machine on an existing Azure Migrate appliance.
3. Change the PowerShell directory to the folder where the contents have been extracted from
the downloaded zipped file.
4. Run the script named AzureMigrateInstaller.ps1 by running the following command:
PS C:\Users\administrator\Desktop\AzureMigrateInstaller-Server-Public>
PS C:\Users\Administrators\Desktop\AzureMigrateInstaller-Server-
USGov>.\AzureMigrateInstaller.ps1
The script will launch the appliance web application when it finishes successfully.
If you come across any issues, you can access the script logs at C:\ProgramData\Microsoft

Make sure that the appliance can connect to Azure URLs for public and government clouds.

1. Open a browser on any machine that can connect to the appliance and open the URL of the
Alternately, you can open the app from the desktop by clicking the app shortcut.
proxy:
port.

work properly.
these steps:
７ Note
select View appliance services to see the status and versions of the services running on
the appliance server.
７ Note
If you close the sign in tab accidentally without logging in, refresh the browser tab of
Login button.
details.

Now, connect from the appliance to the GCP servers to be discovered, and start the discovery.
1. In Step 1: Provide credentials for discovery of Windows and Linux physical or virtual
servers, select Add credentials.
2. For Windows server, select the source type as Windows Server, specify a friendly name for
credentials, add the username and password. Select Save.
3. If you're using password-based authentication for Linux server, select the source type as
Linux Server (Password-based), specify a friendly name for credentials, add the username
and password. Select Save.
4. If you're using SSH key-based authentication for Linux server, you can select source type as
Linux Server (SSH key-based), specify a friendly name for credentials, add the username,
browse and select the SSH private key file. Select Save.
Azure Migrate supports the SSH private key generated by ssh-keygen command using
RSA, DSA, ECDSA, and ed25519 algorithms.
Currently Azure Migrate doesn't support passphrase-based SSH key. Use an SSH key
without a passphrase.
Currently Azure Migrate doesn't support SSH private key file generated by PuTTY.
Azure Migrate supports OpenSSH format of the SSH private key file as shown below:
credentials.
７ Note
By default, the credentials will be used to gather data about the installed applications,
roles, and features, and also to collect dependency data from Windows and Linux
servers, unless you disable the slider to not perform these features (as instructed in the
last step).
6. In Step 2:Provide physical or virtual server details, select Add discovery source to specify
the server IP address/FQDN and the friendly name for credentials to connect to the server.
7. You can either Add single item at a time or Add multiple items in one go. There's also an
option to provide server details through Import CSV.
If you choose Add single item, you can choose the OS type, specify friendly name for
credentials, add server IP address/FQDN and select Save.
If you choose Add multiple items, you can add multiple records at once by specifying
server IP address/FQDN with the friendly name for credentials in the text box. Verify**
the added records and select Save.
If you choose Import CSV (selected by default), you can download a CSV template file,
populate the file with the server IP address/FQDN and friendly name for credentials.
You then import the file into the appliance, verify the records in the file and select Save.
8. On clicking Save, the appliance will try validating the connection to the servers added and
show the Validation status in the table against each server.
If validation fails for a server, review the error by clicking on Validation failed in the
Status column of the table. Fix the issue, and validate again.
9. You can revalidate the connectivity to servers anytime before starting the discovery.
10. Before initiating discovery, you can choose to disable the slider to not perform software
inventory and agentless dependency analysis on the added servers. You can change this
option at any time.
11. To perform discovery of SQL Server instances and databases, you can add additional
credentials (Windows domain/non-domain, SQL authentication credentials) and the
appliance will attempt to automatically map the credentials to the SQL servers. If you add
domain credentials, the appliance will authenticate the credentials against Active Directory of
the domain to prevent any user accounts from locking out. To check validation of the domain
credentials, follow these steps:
In the configuration manager credentials table, see Validation status for domain credentials.
Only the domain credentials are validated.
If validation fails, you can select a Failed status to see the validation error. Fix the issue, and
then select Revalidate credentials to reattempt validation of the credentials.
Start discovery
Click Start discovery, to kick off discovery of the successfully validated servers. After the discovery
has been successfully initiated, you can check the discovery status against each server in the table.
How discovery works

It takes approximately 2 minutes to complete discovery of 100 servers and their metadata to
Software inventory (discovery of installed applications) is automatically initiated when the

discovery of servers is finished.

2. In Servers, databases and web apps > Azure Migrate: Discovery and assessment page, click
the icon that displays the count for Discovered servers.
Next steps
Assess GCP servers for migration to Azure VMs.
 Documentation
What's new in Azure Migrate - Azure Migrate

Learn about what's new and recent updates in the Azure Migrate service.
Customize assessments for Azure Migrate - Azure Migrate

Describes how to customize assessments created with Azure Migrate
Discover AWS instances with Azure Migrate Discovery and assessment - Azure Migrate
Learn how to discover AWS instances with Azure Migrate Discovery and assessment.
Assessment best practices in Azure Migrate Discovery and assessment tool - Azure Migrate
Tips for creating assessments with Azure Migrate Discovery and assessment tool.


Discover SQL Server instances in an existing Azure Migrate project - Azure Migrate
Learn how to discover SQL Server instances in an existing Azure Migrate project.
Create an Azure VM assessment with Azure Migrate Discovery and assessment tool - Azure
Migrate
Describes how to create an Azure VM assessment with the Azure Migrate Discovery and assessment tool
Show 5 more
Build a business case (preview)
Article • 04/28/2023
This article describes how to build a Business case for on-premises servers and
workloads in your datacenter with Azure Migrate: Discovery and assessment tool.
Azure Migrate helps you to plan and execute migration and modernization projects to
Azure. Azure Migrate provides a centralized hub to track discovery, assessment, and
migration of on-premises infrastructure, applications, and data to Azure. The hub
provides Azure tools for assessment and migration, and third-party independent
software vendor (ISV) offerings.
Prerequisites
Make sure you've created an Azure Migrate project. You can also reuse an existing
project to use this capability.
Once you've created a project, the Azure Migrate: Discovery and assessment tool is
automatically added to the project.
Before you build the Business case, you need to first discover your IT estate. You
can choose one of the two discovery sources based on your use case:
Discovery Details Migration strategies

Source that can be used to
build a business case
Use more You need to set up an Azure Migrate appliance for Azure recommended
accurate VMware or Hyper-V or Physical/Bare-metal or other to minimize cost,
data clouds. The appliance discovers servers, SQL Server Migrate to all IaaS
insights instance and databases, and ASP.NET webapps and (Infrastructure as a
collected sends metadata and performance (resource Service), Modernize
via Azure utilization) data to Azure Migrate. Learn more. to PaaS (Platform as a
Migrate Service)
appliance
Build a You need to provide the server inventory in a .CSV file Migrate to all IaaS
quick and import in Azure Migrate to get a quick business (Infrastructure as a
business case based on the provided inputs. You don't need to Service)
case using set up the Azure Migrate appliance to discover
the servers for this option.
servers
imported
via a .csv
file
Business case overview

The Business case capability helps you build a business proposal to understand how
Azure can bring the most value to your business. It highlights:

Resource utilization based insights to identify servers and workloads that are ideal
for cloud.
Quick wins for migration and modernization including end of support Windows OS
and SQL versions.
Other key features:
Helps remove guess work in your cost planning process and adds data insights
driven calculations.
It can be generated in just a few clicks after you have performed discovery using
the Azure Migrate appliance.
The feature is automatically enabled for existing Azure Migrate projects.
There are three types of migration strategies that you can choose while building your
Business case:

Strategy
Strategy
to minimize recommendation in Azure across optimization strategy - minimize cost
cost Azure IaaS and Azure PaaS targets. from Azure SQL assessment.
For web apps, sizing and cost comes

from Azure App Service assessment is
picked.
For general servers, sizing and cost

comes from Azure VM assessment.
as a Service)
PaaS recommendation that means, the from the Instance to Azure SQL MI report.
(Platform as a logic identifies workloads best fit for
Service) PaaS targets. For web apps, sizing and cost comes
from Azure App Service assessment.
General servers are recommended
with a quick lift and shift For general servers, sizing and cost
recommendation to Azure IaaS. comes from Azure VM assessment.
７ Note

Build a business case

1. On the Get started page > Servers, databases and web apps, select Discover,
assess and migrate.

2. In Azure Migrate: Discovery and assessment, select Build business case.
We recommend that you wait at least a day after starting discovery before you
build a Business case so that enough performance/resource utilization data points
are collected. Also, review the Notifications/Resolve issues blades on the Azure
Migrate hub to identify any discovery related issues prior to Business case
computation. It ensures that the IT estate in your datacenter is represented more
accurately and the Business case recommendations are more valuable.
3. In Business case name, specify a name for the Business case. Make sure the
Business case name is unique within a project, else the previous Business case with
the same name gets recomputed.
4. In Target location, specify the Azure region to which you want to migrate.
Azure SKU size and cost recommendations are based on the location that you
specify.
5. In Discovery source, specify the discovery source on which you wish to create the
business case. The options to build the business case using data discovered via the
appliance or imported via a .csv file is present based on the type of discovered
servers present in your project. The discovery source will be defaulted to the
option chosen by you while building the business case and you won't be able to
update this field later.
6. In Migration strategy, specify the migration strategy for your Business case:
With the default Azure recommended approach to minimize cost, you can get
the most cost-efficient and compatible target recommendation in Azure
across Azure IaaS and Azure PaaS targets.
With Migrate to all IaaS (Infrastructure as a Service), you can get a quick lift
and shift recommendation to Azure IaaS.
With Modernize to PaaS (Platform as a Service), you can get cost effective
recommendations for Azure IaaS and more PaaS preferred targets in Azure
PaaS.
7. In Savings options, specify the savings options combination that you want to be
considered while optimizing your Azure costs and maximize savings. Based on the
availability of the savings option in the chosen region and the targets, the business
case recommends the appropriate savings options to maximize your savings on
Azure.
Choose 'Reserved Instance', if your datacenter comprises most consistently

running resources.
Choose 'Reserved Instance + Azure Savings Plan', if you want additional
flexibility and automated cost optimization for workloads applicable for
Azure Savings Plan (Compute targets including Azure VM and Azure App
Service).
8. In Discount (%) on Pay as you go, add any subscription-specific discounts you
receive on top of the Azure offer. The default setting is 0%. The discount isn't
applicable on top of reserved instance savings option.
9. Currency is defaulted to USD and can't be edited.
10. Review the chosen inputs, and select Build business case.
11. You're directed to the newly created Business case with a banner that says that
your Business case is computing. The computation might take some time,
depending on the number of servers and workloads in the project. You can come
back to the Business case page after ~30 minutes and select Refresh.
Next steps
Tutorial: Assess VMware VMs for
migration to Azure VMs
As part of your migration journey to Azure, you assess your on-premises workloads to
measure cloud readiness, identify risks, and estimate costs and complexity.
This article shows you how to assess discovered servers from your VMware environment
in preparation for migration to Azure VMs, using the Azure Migrate: Discovery and
assessment tool.
Run an assessment based on server metadata and configuration information.

Run an assessment based on performance data.
７ Note
Tutorials show the quickest path for trying out a scenario, and use default options
where possible.
Prerequisites
Before you follow this tutorial to assess your servers for migration to Azure VMs, make
sure you've discovered the servers you want to assess:
To discover servers using the Azure Migrate appliance, follow this tutorial.
To discover servers using an imported CSV file, follow this tutorial.
Decide which assessment to run

Decide whether you want to run an assessment using sizing criteria based on server
configuration data/metadata that's collected as-is on-premises, or on dynamic
performance data.
Assessment Details Recommendation

As-is on- Assess based on server Recommended Azure VM size is based on the on-
premises configuration premises VM size.
data/metadata.
The recommended Azure disk type is based on what
you select in the storage type setting in the
assessment.
Performance- Assess based on Recommended Azure VM size is based on CPU and

based collected dynamic memory utilization data.
performance data.
The recommended disk type is based on the IOPS
and throughput of the on-premises disks.
Run an assessment
Run an assessment as follows:
1. On the Get started page > Servers, databases and web apps, select Assess and
migrate servers.
2. In Azure Migrate: Discovery and assessment, select Assess and select Azure VM.
3. In Assess servers > Assessment type, select Azure VM.
4. In Discovery source:
If you discovered servers using the appliance, select Servers discovered from
Azure Migrate appliance.
If you discovered servers using an imported CSV file, select Imported servers.
5. Select Edit to review the assessment properties.
6. In Assessment settings, set the necessary values or retain the default values:
Section Setting Details

Target and Target location The Azure region to which you want to migrate. Azure SQL
pricing configuration and cost recommendations are based on the
settings location that you specify.
Target and Environment The environment for the SQL deployments to apply pricing
pricing type applicable to Production or Dev/Test.
settings
Target and Offer/Licensing The Azure offer if you're enrolled. Currently, the field is
pricing program Pay-as-you-go by default, which gives you retail Azure
settings prices.
You can avail additional discount by applying reserved

capacity and Azure Hybrid Benefit on top of Pay-as-you-go
offer.
You can apply Azure Hybrid Benefit on top of Pay-as-you-
go offer and Dev/Test environment. The assessment
doesn't support applying Reserved Capacity on top of Pay-
as-you-go offer and Dev/Test environment.
If the offer is set to Pay-as-you-go and Reserved capacity is
set to No reserved instances, the monthly cost estimates
are calculated by multiplying the number of hours chosen
in the VM uptime field with the hourly price of the
recommended SKU.
Target and Savings Specify the reserved capacity savings option that you want
pricing options - Azure the assessment to consider, to help optimize your Azure
settings SQL MI and DB compute cost.
(PaaS)
Azure reservations (1 year or 3 year reserved) are a good
option for the most consistently running resources.
When you select 'None', the Azure compute cost is based

on the Pay as you go rate or based on actual usage.
You need to select pay-as-you-go in offer/licensing

program to be able to use Reserved Instances. When you
select any savings option other than 'None', the 'Discount
(%)' and "VM uptime" settings aren't applicable. The
monthly cost estimates are calculated by multiplying 744
hours with the hourly price of the recommended SKU.
Target and Savings Specify the savings option that you want the assessment to
pricing options - SQL consider, to help optimize your Azure compute cost.
settings Server on
Azure VM Azure reservations (1 year or 3 year reserved) are a good
(IaaS) option for the most consistently running resources.
Azure Savings Plan (1 year or 3 year savings plan) provide

additional flexibility and automated cost optimization.
Ideally post migration, you could use Azure reservation
and savings plan at the same time (reservation is
consumed first), but in the Azure Migrate assessments, you
can only see cost estimates of 1 savings option at a time.


program to be able to use Reserved Instances or Azure
Savings Plan. When you select any savings option other
than 'None', the 'Discount (%)' and "VM uptime" settings
aren't applicable. The monthly cost estimates are
calculated by multiplying 744 hours in the VM uptime field
with the hourly price of the recommended SKU.
Target and Currency The billing currency for your account.

pricing
settings
Target and Discount (%) Any subscription-specific discounts you receive on top of
pricing the Azure offer. The default setting is 0%.
settings
Target and VM uptime Specify the duration (days per month/hour per day) that
pricing servers/VMs run. This is useful for computing cost
settings estimates for SQL Server on Azure VM where you're aware
that Azure VMs might not run continuously.
Cost estimates for servers where recommended target is
SQL Server on Azure VM are based on the duration
specified. Default is 31 days per month/24 hours per day.
Target and Azure Hybrid Specify whether you already have a Windows Server
pricing Benefit and/or SQL Server license. Azure Hybrid Benefit is a
settings licensing benefit that helps you to significantly reduce the
costs of running your workloads in the cloud. It works by
letting you use your on-premises Software Assurance-
enabled Windows Server and SQL Server licenses on Azure.
For example, if you have a SQL Server license and they're
covered with active Software Assurance of SQL Server
Subscriptions, you can apply for the Azure Hybrid Benefit
when you bring licenses to Azure.
Assessment Sizing criteria Set to Performance-based by default, which means Azure

criteria Migrate collects performance metrics pertaining to SQL
instances and the databases managed by it to recommend
an optimal-sized SQL Server on Azure VM and/or Azure
SQL Database and/or Azure SQL Managed Instance
configuration.
Assessment Performance Indicate the data duration on which you want to base the
criteria history assessment. (Default is one day)
Assessment Percentile Indicate the percentile value you want to use for the
criteria utilization performance sample. (Default is 95th percentile)
Assessment Comfort factor Indicate the buffer you want to use during assessment.
criteria This accounts for issues like seasonal usage, short
performance history, and likely increases in future usage.
For example, consider a comfort factor of 2 for effective
utilization of 2 Cores. In this case, the assessment
considers the effective cores as 4 cores. Similarly, for the
same comfort factor and an effective utilization of 8 GB
memory, the assessment considers effective memory as 16
GB.
Assessment Optimization Specify the preference for the recommended assessment

criteria preference report. Selecting Minimize cost would result in the
Recommended assessment report recommending those
deployment types that have least migration issues and are
most cost effective, whereas selecting Modernize to PaaS
would result in Recommended assessment report
recommending PaaS(Azure SQL MI or DB) deployment
types over IaaS Azure(VMs), wherever the SQL Server
instance is ready for migration to PaaS irrespective of cost.
Azure SQL Service Tier Choose the most appropriate service tier option to
Managed accommodate your business needs for migration to Azure
Instance SQL Managed Instance:
sizing
Select Recommended if you want Azure Migrate to
recommend the best suited service tier for your servers.
This can be General purpose or Business critical.
Select General Purpose if you want an Azure SQL

configuration designed for budget-oriented workloads.
Select Business Critical if you want an Azure SQL

configuration designed for low-latency workloads with
high resiliency to failures and fast failovers.
Azure SQL Instance type Defaulted to Single instance.

Managed
Instance
sizing
Azure SQL Pricing Tier Defaulted to Standard.

Managed
Instance
sizing
SQL Server VM series Specify the Azure VM series you want to consider for SQL
on Azure Server on Azure VM sizing. Based on the configuration and
VM sizing performance requirements of your SQL Server or SQL
Server instance, the assessment recommends a VM size
from the selected list of VM series.
You can edit settings as needed. For example, if you don't
want to include D-series VM, you can exclude D-series
from this list.
As Azure SQL assessments intend to give the best
performance for your SQL workloads, the VM series list
only has VMs that are optimized for running your SQL
Server on Azure Virtual Machines (VMs). Learn more.
SQL Server Storage Type Defaulted to Recommended, which means the assessment
on Azure recommends the best suited Azure Managed Disk based
VM sizing on the chosen environment type, on-premises disk size,
IOPS and throughput.
Database accommodate your business needs for migration to Azure
sizing SQL Database:



Azure SQL Instance type Defaulted to Single database.

Database
sizing
Azure SQL Purchase Defaulted to vCore.

Database model
sizing
Azure SQL Compute tier Defaulted to Provisioned.

Database
sizing
High Disaster Defaulted to the cross-region replication pair of the Target

availability recovery Location. In the unlikely event that the chosen Target
and region Location doesn't yet have such a pair, the specified Target
disaster Location itself is chosen as the default disaster recovery
recovery region.
properties
High Multi-subnet Defaulted to Disaster recovery.

availability intent
and Select Disaster recovery if you want asynchronous data
disaster replication where some replication delays are tolerable.
recovery This allows higher durability using geo-redundancy. In the
properties event of failover, data that hasn't yet been replicated may
be lost.
Select High availability if you desire the data replication to

be synchronous and no data loss due to replication delay
is allowable. This setting allows assessment to leverage
built-in high availability options in Azure SQL Databases
and Azure SQL Managed Instances, and availability zones
and zone-redundancy in Azure Virtual Machines to provide
higher availability. In the event of failover, no data is lost.
High Internet Access Defaulted to Available.

availability
and Select Available if you allow outbound internet access
disaster from Azure VMs. This allows the use of Cloud Witness
recovery which is the recommended approach for Windows Server
properties Failover Clusters in Azure Virtual Machines.
Select Not available if the Azure VMs have no outbound

internet access. This requires the use of a Shared Disk as a
witness for Windows Server Failover Clusters in Azure
Virtual Machines.
High Async commit Defaulted to Disaster recovery.

availability mode intent
and Select Disaster recovery if you're using asynchronous
disaster commit availability mode to enable higher durability for
recovery the data without affecting performance. In the event of
properties failover, data that hasn't yet been replicated may be lost.
Select High availability if you're using asynchronous

commit data availability mode to improve availability and
scale out read traffic. This setting allows assessment to
leverage built-in high availability features in Azure SQL
Databases, Azure SQL Managed Instances, and Azure
Virtual Machines to provide higher availability and scale
out.
7. Select Save if you make changes.
8. In Assess Servers, select Next.

9. In Select servers to assess > Assessment name, specify a name for the
assessment.
10. In Select or create a group, select Create New and specify a group name.
11. Select the appliance, and select the VMs you want to add to the group. Then select
Next.
12. In Review + create assessment, review the assessment details, and select Create
Assessment to create the group and run the assessment.
13. After the assessment is created, view it in Servers, databases and web apps >
Azure Migrate: Discovery and assessment > Assessments.
14. Select Export assessment, to download it as an Excel file.
７ Note
For performance-based assessments, we recommend that you wait at least a

day after starting discovery before you create an assessment. This provides
time to collect performance data with higher confidence. Ideally, after you
start discovery, wait for the performance duration you specify
(day/week/month) for a high-confidence rating.
Review an assessment
An assessment describes:
Azure readiness: Whether VMs are suitable for migration to Azure.

Monthly cost estimation: The estimated monthly compute and storage costs for
running the VMs in Azure.
Monthly storage cost estimation: Estimated costs for disk storage after migration.
To view an assessment:
1. In Servers, databases and web apps > Azure Migrate: Discovery and assessment,
select the number next to Azure VM assessment.
2. In Assessments, select an assessment to open it. As an example (estimations and

costs for example only):
3. Review the assessment summary. You can also edit the assessment properties, or
recalculate the assessment.
Review readiness
1. Select Azure readiness.
2. In Azure readiness, review the VM status:
Ready for Azure: Used when Azure Migrate recommends a VM size and cost
estimates, for VMs in the assessment.
Ready with conditions: Shows issues and suggested remediation.
Not ready for Azure: Shows issues and suggested remediation.
Readiness unknown: Used when Azure Migrate can't assess readiness,
because of data availability issues.
3. Select an Azure readiness status. You can view VM readiness details. You can also
drill down to see VM details, including compute, storage, and network settings.
Review cost estimates

The assessment summary shows the estimated compute and storage cost of running
VMs in Azure.
1. Review the monthly total costs. Costs are aggregated for all VMs in the assessed
group.
Cost estimates are based on the size recommendations for a server, its disks,
and its properties.
Estimated monthly costs for compute and storage are shown.
The cost estimation is for running the on-premises VMs on Azure VMs. The
estimation doesn't consider PaaS or SaaS costs.
2. Review monthly storage costs. The view shows the aggregated storage costs for
the assessed group, split over different types of storage disks.
3. You can drill down to see cost details for specific VMs.
Review confidence rating

Azure Migrate assigns a confidence rating to performance-based assessments. Rating is
from one star (lowest) to five stars (highest).
The confidence rating helps you estimate the reliability of size recommendations in the
assessment. The rating is based on the availability of data points needed to compute the
assessment.
７ Note
Confidence ratings aren't assigned if you create an assessment based on a CSV file.
Confidence ratings are as follows.

Data point availability Confidence rating
0%-20% 1 star
21%-40% 2 stars
41%-60% 3 stars
61%-80% 4 stars
81%-100% 5 stars
Learn more about confidence ratings.
Next steps
Find server dependencies using dependency mapping.
Set up agentless or agent-based dependency mapping.
Tutorial: Assess SQL instances for
migration to Azure SQL
measure cloud readiness, identify risks, and estimate costs and complexity. This article
shows you how to assess discovered SQL Server instances and databases in preparation
for migration to Azure SQL, using the Azure Migrate: Discovery and assessment tool.
＂ Run an assessment based on configuration and performance data.

＂ Review an Azure SQL assessment.
７ Note
where possible.
Prerequisites
Before you follow this tutorial to assess your SQL Server instances for migration to
Azure SQL, make sure you've discovered the SQL instances you want to assess
using the Azure Migrate appliance, follow this tutorial.
If you want to try out this feature in an existing project, ensure that you have
Run an assessment
1. On the Overview page > Servers, databases and web apps, select Assess and
migrate servers.

2. In Azure Migrate: Discovery and assessment, select Assess and choose the
assessment type as Azure SQL.
3. In Assess servers, the assessment type is pre-selected as Azure SQL and the
discovery source is defaulted to Servers discovered from Azure Migrate
appliance.
4. Select Edit to review the assessment settings.
settings
settings prices.

offer.
recommended SKU.
pricing options - Azure the assessment to consider to help optimize your Azure
(PaaS)


pricing options - SQL consider to help optimize your Azure compute cost.
settings Server on




pricing
settings
settings

configuration.

sizing



Managed
Instance
sizing

Managed
Instance
sizing
from this list.




Database
sizing

Database model
sizing

Database
sizing

recovery region.
properties

availability intent
be lost.


availability

Virtual Machines.


out.
6. Select Save if you made changes.

8. In Select servers to assess > Assessment name > specify a name for the
assessment.
9. In Select or create a group > select Create New and specify a group name.
10. Select the appliance and select the servers you want to add to the group and
select Next.
12. After the assessment is created, go to Servers, databases and web apps > Azure
Migrate: Discovery and assessment, select the number next to Azure SQL
assessment. If you do not see the number populated, select Refresh to get the
latest updates.
13. Select the assessment name, which you wish to view.
７ Note
As Azure SQL assessments are performance-based assessments, we recommend

that you wait at least a day after starting discovery before you create an
assessment. This provides time to collect performance data with higher confidence.
If your discovery is still in progress, the readiness of your SQL instances will be
marked as Unknown. Ideally, after you start discovery, wait for the performance
duration you specify (day/week/month) to create or recalculate the assessment
for a high-confidence rating.
select the number next to Azure SQL assessment.
2. Select the assessment name, which you wish to view. As an example(estimations

and costs, for example, only):

3. Review the assessment summary. You can also edit the assessment settings or
Discovered entities
This indicates the number of SQL servers, instances, and databases that were assessed in
this assessment.
SQL Server migration scenarios

This indicates the different migration strategies that you can consider for your SQL
deployments. You can review the readiness for target deployment types and the cost
estimates for SQL Servers/Instances/Databases that are marked ready or ready with
conditions:
1. Recommended deployment: This is a strategy where an Azure SQL deployment

type that is the most compatible with your SQL instance. It is the most cost-
effective and is recommended. Migrating to a Microsoft-recommended target
reduces your overall migration effort. If your instance is ready for SQL Server on
Azure VM, Azure SQL Managed Instance and Azure SQL Database, the target
deployment type, which has the least migration readiness issues and is the most
cost-effective is recommended. You can see the SQL Server instance readiness for
different recommended deployment targets and monthly cost estimates for SQL
instances marked Ready and Ready with conditions.
You can go to the Readiness report to:

Review the recommended Azure SQL configurations for migrating to SQL
Server on Azure VM and/or Azure SQL databases and/or Azure SQL
Managed Instances.
Understand details around migration issues/warnings that you can
remediate before migration to the different Azure SQL targets. Learn
More.
You can go to the cost estimates report to review cost of each of the SQL
instance after migrating to the recommended deployment target.
７ Note
In the recommended deployment strategy, migrating instances to SQL Server

on Azure VM is the recommended strategy for migrating SQL Server
instances. When the SQL Server credentials are not available, the Azure SQL
assessment provides right-sized lift-and-shift, that is, Server to SQL Server on
Azure VM recommendations.
2. Migrate all instances to Azure SQL MI: In this strategy, you can see the readiness
and cost estimates for migrating all SQL Server instances to Azure SQL Managed
Instance.
3. Migrate all instances to SQL Server on Azure VM: In this strategy, you can see the
readiness and cost estimates for migrating all SQL Server instances to SQL Server
on Azure VM.
4. Migrate all servers to SQL Server on Azure VM: In this strategy, you can see how
you can rehost the servers running SQL Server to SQL Server on Azure VM and
review the readiness and cost estimates. Even when SQL Server credentials are not
available, this report will provide right-sized lift-and-shift, that is, "Server to SQL
Server on Azure VM" recommendations. The readiness and sizing logic is similar to
Azure VM assessment type.
5. Migrate all SQL databases to Azure SQL Database In this strategy, you can see
how you can migrate individual databases to Azure SQL Database and review the
readiness and cost estimates.
Review readiness
You can review readiness reports for different migration strategies:
1. Select the Readiness report for any of the migration strategies.


2. Review the readiness columns in the respective reports:
Migration strategy Readiness Columns (Respective deployment target)
Recommended MI readiness (Azure SQL MI), VM readiness (SQL Server on Azure

VM), DB readiness (Azure SQL DB).
Instances to Azure SQL MI readiness (Azure SQL Managed Instance)

MI
Instances to SQL Server VM readiness (SQL Server on Azure VM).

on Azure VM
Servers to SQL Server Azure VM readiness (SQL Server on Azure VM).

on Azure VM
Databases to Azure DB readiness (Azure SQL Database)

SQL DB
3. Review the readiness for the assessed SQL instances/SQL Servers/Databases:
Ready: The instance/server is ready to be migrated to SQL Server on Azure

VM/Azure SQL MI/Azure SQL DB without any migration issues or warnings.
Ready: The instance is ready to be migrated to Azure VM/Azure SQL
MI/Azure SQL DB without any migration issues but has some migration
warnings that you need to review. You can select the hyperlink to review
the migration warnings and the recommended remediation guidance.
Ready with conditions: The instance/server has one or more migration issues
for migrating to Azure VM/Azure SQL MI/Azure SQL DB. You can select on
the hyperlink and review the migration issues and the recommended
remediation guidance.
Not ready: The assessment could not find a SQL Server on Azure VM/Azure
SQL MI/Azure SQL DB configuration meeting the desired configuration and
performance characteristics. Select the hyperlink to review the
recommendation to make the instance/server ready for the desired target
deployment type.
Unknown: Azure Migrate can't assess readiness, because the discovery is in
progress or there are issues during discovery that need to be fixed from the
notifications blade. If the issue persists, contact Microsoft support .
4. Select the instance name and drill-down to see the number of user databases,
instance details including instance properties, compute (scoped to instance) and
source database storage details.
5. Click the number of user databases to review the list of databases and their details.
6. Click review details in the Migration issues column to review the migration issues
and warnings for a particular target deployment type.

The assessment summary shows the estimated monthly compute and storage costs for
Azure SQL configurations corresponding to the recommended SQL Server on Azure VM
and/or Azure SQL Managed Instances and/or Azure SQL Database deployment type.
1. Review the monthly total costs. Costs are aggregated for all SQL instances in the
assessed group.
Cost estimates are based on the recommended Azure SQL configuration for
an instance/server/database.
Estimated total(compute and storage) monthly costs are displayed. As an

example:

The compute and storage costs are split in the individual cost estimates
reports and at instance/server/database level.
2. You can drill down at an instance level to see Azure SQL configuration and cost
estimates at an instance level.
3. You can also drill down to the database list to review the Azure SQL configuration
and cost estimates per database when an Azure SQL Database configuration is
recommended.

Azure Migrate assigns a confidence rating to all Azure SQL assessments based on the
availability of the performance/utilization data points needed to compute the
assessment for all the assessed SQL instances and databases. Rating is from one star
(lowest) to five stars (highest). The confidence rating helps you estimate the reliability of
size recommendations in the assessment. Confidence ratings are as follows:
0%-20% 1 star
21%-40% 2 stars
41%-60% 3 stars
61%-80% 4 stars
81%-100% 5 stars

Next steps
Learn more about how Azure SQL assessments are calculated.
Start migrating SQL instances and databases using Azure Database Migration
Service.
Tutorial: Assess ASP.NET web apps for
migration to Azure App Service
shows you how to assess discovered ASP.NET web apps running on IIS web servers in
preparation for migration to Azure App Service, using the Azure Migrate: Discovery and
assessment tool.
＂ Run an assessment based on web apps configuration data.

＂ Review an Azure App Service assessment
７ Note
where possible.
Prerequisites
Before you follow this tutorial to assess your web apps for migration to Azure App
Service, make sure you've discovered the web apps you want to assess using the
Azure Migrate appliance, follow this tutorial
Run an assessment
1. On the Overview page > Servers, databases and web apps, select Discover, assess
and migrate.
2. On Azure Migrate: Discovery and assessment, select Assess and choose the
assessment type as Azure App Service.
3. In Create assessment, you will be able to see the assessment type pre-selected as
Azure App Service and the discovery source defaulted to Servers discovered from

5. Here's what's included in Azure App Service assessment properties:
Property Details
Target The Azure region to which you want to migrate. Azure App Service
location configuration and cost recommendations are based on the location that you
specify.
Isolation Select yes if you want your web apps to run in a private and dedicated
required environment in an Azure datacenter using Dv2-series VMs with faster
processors, SSD storage, and double the memory to core ratio compared to
Standard plans.
In Savings options (compute), specify the savings option that you want the
assessment to consider to help optimize your Azure compute cost.
Azure reservations (1 year or 3 year reserved) are a good option for the
most consistently running resources.
Azure Savings Plan (1 year or 3 year savings plan) provide additional
flexibility and automated cost optimization. Ideally post migration, you
could use Azure reservation and savings plan at the same time (reservation
will be consumed first), but in the Azure Migrate assessments, you can
only see cost estimates of 1 savings option at a time.
When you select 'None', the Azure compute cost is based on the Pay as
you go rate or based on actual usage.
You need to select pay-as-you-go in offer/licensing program to be able to
use Reserved Instances or Azure Savings Plan. When you select any
savings option other than 'None', the 'Discount (%)' setting is not
applicable. Offer | The Azure offer in which you're enrolled. The
assessment estimates the cost for that offer. Currency | The billing
currency for your account. Discount (%) | Any subscription-specific
discounts you receive on top of the Azure offer. The default setting is 0%.
EA subscription | Specifies that an Enterprise Agreement (EA) subscription
is used for cost estimation. Takes into account the discount applicable to
the subscription.
Leave the settings for reserved instances, and discount (%) properties with
their default settings.
6. In Create assessment, select Next.
assessment.
9. Select the appliance, and select the servers that you want to add to the group.
Select Next.
Migrate: Discovery and assessment. Refresh the tile data by selecting the Refresh
option on top of the tile. Wait for the data to refresh.
12. Select the number next to Azure App Service assessment.
1. Servers, databases and web apps > Azure Migrate: Discovery and assessment,
select the number next to the Azure App Service assessment.
3. Review the assessment summary. You can also edit the assessment properties or
Azure App Service readiness
This indicates the distribution of the assessed web apps. You can drill down to
understand the details around migration issues/warnings that you can remediate before
migration to Azure App Service. Learn More. You can also view the recommended App
Service SKU and plan for migrating to Azure App Service.
Azure App Service cost details
An App Service plan carries a charge on the compute resources it uses.
Review readiness
1. Select Azure App Service readiness.
2. Review Azure App Service readiness column in table, for the assessed web apps:
a. If there are no compatibility issues found, the readiness is marked as Ready for
the target deployment type.
b. If there are non-critical compatibility issues, such as degraded or unsupported
features that do not block the migration to a specific target deployment type,
the readiness is marked as Ready with conditions (hyperlinked) with warning
details and recommended remediation guidance.
c. If there are any compatibility issues that may block the migration to a specific
target deployment type, the readiness is marked as Not ready with issue details
and recommended remediation guidance.
d. If the discovery is still in progress or there are any discovery issues for a web
app, the readiness is marked as Unknown as the assessment could not compute
the readiness for that web app.
3. Review the recommended SKU for the web apps, which is determined as per the
matrix below:
Isolation required Reserved instance App Service plan/ SKU
Yes Yes I1
Yes No I1
No Yes P1v3
No No P1v2
Azure App Service readiness Determine App Service SKU Determine Cost estimates
Ready Yes Yes
Ready with conditions Yes Yes
Not ready No No
Unknown No No
4. Select the App Service plan link in the Azure App Service readiness table to see the
App Service plan details such as compute resources and other web apps that are
part of the same plan.

The assessment summary shows the estimated monthly costs for hosting you web apps
in App Service. In App Service, you pay charges per App Service plan and not per web
app. One or more apps can be configured to run on the same computing resources (or
in the same App Service plan). The apps that you add into this App Service plan run on
the compute resources defined by your App Service plan. To optimize cost, Azure
Migrate assessment allocates multiple web apps to each recommended App Service
plan. The number of web apps allocated to each plan instance is shown below.
App Service plan Web apps per App Service plan
I1 8
P1v2 8
P1v3 16
Next steps
Learn how to perform at-scale agentless migration of ASP.NET web apps to Azure
App Service.
Learn more about how Azure App Service assessments are calculated.
Tutorial: Assess VMware servers for
migration to AVS
This article shows you how to assess discovered VMware virtual machines/servers for
migration to Azure VMware Solution (AVS), using the Azure Migrate. AVS is a managed
service that allows you to run the VMware platform in Azure.
In this tutorial, you'll learn how to:

７ Note
Tutorials show the quickest path for trying out a scenario and using default options
where possible.
Prerequisites
Before you follow this tutorial to assess your servers for migration to AVS, make sure
you've discovered the servers you want to assess:

performance data.

As-is on- Assess based Recommended node size in AVS is based on the on-premises
premises on server VM/server size, along with the settings you specify in the
configuration assessment for the node type, storage type, and failure-to-
data/metadata. tolerate setting.
Performance- Assess based Recommended node size in AVS is based on CPU and memory
based on collected utilization data, along with the settings you specify in the
dynamic assessment for the node type, storage type, and failure-to-
performance tolerate setting.
data.
７ Note
Azure VMware Solution (AVS) assessment can be created for VMware VMs/servers
only.
Run an assessment
1. In Servers, databases and web apps > Azure Migrate: Discovery and assessment.
2. In Azure Migrate: Discovery and assessment, select Assess.
3. In Assess servers > Assessment type, select Azure VMware Solution (AVS).

settings
settings prices.

offer.
recommended SKU.
(PaaS)


settings Server on




pricing
settings
settings
Assessment Sizing criteria Set to be Performance-based by default, which means

criteria Azure Migrate collects performance metrics pertaining to
SQL instances and the databases managed by it to
recommend an optimal-sized SQL Server on Azure VM
and/or Azure SQL Database and/or Azure SQL Managed
Instance configuration.
GB.

sizing



Managed
Instance
sizing

Managed
Instance
sizing
from this list.




Database
sizing

Database model
sizing

Database
sizing

recovery region.
properties

availability intent
be lost.


availability

Virtual Machines.


out.

assessment.
11. Select the appliance and select the servers that you want to add to the group. Then
select Next.
７ Note

An AVS assessment describes:
Azure VMware Solution (AVS) readiness: Whether the on-premises servers are
suitable for migration to Azure VMware Solution (AVS).
Number of Azure VMware Solution nodes: Estimated number of Azure VMware
Solution nodes required to run the servers.
Utilization across AVS nodes: Projected CPU, memory, and storage utilization
across all nodes.
Utilization includes upfront factoring in the cluster management overheads such
as the vCenter Server, NSX Manager (large), NSX Edge, if HCX is deployed also
the HCX Manager and IX appliance consuming ~ 44vCPU (11 CPU), 75 GB of
RAM and 722 GB of storage before compression and deduplication.
Limiting factor determines the number of hosts/nodes required to
accommodate the resources.
Monthly cost estimation: The estimated monthly costs for all Azure VMware
Solution (AVS) nodes running the on-premises VMs.
You can select Sizing assumptions to understand the assumptions that went in node
sizing and resource utilization calculations. You can also edit the assessment properties
or recalculate the assessment.
View an assessment
select the number next to Azure VMware Solution.

3. Review the assessment summary.
Review readiness
2. In Azure readiness, review the readiness status.

Ready for AVS: The server can be migrated as-is to Azure (AVS) without any
changes. It starts in AVS with full AVS support.
Ready with conditions: There might be some compatibility issues, for
example, internet protocol or deprecated OS in VMware and need to be
remediated before migrating to Azure VMware Solution. To fix any readiness
problems, follow the remediation guidance that the assessment suggests.
Not ready for AVS: The VM won't start in AVS. For example, if the on-
premises VMware VM has an external device attached such as a CD-ROM the
VMware VMotion operation fails (if using VMware VMotion).
Readiness unknown: Azure Migrate couldn't determine the readiness of the
server because of insufficient metadata collected from the on-premises
environment.
3. Review the suggested tool.
VMware HCX or Enterprise: For VMware servers, the VMware Hybrid Cloud
Extension (HCX) solution is the suggested migration tool to migrate your on-
premises workload to your Azure VMware Solution (AVS) private cloud.
Unknown: For servers imported via a CSV file, the default migration tool is
unknown. Though for VMware servers, it's suggested to use the VMware
Hybrid Cloud Extension (HCX) solution.
4. Select an AVS readiness status. You can view the server readiness details, and drill
down to see server details, including compute, storage, and network settings.

servers in Azure.
1. Review the monthly total costs. Costs are aggregated for all servers in the assessed
group.
Cost estimates are based on the number of AVS nodes required considering
the resource requirements of all the servers in total.
As the pricing is per node, the total cost doesn't have compute cost and
storage cost distribution.
The cost estimation is for running the on-premises servers in AVS. The AVS
assessment doesn't consider PaaS or SaaS costs.
2. Review monthly storage estimates. The view shows the aggregated storage costs
for the assessed group, split over different types of storage disks.
3. You can drill down to see cost details for specific servers.

Server Assessment assigns a confidence rating to performance-based assessments.
Rating is from one star (lowest) to five stars (highest).
assessment.
７ Note
0%-20% 1 star
21%-40% 2 stars
41%-60% 3 stars
61%-80% 4 stars
81%-100% 5 stars
Next steps
Set up agentless or agent-based dependency mapping.
Tutorial: Assess Hyper-V VMs for
migration to Azure
This article shows you how to assess discovered servers from your Hyper-V environment
for migration to Azure, using the Azure Migrate: Discovery and assessment tool.
Run an assessment.
Analyze an assessment.
７ Note
where possible.
Prerequisites
Before you follow this tutorial to assess your servers for migration to Azure VMs,
make sure you've discovered the servers you want to assess:

performance data.

data/metadata.
assessment.

performance data.
Run an assessment
migrate servers.
2. In Azure Migrate: Discovery and assessment, select Assess > Azure VM.

settings
settings prices.

offer.
recommended SKU.
pricing options - Azure the assessment to consider, to help optimize your Azure
(PaaS)


settings Server on




pricing
settings
settings

configuration.
same comfort factor and an effective utilization of 8-GB
GB.

sizing



Managed
Instance
sizing

Managed
Instance
sizing
from this list.




Database
sizing

Database model
sizing

Database
sizing

recovery region.
properties

availability intent
be lost.


availability

Virtual Machines.


out.

assessment.
Next.
７ Note


select the number next to Assessments.

costs, for example, only):
Review readiness

VMs in Azure.
group.
Cost estimates are based on the size recommendations for a machine, its
disks, and its properties.

assessment.
７ Note
0%-20% 1 star
21%-40% 2 stars
41%-60% 3 stars
61%-80% 4 stars
81%-100% 5 stars
Next steps
Set up agent-based dependency mapping.

７ Note
where possible.
Prerequisites
Run an assessment
migrate servers.

appliance.
settings
settings prices.

offer.
recommended SKU.
(PaaS)


settings Server on




pricing
settings
settings

configuration.

sizing



Managed
Instance
sizing

Managed
Instance
sizing
from this list.




Database
sizing

Database model
sizing

Database
sizing

recovery region.
properties

availability intent
be lost.


availability

Virtual Machines.


out.

assessment.
select Next.
latest updates.
７ Note



Discovered entities
this assessment.

conditions:


Managed Instances.
More.
７ Note

Instance.
on Azure VM.
Review readiness




MI

on Azure VM

on Azure VM

SQL DB

deployment type.

assessed group.

example:

recommended.

0%-20% 1 star
21%-40% 2 stars
41%-60% 3 stars
61%-80% 4 stars
81%-100% 5 stars

Next steps
Service.
migration to Azure App Service for
Hyper-V VMs
assessment tool.

７ Note
where possible.
Prerequisites
Run an assessment
and migrate.

Property Details
specify.
Standard plans.
the subscription.
assessment.
Select Next.
Review readiness
matrix below:
Yes Yes I1
Yes No I1
No Yes P1v3
No No P1v2
Ready Yes Yes
Not ready No No
Unknown No No

I1 8
P1v2 8
P1v3 16
Next steps
App Service.
Tutorial: Assess physical servers for
migration to Azure
This article shows you how to assess on-premises physical servers for migration to
Azure, using the Azure Migrate: Discovery and assessment tool.

７ Note
where possible.
Prerequisites
Before you follow this tutorial to assess your servers for migration to Azure VMs,
make sure you've discovered the servers you want to assess:
Make sure physical servers you want to assess aren't running Windows Server
2003, or SUSE Linux. Assessment isn't supported for these servers.

performance data.

data/metadata.
assessment.

performance data.
Run an assessment
migrate servers.

settings
settings prices.

offer.
recommended SKU.
(PaaS)


settings Server on




pricing
settings
settings

configuration.
same comfort factor and an effective utilization of 8-GB
GB.

sizing



Managed
Instance
sizing

Managed
Instance
sizing
from this list.




Database
sizing

Database model
sizing

Database
sizing

recovery region.
properties

availability intent
be lost.


availability

Virtual Machines.


out.

assessment.
Next.
13. After the assessment is created, view it in Servers > Azure Migrate: Discovery and
assessment > Assessments.
７ Note



Review readiness

VMs in Azure.
group.
and its properties.

assessment.
７ Note
0%-20% 1 star
21%-40% 2 stars
41%-60% 3 stars
61%-80% 4 stars
81%-100% 5 stars
Next steps

７ Note
where possible.
Prerequisites
Run an assessment
migrate servers.

appliance.
settings
settings prices.

offer.
recommended SKU.
(PaaS)


settings Server on




pricing
settings
settings

configuration.

sizing



Managed
Instance
sizing

Managed
Instance
sizing
from this list.




Database
sizing

Database model
sizing

Database
sizing

recovery region.
properties

availability intent
be lost.


availability

Virtual Machines.


out.

assessment.
select Next.
latest updates.
７ Note



Discovered entities
this assessment.

conditions:


Managed Instances.
More.
７ Note

Instance.
on Azure VM.
Review readiness




MI

on Azure VM

on Azure VM

SQL DB

deployment type.

assessed group.

example:

recommended.

0%-20% 1 star
21%-40% 2 stars
41%-60% 3 stars
61%-80% 4 stars
81%-100% 5 stars

Next steps
Service.
migration to Azure App Service for
Physical machines
assessment tool.

７ Note
where possible.
Prerequisites
Run an assessment
and migrate.

Property Details
specify.
Standard plans.
the subscription.
assessment.
Select Next.
Review readiness
matrix below:
Yes Yes I1
Yes No I1
No Yes P1v3
No No P1v2
Ready Yes Yes
Not ready No No
Unknown No No

I1 8
P1v2 8
P1v3 16
Next steps
App Service.
Tutorial: Assess AWS instances for
migration to Azure
This article shows you how to assess Amazon Web Services (AWS) instances for
migration to Azure, using the Azure Migrate: Discovery and assessment tool.

７ Note
where possible.
Prerequisites
Before you follow the steps in this tutorial, complete the first tutorial in this series
to discover your on-premises inventory.
Make sure AWS instances aren't running Windows Server 2003, or SUSE Linux.
Assessment isn't supported for these servers.

performance data.

data/metadata.
assessment.

performance data.
Run an assessment
assess and migrate.
3. In Assess servers > Assessment type > Azure VM.
6. In Assessment properties > Target Properties:
In Target location, specify the Azure region to which you want to migrate.
Size and cost recommendations are based on the location that you specify.
Once you change the target location from default, you'll be prompted to
specify Reserved Instances and VM series.
In Azure Government, you can target assessments in these regions
In Storage type,
If you want to use performance-based data in the assessment, select
Automatic for Azure Migrate to recommend a storage type, based on disk
Alternatively, select the storage type you want to use for VM when you
migrate it.
assessment to consider, to help optimize your Azure compute cost.
savings option other than 'None', the 'Discount (%)' and 'VM uptime'
properties aren't applicable.
7. In VM Size:
In Sizing criterion, select if you want to base the assessment on server

configuration data/metadata, or on performance-based data. If you use
performance data:
In Performance history, indicate the data duration on which you want to
base the assessment
In Percentile utilization, specify the percentile value you want to use for
the performance sample.
In VM Series, specify the Azure VM series you want to consider.

If you're using performance-based assessment, Azure Migrate suggests a
value for you.
Tweak settings as needed. For example, if you don't have a production
environment that needs A-series VMs in Azure, you can exclude A-series
from the list of series.
In Comfort factor, indicate the buffer you want to use during assessment.
This accounts for issues like seasonal usage, short performance history, and
likely increases in future usage. For example, if you use a comfort factor of
two:
Component Effective utilization Add comfort factor (2.0)
Cores 2 4
Memory 8 GB 16 GB
8. In Pricing:
In Offer, specify the Azure offer if you're enrolled. The assessment

estimates the cost for that offer.
In Currency, select the billing currency for your account.
In Discount (%), add any subscription-specific discounts you receive on top
of the Azure offer. The default setting is 0%.
In VM Uptime, specify the duration (days per month/hour per day) that VMs
will run.
This is useful for Azure VMs that won't run continuously.
Cost estimates are based on the duration specified.
Default is 31 days per month/24 hours per day.
In EA Subscription, specify whether to take an Enterprise Agreement (EA)
subscription discount into account for cost estimation.
In Azure Hybrid Benefit, specify whether you already have a Windows Server
license. If you do and they're covered with active Software Assurance of
Windows Server Subscriptions, you can apply for the Azure Hybrid Benefit
assessment.
Next.
14. In Review + create assessment, review the assessment details and select Create
16. Select Export assessment to download it as an Excel file.
７ Note



Review readiness

VMs in Azure.
group.
and its properties.

assessment.
７ Note
0%-20% 1 star
21%-40% 2 stars
41%-60% 3 stars
61%-80% 4 stars
81%-100% 5 stars
Next steps
 Documentation
Discover AWS instances with Azure Migrate Discovery and assessment - Azure
Migrate
Business case in Azure Migrate - Azure Migrate

Learn about Business case in Azure Migrate
Azure VMware Solution assessment calculations in Azure Migrate - Azure Migrate

Provides an overview of Azure VMware Solution assessment calculations in the Azure Migrate
service.
Build a Business case with Azure Migrate - Azure Migrate

Describes how to build a Business case with Azure Migrate

Assessment best practices in Azure Migrate Discovery and assessment tool - Azure
Migrate

Assess VMware servers for migration to Azure VMware Solution (AVS) with Azure
Migrate - Azure Migrate
Learn how to assess servers in VMware environment for migration to AVS with Azure Migrate.
Show 5 more
 Training
Module
Discover and assess your on-premises servers with Azure Migrate - Training
Explore the Azure Migrate tools for discovering and assessing your virtual machine servers. Learn
how to install and configure a virtual machine appliance in your virtualization host infrastructure.
Tutorial: Assess Google Cloud Platform
(GCP) VM instances for migration to
Azure
determine cloud readiness, identify risks, and estimate costs and complexity.
This article shows you how to assess Google Cloud Platform (GCP) VM instances for

７ Note
Tutorials show the quickest path for trying out a scenario and using default options
where possible.
Prerequisites
Before you follow the steps in this tutorial, complete the first tutorial in this series
to discover your on-premises inventory.

configuration data/metadata that's collected as-is on-premises or based on
performance data.

data/metadata.
assessment.

based collected performance memory utilization data.
data.
Run an assessment
1. Go to Servers, databases and web apps > Azure Migrate: Discovery and
assessment.
2. In Azure Migrate: Discovery and assessment, click Assess.

5. Click Edit to review the assessment properties.
6. In Assessment properties > Target Properties, do the following:
Once you change the target location from default, you will be prompted to
In Azure Government, you can target assessments in these regions.
In Storage type,
Automatic for Azure Migrate to recommend a storage type, based on the
disk IOPS and throughput.
migrate it.
savings option other than 'None', the 'Discount (%)' and 'VM uptime'
properties are not applicable.
7. In VM Size:
In Sizing criteria, select if you want to base the assessment on server

performance data:
base the assessment.
In VM Series, specify the Azure VM series you want to consider.

value for you.
Tweak the settings as needed. For example, if you don't have a production
In Comfort factor, indicate the buffer you want to use during the assessment.
likely increases during future usage. For example, if you use a comfort factor
of two:
Cores 2 4
Memory 8 GB 16 GB
8. In Pricing:

In VM Uptime, specify the duration (days per month/hour per day) for which
the VMs will run.
9. Click Save if you make changes.
10. In Assess Servers, click Next.
assessment.
12. In Select or create a group > Create New and specify a group name.
13. Select the appliance, and select the VMs you want to add to the group. Click Next.
14. In Review + create assessment, review the assessment details, and click Create
15. After the assessment is created, view it in Servers > Azure Migrate: Discovery and
assessment > Assessments.
16. Click Export assessment to download it as an Excel file.
７ Note


click the number next to Assessments.

Review readiness
1. Click Azure readiness.
3. Select an Azure readiness status. You can view the VM readiness details. You can
also drill down to see VM details, including compute, storage, and network
settings.

VMs in Azure.
group.
and its properties.

assessment.
７ Note
0%-20% 1 star
21%-40% 2 stars
41%-60% 3 stars
61%-80% 4 stars
81%-100% 5 stars
Next steps
Tutorial: Build a business case or assess
servers using an imported CSV file
Article • 04/28/2023
As part of your migration journey to Azure, you discover your on-premises inventory
and workloads.
This tutorial shows you how to build a business case or assess on-premises machines
with the Azure Migrate: Discovery and Assessment tool, using an imported comma-
separate values (CSV) file.
If you use a CSV file, you don't need to set up the Azure Migrate appliance to discover
servers. You can control the data you share in the file, and much of the data is optional.
This method is useful if:
You want to create a quick, initial business case or assessment before you deploy
the appliance.
You can't deploy the Azure Migrate appliance in your organization.
You can't share credentials that allow access to on-premises servers.
Security constraints prevent you from gathering and sending data collected by the
appliance to Azure.
７ Note
You can't migrate servers imported using a CSV file.
＂ Set up an Azure account

＂ Set up an Azure Migrate project
＂ Prepare a CSV file
＂ Import the file
＂ Assess servers
７ Note
where possible.
Prerequisites
You can add up to 20,000 servers in a single CSV file, and in an Azure Migrate
project.
Operating system names specified in the CSV file must contain and match
supported names.

To create an Azure Migrate project, you need an account with:

Subscriptions.
2. In the Subscriptions page, select the subscription in which you want to create an
Azure Migrate project.
Azure portal.
Setting Value

Setting Value
6. In the portal, search for users, and under Services, select Users.
default).
Set up a project
Set up a new Azure Migrate project if you don't have one.
4. In Create project, select your Azure subscription and resource group. Create a
to create the project. Review supported geographies for public and government
clouds.
７ Note

with private endpoint connectivity. Learn more
6. Select Create.
7. Wait a few minutes for the Azure Migrate project to deploy.
The Azure Migrate: Discovery and assessment tool is added by default to the new
project.
Prepare the CSV
Download the CSV template and add server information to it.
Download the template

1. In Migration goals > Servers > Azure Migrate: Discovery and assessment, select
Discover.
2. In Discover machines, select Import using CSV.
3. Select Download to download the CSV template. Alternatively, you can download
it directly .
Add server information
Gather server data and add it to the CSV file.
To gather data, you can export it from tools you use for on-premises server
management, such as VMware vSphere or your configuration-management
database (CMDB).
To review sample data, download our example file .
The following table summarizes the file fields to fill in:
Field name Mandatory Details
Server name Yes We recommend specifying the fully qualified domain name
(FQDN).
IP address No Server address.
Cores Yes Number of processor cores allocated to the server.
Memory Yes Total RAM, in MB, allocated to the server.
OS name Yes Server operating system.

Operating system names that match or contain the names in
this list are recognized by the assessment.
OS version No Server operating system version.
OS architecture No Server OS architecture

Valid values are: x64, x86, amd64, 32-bit or 64-bit
Server type No Type of server

Valid values are: Virtual, Physical
Hypervisor No If server type is Virtual, specify hypervisor name

Valid values are: VMware, Hyper-V
Number of disks No Not needed if individual disk details are provided.
Storage in use (In No You can add how much storage is in use per server.
GB) This field will only be used in Azure VMware Solution
assessment sizing logic.
Disk 1 size No Maximum size of disk, in GB.

You can add details for more disks by adding columns in the
template. You can add up to twenty disks.
Disk 1 read ops No Disk read operations per second.
Disk 1 write ops No Disk write operations per second.
Disk 1 read No Data read from the disk per second, in MB per second.
throughput
Disk 1 write No Data written to disk per second, in MB per second.

throughput
CPU utilization No Percentage of CPU used.

percentage
Memory No Percentage of RAM used.

utilization
percentage
Total disks read No Disk-read operations per second.

ops
Total disks write No Disk-write operations per second.

ops
Total disks read No Data read from the disk, in MB per second.
throughput
Total disks write No Data written to disk, in MB per second.

throughput
Network In No Data received by the server, in MB per second.

throughput
Network Out No Data transmitted by the server, in MB per second.

throughput
Firmware type No Server firmware. Values can be "BIOS" or "UEFI".
No Server
MAC
address.
Add operating systems

Assessment recognizes specific operating system names. Any name you specify must
exactly match one of the strings in the supported names list.
Add multiple disks

The template provides default fields for the first disk. You can add similar columns for up
to twenty disks.
For example, to specify all fields for a second disk, add these columns:
Disk 2 size
Disk 2 read ops
Disk 2 write ops
Disk 2 read throughput
Disk 2 write throughput
Import the server information

After adding information to the CSV template, import the CSV file.
1. In Migration goals > Servers > Azure Migrate: Discovery and assessment, select
Discover.
2. In Discover machines, select Import using CSV
3. Upload the .csv file and select Import.
4. The import status is shown.
If warnings appear in the status, you can either fix them or continue without
addressing them.
To improve assessment accuracy, improve the server information as
suggested in warnings.
To view and fix warnings, select Download warning details .CSV. This
operation downloads the CSV with warnings included. Review the warnings
and fix issues as needed.
If errors appear in the status so that the import status is Failed, you must fix
those errors before you can continue with the import:
a. Download the CSV, which now includes error details.
b. Review and address the errors as necessary.
c. Upload the modified file again.
5. When the import status is Completed, the server information has been imported.
Refresh if the import process doesn't seem to be complete.
Update server information

You can update the information for a server by importing the data for the server again
with the same Server name. You can't modify the Server name field. Deleting servers is
currently not supported.

To verify that the servers appear in the Azure portal after discovery:

2. On the Azure Migrate - Servers > Azure Migrate: Discovery and assessment
page, select the icon that displays the count for Discovered servers.
3. Select the Import based tab.
Supported operating system names

Operating system names provided in the CSV must contain and match. If they don't, you
won't be able to assess them.
A-H I-R S-T U-Z

A-H I-R S-T U-Z
Asianux 3 IBM OS/2 SCO OpenServer 5 Ubuntu Linux

Asianux 4 macOS X 10 SCO OpenServer 6 VMware ESXi 4
Asianux 5 MS-DOS SCO UnixWare 7 VMware ESXi 5
CentOS Novell NetWare 5 Serenity Systems VMware ESXi 6
CentOS 4/5 Novell NetWare 6 eComStation Windows 10
CoreOS Linux Oracle Linux Serenity Systems Windows 2000
Debian Oracle Linux 4/5 eComStation 1 Windows 3
GNU/Linux 4 Oracle Solaris 10 Serenity Systems Windows 7
Debian Oracle Solaris 11 eComStation 2 Windows 8
GNU/Linux 5 Red Hat Enterprise Sun Microsystems Solaris Windows 95
Debian Linux 2 8 Windows 98
GNU/Linux 6 Red Hat Enterprise Sun Microsystems Solaris Windows NT
Debian Linux 3 9 Windows Server (R) 2008
GNU/Linux 7 Red Hat Enterprise Windows Server 2003
Debian Linux 4 SUSE Linux Enterprise 10 Windows Server 2008
GNU/Linux 8 Red Hat Enterprise SUSE Linux Enterprise 11 Windows Server 2008 R2
FreeBSD Linux 5 SUSE Linux Enterprise 12 Windows Server 2012
Red Hat Enterprise SUSE Linux Enterprise 8/9 Windows Server 2012 R2
Linux 6 SUSE Linux Enterprise 11 Windows Server 2016
Red Hat Enterprise SUSE openSUSE Windows Server 2019
Linux 7 Windows Server
Red Hat Fedora Threshold
Windows Vista
Windows Web Server
2008 R2
Windows XP
Professional
Business case considerations

If you import servers by using a CSV file and build a business case:
Performance history duration in Azure settings will not be applicable
Servers where no performance data is specified will be classified as unknown in
the business case utilization insights chart and will be sized as-is without
rightsizing for Azure cost
Servers where server type and virtualization are not specified will be classified as
Not applicable in virtualization distribution and no virtualization software cost
will be added in on-premises cost
Assessment considerations
If you import servers by using a CSV file and creating an assessment with sizing
criteria as "performance-based":
For Azure VM assessment, the performance values you specify (CPU utilization,
Memory utilization, Disk IOPS and throughput) are used if you choose
performance-based sizing. You will not be able to provide performance history
and percentile information.
For Azure VMware Solution assessment, the performance values you specify
(CPU utilization, Memory utilization, Storage in use(GB)) are used if you choose
performance-based sizing. You will not be able to provide performance history
and percentile information.
To get an accurate OS suitability/readiness in Azure VM and Azure VMware
Solution assessment, please enter the Operating system version and architecture in
the respective columns.
Next steps
In this tutorial, you:
＂ Created an Azure Migrate project.

＂ Discovered servers using an imported CSV file. Now, build a quick business case or
run an assessment for migration to Azure VMs.
Select a VMware migration option
You can migrate VMware VMs to Azure using the Migration and modernization tool.
This tool offers a couple of options for VMware VM migration:
Migration using agentless replication. Migrate VMs without needing to install

anything on them.
Migration with an agent for replication. Install an agent on the VM for replication.
Compare migration methods

Use these selected comparisons to help you decide which method to use. You can also
review full support requirements for agentless and agent-based migration.
Setting Agentless Agent-based
Azure You need permissions to create an Azure Migrate You need Contributor
permissions project, and to register Azure AD apps created when permissions on the
you deploy the Azure Migrate appliance. Azure subscription.
Replication You can simultaneously replicate a maximum of 500 Replication capacity

VMs across multiple vCenter Servers (discovered from increases by scaling the
one appliance) using a scale-out appliance. In the replication appliance.
portal, you can select up to 10 machines at once for
replication. To replicate more machines, add in batches
of 10.
Appliance The Azure Migrate appliance is deployed on-premises. The Azure Migrate
deployment Replication appliance is
deployed on-premises.
Site Compatible. You can't replicate with

Recovery the Migration and
compatibility modernization tool if
you've set up
replication for a
machine using Site
Recovery.
Target disk Managed disks Managed disks

Setting Agentless Agent-based
Disk limits OS disk: 2 TB OS disk: 2 TB
Data disk: 32 TB Data disk: 32 TB
Maximum disks: 60 Maximum disks: 63
Passthrough Not supported Supported

disks
UEFI boot Supported. Supported.
Connectivity Public internet Public internet

ExpressRoute with Private peering ExpressRoute with
ExpressRoute with Microsoft peering Private peering
Site-to-site VPN ExpressRoute with
Microsoft peering
Site-to-site VPN
Compare deployment steps

After reviewing the limitations, understanding the steps involved in deploying each
solution might help you decide which option to choose.
Task Details Agentless Agent-based
Deploy the A lightweight appliance that runs Required. Not required.

Azure on a VMware VM.
Migrate If you've already set If you've set up an
appliance The appliance is used to discover up the appliance for appliance for
and assess machines, and to assessment, you can assessment, you can
migrate machines using use the same leave it in place, or
agentless migration. appliance for remove it if you're
agentless migration. done with assessment.
Use the Assess machines with the Azure Assessment is Assessment is

Server Migrate: Server Assessment tool. optional. optional.
Assessment
tool
Use the Add the Migration and Required Required

Migration modernization tool in the Azure
tool Migrate project.
Prepare Configure settings on VMware Required Required

VMware for servers and VMs.
migration
Task Details Agentless Agent-based
Install the Mobility service runs on each VM Not required Required

Mobility you want to replicate
service on
VMs
Deploy the The replication appliance is used Not required Required

replication for agent-based migration. It
appliance connects between the Mobility
service running on VMs, and the
Migration and modernization
tool.
Replicate Configure replication settings Required Required

VMs. and select VMs to replicate
Enable VM
replication.
Run a test Run a test migration to make Required Required

migration sure everything's working as
expected.
Run a full Migrate the VMs. Required Required

migration
Next steps
Migrate VMware VMs with agentless migration.
 Documentation
Test migrate replicating virtual machines - Azure Migrate

Learn best practices for testing replicating virtual machines
Azure Migrate replication appliance - Azure Migrate

Learn about the Azure Migrate replication appliance for agent-based VMware migration.
How does Hyper-V migration work in Azure Migrate? - Azure Migrate

Learn about Hyper-V migration with Azure Migrate
Agent-based migration in Azure Migrate Server Migration - Azure Migrate

Provides an overview of agent-based VMware VM migration in Azure Migrate.
Discover physical servers with Azure Migrate Discovery and assessment - Azure
Migrate
Learn how to discover on-premises physical servers with Azure Migrate Discovery and assessment.
Support for VMware vSphere migration in Azure Migrate - Azure Migrate

Learn about support for VMware vSphere VM migration in Azure Migrate.
Migrate VMware vSphere VMs with agent-based the Migration and modernization
tool - Azure Migrate
Learn how to run an agent-based migration of VMware vSphere VMs with Azure Migrate.
Agentless replication of VMware virtual machines concepts - Azure Migrate

Describes concepts related to agentless migration of VMware VMs in Azure Migrate.
Show 5 more
 Training
Learning paths and modules

Migrate virtual machines and apps using Azure Migrate - Training
The Virtual machine and app migration using Azure Migrate learning path gives you a step-by-step
process to help you understand, set up, assess, and migrate virtual and physical servers, databases,
applications, and virtual desktops from on-premises to the Azure infrastructure. Azure Migrate now…
Migrate VMware VMs to Azure
(agentless)
This article shows you how to migrate on-premises VMware VMs to Azure, using the
Migration and modernization tool, with agentless migration. You can also migrate
VMware VMs using agent-based migration. Compare the methods.
This tutorial is the third in a series that demonstrates how to assess and migrate
VMware VMs to Azure.
７ Note
Tutorials show you the simplest deployment path for a scenario so that you can
quickly set up a proof-of-concept. Tutorials use default options where possible, and
don't show all possible settings and paths.
＂ Add the Migration and modernization tool.

＂ Discover VMs you want to migrate.
＂ Start replicating VMs.
＂ Run a test migration to make sure everything's working as expected.
＂ Run a full VM migration.
Prerequisites
Before you begin this tutorial, you should:
1. Complete the first tutorial to prepare Azure and VMware for migration.
2. We recommend that you complete the second tutorial to assess VMware VMs
before migrating them to Azure, but you don't have to.
3. Go to the already created project or create a new project
4. Verify permissions for your Azure account - Your Azure account needs permissions
to create a VM, and write to an Azure managed disk.
Set up the Azure Migrate appliance

The Migration and modernization tool runs a lightweight VMware VM appliance that's
used for discovery, assessment, and agentless migration of VMware VMs. If you follow
the assessment tutorial, you've already set the appliance up. If you didn't, set it up now,
using one of these methods:
OVA template: Set up on a VMware VM using a downloaded OVA template.

Script: Set up on a VMware VM or physical machine, using a PowerShell installer
script. This method should be used if you can't set up a VM using an OVA
template, or if you're in Azure Government.
After creating the appliance, you check that it can connect to Azure Migrate:Server
Assessment, configure it for the first time, and register it with the Azure Migrate project.
Replicate VMs
After setting up the appliance and completing discovery, you can begin replication of
You can run up to 500 replications simultaneously.

In the portal, you can select up to 10 VMs at once for migration. To migrate more
machines, add them to groups in batches of 10.
Enable replication as follows:
1. In the Azure Migrate project > Servers, databases and web apps > Migration and
modernization, select Replicate.
2. In Replicate, > Basics > Are your machines virtualized?, select Yes, with VMware
vSphere.
3. In On-premises appliance, select the name of the Azure Migrate appliance that
you set up > OK.
4. In Virtual machines, select the machines you want to replicate. To apply VM sizing
and disk type from an assessment if you've run one, in Import migration settings
from an Azure Migrate assessment?, select Yes, and select the VM group and
assessment name. If you aren't using assessment settings, select No.
5. In Virtual machines, select VMs you want to migrate. Then click Next: Target
settings.
6. In Target settings, select the subscription and target region. Specify the resource
group in which the Azure VMs reside after migration.
７ Note
The region for the project cannot be changed after the first replication is
initiated. Please select the region carefully.
7. In Virtual Network, select the Azure VNet/subnet which the Azure VMs join after
migration.
8. In Availability options, select:
Availability Zone to pin the migrated machine to a specific Availability Zone in

the region. Use this option to distribute servers that form a multi-node
application tier across Availability Zones. If you select this option, you'll need
to specify the Availability Zone to use for each of the selected machine in the
Compute tab. This option is only available if the target region selected for the
migration supports Availability Zones
Availability Set to place the migrated machine in an Availability Set. The
target Resource Group that was selected must have one or more availability
sets in order to use this option.
No infrastructure redundancy required option if you don't need either of
these availability configurations for the migrated machines.
9. In Disk encryption type, select:
Encryption-at-rest with platform-managed key

Encryption-at-rest with customer-managed key
Double encryption with platform-managed and customer-managed keys
７ Note
To replicate VMs with CMK, you'll need to create a disk encryption set under
the target Resource Group. A disk encryption set object maps Managed Disks
to a Key Vault that contains the CMK to use for SSE.
10. In Azure Hybrid Benefit:
Select No if you don't want to apply Azure Hybrid Benefit. Then click Next.
Select Yes if you have Windows Server machines that are covered with active
Software Assurance or Windows Server subscriptions, and you want to apply
the benefit to the machines you're migrating. Then click Next.
11. In Compute, review the VM name, size, OS disk type, and availability configuration
(if selected in the previous step). VMs must conform with Azure requirements.
VM size: If you're using assessment recommendations, the VM size

dropdown shows the recommended size. Otherwise Azure Migrate picks a
size based on the closest match in the Azure subscription. Alternatively, pick a
manual size in Azure VM size.
OS disk: Specify the OS (boot) disk for the VM. The OS disk is the disk that
has the operating system bootloader and installer.
Availability Zone: Specify the Availability Zone to use.
Availability Set: Specify the Availability Set to use.
７ Note
If you want to select a different availability option for a sets of virtual

machines, go to step 1 and repeat the steps by selecting different availability
options after starting replication for one set of virtual machines.
12. In Disks, specify whether the VM disks should be replicated to Azure, and select
the disk type (standard SSD/HDD or premium-managed disks) in Azure. Then click
Next.

13. In Tags, choose to add tags to your Virtual machines, Disks, and NICs.
14. In Review and start replication, review the settings, and click Replicate to start the
initial replication for the servers.
７ Note
You can update replication settings any time before replication starts (Manage >
Replicating machines). You can't change settings after replication starts.
Provisioning for the first time

If this is the first VM you're replicating in the project, the Migration and modernization
tool automatically provisions these resources, in same resource group as the project.
Service bus: The Migration and modernization tool uses the service bus to send
replication orchestration messages to the appliance.
Gateway storage account: The Migration and modernization tool uses the
gateway storage account to store state information about the VMs being
replicated.
Log storage account: The Azure Migrate appliance uploads replication logs for
VMs to a log storage account. Azure Migrate applies the replication information to
the replica managed disks.
Key vault: The Azure Migrate appliance uses the key vault to manage connection
strings for the service bus, and access keys for the storage accounts used in
replication.
Track and monitor

1. Track job status in the portal notifications.
2. Monitor replication status by clicking on Replicating servers in Migration and

modernization.
Replication occurs as follows:
When the Start Replication job finishes successfully, the machines begin their initial
replication to Azure.
During initial replication, a VM snapshot is created. Disk data from the snapshot is
replicated to replica managed disks in Azure.
After initial replication finishes, delta replication begins. Incremental changes to
on-premises disks are periodically replicated to the replica disks in Azure.
Run a test migration

When delta replication begins, you can run a test migration for the VMs, before running
a full migration to Azure. We highly recommend that you do this at least once 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 VM using replicated
data (usually migrating to a non-production VNet in your Azure subscription).
You can use the replicated test Azure VM to validate the migration, perform app
testing, and address any issues before full migration.
Do a test migration as follows:
1. In Migration goals > Servers, databases and web apps > Migration and
modernization, select Test migrated servers.
2. Right-click the VM to test, and click Test migrate.
3. In Test migration, select the Azure VNet in which the Azure VM will be located
during testing. We recommend you use a non-production VNet.
4. Choose the subnet to which you would like to associate each of the Network
Interface Cards (NICs) of the migrated VM.
5. The Test migration job starts. Monitor the job in the portal notifications.
6. After the migration finishes, view the migrated Azure VM in Virtual Machines in
the Azure portal. The machine name has a suffix -Test.
7. After the test is done, right-click the Azure VM in Replicating machines, and click
Clean up test migration.
７ Note
You can now register your servers running SQL server with SQL VM RP to take
advantage of automated patching, automated backup and simplified license
management using SQL IaaS Agent Extension.
Select Manage > Replicating servers > Machine containing SQL server
> Compute and Network and select yes to register with SQL VM RP.
Select Azure Hybrid benefit for SQL Server if you have SQL Server
instances that are covered with active Software Assurance or SQL Server
subscriptions and you want to apply the benefit to the machines you're
migrating.hs.
Migrate VMs
After you've verified that the test migration works as expected, you can migrate the on-
premises machines.
modernization, select Replicating servers.
2. In Replicating machines, right-click the VM > Migrate.
3. In Migrate > Shut down virtual machines and perform a planned migration with
no data loss, select Yes > OK.
By default Azure Migrate shuts down the on-premises VM, and runs an on-
demand replication to synchronize any VM changes that occurred since the
last replication occurred. This ensures no data loss.
If you don't want to shut down the VM, select No
4. A migration job starts for the VM. Track the job in Azure notifications.
5. After the job finishes, you can view and manage the VM from the Virtual Machines
page.
Complete the migration
1. After the migration is done, right-click the VM > Complete migration. This stops
replication for the on-premises machine, and cleans up replication state
information for the VM.
2. We automatically install the VM agent for Windows VMs and Linux during
migration.
3. Verify and troubleshoot any Windows activation issues on the Azure VM.
4. Perform any post-migration app tweaks, such as updating host names, database
connection strings, and web server configurations.
5. Perform final application and migration acceptance testing on the migrated
application now running in Azure.
6. Cut over traffic to the migrated Azure VM instance.
7. Remove the on-premises VMs from your local VM inventory.
8. Remove the on-premises VMs from local backups.
9. Update any internal documentation to show the new location and IP address of
the Azure VMs.
Post-migration best practices

For increased resilience:
Keep data secure by backing up Azure VMs using the Azure Backup service.
Learn more.
Keep workloads running and continuously available by replicating Azure VMs to
a secondary region with Site Recovery. Learn more.
For increased performance:
By default, data disks are created with host caching set to "None". Review and
adjust data disk caching to your workload needs. Learn more.
For increased security:
Lock down and limit inbound traffic access with Microsoft Defender for Cloud -
Just in time administration.
Restrict network traffic to management endpoints with Network Security
Groups.
Deploy Azure Disk Encryption to help secure disks, and keep data safe from
theft and unauthorized access.
Read more about securing IaaS resources , and visit the Microsoft Defender
for Cloud .
For monitoring and management:
Consider deploying Azure Cost Management to monitor resource usage and
spending.
Next steps
Investigate the cloud migration journey in the Azure Cloud Adoption Framework.
Migrate VMware vSphere VMs to Azure
(agent-based)
This article shows you how to migrate on-premises VMware vSphere VMs to Azure, using
the Migration and modernization tool, with agent-based migration. You can also migrate
VMware vSphere VMs using agentless migration. Compare the methods.
＂ Prepare Azure to work with Azure Migrate.

＂ Prepare for agent-based migration. Set up a VMware vCenter Server account so that
Azure Migrate can discover machines for migration. Set up an account so that the
Mobility service agent can install on machines you want to migrate, and prepare a
machine to act as the replication appliance.
＂ Add the Migration and modernization tool
＂ Set up the replication appliance.
＂ Replicate VMs.
＂ Run a full migration to Azure.
７ Note
Prerequisites
Before you begin this tutorial, review the VMware vSphere agent-based migration
architecture.
Prepare Azure
Complete the tasks in the table to prepare Azure for agent-based migration.
Task Details
Task Details
Create an Azure Migrate Your Azure account needs Contributor or Owner permissions to create
project a project.
Verify Azure account Your Azure account needs permissions to create a VM, and write to an
permissions Azure managed disk.
Set up an Azure network Set up a network that Azure VMs will join after migration.
Assign permissions to create project

If you don't have an Azure Migrate project, verify permissions to create one.
1. In the Azure portal, open the subscription, and select Access control (IAM).
2. In Check access, find the relevant account, and select it to view permissions.
3. Verify that you have Contributor or Owner permissions.
If you just created a free Azure account, you're the owner of your subscription.
If you're not the subscription owner, work with the owner to assign the role.
Assign Azure account permissions

Assign the Virtual Machine Contributor role to the account, so that you have permissions
to:
Create a VM in the selected resource group.

Create a VM in the selected virtual network.
Write to an Azure managed disk.
Assign permissions to register the Replication Appliance in

Azure AD
If you are following the least privilege principle, assign the Application Developer Azure
AD role to the user registering the Replication Appliance. Follow the Assign administrator
and non-administrator roles to users with Azure Active Directory guide to do so.
） Important
If the user registering the Replication Appliance is an Azure AD Global administrator,

that user already has the required permissions.
Set up an Azure network
Set up an Azure network. On-premises machines are replicated to Azure managed disks.
When you fail over to Azure for migration, Azure VMs are created from these managed
disks, and joined to the Azure network you set up.
Prepare for migration

Verify support requirements and permissions, and prepare to deploy a replication
appliance.
Prepare an account to discover VMs

The Migration and modernization tool needs access to VMware vSphere to discover VMs
you want to migrate. Create the account as follows:
1. To use a dedicated account, create a role at the vCenter Server level. Give the role a
name such as Azure_Migrate.
2. Assign the role the permissions summarized in the table below.
3. Create a user on the vCenter Server or vSphere host. Assign the role to the user.
VMware vSphere account permissions
Task Role/Permissions Details
VM At least a read-only user User assigned at datacenter level, and

discovery has access to all the objects in the
Data Center object –> Propagate to Child datacenter.
Object, role=Read-only
To restrict access, assign the No access
role with the Propagate to child object,
to the child objects (vSphere hosts,
datastores, VMs, and networks).
Task Role/Permissions Details
Replication Create a role (Azure Site Recovery) with User assigned at datacenter level, and
the required permissions, and then assign has access to all the objects in the
the role to a VMware vSphere user or datacenter.
group
To restrict access, assign the No access
Data Center object –> Propagate to Child role with the Propagate to child object,
Object, role=Azure Site Recovery to the child objects (vSphere hosts,
datastores, VMs, and networks).
Datastore -> Allocate space, browse
datastore, low-level file operations,
remove file, update virtual machine files
Network -> Network assign
Resource -> Assign VM to resource pool,

migrate powered off VM, migrate
powered on VM
Tasks -> Create task, update task
Virtual machine -> Configuration
Virtual machine -> Interact -> answer

question, device connection, configure CD
media, configure floppy media, power off,
power on, VMware tools install
Virtual machine -> Inventory -> Create,

register, unregister
Virtual machine -> Provisioning -> Allow

virtual machine download, allow virtual
machine files upload
Virtual machine -> Snapshots -> Remove

snapshots
Prepare an account for Mobility service installation

The Mobility service must be installed on machines you want to replicate.
The Azure Migrate replication appliance can do a push installation of this service
when you enable replication for a machine, or you can install it manually, or using
installation tools.
In this tutorial, we're going to install the Mobility service with the push installation.
For push installation, you need to prepare an account that the Migration and
modernization tool can use to access the VM. This account is used only for the push
installation, if you don't install the Mobility service manually.
Prepare the account as follows:
1. Prepare a domain or local account with permissions to install on the VM.

2. For Windows VMs, if you're not using a domain account, disable Remote User
Access control on the local machine by adding the DWORD entry
LocalAccountTokenFilterPolicy, with a value of 1 in the registry, under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
3. For Linux VMs, prepare a root account on the source Linux server.
Prepare a machine for the replication appliance

The appliance is used to replication machines to Azure. The appliance is single, highly
available, on-premises VMware vSphere VM that hosts these components:
Configuration server: The configuration server coordinates communications

between on-premises and Azure, and manages data replication.
Process server: The process server acts as a replication gateway. It receives
replication data; optimizes it with caching, compression, and encryption, and sends
it to a cache storage account in Azure. The process server also installs the Mobility
Service agent on VMs you want to replicate, and performs automatic discovery of
on-premises VMware VMs.
Prepare for the appliance as follows:
Review appliance requirements. Generally, you set up the replication appliance a

VMware vSphere VM using a downloaded OVA file. The template creates an
appliance that complies with all requirements.
MySQL must be installed on the appliance. Review installation methods.
Review the public cloud URLs, and Azure Government URLs that the appliance
machine needs to access.
Review the ports that the replication appliance machine needs to access.
Check VMware vSphere requirements

Make sure VMware vSphere VMs comply with requirements for migration to Azure.
1. Verify VMware vSphere VM requirements.

2. Verify VM requirements for migration.
3. Verify Azure settings. On-premises VMs you replicate to Azure must comply with
Azure VM requirements.
4. There are some changes needed on VMs before you migrate them to Azure.
It's important to make these changes before you begin migration. If you
migrate the VM before you make the change, the VM might not boot up in
Azure.
Review Windows and Linux changes you need to make.
７ Note
Agent-based migration with the Migration and modernization tool is based on

features of the Azure Site Recovery service. Some requirements might link to Site
Recovery documentation.
Set up the replication appliance

This procedure describes how to set up the appliance with a downloaded Open
Virtualization Application (OVA) template. If you can't use this method, you can set up the
appliance using a script.
Download the replication appliance template

Download the template as follows:
1. In the Azure Migrate project, select Servers, databases and web apps under
Migration goals.
2. In Servers, databases and web apps > Migration and modernization, click
Discover.
3. In Discover machines > Are your machines virtualized?, click Yes, with VMware
vSphere hypervisor.
4. In How do you want to migrate?, select Using agent-based replication.
5. In Target region, select the Azure region to which you want to migrate the
machines.
6. Select Confirm that the target region for migration is region-name.

7. Click Create resources. This creates an Azure Site Recovery vault in the background.
You can't change the target region for this project after clicking this button, and all
subsequent migrations are to this region.
７ Note
If you selected private endpoint as the connectivity method for the Azure
Migrate project when it was created, the Recovery Services vault will also be
configured for private endpoint connectivity. Ensure that the private endpoints
are reachable from the replication appliance: Learn more
8. In Do you want to install a new replication appliance?, select Install a replication

appliance.
9. Click Download. This downloads an OVF template.
10. Note the name of the resource group and the Recovery Services vault. You need
these during appliance deployment.
Import the template into VMware vSphere
After downloading the OVF template, you import it into VMware vSphere to create the
replication application on a VMware vSphere VM running Windows Server 2016.
1. Sign in to the VMware vCenter Server or vSphere ESXi host with the VMware
vSphere Client.
2. On the File menu, select Deploy OVF Template to start the Deploy OVF Template
Wizard.
3. In Select source, enter the location of the downloaded OVF.
4. In Review details, select Next.
5. In Select name and folder and Select configuration, accept the default settings.
6. In Select storage > Select virtual disk format, for best performance select Thick
Provision Eager Zeroed.
7. On the rest of the wizard pages, accept the default settings.
8. In Ready to complete, to set up the VM with the default settings, select Power on
after deployment > Finish.
 Tip
If you want to add an additional NIC, clear Power on after deployment >
Finish. By default, the template contains a single NIC. You can add additional
NICs after deployment.
Start appliance setup

1. In the VMware vSphere Client console, turn on the VM. The VM boots up into a
Windows Server 2016 installation experience.
2. Accept the license agreement, and enter an administrator password.
3. After the installation finishes, sign in to the VM as the administrator, using the
admin password. The first time you sign in, the replication appliance setup tool
(Azure Site Recovery Configuration Tool) starts within a few seconds.
4. Enter a name to use for registering the appliance with the Migration and
modernization tool. Select Next.
5. The tool checks that the VM can connect to Azure. After the connection is
established, select Sign in to sign in to your Azure subscription.
6. Wait for the tool to finish registering an Azure AD app to identify the appliance. The
appliance reboots.
7. Sign in to the machine again. In a few seconds, the Configuration Server
Management Wizard starts automatically.
Register the replication appliance

Finish setting up and registering the replication appliance.
1. In appliance setup, select Setup connectivity.
2. Select the NIC (by default there's only one NIC) that the replication appliance uses
for VM discovery, and to do a push installation of the Mobility service on source
machines.
3. Select the NIC that the replication appliance uses for connectivity with Azure. Then
select Save. You cannot change this setting after it's configured.
 Tip
If for some reason you need to change the NIC selection and you have not
clicked the Finalize configuration button in step 12, you can do so by clearing
your browser cookies and restarting the Configuration Server Management
Wizard.
4. If the appliance is located behind a proxy server, you need to specify proxy settings.
Specify the proxy name as http://ip-address, or http://FQDN. HTTPS proxy

servers aren't supported.
5. When prompted for the subscription, resource groups, and vault details, add the
details that you noted when you downloaded the appliance template.
6. In Install third-party software, accept the license agreement. Select Download and
Install to install MySQL Server.
7. Select Install VMware PowerCLI. Make sure all browser windows are closed before
you do this. Then select Continue.
７ Note
In newer versions of the Replication Appliance the VMware PowerCLI

installation is not required.
8. In Validate appliance configuration, prerequisites are verified before you continue.
9. In Configure vCenter Server/vSphere ESXi server, enter the FQDN or IP address of

the vCenter server, or vSphere host, where the VMs you want to replicate are
located. Enter the port on which the server is listening. Enter a friendly name to be
used for the VMware server in the vault.
10. Enter the credentials for the account you created for VMware discovery. Select Add
> Continue.
11. In Configure virtual machine credentials, enter the credentials you created for push
installation of the Mobility service, when you enable replication for VMs.
For Windows machines, the account needs local administrator privileges on the
machines you want to replicate.
For Linux, provide details for the root account.
12. Select Finalize configuration to complete registration.
After the replication appliance is registered, Azure Migrate Server Assessment connects to
VMware servers using the specified settings, and discovers VMs. You can view discovered
VMs in Manage > Discovered items, in the Other tab.
Replicate VMs
Select VMs for migration.
７ Note
In the portal you can select up to 10 machines at once for replication. If you need to
replicate more, then group them in batches of 10.
modernization, click Replicate.
2. In Replicate, > Source settings > Are your machines virtualized?, select Yes, with
VMware vSphere.
3. In On-premises appliance, select the name of the Azure Migrate appliance that you
set up.
4. In vCenter server, specify the name of the vCenter server managing the VMs, or the
vSphere server on which the VMs are hosted.
5. In Process Server, select the name of the replication appliance.
6. In Guest credentials, specify the VM admin account that will be used for push
installation of the Mobility service. Then click Next: Virtual machines.
7. In Virtual Machines, select the machines that you want to replicate.

If you've run an assessment for the VMs, you can apply VM sizing and disk
type (premium/standard) recommendations from the assessment results. To do
this, in Import migration settings from an Azure Migrate assessment?, select
the Yes option.
If you didn't run an assessment, or you don't want to use the assessment
settings, select the No options.
If you selected to use the assessment, select the VM group, and assessment
name.

Availability Set to place the migrated machine in an Availability Set. The target
Resource Group that was selected must have one or more availability sets in
order to use this option.
No infrastructure redundancy required option if you don't need either of these
availability configurations for the migrated machines.
9. Check each VM you want to migrate. Then click Next: Target settings.
10. In Target settings, select the subscription, and target region to which you'll migrate,
and specify the resource group in which the Azure VMs will reside after migration.
11. In Virtual Network, select the Azure VNet/subnet to which the Azure VMs will be
joined after migration.
12. In Cache storage account, keep the default option to use the cache storage account
that is automatically created for the project. Use the dropdown if you'd like to
specify a different storage account to use as the cache storage account for
replication.
７ Note
Migrate project, grant the Recovery Services vault access to the cache
storage account. Learn more
To replicate using ExpressRoute with private peering, create a private
endpoint for the cache storage account. Learn more

Availability Set to place the migrated machine in an Availability Set. The target
Resource Group that was selected must have one or more availability sets in
order to use this option.
No infrastructure redundancy required option if you don't need either of these
availability configurations for the migrated machines.

７ Note
To replicate VMs with CMK, you'll need to create a disk encryption set under the
target Resource Group. A disk encryption set object maps Managed Disks to a Key
Vault that contains the CMK to use for SSE.
VM size: If you're using assessment recommendations, the VM size dropdown

shows the recommended size. Otherwise Azure Migrate picks a size based on the
closest match in the Azure subscription. Alternatively, pick a manual size in Azure
VM size.
OS disk: Specify the OS (boot) disk for the VM. The OS disk is the disk that has the
operating system bootloader and installer.
17. In Disks, specify whether the VM disks should be replicated to Azure, and select the
disk type (standard SSD/HDD or premium managed disks) in Azure. Then click Next.
You can exclude disks from replication.

If you exclude disks, they won't be present on the Azure VM after migration.

You can exclude disks if the mobility agent is already installed on that server.
Learn more.
７ Note
You can update replication settings any time before replication starts, Manage >
Replicating machines. Settings can't be changed after replication starts.
Track and monitor

1. Track job status in the portal notifications.
2. To monitor replication status, click Replicating servers in Migration and

modernization.
After initial replication finishes, delta replication begins. Incremental changes to on-
premises disks are periodically replicated to the replica disks in Azure.

When delta replication begins, you can run a test migration for the VMs, before running a
full migration to Azure. We highly recommend that you do this at least once for each
replicating.

1. In Migration goals > Servers > Migration and modernization, select Test migrated
servers.
3. In Test Migration, select the Azure VNet in which the Azure VM will be located after
the migration. We recommend you use a non-production VNet.
5. After the migration finishes, view the migrated Azure VM in Virtual Machines in the
Azure portal. The machine name has a suffix -Test.

７ Note
Select Manage > Replicating servers > Machine containing SQL server >
Compute and Network and select yes to register with SQL VM RP.
migrating.hs.
Migrate VMs
premises machines.
By default Azure Migrate shuts down the on-premises VM to ensure minimum

data loss.
If you don't want to shut down the VM, select No
page.

1. After the migration is done, right-click the VM > Stop replication. This does the
following:
Stops replication for the on-premises machine.

Removes the machine from the Replicating servers count in the Migration and
modernization tool.
Cleans up replication state information for the VM.
3. Perform any post-migration app tweaks, such as host names, updating database
8. Update any internal documentation to show the new location and IP address of the
Azure VMs.

On-premises
Move app traffic over to the app running on the migrated Azure VM instance.
Remove the on-premises VMs from your local VM inventory.
Remove the on-premises VMs from local backups.
Update any internal documentation to show the new location and IP address of
the Azure VMs.
Tweak Azure VM settings after migration:
The Azure VM agent manages VM interaction with the Azure Fabric Controller.
It's required for some Azure services, such as Azure Backup, Site Recovery, and
Azure Security. When migrating VMare VMs with agent-based migration, the
Mobility Service installer installs Azure VM agent on Windows machines. On Linux
VMs, we recommend that you install the agent after migration.
Manually uninstall the Mobility service from the Azure VM after migration.
Manually uninstall VMware tools after migration.
In Azure:
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
Business continuity/disaster recovery
Keep data secure by backing up Azure VMs using the Azure Backup service. Learn
more.
Keep workloads running and continuously available by replicating Azure VMs to a
secondary region with Site Recovery. Learn more.
Restrict network traffic to management endpoints with Network Security Groups.
Deploy Azure Disk Encryption to help secure disks, and keep data safe from theft
and unauthorized access.
Read more about securing IaaS resources , and visit the Microsoft Defender for
Cloud .
spending.
Next steps
Migrate VMware VMs to Azure
(agentless) - PowerShell
Article • 05/11/2023
In this article, you'll learn how to migrate discovered VMware VMs with the agentless
method using Azure PowerShell for Migration and modernization.
You learn how to:
＂ Retrieve discovered VMware VMs in an Azure Migrate project.

＂ Update properties for replicating VMs.
＂ Monitor replication.
７ Note
quickly set up a proof-of-concept. Tutorials use default options where possible and
1. Prerequisites
1. Complete the Tutorial: Discover VMware VMs with Server Assessment to prepare
Azure and VMware for migration.
2. Complete the Tutorial: Assess VMware VMs for migration to Azure VMs before
migrating them to Azure.
3. Install the Az PowerShell module
2. Install Azure Migrate PowerShell module

Azure Migrate PowerShell module is available as part of Azure PowerShell ( Az ). Run the
Get-InstalledModule -Name Az.Migrate command to check if the Azure Migrate
PowerShell module is installed on your machine.

3. Sign in to your Microsoft Azure subscription
Sign in to your Azure subscription with the Connect-AzAccount cmdlet.
Azure PowerShell
Connect-AzAccount
Select your Azure subscription

Use the Get-AzSubscription cmdlet to get the list of Azure subscriptions you have access
to. Select the Azure subscription that has your Azure Migrate project to work with using
the Set-AzContext cmdlet.
Azure PowerShell
Set-AzContext -SubscriptionId 00000000-0000-0000-0000-000000000000
4. Retrieve the Azure Migrate project

An Azure Migrate project is used to store discovery, assessment, and migration
metadata collected from the environment you're assessing or migrating. In a project you
can track discovered assets, orchestrate assessments, and perform migrations.
As part of prerequisites, you would have already created an Azure Migrate project. Use
the Get-AzMigrateProject cmdlet to retrieve details of an Azure Migrate project. You'll
need to specify the name of the Azure Migrate project ( Name ) and the name of the
resource group of the Azure Migrate project ( ResourceGroupName ).
Azure PowerShell
# Get resource group of the Azure Migrate project

$ResourceGroup = Get-AzResourceGroup -Name MyResourceGroup
Azure PowerShell
# Get details of the Azure Migrate project

$MigrateProject = Get-AzMigrateProject -Name MyMigrateProject -
ResourceGroupName $ResourceGroup.ResourceGroupName
Azure PowerShell
# View Azure Migrate project details
Write-Output $MigrateProject
5. Retrieve discovered VMs in an Azure Migrate

project
Azure Migrate uses a lightweight Azure Migrate appliance. As part of the prerequisites,
you would have deployed the Azure Migrate appliance as a VMware VM.
To retrieve a specific VMware VM in an Azure Migrate project, specify name of the Azure
Migrate project ( ProjectName ), resource group of the Azure Migrate project
( ResourceGroupName ), and the VM name ( DisplayName ).
Azure PowerShell
# Get a specific VMware VM in an Azure Migrate project

$DiscoveredServer = Get-AzMigrateDiscoveredServer -ProjectName
$MigrateProject.Name -ResourceGroupName $ResourceGroup.ResourceGroupName -
DisplayName MyTestVM | Format-Table DisplayName, Name, Type
# View discovered server details

Write-Output $DiscoveredServer
We'll migrate this VM as part of this tutorial.
You can also retrieve all VMware VMs in an Azure Migrate project by using the
( ProjectName ) and ( ResourceGroupName ) parameters.
Azure PowerShell
# Get all VMware VMs in an Azure Migrate project

$DiscoveredServers = Get-AzMigrateDiscoveredServer -ProjectName
$MigrateProject.Name -ResourceGroupName $ResourceGroup.ResourceGroupName
If you have multiple appliances in an Azure Migrate project, you can use ( ProjectName ),
( ResourceGroupName ), and ( ApplianceName ) parameters to retrieve all VMs discovered
using a specific Azure Migrate appliance.
Azure PowerShell
# Get all VMware VMs discovered by an Azure Migrate Appliance in an Azure

Migrate project
$DiscoveredServers = Get-AzMigrateDiscoveredServer -ProjectName
ApplianceName MyMigrateAppliance
6. Initialize replication infrastructure

Migration and modernization leverages multiple Azure resources for migrating VMs.
Migration and modernization provisions the following resources, in the same resource
group as the project.
Service bus: Migration and modernization uses the service bus to send replication
orchestration messages to the appliance.
Gateway storage account: Migration and modernization uses the gateway storage
account to store state information about the VMs being replicated.
Log storage account: The Azure Migrate appliance uploads replication logs for
VMs to a log storage account. Azure Migrate applies the replication information to
the replica-managed disks.
Key vault: The Azure Migrate appliance uses the key vault to manage connection
strings for the service bus, and access keys for the storage accounts used in
replication.
Before replicating the first VM in the Azure Migrate project, run the following command
to provision the replication infrastructure. This command provisions and configures the
aforementioned resources so that you can start migrating your VMware VMs.
７ Note
One Azure Migrate project supports migrations to one Azure region only. Once you
run this script, you can't change the target region to which you want to migrate
your VMware VMs. You'll need to run the Initialize-
AzMigrateReplicationInfrastructure command if you configure a new appliance in
your Azure Migrate project.
In the article, we'll initialize the replication infrastructure so that we can migrate our VMs
to Central US region.
Azure PowerShell
# Initialize replication infrastructure for the current Migrate project

Initialize-AzMigrateReplicationInfrastructure -ResourceGroupName
$ResourceGroup.ResourceGroupName -ProjectName $MigrateProject. Name -
Scenario agentlessVMware -TargetRegion "CentralUS"
7. Replicate VMs
After completing discovery and initializing replication infrastructure, you can begin
replication of VMware VMs to Azure. You can run up to 500 replications simultaneously.
You can specify the replication properties as follows.
Parameter Type Description
Target Mandatory Specify the subscription and resource group that the VM should be
subscription migrated to by providing the resource group ID using the
and resource ( TargetResourceGroupId ) parameter.
group
Target virtual Mandatory Specify the ID of the Azure Virtual Network and the name of the
network and subnet that the VM should be migrated to by using the
subnet ( TargetNetworkId ) and ( TargetSubnetName ) parameters respectively.
Machine ID Mandatory Specify the ID of the discovered machine that needs to be replicated
and migrated. Use ( InputObject ) to specify the discovered VM
object for replication.
Target VM Mandatory Specify the name of the Azure VM to be created by using the
name ( TargetVMName ) parameter.
Target VM Mandatory Specify the Azure VM size to be used for the replicating VM by
size using ( TargetVMSize ) parameter. For instance, to migrate a VM to
D2_v2 VM in Azure, specify the value for ( TargetVMSize ) as
"Standard_D2_v2".
License Mandatory To use Azure Hybrid Benefit for your Windows Server machines that
are covered with active Software Assurance or Windows Server
subscriptions, specify the value for ( LicenseType ) parameter as
WindowsServer. Otherwise, specify the value as NoLicenseType.
OS Disk Mandatory Specify the unique identifier of the disk that has the operating
system bootloader and installer. The disk ID to be used is the unique
identifier (UUID) property for the disk retrieved using the Get-
AzMigrateDiscoveredServer cmdlet.
Disk Type Mandatory Specify the type of disk to be used.

Infrastructure Optional Specify infrastructure redundancy option as follows.

redundancy
- Availability Zone to pin the migrated machine to a specific
Availability Zone in the region. Use this option to distribute servers
that form a multi-node application tier across Availability Zones. This
option is only available if the target region selected for the
migration supports Availability Zones. To use availability zones,
specify the availability zone value for ( TargetAvailabilityZone )
parameter.
- Availability Set to place the migrated machine in an Availability
Set. The target Resource Group that was selected must have one or
more availability sets to use this option. To use availability set,
specify the availability set ID for ( TargetAvailabilitySet ) parameter.
Boot Optional To use a boot diagnostic storage account, specify the ID for
Diagnostic ( TargetBootDiagnosticStorageAccount ) parameter.
Storage - The storage account used for boot diagnostics should be in the
Account same subscription that you're migrating your VMs to.
- By default, no value is set for this parameter.
Tags Optional Add tags to your migrated virtual machines, disks, and NICs.
Use ( Tag ) to add tags to virtual machines, disks, and NICs.
or
Use ( VMTag ) for adding tags to your migrated virtual machines.
Use ( DiskTag ) for adding tags to disks.
Use ( NicTag ) for adding tags to network interfaces.
For example, add the required tags to a variable $tags and pass the
variable in the required parameter. $tags =
@{Organization=”Contoso”}
Replicate VMs with all disks

In this tutorial, we'll replicate all the disks of the discovered VM and specify a new name
for the VM in Azure. We specify the first disk of the discovered server as OS Disk and
migrate all disks as Standard HDD. The OS disk is the disk that has the operating system
bootloader and installer. The cmdlet returns a job that can be tracked for monitoring the
status of the operation.
Azure PowerShell
# Retrieve the resource group that you want to migrate to

$TargetResourceGroup = Get-AzResourceGroup -Name MyTargetResourceGroup
Azure PowerShell
# Retrieve the Azure virtual network and subnet that you want to migrate to
$TargetVirtualNetwork = Get-AzVirtualNetwork -Name MyVirtualNetwork
Azure PowerShell
# Start replication for a discovered VM in an Azure Migrate project

$MigrateJob = New-AzMigrateServerReplication -InputObject $DiscoveredServer
-TargetResourceGroupId $TargetResourceGroup.ResourceId -TargetNetworkId
$TargetVirtualNetwork.Id -LicenseType NoLicenseType -OSDiskID
$DiscoveredServer.Disk[0].Uuid -TargetSubnetName
$TargetVirtualNetwork.Subnets[0].Name -DiskType Standard_LRS -TargetVMName
MyMigratedTestVM -TargetVMSize Standard_DS2_v2
Azure PowerShell
# Track job status to check for completion

while (($MigrateJob.State -eq 'InProgress') -or ($MigrateJob.State -eq
'NotStarted')){
#If the job hasn't completed, sleep for 10 seconds before checking
the job status again
sleep 10;
$MigrateJob = Get-AzMigrateJob -InputObject $MigrateJob
}
#Check if the Job completed successfully. The updated job state of a
successfully completed job should be "Succeeded".
Write-Output $MigrateJob.State
Replicate VMs with select disks

You can also selectively replicate the disks of the discovered VM by using New-
AzMigrateDiskMapping cmdlet and providing that as an input to the ( DiskToInclude )
parameter in the New-AzMigrateServerReplication cmdlet. You can also use New-
AzMigrateDiskMapping cmdlet to specify different target disk types for each individual
disk to be replicated.
Specify values for the following parameters of the New-AzMigrateDiskMapping cmdlet.
DiskId - Specify the unique identifier for the disk to be migrated. The disk ID to be
used is the unique identifier (UUID) property for the disk retrieved using the Get-
IsOSDisk - Specify "true" if the disk to be migrated is the OS disk of the VM, else
"false".
DiskType - Specify the type of disk to be used in Azure.
In the following example, we'll replicate only two disks of the discovered VM. We'll
specify the OS disk and use different disk types for each disk to be replicated. The
cmdlet returns a job which can be tracked for monitoring the status of the operation.
Azure PowerShell
# View disk details of the discovered server

Write-Output $DiscoveredServer.Disk
Azure PowerShell
# Create a new disk mapping for the disks to be replicated

$DisksToReplicate = @()
$OSDisk = New-AzMigrateDiskMapping -DiskID $DiscoveredServer.Disk[0].Uuid -
DiskType StandardSSD_LRS -IsOSDisk true
$DataDisk = New-AzMigrateDiskMapping -DiskID $DiscoveredServer.Disk[1].Uuid
-DiskType Premium_LRS -IsOSDisk false
$DisksToReplicate += $OSDisk
$DisksToReplicate += $DataDisk
Azure PowerShell
# Retrieve the resource group that you want to migrate to

$TargetResourceGroup = Get-AzResourceGroup -Name MyTargetResourceGroup
Azure PowerShell
# Retrieve the Azure virtual network and subnet that you want to migrate to
$TargetVirtualNetwork = Get-AzVirtualNetwork -Name MyVirtualNetwork
Azure PowerShell
# Start replication for the VM

$MigrateJob = New-AzMigrateServerReplication -InputObject $DiscoveredServer
-TargetResourceGroupId $TargetResourceGroup.ResourceId -TargetNetworkId
$TargetVirtualNetwork.Id -LicenseType NoLicenseType -DiskToInclude
$DisksToReplicate -TargetSubnetName $TargetVirtualNetwork.Subnets[0].Name -
TargetVMName MyMigratedTestVM -TargetVMSize Standard_DS2_v2
Azure PowerShell

'NotStarted')){
sleep 10;
}
# Check if the Job completed successfully. The updated job state of a
8. Monitor replication
replicated to replica-managed disks in Azure.
Track the status of the replication by using the Get-AzMigrateServerReplication cmdlet.
Azure PowerShell
# List replicating VMs and filter the result for selecting a replicating VM.
This cmdlet will not return all properties of the replicating VM.
$ReplicatingServer = Get-AzMigrateServerReplication -ProjectName
MachineName MyTestVM
Azure PowerShell
# Retrieve all properties of a replicating VM

$ReplicatingServer = Get-AzMigrateServerReplication -TargetObjectID
$ReplicatingServer.Id
You can track the Migration State and Migration State Description properties in the
output.
For initial replication, the values for Migration State and Migration State
Description properties will be InitialSeedingInProgress and Initial replication
respectively.
During delta replication, the values for Migrate State and Migration State
Description properties will be Replicating and Ready to migrate respectively.
After you complete the migration, the values for Migrate State and Migration
State Description properties will be Migration succeeded and Migrated
respectively.
Output
AllowedOperation : {DisableMigration, TestMigrate, Migrate}

CurrentJobId :
/Subscriptions/xxx/resourceGroups/xxx/providers/Micr
osoft.RecoveryServices/vaults/xxx/replicationJobs/None
CurrentJobName : None
CurrentJobStartTime : 1/1/1753 1:01:01 AM
EventCorrelationId : 9d435c55-4660-41a5-a8ed-dd74213d85fa
Health : Normal
HealthError : {}
Id :
osoft.RecoveryServices/vaults/xxx/replicationFabrics/xxx/replicationProtecti
onContainers/xxx/
replicationMigrationItems/10-150-8-52-
b090bef3-b733-5e34-bc8f-eb6f2701432a_5009e941-3e40-
39b2-1e14-f90584522703
LastTestMigrationStatus :
LastTestMigrationTime :
Location :
MachineName : MyTestVM
MigrationState : InitialSeedingInProgress
MigrationStateDescription : Initial replication
Name : 10-150-8-52-b090bef3-b733-5e34-bc8f-
eb6f2701432a_5009e941-3e40-39b2-1e14-f90584522703
PolicyFriendlyName : xxx
PolicyId :
osoft.RecoveryServices/vaults/xxx/replicationPolicies/xxx
ProviderSpecificDetail :
Microsoft.Azure.PowerShell.Cmdlets.Migrate.Models.Api20180110.VMwareCbtMigra
tionDetails
TestMigrateState : None
TestMigrateStateDescription : None
Type :
Microsoft.RecoveryServices/vaults/replicationFabrics/replicationProtectionCo
ntainers/replicationMigrationItems
For details on replication progress, run the following cmdlet.
Azure PowerShell
Write-Output $replicatingserver.ProviderSpecificDetail
You can track the initial replication progress using the Initial Seeding Progress
Percentage properties in the output.
Output
"DataMoverRunAsAccountId":
"/subscriptions/xxx/resourceGroups/xxx/providers/Microsoft.OffAzure/VMwareSi
tes/xxx/runasaccounts/xxx",
"FirmwareType": "BIOS",
"InitialSeedingProgressPercentage": 20,
"InstanceType": "VMwareCbt",
"LastRecoveryPointReceived": "\/Date(1601733591427)\/",
"LicenseType": "NoLicenseType",
"MigrationProgressPercentage": null,
"MigrationRecoveryPointId": null,
"OSType": "Windows",
"PerformAutoResync": "true",
replicated to replica-managed disks in Azure.
9. Retrieve the status of a job

You can monitor the status of a job by using the Get-AzMigrateJob cmdlet.
Azure PowerShell
# Retrieve the updated status for a job

$job = Get-AzMigrateJob -InputObject $job
10. Update properties of a replicating VM

Migration and modernization allows you to change target properties, such as name,
size, resource group, NIC configuration and so on, for a replicating VM.
The following properties can be updated for a VM.

VM Name Optional Specify the name of the Azure VM to be created by using the
[ TargetVMName ] parameter.
VM size Optional Specify the Azure VM size to be used for the replicating VM by using
[ TargetVMSize ] parameter. For instance, to migrate a VM to D2_v2 VM in
Azure, specify the value for [ TargetVMSize ] as Standard_D2_v2 .
Virtual Optional Specify the ID of the Azure Virtual Network that the VM should be
Network migrated to by using the [ TargetNetworkId ] parameter.
Resource Optional IC configuration can be specified using the New-AzMigrateNicMapping

Group cmdlet. The object is then passed an input to the [ NicToUpdate ]
parameter in the Set-AzMigrateServerReplication cmdlet.
- Change IP allocation - To specify a static IP for a NIC, provide the IPv4

address to be used as static IP for the VM using the [ TargetNicIP ]
parameter. To dynamically assign an IP for a NIC, provide auto as the
value for the TargetNicIP parameter.
- Use values Primary , Secondary or DoNotCreate for
[ TargetNicSelectionType ] parameter to specify whether the NIC should
be primary, secondary, or is not to be created on the migrated VM. Only
one NIC can be specified as the primary NIC for the VM.
- To make a NIC primary, you'll also need to specify the other NICs that
should be made secondary or are not to be created on the migrated VM.
- To change the subnet for the NIC, specify the name of the subnet by
using the [ TargetNicSubnet ] parameter.
Network Optional Specify the name of the Azure VM to be created by using the
Interface [ TargetVMName ] parameter.
Availability Optional To use availability zones, specify the availability zone value for
Zone [ TargetAvailabilityZone ] parameter.
Availability Optional To use availability set, specify the availability set ID for
Set [ TargetAvailabilitySet ] parameter.
Tags Optional For updating tags, use the following parameters [ UpdateTag ] or
[ UpdateVMTag ], [ UpdateDiskTag ], [ UpdateNicTag ], and type of update tag
operation [ UpdateTagOperation ] or [ UpdateVMTagOperation ],
[ UpdateDiskTagOperation ], [ UpdateNicTagOperation ]. The update tag
operation takes the following values – Merge, Delete, and Replace.
Use [ UpdateTag ] to update all tags across virtual machines, disks, and
NICs.
Use [ UpdateVMTag ] for updating virtual machine tags.
Use [ UpdateDiskTag ] for updating disk tags.
Use [ UpdateNicTag ] for updating NIC tags.
Use [ UpdateTagOperation ] to update the operation for all tags across
virtual machines, disks, and NICs.
Use [ UpdateVMTagOperation ] for updating virtual machine tags.
Use [ UpdateDiskTagOperation ] for updating disk tags.
Use [ UpdateNicTagOperation ] for updating NIC tags.
The replace option replaces the entire set of existing tags with a new set.
The merge option allows adding tags with new names and updating the
values of tags with existing names.
The delete option allows selectively deleting tags based on given names
or name/value pairs.
Disk(s) Optional For the OS disk:

Update the name of the OS disk by using the [ TargetDiskName ]
parameter.
For updating multiple disks:

Use Set-AzMigrateDiskMapping to set the disk names to a variable
$DiskMapping and then use the [ DiskToUpdate ] parameter and pass
along the variable.
Note: The disk ID to be used in Set-AzMigrateDiskMapping is the unique

identifier (UUID) property for the disk retrieved using the Get-
NIC(s) Optional Use New-AzMigrateNicMapping to set the NIC names to a variable

name $NICMapping and then use the [ NICToUpdate ] parameter and pass the
variable.
The Get-AzMigrateServerReplication cmdlet returns a job which can be tracked for

monitoring the status of the operation.
Azure PowerShell
# List replicating VMs and filter the result for selecting a replicating VM.
This cmdlet will not return all properties of the replicating VM.
$ReplicatingServer = Get-AzMigrateServerReplication -ProjectName
MachineName MyTestVM
Azure PowerShell
# Retrieve all properties of a replicating VM

$ReplicatingServer = Get-AzMigrateServerReplication -TargetObjectID
$ReplicatingServer.Id
# View NIC details of the replicating server

Write-Output $ReplicatingServer.ProviderSpecificDetail.VMNic
In the following example, we'll update the NIC configuration by making the first NIC as
primary and assigning a static IP to it. we'll discard the second NIC for migration, update
the target VM name & size, and customizing NIC names.
Azure PowerShell
# Specify the NIC properties to be updated for a replicating VM.

$NicMapping = @()
$NicMapping1 = New-AzMigrateNicMapping -NicId
$ReplicatingServer.ProviderSpecificDetail.VMNic[0].NicId -TargetNicIP
###.###.###.### -TargetNicSelectionType Primary TargetNicName "ContosoNic_1"
$NicMapping2 = New-AzMigrateNicMapping -NicId
$ReplicatingServer.ProviderSpecificDetail.VMNic[1].NicId -
TargetNicSelectionType DoNotCreate - TargetNicName "ContosoNic_2"
$NicMapping += $NicMapping1
$NicMapping += $NicMapping2
Azure PowerShell
# Update the name, size and NIC configuration of a replicating server

$UpdateJob = Set-AzMigrateServerReplication -InputObject $ReplicatingServer
-TargetVMSize Standard_DS13_v2 -TargetVMName MyMigratedVM -NicToUpdate
$NicMapping
In the following example, we'll customize the disk name.
Azure PowerShell
# Customize the Disk names for a replicating VM

$OSDisk = Set-AzMigrateDiskMapping -DiskID "6000C294-1217-dec3-bc18-
81f117220424" -DiskName "ContosoDisk_1"
$DataDisk1= Set-AzMigrateDiskMapping -DiskID "6000C292-79b9-bbdc-fb8a-
f1fa8dbeff84" -DiskName "ContosoDisk_2"
$DiskMapping = $OSDisk, $DataDisk1
Azure PowerShell
# Update the disk names for a replicating server

$UpdateJob = Set-AzMigrateServerReplication InputObject $ReplicatingServer
DiskToUpdate $DiskMapping
In the following example, we'll add tags to the replicating VMs.
Azure PowerShell
# Update all tags across virtual machines, disks, and NICs.

Set-azmigrateserverreplication UpdateTag $UpdateTag UpdateTagOperation
Merge/Replace/Delete
# Update virtual machines tags

Set-azmigrateserverreplication UpdateVMTag $UpdateVMTag UpdateVMTagOperation
Merge/Replace/Delete
Use the following example to track the job status
Azure PowerShell

while (($UpdateJob.State -eq 'InProgress') -or ($UpdateJob.State -eq
'NotStarted')){
sleep 10;
$UpdateJob = Get-AzMigrateJob -InputObject $UpdateJob
}
Write-Output $UpdateJob.State
11. Run a test migration

When delta replication begins, you can run a test migration for the VMs before running
a full migration to Azure. We highly recommend that you do test migration at least once
for each machine before you migrate it. The cmdlet returns a job which can be tracked
for monitoring the status of the operation.
Running a test migration checks that migration will work as expected. Test
migration doesn't impact the on-premises machine, which remains operational,
and continues replicating.
Select the Azure Virtual Network to be used for testing by specifying the ID of the virtual
network using the [ TestNetworkID ] parameter.
Azure PowerShell
# Retrieve the Azure virtual network created for testing

$TestVirtualNetwork = Get-AzVirtualNetwork -Name MyTestVirtualNetwork
Azure PowerShell
# Start test migration for a replicating server

$TestMigrationJob = Start-AzMigrateTestMigration -InputObject
$ReplicatingServer -TestNetworkID $TestVirtualNetwork.Id
Azure PowerShell

while (($TestMigrationJob.State -eq 'InProgress') -or
($TestMigrationJob.State -eq 'NotStarted')){
sleep 10;
$TestMigrationJob = Get-AzMigrateJob -InputObject $TestMigrationJob
}
Write-Output $TestMigrationJob.State
After testing is complete, clean-up the test migration using the Start-
AzMigrateTestMigrationCleanup cmdlet. The cmdlet returns a job that can be tracked
for monitoring the status of the operation.
Azure PowerShell
# Clean-up test migration for a replicating server

$CleanupTestMigrationJob = Start-AzMigrateTestMigrationCleanup -InputObject
$ReplicatingServer
Azure PowerShell

while (($CleanupTestMigrationJob.State -eq "InProgress") -or
($CleanupTestMigrationJob.State -eq "NotStarted")){
sleep 10;
$CleanupTestMigrationJob = Get-AzMigrateJob -InputObject
$CleanupTestMigrationJob
}
Write-Output $CleanupTestMigrationJob.State
12. Migrate VMs

After you've verified that the test migration works as expected, you can migrate the
replicating server using the following cmdlet. The cmdlet returns a job that can be
tracked for monitoring the status of the operation.
If you don't want to turn-off the source server, then don't use [ TurnOffSourceServer ]
parameter.
Azure PowerShell
# Start migration for a replicating server and turn off source server as
part of migration
$MigrateJob = Start-AzMigrateServerMigration -InputObject $ReplicatingServer
-TurnOffSourceServer
Azure PowerShell

'NotStarted')){
sleep 10;
}
#Check if the Job completed successfully. The updated job state of a
13. Complete the migration

1. After the migration is done, stop replication for the on-premises machine and
clean-up replication state information for the VM using the following cmdlet. The
cmdlet returns a job that can be tracked for monitoring the status of the operation.
Azure PowerShell
# Stop replication for a migrated server

$StopReplicationJob = Remove-AzMigrateServerReplication -InputObject
$ReplicatingServer
Azure PowerShell

while (($StopReplicationJob.State -eq 'InProgress') -or
($StopReplicationJob.State -eq 'NotStarted')){
#If the job hasn't completed, sleep for 10 seconds before
checking the job status again
sleep 10;
$StopReplicationJob = Get-AzMigrateJob -InputObject
$StopReplicationJob
}
Write-Output $StopReplicationJob.State
2. Perform any post-migration app tweaks, such as updating database connection

strings, and web server configurations.

the Azure VMs.
14. Post-migration best practices

Learn more.
Groups.
for Cloud .
spending.
Migrate Hyper-V VMs to Azure
This article shows you how to migrate on-premises Hyper-V VMs to Azure with the
Migration and modernization tool.
This tutorial is the third in a series that demonstrates how to assess and migrate
machines to Azure.
７ Note
＂ Add the Migration and modernization tool.

＂ Discover VMs you want to migrate.
Prerequisites
1. Review the Hyper-V migration architecture.

2. Review Hyper-V host requirements for migration, and the Azure URLs to which
Hyper-V hosts and clusters need access for VM migration.
3. Review the requirements for Hyper-V VMs that you want to migrate to Azure.
4. We recommend that you assess Hyper-V VMs before migrating them to Azure, but
you don't have to.
5. Go to the already created project or create a new project.
6. Verify permissions for your Azure account - Your Azure account needs permissions
to create a VM, and write to an Azure managed disk.
Download the provider

For migrating Hyper-V VMs, the Migration and modernization tool installs software
providers (Microsoft Azure Site Recovery provider and Microsoft Azure Recovery Service
agent) on Hyper-V Hosts or cluster nodes. Note that the Azure Migrate appliance isn't
used for Hyper-V migration.
modernization, select Discover.
2. In Discover machines > Are your machines virtualized?, select Yes, with Hyper-V.
machines.
5. Click Create resources. This creates an Azure Site Recovery vault in the
background.
If you've already set up migration with the Migration and modernization tool,
this option won't appear since resources were set up previously.
You can't change the target region for this project after clicking this button.
All subsequent migrations are to this region.
6. In Prepare Hyper-V host servers, download the Hyper-V Replication provider, and
the registration key file.
The registration key is needed to register the Hyper-V host with the
The key is valid for five days after you generate it.
7. Copy the provider setup file and registration key file to each Hyper-V host (or
cluster node) running VMs you want to replicate.
Install and register the provider
Copy the provider setup file and registration key file to each Hyper-V host (or cluster
node) running VMs you want to replicate. To install and register the provider, follow the
steps below using either the UI or commands:
Using UI
Run the provider setup file on each host, as described below:
1. Select the file icon in the taskbar to open the folder where the installer file and
registration key are downloaded.
2. Select AzureSiteRecoveryProvider.exe file.
In the provider installation wizard, ensure On (recommended) is

checked, and then select Next.
Select Install to accept the default installation folder.
Select Register to register this server in Azure Site Recovery vault.
Select Browse.
Locate the registration key and select Open.
Select Next.
Ensure Connect directly to Azure Site Recovery without a proxy server
is selected, and then select Next.
Select Finish.
After installing the provider on hosts, go to the Azure portal and in Discover machines,
select Finalize registration.
It can take up to 15 minutes after finalizing registration until discovered VMs appear in
the Migration and modernization tile. As VMs are discovered, the Discovered servers
count rises.
Replicate Hyper-V VMs
With discovery completed, you can begin the replication of Hyper-V VMs to Azure.
７ Note
You can replicate up to 10 machines together. If you need to replicate more, then
replicate them simultaneously in batches of 10.
2. In Replicate > Source settings > Are your machines virtualized?, select Yes, with
Hyper-V. Then click Next: Virtual machines.
3. In Virtual machines, select the machines you want to replicate.
If you've run an assessment for the VMs, you can apply VM sizing and disk
type (premium/standard) recommendations from the assessment results. To
do this, in Import migration settings from an Azure Migrate assessment?,
select the Yes option.
If you didn't run an assessment, or you don't want to use the assessment
settings, select the No option.
If you selected to use the assessment, select the VM group, and assessment
name.
4. In Virtual machines, search for VMs as needed, and check each VM you want to
migrate. Then, select Next: Target settings.

5. In Target settings, select the target region to which you'll migrate, the
subscription, and the resource group in which the Azure VMs will reside after
migration.
6. In Replication Storage Account, select the Azure Storage account in which

replicated data will be stored in Azure.
7. Virtual Network, select the Azure VNet/subnet to which the Azure VMs will be

Select No if you don't want to apply Azure Hybrid Benefit. Then, select Next.
the benefit to the machines you're migrating. Then select Next.

dropdown will contain the recommended size. Otherwise Azure Migrate picks
a size based on the closest match in the Azure subscription. Alternatively, pick
a manual size in Azure VM size.
Availability Set: If the VM should be in an Azure availability set after
migration, specify the set. The set must be in the target resource group you
specify for the migration.
11. In Disks, specify the VM disks that need to be replicated to Azure. Then select
Next.

If you exclude disks, won't be present on the Azure VM after migration.

13. In Review and start replication, review the settings, and select Replicate to start
the initial replication for the servers.
７ Note
You can update replication settings any time before replication starts, in Manage >
Provision for the first time

If this is the first VM you're replicating in the Azure Migrate project, the Migration and
modernization tool automatically provisions these resources in same resource group as
the project.
Cache storage account: The Azure Site Recovery provider software installed on
Hyper-V hosts uploads replication data for the VMs configured for replication to a
storage account (known as the cache storage account, or log storage account) in
your subscription. The Azure Migrate service then copies the uploaded replication
data from the storage account to the replica-managed disks corresponding to the
VM. The cache storage account needs to be specified while configuring replication
for a VM and The Azure Migrate portal automatically creates one for the Azure
Migrate project when replication is configured for the first time in the project.
Track and monitor

When you select Replicate, a Start Replication job begins.
on-premises disks are periodically replicated to Azure.
You can track job status in the portal notifications.
You can monitor replication status by clicking on Replicating servers in Migration and
modernization.

replicating.
data (usually migrating to a non-production Azure VNet in your Azure
subscription).

2. Right-click the VM to test, and select Test migrate.
3. In Test Migration, select the Azure virtual network in which the Azure VM will be
located after the migration. We recommend you use a non-production virtual
network.
6. After the test is done, right-click the Azure VM in Replications, and select Clean up
test migration.
７ Note
Select Manage > Replications > Machine containing SQL server >
Compute and Network and select yes to register with SQL VM RP.
migrating.hs.
Migrate VMs
premises machines.
By default Azure Migrate shuts down the on-premises VM, and runs an on-
demand replication to synchronize any VM changes that occurred since the
last replication occurred. This ensures no data loss.
If you don't want to shut down the VM, select No.
page.

following:

Removes the machine from the Replicating servers count in the Migration
and modernization tool.
the Azure VMs.

Learn more.
Groups.
for Cloud .
spending.
Next steps
Migrate machines as physical servers to
Azure
This article shows you how to migrate machines as physical servers to Azure, using the
Migration and modernization tool. Migrating machines by treating them as physical
servers is useful in a number of scenarios:
Migrate on-premises physical servers.

Migrate VMs virtualized by platforms such as Xen, KVM.
Migrate Hyper-V or VMware VMs, if for some reason you're unable to use the
standard migration process for Hyper-V, or VMware migration.
Migrate VMs running in private clouds.
Migrate VMs running in public clouds such as Amazon Web Services (AWS) or
Google Cloud Platform (GCP).
This tutorial is the third in a series that demonstrates how to assess and migrate physical
servers to Azure. In this tutorial, you learn how to:
＂ Prepare to use Azure with Migration and modernization.

＂ Check requirements for machines you want to migrate, and prepare a machine for
the Azure Migrate replication appliance that's used to discover and migrate
machines to Azure.
＂ Add the Migration and modernization tool in the Azure Migrate hub.
＂ Set up the replication appliance.
＂ Install the Mobility service on machines you want to migrate.
＂ Enable replication.
７ Note
don't show all possible settings and paths. For detailed instructions, review the
How-tos for Azure Migrate.
Prerequisites
Review the migration architecture.

Review the limitations related to migrating Windows Server 2008 servers to Azure.
Prepare Azure
Prepare Azure for migration with the Migration and modernization tool.
Task Details
Create an Azure Migrate Your Azure account needs Contributor or Owner permissions to
project create a new project.
Verify permissions for your Your Azure account needs permissions to create a VM, and write
Azure account to an Azure managed disk.

2. In Check access, find the relevant account, and click it to view permissions.
3. You should have Contributor or Owner permissions.
If you just created a free Azure account, you're the owner of your
subscription.

Assign the Virtual Machine Contributor role to the Azure account. This provides
permissions to:

Create an Azure network
） Important
Virtual Networks (VNets) are a regional service, so make sure you create your VNet
in the desired target Azure Region. For example: if you are planning on replicating
and migrating Virtual Machines from your on-premises environment to the East US
Azure Region, then your target VNet must be created in the East US Region. To
connect VNets in different regions refer to the Virtual network peering guide.
Set up an Azure virtual network (VNet). When you replicate to Azure, Azure VMs are
created and joined to the Azure VNet that you specify when you set up migration.

To prepare for physical server migration, you need to verify the physical server settings,
and prepare to deploy a replication appliance.
Check machine requirements for migration

Make sure machines comply with requirements for migration to Azure.
７ Note
When migrating physical machines, the Migration and modernization tool uses the
same replication architecture as agent-based disaster recovery in the Azure Site
Recovery service, and some components share the same code base. Some content
might link to Site Recovery documentation.
1. Verify physical server requirements.

2. Verify that on-premises machines that you replicate to Azure comply with Azure
VM requirements.
3. There are some changes needed on VMs before you migrate them to Azure.
For some operating systems, Azure Migrate makes these changes

automatically.
Azure. Review Windows and Linux changes you need to make.

The Migration and modernization tool uses a replication appliance to replicate machines
to Azure. The replication appliance runs the following components.
between on-premises and Azure, and manages data replication.
replication data; optimizes it with caching, compression, and encryption, and sends
it to a cache storage account in Azure.
Prepare for appliance deployment as follows:
You prepare a machine to host the replication appliance. Review the machine
requirements.
The replication appliance uses MySQL. Review the options for installing MySQL on
the appliance.
Review the Azure URLs required for the replication appliance to access public and
government clouds.
Review port access requirements for the replication appliance.
７ Note
The replication appliance shouldn't be installed on a source machine that you want
to replicate or on the Azure Migrate discovery and assessment appliance you may
have installed before.

The first step of migration is to set up the replication appliance. To set up the appliance
for physical server migration, you download the installer file for the appliance, and then
run it on the machine you prepared. After installing the appliance, you register it with
the Migration and modernization tool.
Download the replication appliance installer

1. In the Azure Migrate project > Servers, in Migration and modernization, select
Discover.
2. In Discover machines > Are your machines virtualized?, select Not
virtualized/Other.
machines.
background.
If you've already set up migration with Migration and modernization, the
target option can't be configured, since resources were set up previously.
All subsequent migrations are to this region.
７ Note
configured for private endpoint connectivity. Ensure that the private
endpoints are reachable from the replication appliance. Learn more

appliance.
7. In Download and install the replication appliance software, download the

appliance installer, and the registration key. You need to the key in order to
register the appliance. The key is valid for five days after it's downloaded.
8. Copy the appliance setup file and key file to the Windows Server 2016 machine
you created for the appliance.
9. After the installation completes, the Appliance configuration wizard will be

launched automatically (You can also launch the wizard manually by using the
cspsconfigtool shortcut that is created on the desktop of the appliance). In this
tutorial, we'll be manually installing the Mobility Service on source VMs to be
replicated, so create a dummy account in this step and proceed. You can provide
the following details for creating the dummy account - "guest" as the friendly
name, "username" as the username, and "password" as the password for the
account. You will be using this dummy account in the Enable Replication stage.
10. After the appliance has restarted after setup, in Discover machines, select the new
appliance in Select Configuration Server, and click Finalize registration. Finalize
registration performs a couple of final tasks to prepare the replication appliance.
Mobility service agent needs to be installed on the servers to get them discovered using
replication appliance. Discovered machines appear in Azure Migrate: Server Migration.
As VMs are discovered, the Discovered servers count rises.
７ Note
It is recommended to perform discovery and asessment prior to the migration

using the Azure Migrate: Discovery and assessment tool, a separate lightweight
Azure Migrate appliance. You can deploy the appliance as a physical server to
continuously discover servers and performance metadata. For detailed steps, see
Discover physical servers.
Install the Mobility service

On machines you want to migrate, you need to install the Mobility service agent. The
agent installers are available on the replication appliance. You find the right installer, and
install the agent on each machine you want to migrate. Do this as follows:
1. Sign in to the replication appliance.

2. Navigate to %ProgramData%\ASR\home\svsystems\pushinstallsvc\repository.
3. Find the installer for the machine operating system and version. Review supported
operating systems.
4. Copy the installer file to the machine you want to migrate.
5. Make sure that you have the passphrase that was generated when you deployed
the appliance.
Store the file in a temporary text file on the machine.

You can obtain the passphrase on the replication appliance. From the
command line, run
C:\ProgramData\ASR\home\svsystems\bin\genpassphrase.exe -v to view
the current passphrase.
Don't regenerate the passphrase. This will break connectivity and you will
have to reregister the replication appliance.
７ Note
In the /Platform parameter, you specify VMware if you migrate VMware VMs, or
physical machines.
Install on Windows
1. Extract the contents of installer file to a local folder (for example C:\Temp) on the
machine, as follows:
ren Microsoft-ASR_UA*Windows*release.exe MobilityServiceInstaller.exe

MobilityServiceInstaller.exe /q /x:C:\Temp\Extracted
cd C:\Temp\Extracted
2. Run the Mobility Service Installer:
UnifiedAgent.exe /Role "MS" /Platform "VmWare" /Silent
3. Register the agent with the replication appliance:

cd C:\Program Files (x86)\Microsoft Azure Site Recovery\agent
UnifiedAgentConfigurator.exe /CSEndPoint <replication appliance IP
address> /PassphraseFilePath <Passphrase File Path>
Install on Linux
1. Extract the contents of the installer tarball to a local folder (for example
/tmp/MobSvcInstaller) on the machine, as follows:
mkdir /tmp/MobSvcInstaller
tar -C /tmp/MobSvcInstaller -xvf <Installer tarball>
cd /tmp/MobSvcInstaller
2. Run the installer script:
sudo ./install -r MS -v VmWare -q
/usr/local/ASR/Vx/bin/UnifiedAgentConfigurator.sh -i <replication
appliance IP address> -P <Passphrase File Path>
Replicate machines
Now, select machines for migration.
７ Note
You can replicate up to 10 machines together. If you need to replicate more, then
replicate them simultaneously in batches of 10.
1. In the Azure Migrate project > Servers, Migration and modernization, click
Replicate.
2. In Replicate, > Source settings > Are your machines virtualized?, select Not
virtualized/Other.
you set up.
5. In Guest credentials, please select the dummy account created previously during
the replication installer setup to install the Mobility service manually (push install is
not supported). Then click Next: Virtual machines.
6. In Virtual Machines, in Import migration settings from an assessment?, leave the

default setting No, I'll specify the migration settings manually.
8. In Target settings, select the subscription, and target region to which you'll
migrate, and specify the resource group in which the Azure VMs will reside after
migration.
10. In Cache storage account, keep the default option to use the cache storage
account that is automatically created for the project. Use the drop down if you'd
like to specify a different storage account to use as the cache storage account for
replication.
７ Note
If you selected private endpoint as the connectivity method for the

Azure Migrate project, grant the Recovery Services vault access to the
cache storage account. Learn more


７ Note

the disk type (standard SSD/HDD or premium managed disks) in Azure. Then click
Next.


７ Note
Track and monitor

When you click Replicate a Start Replication job begins.

modernization.

replicating.
1. In Migration goals > Servers > Migration and modernization, click Test migrated
servers.
3. In Test Migration, select the Azure VNet in which the Azure VM will be located
after the migration. We recommend you use a non-production VNet.

７ Note
migrating.hs.
Migrate VMs
premises machines.
modernization, click Replicating servers.
no data loss, select No > OK.
７ Note
For minimal data loss, the recommendation is to bring the application down
manually as part of the migration window (don't let the applications accept
any connections) and then initiate the migration. The server needs to be kept
running, so remaining changes can be synchronized before the migration is
completed.
page.

following:

Removes the machine from the Replicating servers count in the Migration
Cleans up replication state information for the machine.
the Azure VMs.

Learn more.
Groups.
for Cloud .
spending.
Next steps
Discover, assess, and migrate Amazon
Web Services (AWS) VMs to Azure
This tutorial shows you how to discover, assess, and migrate Amazon Web Services
(AWS) virtual machines (VMs) to Azure VMs, using Azure Migrate: Server Assessment
and Migration and modernization tools.
７ Note
You migrate AWS VMs to Azure by treating them as physical servers.
＂ Verify prerequisites for migration.

＂ Prepare Azure resources with the Migration and modernization tool. Set up
permissions for your Azure account and resources to work with Azure Migrate.
＂ Prepare AWS EC2 instances for migration.
＂ Set up the replication appliance and deploy the configuration server.
＂ Install the Mobility service on AWS VMs you want to migrate.
＂ Enable replication for VMs.
＂ Track and monitor the replication status.
Discover and assess

Before you migrate to Azure, we recommend that you perform a VM discovery and
migration assessment. This assessment helps right-size your AWS VMs for migration to
Azure, and estimate potential Azure run costs.
Set up an assessment as follows:
1. Follow the tutorial to set up Azure and prepare your AWS VMs for an assessment.
Note that:
Azure Migrate uses password authentication when discovering AWS
instances. AWS instances don't support password authentication by default.
Before you can discover instance, you need to enable password
authentication.
For Windows machines, allow WinRM port 5985 (HTTP). This allows remote
WMI calls.
For Linux machines:
a. Sign into each Linux machine.
b. Open the sshd_config file : vi /etc/ssh/sshd_config
c. In the file, locate the PasswordAuthentication line, and change the
value to yes.
d. Save the file and close it. Restart the ssh service.
If you're using a root user to discover your Linux VMs, ensure root login is
allowed on the VMs.
a. Sign into each Linux machine
b. Open the sshd_config file : vi /etc/ssh/sshd_config
c. In the file, locate the PermitRootLogin line, and change the value to yes.
2. Then, follow this tutorial to set up an Azure Migrate project and appliance to
discover and assess your AWS VMs.
Although we recommend that you try out an assessment, performing an assessment

isn’t a mandatory step to be able to migrate VMs.
Prerequisites
Ensure that the AWS VMs you want to migrate are running a supported OS version.
AWS VMs are treated like physical machines for the purpose of the migration.
Review the supported operating systems and kernel versions for the physical server
migration workflow. You can use standard commands like hostnamectl or uname -a
to check the OS and kernel versions for your Linux VMs. We recommend you
perform a test migration (test failover) to validate if the VM works as expected
before proceeding with the actual migration.
Make sure your AWS VMs comply with the supported configurations for migration
to Azure.
Verify that the AWS VMs that you replicate to Azure comply with Azure VM
requirements.
There are some changes needed on the VMs before you migrate them to Azure.
For some operating systems, Azure Migrate makes these changes automatically.
Prepare Azure resources for migration

Task Details

subscription.

permissions to:


Set up an Azure virtual network (VNet). When you replicate to Azure, the Azure VMs that
are created are joined to the Azure VNet that you specify when you set up migration.
Prepare AWS instances for migration

To prepare for AWS to Azure migration, you need to prepare and deploy a replication
appliance for migration.


between the AWS environment and Azure, and manages data replication.
replication data, optimizes it with caching, compression, and encryption, and sends
Set up a separate EC2 VM to host the replication appliance. This instance must be
running Windows Server 2012 R2 or Windows Server 2016. Review the hardware,
software, and networking requirements for the appliance.
The appliance shouldn't be installed on a source VM that you want to replicate or

on the Azure Migrate discovery and assessment appliance you may have installed
before. It should be deployed on a different VM.
The source AWS VMs to be migrated should have a network line of sight to the
replication appliance. Configure necessary security group rules to enable this. It's
recommended that the replication appliance is deployed in the same VPC as the
source VMs to be migrated. If the replication appliance needs to be in a different
VPC, the VPCs need to be connected through VPC peering.
The source AWS VMs communicate with the replication appliance on ports HTTPS
443 (control channel orchestration) and TCP 9443 (data transport) inbound for
replication management and replication data transfer. The replication appliance in
turn orchestrates and sends replication data to Azure over port HTTPS 443
outbound. To configure these rules, edit the security group inbound/outbound
rules with the appropriate ports and source IP information.
the appliance.
government clouds.

for AWS VMs migration, you must download the installer file for the appliance, and then
run it on the VM you prepared.

1. In the Azure Migrate project > Servers, databases and web apps, in Migration and
2. In Discover machines > Are your machines virtualized?, click Not
virtualized/Other.
machines.
4. Select Confirm that the target region for migration is <region-name>.
background.
the target option can't be configured, since resources were set up previously.
To migrate your VMs to a different region, you'll need to create a
new/different Azure Migrate project.
７ Note
endpoints are reachable from the replication appliance. Learn more

appliance.

8. Copy the appliance setup file and key file to the Windows Server 2016 or Windows
Server 2012 AWS VM you created for the replication appliance.
9. Run the replication appliance setup file, as described in the next procedure.
a. Under Before You Begin, select Install the configuration server and process
server, and then select Next.
b. In Third-Party Software License, select I accept the third-party license
agreement, and then select Next.
c. In Registration, select Browse, and then go to where you put the vault
registration key file. Select Next.
d. In Internet Settings, select Connect to Azure Site Recovery without a proxy
e. The Prerequisites Check page runs checks for several items. When it's finished,
select Next.
f. In MySQL Configuration, provide a password for the MySQL DB, and then select
Next.
g. In Environment Details, select No. You don't need to protect your VMs. Then,
select Next.
h. In Install Location, select Next to accept the default.
i. In Network Selection, select Next to accept the default.
j. In Summary, select Install.
k. Installation Progress shows you information about the installation process.
When it's finished, select Finish. A window displays a message about a reboot.
Select OK.
l. Next, a window displays a message about the configuration server connection
passphrase. Copy the passphrase to your clipboard and save the passphrase in a
temporary text file on the source VMs. You’ll need this passphrase later, during
the mobility service installation process.
account. You'll be using this dummy account in the Enable Replication stage.
11. After the appliance has restarted after setup, in Discover machines, select the new
appliance in Select Configuration Server, and click Finalize registration. Finalize
registration performs a couple of final tasks to prepare the replication appliance.
A Mobility service agent must be installed on the source AWS VMs to be migrated. The
install the agent on each machine you want to migrate. Do as follows:

3. Find the installer for the source AWS VMs operating system and version. Review
supported operating systems.
4. Copy the installer file to the source AWS VM you want to migrate.
5. Make sure that you have the saved passphrase text file that was created when you
installed the replication appliance.
If you forgot to save the passphrase, you can view the passphrase on the
replication appliance with this step. From the command line, run
Now, copy this passphrase to your clipboard and save it in a temporary text
file on the source VMs.
Installation guide for Windows AWS VMs

AWS VM, as follows:

UnifiedAgent.exe /Role "MS" /Silent

Installation guide for Linux AWS VMs

/tmp/MobSvcInstaller) on the AWS VM, as follows:
sudo ./install -r MS -q
Enable replication for AWS VMs
７ Note
Through the portal, you can add up to 10 VMs for replication at once. To replicate
more VMs simultaneously, you can add them in batches of 10.
virtualized/Other.
you set up.

migration.
account that is automatically created for the project. Use the dropdown if you'd
replication.
７ Note



７ Note

Next.


７ Note
Track and monitor replication status

When the Start Replication job finishes successfully, the VMs begin their initial
AWS VM disks are periodically replicated to the replica disks in Azure.
modernization.
a full migration to Azure. The test migration is highly recommended and provides an
opportunity to discover any potential issues and fix them before you proceed with the
actual migration. It's advised that you do this at least once for each VM before you
migrate it.
impacting the AWS VMs, which remain operational, and continue replicating.

７ Note
migrating.hs.
Migrate AWS VMs

After you've verified that the test migration works as expected, you can migrate the AWS
VMs.
７ Note
Automatic shutdown isn't supported while migrating AWS virtual machines.
4. A migration job starts for the VM. You can view the job status by clicking the
notification bell icon on the top right of the portal page or by going to the jobs
page of the Migration and modernization tool (Click Overview on the tool tile >
Select Jobs from the left menu).
page.

1. After the migration is done, right-click the VM > Stop migration. This does the
following:
Stops replication for the AWS VM.
Removes the AWS VM from the Replicating servers count in the Migration
the Azure VMs.

Learn more.
Groups.
for Cloud .
spending.
Troubleshooting / Tips
Question: I cannot see my AWS VM in the discovered list of servers for migration
Answer: Check if your replication appliance meets the requirements. Make sure Mobility
Agent is installed on the source VM to be migrated and is registered the Configuration
Server. Check the network setting and firewall rules to enable a network path between
the replication appliance and source AWS VMs.
Question: How do I know if my VM was successfully migrated

Answer: Post-migration, you can view and manage the VM from the Virtual Machines
page. Connect to the migrated VM to validate.
Question: I am unable to import VMs for migration from my previously created Server
Assessment results
Answer: Currently, we don't support the import of assessment for this workflow. As a
workaround, you can export the assessment and then manually select the VM
recommendation during the Enable Replication step.
Question: I am getting the error “Failed to fetch BIOS GUID” while trying to discover my
AWS VMs
Answer: Always use root login for authentication and not any pseudo user. Also review
supported operating systems for AWS VMs.
Question: My replication status is not progressing. Answer: Check if your replication

appliance meets the requirements. Make sure you’ve enabled the required ports on your
replication appliance TCP port 9443 and HTTPS 443 for data transport. Ensure that there
are no stale duplicate versions of the replication appliance connected to the same
project.
Question: I am unable to Discover AWS Instances using Azure Migrate due to HTTP
status code of 504 from the remote Windows management service
Answer: Make sure to review the Azure migrate appliance requirements and URL access
needs. Make sure no proxy settings are blocking the appliance registration.
Question: Do I have to make any changes before I migrate my AWS VMs to Azure
Answer: You may have to make these changes before migrating your EC2 VMs to Azure:
If you're using cloud-init for your VM provisioning, you may want to disable cloud-
init on the VM before replicating it to Azure. The provisioning steps performed
by cloud-init on the VM maybe AWS specific and won't be valid after the migration
to Azure.
If the VM is a PV VM (para-virtualized) and not HVM VM, you may not be able to
run it as-is on Azure because para-virtualized VMs use a custom boot sequence in
AWS. You may be able to get over this challenge by uninstalling PV drivers before
you perform a migration to Azure.
We always recommend you run a test migration before the final migration.
Question: Can I migrate AWS VMs running Amazon Linux Operating system
Answer: VMs running Amazon Linux can't be migrated as-is as Amazon Linux OS is only
supported on AWS. To migrate workloads running on Amazon Linux, you can spin up a
CentOS/RHEL VM in Azure and migrate the workload running on the AWS Linux
machine using a relevant workload migration approach. For example, depending on the
workload, there may be workload-specific tools to aid the migration – such as for
databases or deployment tools in case of web servers.
Next steps
 Documentation
Common questions about the Migration and modernization tool - Azure Migrate
Get answers to common questions about using Migration and modernization to migrate machines.
Troubleshoot assessments in Azure Migrate - Azure Migrate

Get help with assessment in Azure Migrate.
Migrate AWS VMs to Azure with Azure Migrate - Azure Site Recovery
This article describes options for migrating AWS instances to Azure, and recommends Azure Migrate.
Azure VM assessments in Azure Migrate - Azure Migrate

Learn about assessments in Azure Migrate
Migrate
Azure Migrate appliance - Azure Migrate

Provides a summary of support for the Azure Migrate appliance.
Discover servers running in a VMware environment with Azure Migrate Discovery and
assessment - Azure Migrate
Learn how to discover on-premises servers, applications, and dependencies in a VMware
environment by using the Azure Migrate Discovery and assessment tool.
Assess physical servers for migration to Azure with Azure Migrate - Azure Migrate
Describes how to assess on-premises physical servers for migration to Azure using Azure Migrate.
Show 5 more
 Training
Learning path
Migrate application workloads and data to Azure - Training
Migrate application workloads and data to Azure
Discover, assess, and migrate Google
Cloud Platform (GCP) VMs to Azure
This tutorial shows you how to discover, assess, and migrate Google Cloud Platform
(GCP) virtual machines (VMs) to Azure VMs, using Azure Migrate: Server Assessment and
Migration and modernization tools.
In this tutorial, you will learn how to:
＂ Verify prerequisites for migration.

＂ Prepare Azure resources with the Migration and modernization tool. Set up
permissions for your Azure account and resources to work with Azure Migrate.
＂ Prepare GCP VM instances for migration.
＂ Set up the replication appliance and deploy the configuration server.
＂ Install the Mobility service on GCP VMs you want to migrate.
＂ Enable replication for VMs.
＂ Track and monitor the replication status.
Discover and assess

Before you migrate to Azure, we recommend that you perform a VM discovery and
migration assessment. This assessment helps right-size your GCP VMs for migration to
Azure, and estimate potential Azure run costs.
Set up an assessment as follows:
1. Follow the tutorial to set up Azure and prepare your GCP VMs for an assessment.
Note that:
Azure Migrate uses password authentication when discovering GCP VM

instances. GCP instances don't support password authentication by default.
Before you can discover, you need to enable password authentication.
For Windows machines, allow WinRM port 5985 (HTTP). This allows remote
WMI calls.
For Linux machines:
a. Sign in to each Linux machine.
b. Open the sshd_config file: vi /etc/ssh/sshd_config
c. In the file, locate the PasswordAuthentication line, and change the
value to yes.
If you are using a root user to discover your Linux VMs, ensure root login is
allowed on the VMs.
a. Sign into each Linux machine
b. Open the sshd_config file: vi /etc/ssh/sshd_config
c. In the file, locate the PermitRootLogin line, and change the value to yes.
2. Then, follow this tutorial to set up an Azure Migrate project and appliance to
discover and assess your GCP VMs.
Although we recommend that you try out an assessment, performing an assessment

isn’t a mandatory step to be able to migrate VMs.
Prerequisites
Ensure that the GCP VMs you want to migrate are running a supported OS version.
GCP VMs are treated like physical machines for the purpose of the migration.
Review the supported operating systems and kernel versions for the physical server
migration workflow. You can use standard commands like hostnamectl or uname -a
to check the OS and kernel versions for your Linux VMs. We recommend you
perform a test migration to validate if the VM works as expected before
proceeding with the actual migration.
Make sure your GCP VMs comply with the supported configurations for migration
to Azure.
Verify that the GCP VMs that you replicate to Azure comply with Azure VM
requirements.
There are some changes needed on the VMs before you migrate them to Azure.
For some operating systems, Azure Migrate makes these changes automatically.
Prepare Azure resources for migration

Task Details

subscription.

permissions to:


Set up an Azure virtual network (VNet). When you replicate to Azure, the Azure VMs that
are created are joined to the Azure VNet that you specify when you set up migration.
Prepare GCP instances for migration

To prepare for GCP to Azure migration, you need to prepare and deploy a replication
appliance for migration.

between the GCP VMs and Azure, and manages data replication.
replication data, optimizes it with caching, compression, and encryption, and sends
Set up a separate GCP VM to host the replication appliance. This instance must be
running Windows Server 2012 R2 or Windows Server 2016. Review the hardware,
software, and networking requirements for the appliance.
The appliance shouldn't be installed on a source VM that you want to replicate or

on the Azure Migrate discovery and assessment appliance you may have installed
before. It should be deployed on a different VM.
The source GCP VMs to be migrated should have a network line of sight to the
replication appliance. Configure necessary Firewall rules to enable this. It is
recommended that the replication appliance is deployed in the same VPC network
as the source VMs to be migrated. If the replication appliance needs to be in a
different VPC, the VPCs need to be connected through VPC peering.
The source GCP VMs communicate with the replication appliance on ports HTTPS
443 (control channel orchestration) and TCP 9443 (data transport) inbound for
replication management and replication data transfer. The replication appliance in
turn orchestrates and sends replication data to Azure over port HTTPS 443
outbound. To configure these rules, edit the security group inbound/outbound
rules with the appropriate ports and source IP information.
the appliance.
government clouds.

for GCP VMs migration, you must download the installer file for the appliance, and then
run it on the VM you prepared.

1. In the Azure Migrate project > Servers, databases and web apps, in Migration and
2. In Discover machines > Are your machines virtualized?, click Not
virtualized/Other.
machines.
4. Select Confirm that the target region for migration is <region-name>.
background.
the target option can't be configured, since resources were set up previously.
To migrate your VMs to a different region, you'll need to create a
new/different Azure Migrate project.
７ Note
endpoints are reachable from the replication appliance: Learn more

appliance.

8. Copy the appliance setup file and key file to the Windows Server 2016 or Windows
Server 2012 GCP VM you created for the replication appliance.
9. Run the replication appliance setup file, as described in the next procedure.
9.1. Under Before You Begin, select Install the configuration server and process
9.2 In Third-Party Software License, select I accept the third-party license
agreement, and then select Next.
9.3 In Registration, select Browse, and then go to where you put the vault
registration key file. Select Next.
9.4 In Internet Settings, select Connect to Azure Site Recovery without a proxy
9.5 The Prerequisites Check page runs checks for several items. When it's finished,
select Next.
9.6 In MySQL Configuration, provide a password for the MySQL DB, and then
select Next.
9.7 In Environment Details, select No. You don't need to protect your VMs. Then,
select Next.
9.8 In Install Location, select Next to accept the default.
9.9 In Network Selection, select Next to accept the default.
9.10 In Summary, select Install.
9.11 Installation Progress shows you information about the installation process.
When it's finished, select Finish. A window displays a message about a reboot.
Select OK.
9.12 Next, a window displays a message about the configuration server connection
passphrase. Copy the passphrase to your clipboard and save the passphrase in a
temporary text file on the source VMs. You’ll need this passphrase later, during the
mobility service installation process.
account. You will be using this dummy account in the Enable Replication stage.

A Mobility service agent must be installed on the source GCP VMs to be migrated. The
install the agent on each machine you want to migrate. Do as follows:

3. Find the installer for the source GCP VMs operating system and version. Review
supported operating systems.
4. Copy the installer file to the source GCP VM you want to migrate.
5. Make sure that you have the saved passphrase text file that was created when you
installed the replication appliance.
If you forgot to save the passphrase, you can view the passphrase on the
replication appliance with this step. From the command line, run
Now, copy this passphrase to your clipboard and save it in a temporary text
file on the source VMs.
Installation guide for Windows GCP VMs

GCP VM, as follows:

UnifiedAgent.exe /Role "MS" /Silent

Installation guide for Linux GCP VMs
/tmp/MobSvcInstaller) on the GCP VM, as follows:
sudo ./install -r MS -q
Enable replication for GCP VMs
７ Note
Through the portal, you can add up to 10 VMs for replication at once. To replicate
more VMs simultaneously, you can add them in batches of 10.
virtualized/Other.
you set up.

migration.
account that is automatically created for the project. Use the dropdown if you'd
replication.
７ Note



７ Note

Next.


７ Note
Track and monitor replication status

When the Start Replication job finishes successfully, the VMs begin their initial
GCP VM disks are periodically replicated to the replica disks in Azure.
modernization.
a full migration to Azure. The test migration is highly recommended and provides an
opportunity to discover any potential issues and fix them before you proceed with the
actual migration. It is advised that you do this at least once for each VM before you
migrate it.
impacting the GCP VMs, which remain operational, and continue replicating.

７ Note
migrating.hs.
Migrate GCP VMs

After you've verified that the test migration works as expected, you can migrate the GCP
VMs.
modernization, click Replicating servers.
７ Note
Automatic shutdown is not supported while migrating GCP virtual machines.
4. A migration job starts for the VM. You can view the job status by clicking the
notification bell icon on the top right of the portal page or by going to the jobs
page of the Migration and modernization tool (Click Overview on the tool tile >
Select Jobs from the left menu).
page.

1. After the migration is done, right-click the VM > Stop migration. This does the
following:
Stops replication for the GCP VM.
Removes the GCP VM from the Replicating servers count in the Migration
the Azure VMs.

Learn more.
Groups.
for Cloud .
spending.
Troubleshooting / Tips
Question: I cannot see my GCP VM in the discovered list of servers for migration.
Answer: Check if your replication appliance meets the requirements. Make sure Mobility
Agent is installed on the source VM to be migrated and is registered the Configuration
Server. Check the firewall rules to enable a network path between the replication
appliance and source GCP VMs.
Question: How do I know if my VM was successfully migrated? Answer: Post-migration,

you can view and manage the VM from the Virtual Machines page. Connect to the
migrated VM to validate.
Question: I am unable to import VMs for migration from my previously created Server
Assessment results. Answer: Currently, we do not support the import of assessment for
this workflow. As a workaround, you can export the assessment and then manually
select the VM recommendation during the Enable Replication step.
Question: I am getting the error “Failed to fetch BIOS GUID” while trying to discover my
GCP VMs. Answer: Use root login for authentication and not any pseudo user. If you are
not able to use a root user, ensure the required capabilities are set on the user, as per
the instructions provided in the support matrix. Also review supported operating
systems for GCP VMs.
Question: My replication status is not progressing.

Answer: Check if your replication appliance meets the requirements. Make sure you’ve
enabled the required ports on your replication appliance TCP port 9443 and HTTPS 443
for data transport. Ensure that there are no stale duplicate versions of the replication
appliance connected to the same project.
Question: I am unable to Discover GCP Instances using Azure Migrate due to HTTP
status code of 504 from the remote Windows management service.
Answer: Make sure to review the Azure migrate appliance requirements and URL access
needs. Make sure no proxy settings are blocking the appliance registration.
Question: Do I have to make any changes before I migrate my GCP VMs to Azure?
Answer: You may have to make these changes before migrating your GCP VMs to Azure:
If you are using cloud-init for your VM provisioning, you may want
to disable cloud-init on the VM before replicating it to Azure. The provisioning
steps performed by cloud-init on the VM maybe GCP specific and won't be valid
after the migration to Azure.
Review the prerequisites section to determine whether there are any changes
necessary for the operating system before you migrate them to Azure.
We always recommend you run a test migration before the final migration.
Next steps
 Documentation
Discover, assess, and migrate Amazon Web Services (AWS) EC2 VMs to Azure - Azure
Migrate
This article describes how to migrate AWS VMs to Azure with Azure Migrate.
Azure VM assessments in Azure Migrate - Azure Migrate

Learn about assessments in Azure Migrate
Troubleshoot assessments in Azure Migrate - Azure Migrate

Get help with assessment in Azure Migrate.
Create an Azure VM assessment with Azure Migrate Discovery and assessment tool -
Azure Migrate
Describes how to create an Azure VM assessment with the Azure Migrate Discovery and assessment
tool
Assess on-premises servers using an imported CSV file with Azure Migrate Server
Assessment - Azure Migrate
Describes how to discover on-premises servers for migration to Azure using an imported CSV file in
Azure Migrate Server Assessment
Common questions about the Migration and modernization tool - Azure Migrate
Get answers to common questions about using Migration and modernization to migrate machines.
Migrate AWS VMs to Azure with Azure Migrate - Azure Site Recovery
This article describes options for migrating AWS instances to Azure, and recommends Azure Migrate.
Azure Migrate appliance - Azure Migrate

Provides a summary of support for the Azure Migrate appliance.
Show 5 more
 Training
Learning path
Migrate application workloads and data to Azure - Training
ASP.NET app containerization and
migration to Azure Kubernetes Service
Article • 04/24/2023
In this article, you'll learn how to containerize ASP.NET applications and migrate them to
Azure Kubernetes Service (AKS) using the Azure Migrate: App Containerization tool.
The containerization process doesn’t require access to your codebase and provides an
easy way to containerize existing applications. The tool works by using the running state
of the applications on a server to determine the application components and helps you
package them in a container image. The containerized application can then be deployed
on Azure Kubernetes Service (AKS).
The Azure Migrate: App Containerization tool currently supports:
Containerizing ASP.NET apps and deploying them on Windows containers on

Azure Kubernetes Service.
Azure App Service. Learn more.
Containerizing Java Web apps on Apache Tomcat (on Linux servers) and deploying
them on Linux containers on AKS. Learn more.
Containerizing Java Web apps on Apache Tomcat (on Linux servers) and deploying
them on Linux containers on App Service. Learn more.
The Azure Migrate: App Containerization tool helps you to:
Discover your application: The tool remotely connects to the application servers
running your ASP.NET application and discovers the application components. The
tool creates a Dockerfile that can be used to create a container image for the
application.
Build the container image: You can inspect and further customize the Dockerfile as
per your application requirements and use that to build your application container
image. The application container image is pushed to an Azure Container Registry
you specify.
Deploy to Azure Kubernetes Service: The tool then generates the Kubernetes
resource definition YAML files needed to deploy the containerized application to
your Azure Kubernetes Service cluster. You can customize the YAML files and use
them to deploy the application on AKS.
７ Note
The Azure Migrate: App Containerization tool helps you discover specific
application types (ASP.NET and Java web apps on Apache Tomcat) and their
components on an application server. To discover servers and the inventory of
apps, roles, and features running on on-premises machines, use Azure Migrate:
Discovery and assessment capability. Learn more
While all applications won't benefit from a straight shift to containers without significant
rearchitecting, some of the benefits of moving existing apps to containers without
rewriting include:
Improved infrastructure utilization - With containers, multiple applications can

share resources and be hosted on the same infrastructure. This can help you
consolidate infrastructure and improve utilization.
Simplified management - By hosting your applications on a modern managed
platform like AKS and App Service, you can simplify your management practices.
You can achieve this by retiring or reducing the infrastructure maintenance and
management processes that you'd traditionally perform with owned infrastructure.
Application portability - With increased adoption and standardization of container
specification formats and platforms, application portability is no longer a concern.
Adopt modern management with DevOps - Helps you adopt and standardize on
modern practices for management and security and transition to DevOps.

＂ Install the Azure Migrate: App Containerization tool.
＂ Discover your ASP.NET application.
＂ Build the container image.
＂ Deploy the containerized application on AKS.
７ Note
Prerequisites
Requirement Details
Identify a A Windows machine to install and run the Azure Migrate: App Containerization
machine to tool. The Windows machine could be a server (Windows Server 2016 or later) or
install the client (Windows 10) operating system, meaning that the tool can run on your
tool desktop as well.
The Windows machine running the tool should have network connectivity to the
servers/virtual machines hosting the ASP.NET applications to be containerized.
Ensure that 6-GB space is available on the Windows machine running the Azure
Migrate: App Containerization tool for storing application artifacts.
The Windows machine should have internet access, directly or via a proxy.
Install the Microsoft Web Deploy tool on the machine running the App
Containerization helper tool and application server if not already installed. You can
download the tool from here .
Application Enable PowerShell remoting on the application servers: Sign in to the application
servers server and follow these instructions to turn on PowerShell remoting.
If the application server is running Windows Server 2008 R2, ensure that
PowerShell 5.1 is installed on the application server. Follow the instruction here to
download and install PowerShell 5.1 on the application server.
Install the Microsoft Web Deploy tool on the machine running the App
Containerization helper tool and application server if not already installed. You can
download the tool from here .
ASP.NET The tool currently supports:

application - ASP.NET applications using Microsoft .NET framework 3.5 or later.
- Application servers running Windows Server 2008 R2 or later (application servers
should be running PowerShell version 5.1).
- Applications running on Internet Information Services (IIS) 7.5 or later.
The tool currently doesn't support:

- Applications requiring Windows authentication (The App Containerization tool
currently doesn't support gMSA).
- Applications that depend on other Windows services hosted outside IIS.

Once your subscription is set up, you need an Azure user account with:
Owner permissions on the Azure subscription.

Subscriptions.
5. Assign the following role. For detailed steps, see Assigning Azure roles using the
Azure portal.
Setting Value
Role Owner
Members azmigrateuser (in this example)

6. Your Azure account also needs permissions to register Azure Active Directory
apps.
default).
Download and install Azure Migrate: App

Containerization tool
1. Download the Azure Migrate: App Containerization installer on a Windows
machine.
2. Launch PowerShell in administrator mode and change the PowerShell directory to

the folder containing the installer.
3. Run the installation script using the command
PowerShell
.\AppContainerizationInstaller.ps1
Launch the App Containerization tool

1. Open a browser on any machine that can connect to the Windows machine
running the App Containerization tool, and open the tool URL: https://machine
name or IP address: 44369.
2. If you see a warning stating that says your connection isn’t private, select
Advanced and choose to proceed to the website. This warning appears as the web
interface uses a self-signed TLS/SSL certificate.
3. In the Sign in screen, use the local administrator account on the machine to sign
in.
4. Select ASP.NET web apps as the type of application you want to containerize.
5. To specify target Azure service, select Containers on Azure Kubernetes Service.

Complete tool prerequisites
2. In the tool web app > Set up prerequisites, do the following steps:
Connectivity: The tool checks that the Windows machine has internet access.
If the machine uses a proxy:
Select Set up proxy to specify the proxy address (in the form IP address or
FQDN) and listening port.
Specify credentials if the proxy needs authentication.
If you've added proxy details or disabled the proxy and/or authentication,
select Save to trigger connectivity check again.
Install updates: The tool will automatically check for latest updates and install
them. You can also manually install the latest version of the tool from here .
Install Microsoft Web Deploy tool: The tool will check that the Microsoft
Web Deploy tool is installed on the Windows machine running the Azure
Migrate: App Containerization tool.
Enable PowerShell remoting: The tool will inform you to ensure that
PowerShell remoting is enabled on the application servers running the
ASP.NET applications to be containerized.
Sign in to Azure
1. Select Sign in to sign in to your Azure account.
2. You'll need a device code to authenticate with Azure. Selecting on Sign in will open
a modal with the device code.
3. Select Copy code & sign in to copy the device code and open an Azure sign in
prompt in a new browser tab. If it doesn't appear, make sure you've disabled the
pop-up blocker in the browser.
4. On the new tab, paste the device code and complete the sign in using your Azure
account credentials. You can close the browser tab after sign in is complete and
return to the App Containerization tool screen.
5. Select the Azure tenant that you want to use.
6. Specify the Azure subscription that you want to use.
Discover ASP.NET applications

The App Containerization helper tool connects remotely to the application servers using
the provided credentials and attempts to discover ASP.NET applications hosted on the
application servers.
1. Specify the IP address/FQDN and the credentials of the server running the
ASP.NET application that should be used to remotely connect to the server for
application discovery.
The credentials provided must be for a local administrator (Windows) on the

application server.
For domain accounts (the user must be an administrator on the application
server), prefix the username with the domain name in the format
<domain\username>.
You can run application discovery for upto five servers at a time.
2. Select Validate to verify that the application server is reachable from the machine
running the tool and that the credentials are valid. Upon successful validation, the
status column will show the status as Mapped.
3. Select Continue to start application discovery on the selected application servers.
4. Upon successful completion of application discovery, you can select the list of
applications to containerize.
5. Use the checkbox to select the applications to containerize.
6. Specify container name: Specify a name for the target container for each selected
application. The container name should be specified as <name:tag> where the tag
is used for container image. For example, you can specify the target container
name as appname:v1.
Parameterize application configurations

Parameterizing the configuration makes it available as a deployment time parameter.
This allows you to configure this setting while deploying the application as opposed to
having it hard-coded to a specific value in the container image. For example, this option
is useful for parameters like database connection strings.
1. Select app configurations to review detected configurations.

2. Select the checkbox to parameterize the detected application configurations.
3. Select Apply after selecting the configurations to parameterize.
Externalize file system dependencies

You can add other folders that your application uses. Specify if they should be part of
the container image or are to be externalized through persistent volumes on Azure file
share. Using persistent volumes works great for stateful applications that store state
outside the container or have other static content stored on the file system. Learn more.
1. Select Edit under App Folders to review the detected application folders. The
detected application folders have been identified as mandatory artifacts needed by
the application and will be copied into the container image.
2. Select Add folders and specify the folder paths to be added.
3. To add multiple folders to the same volume, provide comma ( , ) separated values.
4. Select Persistent Volume as the storage option if you want the folders to be stored
outside the container on a Persistent Volume.
5. Select Save after reviewing the application folders.
6. Select Continue to proceed to the container image build phase.
Build container image
） Important
If you're using AKS 1.23+, edit the scripts as shown below before building the
docker image, to ensure a seamless migration.
Change the script below
PowerShell
# Run entrypoint script.

COPY ./Entryscript.ps1 c:/Entryscript.ps1
ENTRYPOINT powershell c:/Entryscript.ps1
to
PowerShell
# Run entrypoint script.

COPY ["./Entryscript.ps1", "c:/Entryscript.ps1"]
ENTRYPOINT ["powershell", "c:/Entryscript.ps1"]
To build a container image, follow these steps:
1. Select Azure Container Registry: Use the dropdown to select an Azure Container
Registry that will be used to build and store the container images for the apps. You
can use an existing Azure Container Registry or choose to create a new one using
the Create new registry option.
2. Review the Dockerfile: The Dockerfile needed to build the container images for
each selected application is generated at the beginning of the build step. Select
Review to review the Dockerfile. You can also add any necessary customizations to
the Dockerfile in the review step and save the changes before starting the build
process.
3. Trigger build process: Select the applications to build images for and select Build.
Selecting build will start the container image build for each application. The tool
keeps monitoring the build status continuously and will let you proceed to the
next step upon successful completion of the build.
4. Track build status: You can also monitor progress of the build step by selecting the
Build in Progress link under the status column. The link takes a couple of minutes
to be active after you've triggered the build process.
5. Once the build is completed, select Continue to specify deployment settings.
Deploy the containerized app on AKS

Once the container image is built, the next step is to deploy the application as a
container on Azure Kubernetes Service (AKS) .
1. Select the Azure Kubernetes Service Cluster: Specify the AKS cluster that the
application should be deployed to.
The selected AKS cluster must have a Windows node pool.

The cluster must be configured to allow pulling of images from the Azure
Container Registry that was selected to store the images.
Run the following command in Azure CLI to attach the AKS cluster to the
ACR.
Azure
az aks update -n <cluster-name> -g <cluster-resource-group> --

attach-acr <acr-name>
If you don’t have an AKS cluster or would like to create a new AKS cluster to
deploy the application to, you can choose to create on from the tool by
selecting Create new AKS cluster.
The AKS cluster created using the tool will be created with a Windows
node pool. The cluster will be configured to allow it to pull images from
the Azure Container Registry that was created earlier (if create new registry
option was chosen).
Select Continue after selecting the AKS cluster.
2. Specify secret store: If you had opted to parameterize application configurations,

then specify the secret store to be used for the application. You can choose Azure
Key Vault or App Service application settings for managing your application
secrets. Learn more
If you've selected App Service application settings for managing secrets, then
select Continue.
If you'd like to use an Azure Key Vault for managing your application secrets,
then specify the Azure Key Vault that you'd want to use.
If you don’t have an Azure Key Vault or would like to create a new Key
Vault, you can choose to create on from the tool by selecting Create new
Azure Key Vault.
The tool will automatically assign the necessary permissions for managing
secrets through the Key Vault.
3. Specify Azure file share: If you had added more folders and selected the Persistent
Volume option, then specify the Azure file share that should be used by Azure
Migrate: App Containerization tool during the deployment process. The tool will
create new directories in this Azure file share to copy over the application folders
that are configured for Persistent Volume storage. Once the application
deployment is complete, the tool will clean up the Azure file share by deleting the
directories it had created.
If you don't have an Azure file share or would like to create a new Azure file
share, you can choose to create on from the tool by selecting Create new
Storage Account and file share.
4. Application deployment configuration: Once you've completed the steps above,

you'll need to specify the deployment configuration for the application. Select
Configure to customize the deployment for the application. In the configure step
you can provide the following customizations:
Prefix string: Specify a prefix string to use in the name for all resources that
are created for the containerized application in the AKS cluster.
SSL certificate: If your application requires an https site binding, specify the
PFX file that contains the certificate to be used for the binding. The PFX file
shouldn't be password protected and the original site shouldn't have multiple
bindings.
Replica Sets: Specify the number of application instances (pods) that should
run inside the containers.
Load balancer type: Select External if the containerized application should be
reachable from public networks.
Application Configuration: For any application configurations that were
parameterized, provide the values to use for the current deployment.
Storage: For any application folders that were configured for Persistent
Volume storage, specify whether the volume should be shared across
application instances or should be initialized individually with each instance in
the container. By default, all application folders on Persistent Volumes are
configured as shared.
Select Apply to save the deployment configuration.
Select Continue to deploy the application.
5. Deploy the application: Once the deployment configuration for the application is
saved, the tool will generate the Kubernetes deployment YAML for the application.
Select Review to review and customize the Kubernetes deployment YAML for
the applications.
Select the application to deploy.
Select Deploy to start deployments for the selected applications
Once the application is deployed, you can select the Deployment status
column to track the resources that were deployed for the application.
Download generated artifacts

All artifacts that are used to build and deploy the application into AKS, including the
Dockerfile and Kubernetes YAML specification files, are stored on the machine running
the tool. The artifacts are located at C:\ProgramData\Microsoft Azure Migrate App
Containerization.
A single folder is created for each application server. You can view and download all
intermediate artifacts used in the containerization process by navigating to this folder.
The folder, corresponding to the application server, will be cleaned up at the start of
each run of the tool for a particular server.
Troubleshoot issues
To troubleshoot any issues with the tool, you can look at the log files on the Windows
machine running the App Containerization tool. Tool log files are located at
C:\ProgramData\Microsoft Azure Migrate App Containerization\Logs folder.
Next steps
Containerizing ASP.NET web apps and deploying them on Windows containers on
App Service. Learn more.
Containerizing Java web apps on Apache Tomcat (on Linux servers) and deploying
them on Linux containers on App Service. Learn more.
Java web app containerization and
migration to Azure Kubernetes Service
In this article, you'll learn how to containerize Java web applications (running on Apache
Tomcat) and migrate them to Azure Kubernetes Service (AKS) using the Azure
Migrate: App Containerization tool. The containerization process doesn’t require access
to your codebase and provides an easy way to containerize existing applications. The
tool works by using the running state of the applications on a server to determine the
application components and helps you package them in a container image. The
containerized application can then be deployed on Azure Kubernetes Service (AKS).
The Azure Migrate: App Containerization tool currently supports -
Containerizing Java Web Apps on Apache Tomcat (on Linux servers) and deploying
them on Linux containers on AKS.
them on Linux containers on App Service. Learn more
Containerizing ASP.NET apps and deploying them on Windows containers on AKS.
Learn more
Containerizing ASP.NET apps and deploying them on Windows containers on App
Service. Learn more
The Azure Migrate: App Containerization tool helps you to -
running your Java web application (running on Apache Tomcat) and discovers the
application components. The tool creates a Dockerfile that can be used to create a
container image for the application.
you specify.
Deploy to Azure Kubernetes Service: The tool then generates the Kubernetes
resource definition YAML files needed to deploy the containerized application to
your Azure Kubernetes Service cluster. You can customize the YAML files and use
them to deploy the application on AKS.
７ Note
Discovery and assessment capability. Learn more
rewriting include:
Improved infrastructure utilization: With containers, multiple applications can

Simplified management: By hosting your applications on a modern managed
Application portability: With increased adoption and standardization of container
Adopt modern management with DevOps: Helps you adopt and standardize on

＂ Discover your Java web application.
＂ Deploy the containerized application on AKS.
７ Note
Prerequisites
Requirement Details
servers/virtual machines hosting the Java web applications to be containerized.
Application - Enable Secure Shell (SSH) connection on port 22 on the server(s) running the
servers Java application(s) to be containerized.
Java web The tool currently supports

application
- Applications running on Tomcat 8 or later.
- Application servers on Ubuntu Linux 16.04/18.04/20.04, Debian 7/8, CentOS 6/7,
Red Hat Enterprise Linux 5/6/7.
- Applications using Java version 7 or later.
The tool currently doesn't support
- Applications servers running multiple Tomcat instances

Once your subscription is set up, you'll need an Azure user account with:
Owner permissions on the Azure subscription

Permissions to register Azure Active Directory apps
Subscriptions.
Azure portal.
Setting Value
Role Owner
Members azmigrateuser (in this example)

6. Your Azure account also needs permissions to register Azure Active Directory
apps.
default).

machine.

PowerShell

running the App Containerization tool, and open the tool URL: https://machine
2. If you see a warning stating that says your connection isn’t private, click Advanced
and choose to proceed to the website. This warning appears as the web interface
uses a self-signed TLS/SSL certificate.
3. At the sign-in screen, use the local administrator account on the machine to sign-
in.
4. Select Java web apps on Tomcat as the type of application you want to
containerize.
5. To specify target Azure service, select Containers on Azure Kubernetes Service.
Complete tool pre-requisites

Click on Set up proxy to specify the proxy address (in the form IP address
or FQDN) and listening port.
click on Save to trigger connectivity check again.
Enable Secure Shell (SSH): The tool will inform you to ensure that Secure
Shell (SSH) is enabled on the application servers running the Java web
applications to be containerized.
Sign in to Azure
Click Sign in to log in to your Azure account.
1. You'll need a device code to authenticate with Azure. Clicking on sign in will open a
modal with the device code.
2. Click on Copy code & sign in to copy the device code and open an Azure sign in
3. On the new tab, paste the device code and complete sign in using your Azure
return to the App Containerization tool's web interface.
Discover Java web applications

the provided credentials and attempts to discover Java web applications (running on
Apache Tomcat) hosted on the application servers.
1. Specify the IP address/FQDN and the credentials of the server running the Java
web application that should be used to remotely connect to the server for
The credentials provided must be for a root account (Linux) on the

application server.
<domain\username>.
You can run application discovery for upto five servers at a time.
2. Click Validate to verify that the application server is reachable from the machine
3. Click Continue to start application discovery on the selected application servers.
name as appname:v1.

1. Click app configurations to review detected configurations.
3. Click Apply after selecting the configurations to parameterize.

the container image or are to be externalized through persistent volumes on Azure file
share. Using persistent volumes works great for stateful applications that store state
outside the container or have other static content stored on the file system. Learn more
1. Click Edit under App Folders to review the detected application folders. The
2. Click Add folders and specify the folder paths to be added.
4. Select Persistent Volume as the storage option if you want the folders to be stored
outside the container on a Persistent Volume.
5. Click Save after reviewing the application folders.
6. Click Continue to proceed to the container image build phase.

each selected application are generated at the beginning of the build step. Click
process.
3. Configure Application Insights: You can enable monitoring for your Java apps
running on App Service without instrumenting your code. The tool will install the
Java standalone agent as part of the container image. Once configured during
deployment, the Java agent will automatically collect a multitude of requests,
dependencies, logs, and metrics for your application that can be used for
monitoring with Application Insights. This option is enabled by default for all Java
applications.
4. Trigger build process: Select the applications to build images for and click Build.
Clicking build will start the container image build for each application. The tool
5. Track build status: You can also monitor progress of the build step by clicking the
Build in Progress link under the status column. The link takes a couple of minutes
to be active after you've triggered the build process.
6. Once the build is completed, click Continue to specify deployment settings.
Deploy the containerized app on AKS

container on Azure Kubernetes Service (AKS) .
1. Select the Azure Kubernetes Service Cluster: Specify the AKS cluster that the
application should be deployed to.
The selected AKS cluster must have a Linux node pool.

The cluster must be configured to allow pulling of images from the Azure
Container Registry that was selected to store the images.
Run the following command in Azure CLI to attach the AKS cluster to the
ACR.
Azure
az aks update -n <cluster-name> -g <cluster-resource-group> --

attach-acr <acr-name>
If you don’t have an AKS cluster or would like to create a new AKS cluster to
deploy the application to, you can choose to create on from the tool by
clicking Create new AKS cluster.
The AKS cluster created using the tool will be created with a Linux node
pool. The cluster will be configured to allow it to pull images from the
Azure Container Registry that was created earlier (if create new registry
option was chosen).
Click Continue after selecting the AKS cluster.
2. Specify secret store and monitoring workspace: If you had opted to parameterize
application configurations, then specify the secret store to be used for the
application. You can choose Azure Key Vault or Kubernetes Secrets for managing
your application secrets.
If you've selected Kubernetes secrets for managing secrets, then click

Continue.
Vault, you can choose to create on from the tool by clicking Create new.
Monitoring workspace: If you'd selected to enabled monitoring with
Application Insights, then specify the Application Insights resource that you'd
want to use. This option won't be visible if you had disabled monitoring
integration.
If you don’t have an Application Insights resource or would like to create a
new resource, you can choose to create on from the tool by clicking
Create new.
3. Specify Azure file share: If you had added more folders and selected the Persistent
Volume option, then specify the Azure file share that should be used by Azure
Migrate: App Containerization tool during the deployment process. The tool will
create new directories in this Azure file share to copy over the application folders
that are configured for Persistent Volume storage. Once the application
deployment is complete, the tool will clean up the Azure file share by deleting the
directories it had created.
share, you can choose to create on from the tool by clicking Create new

you'll need to specify the deployment configuration for the application. Click
Prefix string: Specify a prefix string to use in the name for all resources that
are created for the containerized application in the AKS cluster.
Replica Sets: Specify the number of application instances (pods) that should
run inside the containers.
Load balancer type: Select External if the containerized application should be
reachable from public networks.
Application Configuration: For any application configurations that were
Storage: For any application folders that were configured for Persistent
Volume storage, specify whether the volume should be shared across
application instances or should be initialized individually with each instance in
the container. By default, all application folders on Persistent Volumes are
configured as shared.
Click Apply to save the deployment configuration.
Click Continue to deploy the application.
Click Review to review and customize the Kubernetes deployment YAML for
the applications.
Click Deploy to start deployments for the selected applications
Once the application is deployed, you can click the Deployment status column
to track the resources that were deployed for the application.
Download generated artifacts

All artifacts that are used to build and deploy the application into AKS, including the
Dockerfile and Kubernetes YAML specification files, are stored on the machine running
the tool. The artifacts are located at C:\ProgramData\Microsoft Azure Migrate App
Containerization.
A single folder is created for each application server. You can view and download all
intermediate artifacts used in the containerization process by navigating to this folder.
The folder, corresponding to the application server, will be cleaned up at the start of
each run of the tool for a particular server.
Troubleshoot issues
machine running the App Containerization tool. Tool log files are located at
Next steps
them on Linux containers on App Service. Learn more
AKS. Learn more
Azure App Service. Learn more
What are solutions for running Oracle WebLogic Server on the Azure Kubernetes
Service? Learn more
Open Liberty and WebSphere Liberty on AKS. Learn more
 Documentation
Azure App Containerization ASP.NET; Containerization and migration of ASP.NET

applications to Azure Kubernetes. - Azure Migrate
Tutorial - Containerize & migrate ASP.NET applications to Azure Kubernetes Service.
Magento e-commerce platform in Azure Kubernetes Service - Azure Example

Scenarios
Deploy the Magento e-commerce platform to Azure Kubernetes Service (AKS), and learn about
considerations for hosting Magento on Azure.
Containerization and migration of Java web applications to Azure App Service. -
Azure Migrate
Tutorial:Containerize & migrate Java web applications to Azure App Service.
Kubernetes in the Cloud Adoption Framework - Cloud Adoption Framework

Learn about Kubernetes in the Cloud Adoption Framework.
Enable dual-stack network traffic on AKS - Azure Architecture Center

Discover infrastructure considerations for an Azure Kubernetes Service cluster on a dual-stack
network using both IPv4 and IPv6 addresses.
ASP.NET app containerization and migration to App Service - Azure Migrate

This tutorial demonstrates how to containerize ASP.NET applications and migrate them to Azure App
Service.
Azure Well-Architected Framework review for Azure Kubernetes Service (AKS) -

Microsoft Azure Well-Architected Framework
Provides a template for a Well-Architected Framework (WAF) article that is specific to Azure
Kubernetes Service (AKS).
Elastic demand handling with AKS - Azure Solution Ideas

Learn how to achieve fast and reliable service quality during seasonal and other high-traffic demand
periods.
Show 5 more
ASP.NET app containerization and
In this article, you'll learn how to containerize ASP.NET applications and migrate them to
Azure App Service by using the Azure Migrate App Containerization tool. The
containerization process doesn't require access to your codebase and provides an easy
way to containerize existing applications. The tool works by using the running state of
the applications on a server to determine the application components. It then helps you
package them in a container image. You can then deploy the containerized application
on Azure App Service.
The Azure Migrate App Containerization tool currently supports:

Service.
Azure Kubernetes Service (AKS). Learn more about this containerization scenario.
them on Linux containers on AKS. Learn more about this containerization scenario.
them on Linux containers on App Service. Learn more about this containerization
scenario.
The App Containerization tool helps you:
Discover your application components. The tool remotely connects to the

application servers that run your ASP.NET application and discovers the application
components. It creates a Dockerfile that you can use to create a container image
for the application.
Build the container image. You can inspect and further customize the Dockerfile
based on your application requirements and use it to build your application
container image. The application container image is pushed to an Azure container
registry that you specify.
Deploy to Azure App Service. The tool then generates the deployment files
needed to deploy the containerized application to Azure App Service.
７ Note
The Azure Migrate App Containerization tool helps you discover specific
apps, roles, and features running on on-premises computers, use the Azure
Migrate Discovery and assessment tool.
Not all applications will benefit from a straight shift to containers without significant
rearchitecting. But some of the benefits of moving existing apps to containers without
rewriting include:
Improved infrastructure utilization. When you use containers, multiple

applications can share resources and be hosted on the same infrastructure. This
can help you consolidate infrastructure and improve utilization.
Simplified management. By hosting your applications on modern managed
platforms like AKS and App Service, you can simplify your management practices.
You can achieve this simplification by retiring or reducing the infrastructure
maintenance and management processes that you'd traditionally perform with
owned infrastructure.
Application portability. With increased adoption and standardization of container
Adopt modern management by using DevOps. Using containers helps you adopt
and standardize on modern practices for management and security and transition
to DevOps.

＂ Install the Azure Migrate App Containerization tool.
＂ Discover your ASP.NET application.
＂ Deploy the containerized application on App Service.
７ Note
Tutorials provide the simplest deployment path for a scenario so that you can
quickly set up a proof of concept. Tutorials use default options when possible and
don't show all settings and paths.
Prerequisites
Before you start this tutorial, you should:
Requirement Details
Identify a You need a Windows machine on which to install and run the Azure Migrate App
machine on Containerization tool. The Windows machine could run a server (Windows Server
which to 2016 or later) or client (Windows 10) operating system. (The tool can run on your
install the desktop.)
tool
servers or virtual machines hosting the ASP.NET applications that you'll
containerize.
Ensure that 6 GB is available on the Windows machine running the Azure Migrate
App Containerization tool. This space is for storing application artifacts.
If the Microsoft Web Deployment tool isn't already installed on the machine
running the App Containerization tool and the application server, install it. You
can download the tool .
Application Enable PowerShell remoting on the application servers: sign in to the application
servers server and follow these instructions to turn on PowerShell remoting.
If the application server is running Window Server 2008 R2, ensure that
PowerShell 5.1 is installed on the application server. Follow the instructions here
to download and install PowerShell 5.1 on the application server.
If the Microsoft Web Deployment tool isn't already installed on the machine
running the App Containerization tool and the application server, install it. You
can download the tool .
ASP.NET The tool currently supports:

application
ASP.NET applications that use .NET Framework 3.5 or later.
Application servers that run Windows Server 2008 R2 or later. (Application
servers should be running PowerShell 5.1.)
Applications that run on Internet Information Services 7.5 or later.
Applications that require Windows authentication. (AKS doesn't currently

support gMSA.)
Applications that depend on other Windows services hosted outside of
Internet Information Services.
If you don't have an Azure subscription, create a free account before you start.
After your subscription is set up, you'll need an Azure user account with:

1. In the Azure portal, search for "subscriptions." Under Services, select

Subscriptions:
2. On the Subscriptions page, select the subscription in which you want to create an
3. In the subscription, on the left pane, select Access control (IAM).
4. On the Check access tab, search for the relevant user account.
5. Under Add a role assignment, select Add:

6. On the Add role assignment page, select the Owner role, and then select the
account (azmigrateuser in our example). Then select Save.
Your Azure account also needs permissions to register Azure Active Directory apps.
7. In the Azure portal, go to Azure Active Directory > Users > User Settings.
8. In User settings, verify that Azure AD users can register applications. (This option is
set to Yes by default.)
9. If the App registrations option is set to No, ask the tenant/global admin to assign
the required permission. Alternatively, the tenant/global admin can assign the
Application developer role to an account to allow the registration of Azure Active
Directory apps. For more information, see Assign roles to users.
Download and install the Azure Migrate App

1. Download the Azure Migrate App Containerization installer on a Windows
machine.
2. Open PowerShell in administrator mode and change the PowerShell directory to

the folder that contains the installer.
3. Run the installation script by using this command:
PowerShell
Open the App Containerization tool

1. Open a browser on any machine that can connect to the Windows machine that's
running the App Containerization tool. Go to the tool URL: https://machine name
or IP address: 44369.
Alternatively, you can open the app from your desktop by using the app shortcut.
2. If you see a warning that says your connection isn't private, select Advanced and
continue to the website. This warning appears because the web interface uses a
self-signed TLS/SSL certificate.
3. On the sign-in screen, use the machine's local administrator account to sign in.
4. Select ASP.NET web apps as the type of application you want to containerize.
5. In the Target Azure service list, select Containers on Azure App Service:
Complete the tool prerequisites

2. In the tool web app Set up prerequisites, complete these steps:
Connectivity. The tool checks whether the Windows machine has internet
access. If the machine uses a proxy:
a. Select Set up proxy to specify the proxy address (in the form IP address or
b. Specify credentials if the proxy needs authentication.
c. If you've added proxy details or disabled the proxy or authentication,

select Save to trigger the connectivity check again.
Install updates. The tool automatically checks for the latest updates and
installs them. You can also manually install the latest version of the tool .
Install Microsoft Web Deploy tool. The tool checks whether the Microsoft
Web Deployment tool is installed on the Windows machine that's running the
Azure Migrate App Containerization tool.
Enable PowerShell remoting. The tool prompts you to ensure that

PowerShell remoting is enabled on the application servers running the
ASP.NET applications that you want to containerize.
Sign in to Azure
1. Select Sign in to sign in to your Azure account.
You need a device code to authenticate with Azure. Selecting Sign in should open
a window that contains the device code. If the window doesn't appear, make sure
you've disabled the pop-up blocker in the browser.
2. Select Copy code and Sign in to copy the device code and open an Azure sign-in
prompt in a new browser tab:
3. On the new tab, paste in the device code and complete sign-in by using your
Azure account credentials. After you're signed in, you can close the browser tab
and return to the App Containerization tool's web interface.
Discover ASP.NET applications

The App Containerization tool connects remotely to the application servers by using the
provided credentials and attempts to discover ASP.NET applications hosted on the
application servers.
1. Specify the Server IP address / FQDN and the credentials of the server that's
running the ASP.NET application that should be used to remotely connect to the
server for application discovery.
The credentials provided must be for a local administrator (Windows) on the

application server.
server), prefix the user name with the domain name in this format:
<domain\user name>.
For local accounts (the user must be an administrator on the application
server), prefix the user name with the host name in this format: <host
name\user name>.
You can run application discovery for as many as five servers at a time.
2. Select Validate to verify that the application server is reachable from the machine
Status column will show the status as Mapped:
3. Select Continue to start application discovery on the selected application servers.
4. When application discovery is finished, select the applications that you want to
containerize:
5. Specify a name for the target container for each selected application. Specify the
container name as <name:tag>, where tag is used for the container image. For
example, you can specify the target container name as appname:v1.

Parameterizing the configuration makes it available as a deploy-time parameter.
Parameterization allows you to configure a setting when you deploy the application as
opposed to having it hard coded to a specific value in the container image. For example,
this option is useful for parameters like database connection strings.
1. Select app configurations to review detected configurations.
2. Select the parameters that you want to parameterize, and then select Apply:

the container image or should be externalized to persistent storage via Azure file share.
Using external persistent storage works great for stateful applications that store state
outside the container or have other static content stored on the file system.
1. Select Edit under Application folders to review the detected application folders.
These folders have been identified as mandatory artifacts needed by the
application. They'll be copied into the container image.
2. Select Add folder and specify the folder paths that you want to add.
3. To add multiple folders to the same volume, separate the values with commas.
4. Select Azure file share as the storage option if you want the folders to be stored
outside the container on persistent storage.
5. Select Save after you review the application folders:
6. Select Continue to proceed to the container image build phase.

1. In the dropdown list, select an Azure container registry that will be used to build
and store the container images for the apps. You can use an existing Azure
container registry or create a new one by selecting Create new registry:
７ Note
Only Azure container registries with the admin user account enabled are
displayed. The admin user account is currently required for deploying an
image from an Azure container registry to Azure App Service. For more
information, see Authenticate with an Azure container registry.
2. The Dockerfiles needed to build the container images for each selected application
are generated at the beginning of the build step. Select Review to review the
Dockerfile. You can also add any necessary customizations to the Dockerfile in the
review step and save the changes before you start the build process.
3. Select the applications that you want to build images for, and then select Build.
Selecting Build will start the container image build for each application. The tool
monitors the build status and will let you continue to the next step when the build
finishes.
4. You can monitor the progress of the build by selecting Build in Progress under the
status column. The link will become active a couple minutes after you trigger the
build process.
5. After the build is complete, select Continue to specify deployment settings:
Deploy the containerized app on Azure App

Service
After the container image is built, the next step is to deploy the application as a
container on Azure App Service .
1. Select the Azure App Service plan that the application should use.
If you don't have an App Service plan or want to create a new App Service plan to
use, you can create one by selecting Create new App Service plan.
2. Select Continue after you select the App Service plan.

3. If you parameterized application configurations, specify the secret store to use for
the application. You can choose Azure Key Vault or App Service application settings
to manage your application secrets. For more information, see Configure
connection strings.
If you selected App Service application settings to manage your secrets,

select Continue.
If you want to use an Azure key vault to manage your application secrets,
specify the key vault that you want to use.
If you don’t have an Azure key vault or want to create a new key vault, you
can create one by selecting Create new Azure Key Vault.
secrets via the key vault.
4. If you added more folders and selected the Azure file share option for persistent
storage, specify the Azure file share to be used by the App Containerization tool
during deployment. The tool will copy over the application folders that you
configured for Azure Files and mount them on the application container during
deployment.
If you don't have an Azure file share or want to create a new Azure file share, you
can create one by selecting Create new Storage Account and file share.
5. You now need to specify the deployment configuration for the application. Select
Configure to customize the deployment for the application. In the configure step,
you can provide these customizations:
Name. Specify a unique app name for the application. This name will be used
to generate the application URL. It will also be used as a prefix for other
resources created as part of the deployment.
Application configuration. For any application configurations that are
Storage configuration. Review the information for any application folders
that are configured for persistent storage.
6. After you save the deployment configuration for the application, the tool will
generate the Kubernetes deployment YAML for the application.
Select Review to review the deployment configuration for the applications.
Select the applications that you want to deploy.
Select Deploy to start deployment for the selected applications.
After the application is deployed, you can select the Deployment status
column to track the resources that were deployed for the application.
Troubleshoot problems
To troubleshoot problems with the App Containerization tool, you can look at the log
files on the Windows machine that's running the tool. Log files for the tool are located
at C:\ProgramData\Microsoft Azure Migrate App Containerization\Logs.
Next steps
AKS
them on Linux containers on AKS
them on Linux containers on App Service
Java web app containerization and
In this article, you'll learn how to containerize Java web applications (running on Apache
Tomcat) and migrate them to Azure App Service using the Azure Migrate: App
Containerization tool. The containerization process doesn’t require access to your
codebase and provides an easy way to containerize existing applications. The tool works
by using the running state of the applications on a server to determine the application
components and helps you package them in a container image. The containerized
application can then be deployed on Azure App Service.
The Azure Migrate: App Containerization tool currently supports:
them on Linux containers on App Service.
Containerizing ASP.NET apps and deploying them on Windows containers on AKS.
Learn more.
Service. Learn more.
The Azure Migrate: App Containerization tool helps you to:
running your Java web application (running on Apache Tomcat) and discovers the
application components. The tool creates a Dockerfile that can be used to create a
container image for the application.
you specify.
Deploy to Azure App Service: The tool then generates the deployment files
needed to deploy the containerized application to Azure App Service.
７ Note
Discovery and assessment capability. Learn more.
rewriting include:
Improved infrastructure utilization: With containers, multiple applications can

Simplified management: By hosting your applications on a modern managed
Application portability: With increased adoption and standardization of container
Adopt modern management with DevOps: Helps you adopt and standardize on

＂ Discover your Java web application.
＂ Deploy the containerized application on App Service.
７ Note
Prerequisites
Requirement Details
Requirement Details
servers/virtual machines hosting the Java web applications to be containerized.
Application Enable Secure Shell (SSH) connection on port 22 on the server(s) running the Java
servers application(s) to be containerized.
Java web The tool currently supports:

application
- Applications running on Tomcat 8 or later.
- Application servers on Ubuntu Linux 16.04/18.04/20.04, Debian 7/8, CentOS 6/7,
Red Hat Enterprise Linux 5/6/7.
- Applications using Java version 7 or later.
- Application servers running multiple Tomcat instances.

Once your subscription is set up, you'll need an Azure user account with:

Subscriptions.
3. In the subscription, select Access control (IAM) > Check access.
4. In Check access, search for the relevant user account.
5. In Add a role assignment, click Add.
6. In Add role assignment, select the Owner role, and select the account
(azmigrateuser in our example). Click Save.
Your Azure account also needs permissions to register Azure Active Directory apps. 8.
In the Azure portal, navigate to Azure Active Directory > Users > User Settings. 9. In
User settings, verify if Azure AD users can register applications (set to Yes by default).
10. In case the 'App registrations' setting is set to 'No', request the tenant/global
machine.

PowerShell

running the App Containerization tool and open the tool URL: https://machine
2. If you see a warning stating that your connection isn’t private, click Advanced and
choose to proceed to the website. This warning appears as the web interface uses
a self-signed TLS/SSL certificate.
3. At the sign-in screen, use the local administrator account on the machine to sign
in.
4. Select Java web apps on Tomcat as the type of application you want to
containerize.
5. To specify target Azure service, select Containers on Azure App Service.

Complete tool pre-requisites
Click Set up proxy to specify the proxy address (in the form IP address or
click Save to trigger connectivity check again.
Enable Secure Shell (SSH): The tool will inform you to ensure that Secure
Shell (SSH) is enabled on the application servers running the Java web
applications to be containerized.
Sign in to Azure
Click Sign in to log in to your Azure account.
1. You'll need a device code to authenticate with Azure. Clicking Sign in will open a
modal with the device code.
2. Click Copy code & sign in to copy the device code and open an Azure sign-in
3. On the new tab, paste the device code and complete sign in using your Azure
return to the App Containerization tool's web interface.
Discover Java web applications

the provided credentials and attempts to discover Java web applications (running on
Apache Tomcat) hosted on the application servers.
1. Specify the IP address/FQDN and the credentials of the server running the Java
web application that should be used to remotely connect to the server for
The credentials provided must be for a root account (Linux) on the

application server.
<domain\username>.
You can run application discovery for up to five servers at a time.
2. Click Validate to verify that the application server is reachable from the machine
3. Click Continue to start application discovery on the selected application servers.
name as appname:v1.

1. Click App configurations to review detected configurations.
3. Click Apply after selecting the configurations to parameterize.

the container image or are to be externalized to persistent storage through Azure file
share. Using external persistent storage works great for stateful applications that store
state outside the container or have other static content stored on the file system.
1. Click Edit under App Folders to review the detected application folders. The
2. Click Add folders and specify the folder paths to be added.
4. Select Azure file share as the storage option if you want the folders to be stored
outside the container on persistent storage.
5. Click Save after reviewing the application folders.
6. Click Continue to proceed to the container image build phase.

７ Note
Only Azure container registries with admin user enabled are displayed. The admin
account is currently required for deploying an image from an Azure container
registry to Azure App Service. Learn more.
each selected application are generated at the beginning of the build step. Click
process.
3. Configure Application Insights: You can enable monitoring for your Java apps
running on App Service without instrumenting your code. The tool will install the
Java standalone agent as part of the container image. Once configured during
deployment, the Java agent will automatically collect a multitude of requests,
dependencies, logs, and metrics for your application that can be used for
monitoring with Application Insights. This option is enabled by default for all Java
applications.
4. Trigger build process: Select the applications to build images for and click Build.
Clicking Build will start the container image build for each application. The tool
5. Track build status: You can also monitor progress of the build step by clicking the
Build in Progress link under the Build status column. The link takes a couple of
minutes to be active after you've triggered the build process.
6. Once the build is completed, click Continue to specify the deployment settings.
Deploy the containerized app on Azure App

Service
container on Azure App Service .
1. Select the Azure App Service plan: Specify the Azure App Service plan that the
application should use.
If you don’t have an App Service plan or would like to create a new App
Service plan to use, you can choose to create one from the tool by clicking
Create new App Service plan.
Click Continue after selecting the App Service plan.
2. Specify secret store and monitoring workspace: If you had opted to parameterize
application configurations, then specify the secret store to be used for the
application. You can choose Azure Key Vault or App Service application settings for
managing your application secrets. Learn more.
If you've selected App Service application settings for managing secrets, then
click Continue.
Vault, you can choose to create one from the tool by clicking Create new.
Monitoring workspace: If you'd selected to enabled monitoring with
Application Insights, then specify the Application Insights resource that you'd
want to use. This option won't be visible if you had disabled monitoring
integration.
If you don’t have an Application Insights resource or would like to create a
new resource, you can choose to create on from the tool by clicking
Create new.
3. Specify Azure file share: If you had added more directories/folders and selected
the Azure file share option for persistent storage, then specify the Azure file share
to be used by Azure Migrate: App Containerization tool during the deployment
process. The tool will copy over the application directories/folders that are
configured for Azure Files and mount them on the application container during
deployment.
share, you can choose to create on from the tool by clicking Create new

you'll need to specify the deployment configuration for the application. Click
Name: Specify a unique app name for the application. This name will be used
to generate the application URL and used as a prefix for other resources
being created as part of this deployment.
Application configuration: For any application configurations that were
Storage configuration: Review the information for any application
directories/folders that were configured for persistent storage.
Click Review to review the deployment configuration for the applications.
Click Deploy to start deployments for the selected applications
Once the application is deployed, you can click the Deployment status column
to track the resources that were deployed for the application.
Troubleshoot issues
machine running the App Containerization tool. Tool log files are available in the
Next steps
them on Linux containers on AKS. Learn more
AKS. Learn more
Azure App Service. Learn more
Modernize ASP.NET web apps to Azure
App Service code
This article shows you how to migrate ASP.NET web apps at-scale to Azure App
Service using Azure Migrate.
７ Note
＂ Migrate ASP.NET web apps at-scale to Azure App Service using integrated flow in
Azure Migrate.
＂ Change migration plans for web apps.
＂ Change App Service plan for web apps.
Prerequisites
1. Complete the first tutorial to discover web apps running in your VMware
environment.
2. Complete the second tutorial to assess web apps to determine their readiness
status for migration to Azure App Service . It's necessary to assess web apps in
order to migrate them using the integrated flow.
3. Go to the existing project or create a new project.
Migrate web apps

Once the web apps are assessed, you can migrate them using the integrated migration
flow in Azure Migrate.
You can select up to five App Service Plans as part of a single migration.
Currently, we don't support selecting existing App Service Plans during the
migration flow.
You can migrate web apps up to a maximum size of 2 GB, including content stored
in the mapped virtual directory.
Currently, we don't support migrating UNC directory content.
You need Windows PowerShell 4.0 installed on servers hosting the IIS web servers
from which you plan to migrate ASP.NET web apps to Azure App Services.
Currently, the migration flow doesn't support VNet integrated scenarios.
To migrate the web apps, perform these steps:
1. In the Azure Migrate project > Servers, databases and web apps > Migration
tools > Migration and modernization, select Replicate.
2. In Specify intent, > What do you want to migrate?, select ASP.NET web apps.
3. In Where do you want to migrate to?, select Azure App Service native.
4. In Virtualization type, select VMware vSphere.
5. In Select assessment, select the assessment you want to use to migrate web apps
and then select the Continue button. Specify the Azure App Service details where
the apps will be hosted.
6. In Basics, under Project details, select the Subscription, Resource Group, and
Region where the web apps will be hosted, from the drop-down. Under Storage,
select the Storage account for an intermediate storage location during the
migration process. Select Next: Web Apps >.
7. In the Web Apps section, review the web apps you'd like to migrate.
７ Note
Apps with the Ready status are tagged for migration by default. Apps tagged
as Ready with conditions can be migrated by selecting Yes in Will migrate?.
a. Select the web apps to migrate and select Edit.
b. In Edit apps, under Will migrate?, select Yes, and select the App Service Plan
and Pricing tier of where the apps will be hosted. Next, select the Ok button.
７ Note
Up to five App Service plans can be migrated at a time.
Select the Next: App Service Plans > button.
8. In the App Service Plans section, verify the App Service Plan details.
７ Note
Depending on your web app requirements, you can edit the number of apps
in an App Service plan or update the pricing tier. Follow these steps to update
these details:
a. Select the Edit button.
b. In Edit plan, select the Target name and Pricing tier, then select Ok.
9. Once the App Service Plans are verified, select Next: Review + create.
10. Azure Migrate will now validate the migration settings. Validation may take a few
minutes to run. Once complete, review the details and select Migrate.
７ Note
To download the migration summary, select the Download CSV button.
Once the migration is initiated, you can track the status using the Azure Resource
Manager Deployment Experience as shown below:
Post-migration steps
Once you have successfully completed migration, you may explore the following steps
based on web app specific requirement(s):
Map existing custom DNS name.

Secure a custom DNS with a TLS/SSL binding.
Securely connect to Azure resources
Deployment best practices.
Security recommendations.
Networking features.
Monitor App Service with Azure Monitor.
Configure Azure AD authentication.
Next steps
Review best practices for deploying to Azure App service.
Modernize ASP.NET web apps to Azure
Kubernetes Service (preview)
This article shows you how to migrate ASP.NET web apps at-scale to Azure Kubernetes
Service using Azure Migrate. Currently, this flow only supports ASP.NET web apps
running on VMware. For other environments, follow these steps.
７ Note
＂ Choose and prepare ASP.NET web apps at-scale for migration to Azure Kubernetes
Service using the integrated flow in Azure Migrate.
＂ Configure target settings such as the number of application instances to run and
replicate your applications.
＂ Run test migrations to ensure your applications spin up correctly.
＂ Run a full migration of your applications to AKS.
Prerequisites
Before you begin this tutorial, you should address the following:
Complete the first tutorial to discover web apps running in your VMware
environment.
Go to the existing project or create a new project.
Limitations
You can migrate ASP.NET applications using Microsoft .NET framework 3.5 or later.
You can migrate application servers running Windows Server 2008 R2 or later
(application servers should be running PowerShell version 5.1).
Applications should be running on Internet Information Services (IIS) 7.5 or later.
Enable replication
Once the web apps are assessed, you can migrate them using the integrated migration
flow in Azure Migrate. The first step in this process is to configure and begin replication
of your web apps.
Specify intent
1. Navigate to your Azure Migrate project > Servers, databases and web apps >
Migration tools > Migration and modernization, select Replicate.
2. In the Specify intent tab, > What do you want to migrate?, select ASP.NET web
apps from the drop-down.
3. In Where do you want to migrate to?, select Azure Kubernetes Service (AKS).
4. In Virtualization type, select VMware vSphere.
5. In On-premises appliance, choose the appliance which discovered your desired

web apps on vSphere.
6. Select Continue.
Choose from discovered apps
In Replicate > Web apps, a paged list of discovered ASP.NET apps discovered on your
environment is shown.
1. Choose one or more applications that should be replicated.
2. The Modernization status column indicates the readiness of the application to run
on AKS. This can take one of the following values - Ready, Error(s), Replication in
Progress.
3. Select the application and select the App configuration(s) link to open the
Application configurations tab. This provides the list of attributes detected from
the discovered config files. Enter the required attribute values and select Save.
These configurations will either be stored directly on the target cluster as secrets
or can be mounted using Azure Key Vault. This can be configured in the advanced
settings.
4. Select the application and select the App directories link to open the Application
directories tab. Provide the path to folders/files that need to be copied for the
application to run and select Save. Based on the option selected from the drop-
down, these artifacts are either be copied directly into the container image or
mounted as a persistent volume on the cluster via Azure file share. If persistent
volume is chosen, the target can be configured in the advanced settings.
5. Select Next.
Configure target settings
In Replicate > Target settings, settings are provided to configure the target where the
applications will be migrated to.
1. Choose the subscription, resource group, and container registry resource to which
the app container images should be pushed to.
2. Choose the subscription, resource group, and AKS cluster resource on which the
app should be deployed.
3. Select Next.
７ Note
Only AKS clusters with windows nodes are listed.
Configure deployment settings

In Replicate > Deployment settings, settings are provided to configure the application
on the AKS cluster.
1. Default values are provided based on the app discovery.
2. In the Replica option, choose the number of app instances for each app.
3. In the Load balancer option, choose External if the app needs to be accessed over
the Internet. If Internal is chosen, the app can only be accessed within the virtual
network of the AKS cluster.
4. Select Next.
Configure advanced settings

If one or more apps had app configurations or directories updated in Replicate > Web
apps, then Replicate > Advanced is used to provide additional required configurations.
1. If application configurations were provided, choose to store them either as native

Kubernetes secrets or on Azure Key Vault using secrets store CSI driver. Ensure that
the target cluster has the secrets store driver addon enabled.
2. If application directories were provided with a persistent storage option, select an
Azure file share to store these files.
3. Select Next.
Review and start replication

Review your selections and make any other required changes by navigating to the right
tab on the Replicate tab. After reviewing, select Replicate.

Once you begin replication, Azure Migrate creates a replication job which can be
accessed from your project.
Navigate to the target resource

1. Navigate to your Azure Migrate project > Servers, databases and web apps >
Migration tools > Migration and modernization, select Overview.
2. Select Azure Migrate: Server Migration hub > Modernization (Preview) > Jobs.
3. Select Azure Kubernetes Service (AKS) as the replication target. Azure Migrate will
create one replication job for each ASP.NET app replicated. Select the Create or
update the Workload deployment job of type Workload Deployment.
4. Select the Target resource. All the pre-migration steps can be configured here.
5. After replication is completed, the Replication status will be Completed and the
overall Status will be Image build pending.
Review the container image and Kubernetes manifests

In the Target settings tab, links to the Docker file and the Kubernetes manifests will be
provided.
1. Select the Docker file review link to open the editor. Review and make changes as
required. Select Save.
2. Select the Deployment specs review link to open the editor. This contains the
Kubernetes manifest file containing all the resources that will be deployed
including StatefulSet , Service , ServiceAccount etc. Review and make changes as
required. Select Save.
3. In the Overview tab, select Build container image to build and push the container
image to the provided container registry.
4. After the image is built, the overall Status will change to Ready to Migrate.
With the container image ready, run a test migration to ensure your application spins up
correctly on AKS.
1. In the Overview tab, select Test migration, then select Yes to confirm.
2. Once the test migration completes, verify that the workloads are running on the
AKS cluster. If the external load balancer option was chosen during the replication
process, your application should be exposed to the Internet via a service of type
loadbalancer with an assigned public IP address.
3. After verifying that the application is working, clean up the test migration by
selecting Clean up test migration.
If the test migration fails:
1. Navigate to Azure Migrate: Server Migration hub > Modernization (Preview) >
Jobs.
2. Select the Initiate test migrate job that failed.
3. Select the failed task link to see possible failure causes and recommendations.
Migrate your applications to AKS

The application is finally ready for migration:
1. In the Overview tab, select Migrate, then select Yes to confirm.

2. Similar to the test migration workflow, verify that the workloads are running on the
AKS cluster.
3. The application has now successfully been migrated. If you wish for the appliance
to discover it again and make it available for migration, select Complete
migration.
Next steps
After successfully migrating your applications to AKS, you may explore the following
articles to optimize your apps for cloud:
Set up CI/CD with Azure Pipelines, GitHub Actions or through GitOps.

Use Azure Monitor to monitor health and performance of AKS and your apps.
Harden the security posture of your AKS cluster and containers with Microsoft
Defender for Containers.
Optimize Windows Dockerfiles.
Review and implement best practices to build and manage apps on AKS.
Continuous deployment for
containerized applications with Azure
DevOps
In this step-by-step guide, you'll learn how to create a pipeline that continuously builds
and deploys your containerized apps for Day 2 operations with Azure DevOps. Every
time you change your code in a repository that contains a Dockerfile, the images are
pushed to your Azure Container Registry, and the manifests are then deployed to either
Azure Kubernetes Service or Azure App Service.
Azure DevOps enables you to host, build, plan and test your code with complimentary
workflows. Using Azure Pipelines as one of these workflows allows you to deploy your
application with CI/CD that works with any platform and cloud. A pipeline is defined as a
YAML file in the root directory of your repository.
Prerequisites
Containerize and deploy your ASP.NET or Java web app using Azure Migrate App
Containerization.
A GitHub account, where you can create a repository. If you don't have one, you
can create one for free .
An Azure DevOps organization. If you don't have one, you can create one for free.
(An Azure DevOps organization is different from your GitHub organization. You can
give your DevOps organization and your GitHub organization the same name if
you want alignment between them.)
If your team already has one, then make sure you're an administrator of the Azure
DevOps project that you want to use.
An ability to run pipelines on Microsoft-hosted agents. You can either purchase a
parallel job or you can request a free tier. To request a free tier, follow the
instructions in this article. Please note that it may take us 2-3 business days to
grant the free tier.
Locate the artifacts

Azure Migrate App Containerization tool automatically generates artifacts that can be
used for configuring a CI/CD workflow for your application using Azure Pipelines. The
artifacts are generated once the application deployment is completed through the tool.
You can find the artifacts as follows -
1. Go to the machine running the Azure Migrate App Containerization tool.

2. Navigate to C:\ProgramData\Microsoft Azure Migrate App Containerization
directory. If you are unable to navigate to C:\ProgramData, make sure to select the
option for showing Hidden items under View in file explorer.
3. Select the directory corresponding to the source machine IP/FQDN. The source
machine is the machine specified in the App Containerization tool running the
application that was containerized.
4. For Java applications
Navigate to JavaTomcatWebApp\Artifacts.
Navigate to the directory Catalina\localhost. If you do not find this directory,
then try navigating to the directory corresponding to Tomcat engine name
and host name.
Locate the application folder within this directory.
5. For ASP.NET applications
Navigate to IISAspNetWebApp.
Locate the application folder within this directory.
Upload artifacts to GitHub

You'll need to upload the artifacts to a source repository that will be used with Azure
DevOps.
1. Sign in to your GitHub account.

2. Follow the steps in this article to create a new repository.
3. The next step is to upload the following artifacts to this repository.
For Java apps, select the following folders and files in the application folder
on the machine running the App Containerization tool.
MandatoryArtifacts folder
manifests folder
OptionalArtifacts folder
Dockerfile
Entryscript.sh file
azure-pipelines.yml file
For ASP.NET apps, select the following folders and files in the application
folder on the machine running the App Containerization tool.
manifests folder
Build folder
azure-pipelines.yml file
Sign in to Azure Pipelines

Sign in to Azure Pipelines . After you sign in, your browser goes to
https://dev.azure.com/my-organization-name and displays your Azure DevOps
dashboard.
Within your selected organization, create a project. If you don't have any projects in your
organization, you see a Create a project to get started screen. Otherwise, select the
Create Project button in the upper-right corner of the dashboard.
Add service connections

Before you create your pipeline, you should first create your service connections since
you will be asked to choose and verify your connections in the template. A service
connection will allow you to connect to your Azure Container Registry when using the
task templates and to the Azure subscription where you want to deploy the application.
1. In the bottom left corner, select Project settings > Service connections.
2. Select new service connection, select the Docker Registry > Azure Container
Registry option for type of service connection that you need, and select Next.
3. Choose an authentication method, and select Next.
4. Enter the parameters for the service connection. The list of parameters differs for
each type of service connection. For more information, see the list of service
connection types and associated parameters.
5. Select Save to create the connection.
6. Validate the connection, once it's created and parameters are entered. The
validation link uses a REST call to the external service with the information that you
entered, and indicates whether the call succeeded.
7. Repeat the same steps for creating a service connection to your Azure Subscription
by selecting new service connection > Azure Resource Manager.
8. Note the resource ID for both the service connections.
Create the pipeline

Now that you've created both the service connections, you can configure your pipeline.
The pipeline YAML has automatically been created by the App Containerization tool and
can be configured as follows -
1. Go to Pipelines, and then select New Pipeline.

2. Walk through the steps of the wizard by first selecting GitHub as the location of
your source code.
3. You might be redirected to GitHub to sign in. If so, enter your GitHub credentials.
4. When the list of repositories appears, select your repository.
5. You might be redirected to GitHub to install the Azure Pipelines app. If so, select
Approve & install.
6. When your new pipeline appears, review the YAML to see what it does.
7. In the YAML, provide the resource ID for the Azure Container Registry service
connection as the value for the dockerRegistryServiceConnection variable.
8. Provide the resource ID for the Azure Resource Manager service connection as the
value for the dockerRegistryServiceConnection variable.
9. When you're ready, Save to commit the new pipeline into your repo.
Your pipeline is all setup to build and deploy your containerized for Day 2 operations.
You can customize your pipeline to meet your organizational needs.
Azure Migrate support matrix
You can use the Azure Migrate service to assess and migrate servers to the Microsoft
Azure cloud. This article summarizes general support settings and limitations for Azure
Migrate scenarios and deployments.
Supported assessment/migration scenarios

The table summarizes supported discovery, assessment, and migration scenarios.
Deployment Details
Discovery You can discover server metadata, and dynamic performance data.
Software You can discover apps, roles, and features running on VMware VMs. Currently this
inventory feature is limited to discovery only. Assessment is currently at the server level. We
don't yet offer app, role, or feature-based assessments.
Assessment Assess on-premises workloads and data running on VMware VMs, Hyper-V VMs,
and physical servers. Assess using Azure Migrate: Discovery and assessment,
Microsoft Data Migration Assistant (DMA), as well as other tools and ISV offerings.
Migration Migrate workloads and data running on physical servers, VMware VMs, Hyper-V
VMs, physical servers, and cloud-based VMS to Azure. Migrate using the Migration
and modernization tool and Azure Database Migration Service (DMS), and well as
other tools and ISV offerings.
７ Note
Currently, ISV tools can't send data to Azure Migrate in Azure Government. You can
use integrated Microsoft tools, or use partner tools independently.
Supported tools
Specific tool support is summarized in the table.
Tool Assess Migrate
Azure Migrate: Assess VMware VMs, Hyper-V VMs, and Not available (N/A)
Discovery and physical servers.
assessment
Tool Assess Migrate
Migration and N/A Migrate VMware VMs, Hyper-V

modernization VMs, and physical servers.
Carbonite N/A Migrate VMware VMs, Hyper-V

VMs, physical servers, and other
cloud workloads.
Cloudamize Assess VMware VMs, Hyper-V VMs, N/A

physical servers, and other cloud
workloads.
CloudSphere Assess VMware VMs, Hyper-V VMs, N/A

workloads.
Corent Assess VMware VMs, Hyper-V VMs, Migrate VMware VMs, Hyper-V
Technology physical server sand other cloud VMs, physical servers, public cloud
workloads. workloads.
Device 42 Assess VMware VMs, Hyper-V VMs, N/A

workloads.
DMA Assess SQL Server databases. N/A
DMS N/A Migrate SQL Server, Oracle, MySQL,

PostgreSQL, MongoDB.
Lakeside Assess virtual desktop infrastructure (VDI) N/A
Movere Assess VMware VMs, Hyper-V VMs, Xen N/A

VMs, physical servers, workstations
(including VDI) and other cloud
workloads.
RackWare N/A Migrate VMware VMs, Hyper-V

VMs, Xen VMs, KVM VMs, physical
servers, and other cloud workloads
Turbonomic Assess VMware VMs, Hyper-V VMs, N/A

workloads.
UnifyCloud Assess VMware VMs, Hyper-V VMs, N/A

physical servers and other cloud
workloads, and SQL Server databases.
Tool Assess Migrate
Webapp Assess web apps Migrate web apps.

Migration
Assistant
Zerto N/A Migrate VMware VMs, Hyper-V

VMs, physical servers, and other
cloud workloads.
Project
Support Details
Subscription Can have multiple projects within a subscription.
Azure Users need Contributor or Owner permissions in the subscription to create a

permissions project.
VMware VMs Assess up to 35,000 VMware VMs in a single project.
Hyper-V VMs Assess up to 35,000 Hyper-V VMs in a single project.
A project can include both VMware VMs and Hyper-V VMs, up to the assessment limits.
Azure permissions
For Azure Migrate to work with Azure you need these permissions before you start
assessing and migrating servers.
Task Permissions Details
Create a Your Azure account needs permissions to create a project. Set up for
project VMware,
Hyper-V, or
physical
servers.
Task Permissions Details
Register Azure Migrate uses a lightweight Azure Migrate appliance to discover Set up for
the Azure and assess servers with Azure Migrate: Discovery and assessment, and VMware,
Migrate to run agentless migration of VMware VMs with the Migration and Hyper-V, or
appliance modernization tool. This appliance discovers servers, and sends physical
metadata and performance data to Azure Migrate. servers.
During registration, register providers (Microsoft.OffAzure,

Microsoft.Migrate, and Microsoft.KeyVault) are registered with the
subscription chosen in the appliance, so that the subscription works
with the resource provider. To register, you need Contributor or Owner
access on the subscription.
VMware-During onboarding, Azure Migrate creates two Azure Active

Directory (Azure AD) apps. The first app communicates between the
appliance agents and the Azure Migrate service. The app doesn't have
permissions to make Azure resource management calls or have Azure
RBAC access for resources. The second app accesses an Azure Key
Vault created in the user subscription for agentless VMware migration
only. In agentless migration, Azure Migrate creates a Key Vault to
manage access keys to the replication storage account in your
subscription. It has Azure RBAC access on the Azure Key Vault (in the
customer tenant) when discovery is initiated from the appliance.
Hyper-V-During onboarding. Azure Migrate creates one Azure AD

app. The app communicates between the appliance agents and the
Azure Migrate service. The app doesn't have permissions to make
Azure resource management calls or have Azure RBAC access for
resources.
Create a To migrate VMware VMs with agentless Migration and modernization, Set up
key vault Azure Migrate creates a Key Vault to manage access keys to the permissions.
for replication storage account in your subscription. To create the vault,
VMware you set permissions (Owner, or Contributor and User Access
agentless Administrator) on the resource group where the project resides.
migration
Supported geographies
Public cloud
You can create a project in many geographies in the public cloud.
Although you can only create projects in these geographies, you can assess or
migrate servers for other target locations.
The project geography is only used to store the discovered metadata.
When you create a project, you select a geography. The project and related
resources are created in one of the regions in the geography. The region is
allocated by the Azure Migrate service. Azure Migrate does not move or store
customer data outside of the region allocated.
Geography Metadata storage location
Africa South Africa or North Africa
Asia Pacific East Asia
Australia Australia East or Australia Southeast
Brazil Brazil South
Canada Canada Central or Canada East
Europe North Europe or West Europe
France France Central
Germany Germany West Central
India Central India or South India
Japan Japan East or Japan West
Jio India Jio India West
Korea Korea Central
Norway Norway East
Sweden Sweden Central
Switzerland Switzerland North
United Arab Emirates UAE North
United Kingdom UK South or UK West
United States Central US or West US 2
７ Note
For Switzerland geography, Switzerland West is only available for REST API users
and need an approved subscription.
Azure Government
Task Geography Details
Create United Metadata is stored in US Gov Arizona, US Gov Virginia

project States
Target United Target regions: US Gov Arizona, US Gov Virginia, US Gov Texas
assessment States
Target United Target regions: US DoD Central, US DoD East, US Gov Arizona, US Gov
replication States Iowa, US Gov Texas, US Gov Virginia
Azure China 21Vianet (Azure China)
Geography Metadata storage location
Azure China China North 2
VMware assessment and migration

Review the Azure Migrate: Discovery and assessment and Migration and modernization
support matrix for VMware VMs.
Hyper-V assessment and migration

Review the Azure Migrate: Discovery and assessment and Migration and modernization
support matrix for Hyper-V VMs.
Azure Migrate versions

There are two versions of the Azure Migrate service:
Current version: Using this version you can create new projects, discover on-
premises assesses, and orchestrate assessments and migrations. Learn more.
Previous version: For customer using the previous version of Azure Migrate (only
assessment of on-premises VMware VMs was supported), you should now use the
current version. In the previous version, you can't create new projects or perform
new discoveries.
Next steps
Assess VMware VMs for migration.
Assess Hyper-V VMs for migration.
 Documentation

Azure Migrate appliance FAQ - Azure Migrate

Get answers to common questions about the Azure Migrate appliance.
Migrate servers to Azure by using Private Link - Azure Migrate

Use Azure Migrate with private endpoints for migrations by using ExpressRoute private peering or
VPN connections.

Assess VMware servers for migration to Azure VMs in Azure Migrate - Azure Migrate
Learn how to assess VMware servers for migration to Azure VMs with Azure Migrate.

Migrate
Discover and assess using Azure Private Link - Azure Migrate

Create an Azure Migrate project, set up the Azure Migrate appliance, and use it to discover and
assess servers for migration.
Show 5 more
 Training

Azure security baseline for Azure
Migrate
This security baseline applies guidance from the Microsoft cloud security benchmark
version 1.0 to Azure Migrate. The Microsoft cloud security benchmark provides
recommendations on how you can secure your cloud solutions on Azure. The content is
grouped by the security controls defined by the Microsoft cloud security benchmark and
the related guidance applicable to Azure Migrate.
You can monitor this security baseline and its recommendations using Microsoft
Defender for Cloud. Azure Policy definitions will be listed in the Regulatory Compliance
section of the Microsoft Defender for Cloud dashboard.
When a feature has relevant Azure Policy Definitions, they are listed in this baseline to
help you measure compliance to the Microsoft cloud security benchmark controls and
recommendations. Some recommendations may require a paid Microsoft Defender plan
to enable certain security scenarios.
７ Note
Features not applicable to Azure Migrate have been excluded. To see how Azure
Migrate completely maps to the Microsoft cloud security benchmark, see the full
Azure Migrate security baseline mapping file .
Security profile
The security profile summarizes high-impact behaviors of Azure Migrate, which may
result in increased security considerations.
Service Behavior Attribute Value
Product Category Migration
Customer can access HOST / OS No Access
Service can be deployed into customer's virtual network True
Stores customer content at rest True

Network security
For more information, see the Microsoft cloud security benchmark: Network security.
NS-2: Secure cloud services with network controls
Features
Azure Private Link
Description: Service native IP filtering capability for filtering network traffic (not to be
confused with NSG or Azure Firewall). Learn more.
Supported Enabled By Default Configuration Responsibility
True False Customer
Feature notes: The customer is able to configure Azure Migrate to require Private Link.
Configuration Guidance: Deploy private endpoints for all Azure resources that support
the Private Link feature, to establish a private access point for the resources.
Azure Migrate Private Link support allows customers to securely discover, assess, and
migrate servers over a private network while offering protection against data exfiltration
risks and enabling greater migration velocity.
You can connect privately and securely to Azure Migrate over an Azure ExpressRoute
private peering or a site-to-site (S2S) VPN connection by using Private Link.
Reference: Using Azure Migrate with Azure Private Link
Disable Public Network Access
Description: Service supports disabling public network access either through using
service-level IP ACL filtering rule (not NSG or Azure Firewall) or using a 'Disable Public
Network Access' toggle switch. Learn more.
True False Customer
Feature notes: The customer may configure Azure Migrate with Private Link, thereby
disabling public endpoint access.
Configuration Guidance: Disable public network access using by toggling the switch for
public network access.
You can configure the connectivity method for your Azure Migrate project and choose
to enable or disable public network access to the Migrate project.
Reference: Using Azure Migrate with private endpoints
Identity management
For more information, see the Microsoft cloud security benchmark: Identity management.
IM-1: Use centralized identity and authentication system
Features
Azure AD Authentication Required for Data Plane Access
Description: Service supports using Azure AD authentication for data plane access.
Learn more.
True True Microsoft
Feature notes: Azure Migrate leverages managed identities and service principals in
Azure AD for certain data plane operations. Azure Migrate also supports Azure AD for
user access of the control plane through the Azure Portal.
Configuration Guidance: No additional configurations are required as this is enabled on

a default deployment.
IM-3: Manage application identities securely and

automatically
Features
Managed Identities
Description: Data plane actions support authentication using managed identities. Learn
more.
True False Microsoft
Feature notes: Azure Migrate uses managed identity to securely access migrated data
that is kept in a storage account. This is currently used in a scenario where private
endpoint is configured.
Configuration Guidance: Use Azure managed identities instead of service principals

when possible, which can authenticate to Azure services and resources that support
Azure Active Directory (Azure AD) authentication. Managed identity credentials are fully
managed, rotated, and protected by the platform, avoiding hard-coded credentials in
source code or configuration files.
Service Principals
Description: Data plane supports authentication using service principals. Learn more.
True False Customer
Feature notes: The discovery and assessment services within Azure Migrate do not use
service principals, however the migration service does use service principals in a public
endpoint scenario to connect to the customer’s key vault using Hyper-V recovery
manager app.
Configuration Guidance: There is no current Microsoft guidance for this feature

configuration. Please review and determine if your organization wants to configure this
security feature.
IM-8: Restrict the exposure of credential and secrets
Features
Service Credential and Secrets Support Integration and Storage in

Azure Key Vault
Description: Data plane supports native use of Azure Key Vault for credential and secrets
store. Learn more.
True True Microsoft
Feature notes: The Azure Migrate appliance leverages Key Vault to manage connection
strings for the service bus, and access keys for the storage accounts are used for
replication.

Data protection
For more information, see the Microsoft cloud security benchmark: Data protection.
DP-3: Encrypt sensitive data in transit
Features
Data in Transit Encryption
Description: Service supports data in-transit encryption for data plane. Learn more.
True True Microsoft
Feature notes: Encryption of data-in-transit is enabled by default. Azure Migrate

supports data encryption in transit with TLS v1.2 or greater.
While this is optional for traffic on private networks, this is critical for traffic on external
and public networks. For HTTP traffic, ensure that any clients (including the Azure
Migrate appliance and other machines on which you’ve installed Azure Migrate
software) connecting to your Azure resources can negotiate TLS v1.2 or greater. For
remote management, use SSH (for Linux) or RDP/TLS (for Windows) instead of an
unencrypted protocol. Obsoleted SSL, TLS, and SSH versions and protocols, and weak
ciphers should be disabled.
DP-4: Enable data at rest encryption by default
Features
Data at Rest Encryption Using Platform Keys
Description: Data at-rest encryption using platform keys is supported, any customer
content at rest is encrypted with these Microsoft managed keys. Learn more.
True True Microsoft
Feature notes: All data persisted in Azure Migrate is encrypted at rest with Microsoft-
managed keys.
The Server Migration tool in Azure Migrate replicates data from the disks of servers
being migrated to storage accounts and managed disks in your Azure subscription. Data
handling is transient until it is written to storage accounts or managed disks in the
subscription and is not persisted in Azure Migrate. Replicated data on the storage
account and managed disks is encrypted at rest with Microsoft-managed keys. For
highly sensitive data, you have options to implement additional encryption at rest with
customer-managed keys on the storage account and managed disks.

DP-5: Use customer-managed key option in data at rest

encryption when required
Features
Data at Rest Encryption Using CMK
Description: Data at-rest encryption using customer-managed keys is supported for

customer content stored by the service. Learn more.
True False Customer
Configuration Guidance: Enable and implement data at rest encryption for your
replicated data using customer-managed keys.
To replicate VMs with CMK, you'll need to create a disk encryption set under the target
Resource Group. A disk encryption set object maps Managed Disks to a Key Vault that
contains the CMK to use for SSE.
Reference: Migrate VMware VMs to Azure (agentless)
DP-6: Use a secure key management process
Features
Key Management in Azure Key Vault
Description: The service supports Azure Key Vault integration for any customer keys,
secrets, or certificates. Learn more.
True True Microsoft
Feature notes: The Azure Migrate appliance leverages Key Vault to manage connection
strings for the service bus, and access keys for the storage accounts are used for
replication.

Reference: Set up the Azure Migrate appliance
Asset management
For more information, see the Microsoft cloud security benchmark: Asset management.
AM-2: Use only approved services

Features
Azure Policy Support
Description: Service configurations can be monitored and enforced via Azure Policy.
Learn more.
True False Customer
Feature notes: Azure Migrate may leverage Azure Policy, however it must be configured
by the customer to be enforced.
Configuration Guidance: Use Microsoft Defender for Cloud to configure Azure Policy to
audit and enforce configurations of your Azure resources. Use Azure Monitor to create
alerts when there is a configuration deviation detected on the resources. Use Azure
Policy [deny] and [deploy if not exists] effects to enforce secure configuration across
Azure resources.
Reference: Azure Policy built-in definitions for Azure Migrate
Logging and threat detection

For more information, see the Microsoft cloud security benchmark: Logging and threat
detection.
LT-4: Enable logging for security investigation
Features
Azure Resource Logs
Description: Service produces resource logs that can provide enhanced service-specific
metrics and logging. The customer can configure these resource logs and send them to
their own data sink like a storage account or log analytics workspace. Learn more.
False Not Applicable Not Applicable
Configuration Guidance: This feature is not supported to secure this service.

Next steps
See the Microsoft cloud security benchmark overview
Learn more about Azure security baselines
Support matrix for VMware discovery
Article • 05/15/2023
This article summarizes prerequisites and support requirements for using the Azure
Migrate: Discovery and assessment tool to discover and assess servers in a VMware
environment for migration to Azure.
To assess servers, first, create an Azure Migrate project. The Azure Migrate: Discovery
and assessment tool is automatically added to the project. Then, deploy the Azure
Migrate appliance. The appliance continuously discovers on-premises servers and sends
configuration and performance metadata to Azure. When discovery is completed, gather
the discovered servers into groups and run assessments per group.
As you plan your migration of VMware servers to Azure, review the migration support
matrix.
Limitations
Requirement Details
Project limits You can create multiple Azure Migrate projects in an Azure subscription.
You can discover and assess up to 50,000 servers in a VMware environment in a

single project. A project can include physical servers and servers from a Hyper-V
environment, up to the assessment limits.
Discovery The Azure Migrate appliance can discover up to 10,000 servers running across
multiple vCenter Servers.
The appliance supports adding multiple vCenter Servers. You can add up to 10
vCenter Servers per appliance.
Assessment You can add up to 35,000 servers in a single group.
You can assess up to 35,000 servers in a single assessment.
Learn more about assessments.
VMware requirements
VMware Details
VMware Details
vCenter Servers that you want to discover and assess must be managed by vCenter Server
Server version 7.0, 6.7, 6.5, 6.0, or 5.5.
Discovering servers by providing ESXi host details in the appliance currently isn't
supported.
IPv6 addresses aren't supported for vCenter Server (for discovery and assessment
of servers) and ESXi hosts (for replication of servers).
Permissions The Azure Migrate: Discovery and assessment tool requires a vCenter Server read-
only account.
If you want to use the tool for software inventory, agentless dependency analysis,
web apps and SQL discovery, the account must have privileges for guest operations
on VMware VMs.
Server requirements
VMware Details
Operating systems All Windows and Linux operating systems can be assessed for migration.
Storage Disks attached to SCSI, IDE, and SATA-based controllers are supported.
Azure Migrate appliance requirements

Azure Migrate uses the Azure Migrate appliance for discovery and assessment. You can
deploy the appliance as a server in your VMware environment using a VMware Open
Virtualization Appliance (OVA) template that's imported into vCenter Server or by using
a PowerShell script. Learn more about appliance requirements for VMware.
Here are more requirements for the appliance:
In Azure Government, you must deploy the appliance by using a script.

The appliance must be able to access specific URLs in public clouds and
government clouds.
Port access requirements

Device Connection
Device Connection
Azure Inbound connections on TCP port 3389 to allow remote desktop connections to the
Migrate appliance.
Appliance
Inbound connections on port 44368 to remotely access the appliance management
app by using the URL https://<appliance-ip-or-name>:44368 .
Outbound connections on port 443 (HTTPS) to send discovery and performance

metadata to Azure Migrate.
vCenter Inbound connections on TCP port 443 to allow the appliance to collect configuration
Server and performance metadata for assessments.
The appliance connects to vCenter on port 443 by default. If vCenter Server listens on
a different port, you can modify the port when you set up discovery.
ESXi For discovery of software inventory or agentless dependency analysis, the appliance
hosts connects to ESXi hosts on TCP port 443 to discover software inventory and
dependencies on the servers.
Software inventory requirements

In addition to discovering servers, Azure Migrate: Discovery and assessment can perform
software inventory on servers. Software inventory provides the list of applications, roles
and features running on Windows and Linux servers, discovered using Azure Migrate. It
allows you to identify and plan a migration path tailored for your on-premises
workloads.
Support Details
Supported You can perform software inventory on up to 10,000 servers running across
servers vCenter Server(s) added to each Azure Migrate appliance.
Operating Servers running all Windows and Linux versions are supported.
systems
Server For software inventory, VMware Tools must be installed and running on your
requirements servers. The VMware Tools version must be version 10.2.1 or later.
WMI must be enabled and available on Windows servers to gather the details of
the roles and features installed on the servers.
Support Details
vCenter To interact with the servers for software inventory, the vCenter Server read-only
Server account that's used for assessment must have privileges for guest operations on
account VMware VMs.
Server access You can add multiple domain and non-domain (Windows/Linux) credentials in the
appliance configuration manager for software inventory.
You must have a guest user account for Windows servers and a standard user
account (non- sudo access) for all Linux servers.
Port access The Azure Migrate appliance must be able to connect to TCP port 443 on ESXi
hosts running servers on which you want to perform software inventory. The
server running vCenter Server returns an ESXi host connection to download the
file that contains the details of the software inventory.
Discovery Software inventory is performed from vCenter Server by using VMware Tools
installed on the servers.
The appliance gathers the information about the software inventory from the
server running vCenter Server through vSphere APIs.
Software inventory is agentless. No agent is installed on the server, and the

appliance doesn't connect directly to the servers.
SQL Server instance and database discovery

requirements
Software inventory identifies SQL Server instances. Using this information, the appliance
attempts to connect to the respective SQL Server instances through the Windows
authentication or SQL Server authentication credentials in the appliance configuration
manager. The appliance can connect to only those SQL Server instances to which it has
network line of sight, whereas software inventory by itself may not need network line of
sight.
After the appliance is connected, it gathers configuration and performance data for SQL
Server instances and databases. The appliance updates the SQL Server configuration
data once every 24 hours and captures the Performance data every 30 seconds.
Support Details
Support Details
Supported Supported only for servers running SQL Server in your VMware, Microsoft
servers Hyper-V, and Physical/Bare metal environments as well as IaaS Servers of other
public clouds such as AWS, GCP, etc.
You can discover up to 750 SQL Server instances or 15,000 SQL databases,
whichever is less, from a single appliance. It is recommended that you ensure
that an appliance is scoped to discover less than 600 servers running SQL to
avoid scaling issues.
Windows Windows Server 2008 and later are supported.

servers
Linux servers Currently not supported.
Authentication Both Windows and SQL Server authentication are supported. You can provide
mechanism credentials of both authentication types in the appliance configuration
manager.
access account must be a member of the sysadmin server role or have these
permissions for each SQL Server instance.
SQL Server SQL Server 2008 and later are supported.

versions
SQL Server Enterprise, Standard, Developer, and Express editions are supported.
editions
Supported Discovery of standalone, highly available, and disaster protected SQL

SQL deployments is supported. Discovery of HADR SQL deployments powered by
configuration Always On Failover Cluster Instances and Always On Availability Groups is also
supported.
Supported Only SQL Server Database Engine is supported.

SQL services
Discovery of SQL Server Reporting Services (SSRS), SQL Server Integration
Services (SSIS), and SQL Server Analysis Services (SSAS) isn't supported.
７ Note
i.e. Azure Migrate encrypts communication between the Azure Migrate appliance
and the source SQL Server instances by setting the TrustServerCertificate property
to true . Additionally, the transport layer uses SSL to encrypt the channel and
bypass the certificate chain to validate trust. Hence, the appliance server must be
set up to trust the certificate's root authority.
However, you can modify the connection settings, by selecting Edit SQL Server
connection properties on the appliance.Learn more to understand what to choose.
Configure the custom login for SQL Server discovery

The following are sample scripts for creating a login and provisioning it with the
necessary permissions.
Windows Authentication
SQL
-- Create a login to run the assessment

use master;
-- If a SID needs to be specified, add here
DECLARE @SID NVARCHAR(MAX) = N'';
CREATE LOGIN [MYDOMAIN\MYACCOUNT] FROM WINDOWS;
SELECT @SID = N'0x'+CONVERT(NVARCHAR, sid, 2) FROM sys.syslogins where
name = 'MYDOMAIN\MYACCOUNT'
IF (ISNULL(@SID,'') != '')
PRINT N'Created login [MYDOMAIN\MYACCOUNT] with SID = ' + @SID
ELSE
PRINT N'Login creation failed'
GO
-- Create user in every database other than tempdb and model and provide
minimal read-only permissions.
use master;
EXECUTE sp_MSforeachdb 'USE [?]; IF (''?'' NOT IN (''tempdb'',''model''))
BEGIN TRY CREATE USER [MYDOMAIN\MYACCOUNT] FOR LOGIN [MYDOMAIN\MYACCOUNT]
END TRY BEGIN CATCH PRINT ERROR_MESSAGE() END CATCH'
BEGIN TRY GRANT SELECT ON sys.sql_expression_dependencies TO
[MYDOMAIN\MYACCOUNT] END TRY BEGIN CATCH PRINT ERROR_MESSAGE() END CATCH'
BEGIN TRY GRANT VIEW DATABASE STATE TO [MYDOMAIN\MYACCOUNT] END TRY BEGIN
CATCH PRINT ERROR_MESSAGE() END CATCH'
GO
-- Provide server level read-only permissions

use master;
[MYDOMAIN\MYACCOUNT] END TRY BEGIN CATCH PRINT ERROR_MESSAGE() END CATCH;
BEGIN TRY GRANT EXECUTE ON OBJECT::sys.xp_regenumkeys TO
CATCH PRINT ERROR_MESSAGE() END CATCH;
BEGIN TRY GRANT VIEW SERVER STATE TO [MYDOMAIN\MYACCOUNT] END TRY BEGIN
BEGIN TRY GRANT VIEW ANY DEFINITION TO [MYDOMAIN\MYACCOUNT] END TRY BEGIN
GO
-- Required from SQL 2014 onwards for database connectivity.

use master;
BEGIN TRY GRANT CONNECT ANY DATABASE TO [MYDOMAIN\MYACCOUNT] END TRY BEGIN
GO
-- Provide msdb specific permissions

use msdb;
BEGIN TRY GRANT EXECUTE ON [msdb].[dbo].[agent_datetime] TO
BEGIN TRY GRANT SELECT ON [msdb].[dbo].[sysjobsteps] TO
BEGIN TRY GRANT SELECT ON [msdb].[dbo].[syssubsystems] TO
BEGIN TRY GRANT SELECT ON [msdb].[dbo].[sysjobhistory] TO
BEGIN TRY GRANT SELECT ON [msdb].[dbo].[syscategories] TO
BEGIN TRY GRANT SELECT ON [msdb].[dbo].[sysjobs] TO [MYDOMAIN\MYACCOUNT]
END TRY BEGIN CATCH PRINT ERROR_MESSAGE() END CATCH;
BEGIN TRY GRANT SELECT ON [msdb].[dbo].[sysmaintplan_plans] TO
BEGIN TRY GRANT SELECT ON [msdb].[dbo].[syscollector_collection_sets] TO
BEGIN TRY GRANT SELECT ON [msdb].[dbo].[sysmail_profile] TO
BEGIN TRY GRANT SELECT ON [msdb].[dbo].[sysmail_profileaccount] TO
BEGIN TRY GRANT SELECT ON [msdb].[dbo].[sysmail_account] TO
GO
-- Clean up
--use master;
-- EXECUTE sp_MSforeachdb 'USE [?]; BEGIN TRY DROP USER [MYDOMAIN\MYACCOUNT]
END TRY BEGIN CATCH PRINT ERROR_MESSAGE() END CATCH;'
-- BEGIN TRY DROP LOGIN [MYDOMAIN\MYACCOUNT] END TRY BEGIN CATCH PRINT
ERROR_MESSAGE() END CATCH;
--GO
SQL Server Authentication
SQL

use master;
IF (@SID = N'')
BEGIN
CREATE LOGIN [evaluator]
WITH PASSWORD = '<provide a strong password>'
END
ELSE
BEGIN
, SID = @SID
END
name = 'evaluator'
PRINT N'Created login [evaluator] with SID = '+@SID
ELSE
GO
use master;
BEGIN TRY CREATE USER [evaluator] FOR LOGIN [evaluator]END TRY BEGIN CATCH
PRINT ERROR_MESSAGE() END CATCH'
BEGIN TRY GRANT SELECT ON sys.sql_expression_dependencies TO [evaluator]END
TRY BEGIN CATCH PRINT ERROR_MESSAGE() END CATCH'
BEGIN TRY GRANT VIEW DATABASE STATE TO [evaluator]END TRY BEGIN CATCH PRINT
ERROR_MESSAGE() END CATCH'
GO

use master;
BEGIN TRY GRANT SELECT ON sys.sql_expression_dependencies TO [evaluator]
BEGIN TRY GRANT EXECUTE ON OBJECT::sys.xp_regenumkeys TO [evaluator] END
TRY BEGIN CATCH PRINT ERROR_MESSAGE() END CATCH;
BEGIN TRY GRANT VIEW DATABASE STATE TO [evaluator] END TRY BEGIN CATCH
PRINT ERROR_MESSAGE() END CATCH;
BEGIN TRY GRANT VIEW SERVER STATE TO [evaluator] END TRY BEGIN CATCH PRINT
BEGIN TRY GRANT VIEW ANY DEFINITION TO [evaluator] END TRY BEGIN CATCH
GO

use master;
BEGIN TRY GRANT CONNECT ANY DATABASE TO [evaluator] END TRY BEGIN CATCH
GO

use msdb;
BEGIN TRY GRANT EXECUTE ON [msdb].[dbo].[agent_datetime] TO [evaluator] END
BEGIN TRY GRANT SELECT ON [msdb].[dbo].[sysjobsteps] TO [evaluator] END TRY
BEGIN CATCH PRINT ERROR_MESSAGE() END CATCH;
BEGIN TRY GRANT SELECT ON [msdb].[dbo].[syssubsystems] TO [evaluator] END
BEGIN TRY GRANT SELECT ON [msdb].[dbo].[sysjobhistory] TO [evaluator] END
BEGIN TRY GRANT SELECT ON [msdb].[dbo].[syscategories] TO [evaluator] END
BEGIN TRY GRANT SELECT ON [msdb].[dbo].[sysjobs] TO [evaluator] END TRY
BEGIN TRY GRANT SELECT ON [msdb].[dbo].[sysmaintplan_plans] TO [evaluator]
[evaluator] END TRY BEGIN CATCH PRINT ERROR_MESSAGE() END CATCH;
BEGIN TRY GRANT SELECT ON [msdb].[dbo].[sysmail_profile] TO [evaluator] END
BEGIN TRY GRANT SELECT ON [msdb].[dbo].[sysmail_account] TO [evaluator] END
GO
-- Clean up
--use master;
-- EXECUTE sp_MSforeachdb 'USE [?]; BEGIN TRY DROP USER [evaluator] END TRY
BEGIN CATCH PRINT ERROR_MESSAGE() END CATCH;'
-- BEGIN TRY DROP LOGIN [evaluator] END TRY BEGIN CATCH PRINT
--GO
Web apps discovery requirements

Software inventory identifies web server role existing on discovered servers. If a server
has a web server installed, Azure Migrate discovers web apps on the server. The user can
add both domain and non-domain credentials on the appliance. Ensure that the account
used has local admin privileges on source servers. Azure Migrate automatically maps
credentials to the respective servers, so one doesn’t have to map them manually. Most
importantly, these credentials are never sent to Microsoft and remain on the appliance
running in the source environment. After the appliance is connected, it gathers
configuration data for ASP.NET web apps(IIS web server) and Java web apps(Tomcat
servers). Web apps configuration data is updated once every 24 hours.
Support ASP.NET web apps Java web apps
Stack VMware, Hyper-V, and VMware, Hyper-V, and Physical servers

Physical servers
Windows Windows Server 2008 R2 Not supported.

servers and later are supported.
Linux Not supported. Ubuntu Linux 16.04/18.04/20.04, Debian 7/8, CentOS

servers 6/7, Red Hat Enterprise Linux 5/6/7.
Web IIS 7.5 and later. Tomcat 8 or later.

server
versions
Required local admin root or sudo user

privileges
７ Note
Data is always encrypted at rest and during transit.
Dependency analysis requirements (agentless)

Dependency analysis helps you analyze the dependencies between the discovered
servers, which can be easily visualized with a map view in Azure Migrate project and
used to group related servers for migration to Azure. The following table summarizes
the requirements for setting up agentless dependency analysis:
Support Details
Supported You can enable agentless dependency analysis on up to 1000 servers (across
servers multiple vCenter Servers), discovered per appliance.
Windows Windows Server 2019

servers Windows Server 2016
Windows Server 2012 R2
Windows Server 2012
Windows Server 2008 R2 (64-bit)
Microsoft Windows Server 2008 (32-bit)
Linux servers Red Hat Enterprise Linux 5.1, 5.3, 5.11, 6.x, 7.x, 8.x
Cent OS 5.1, 5.9, 5.11, 6.x, 7.x, 8.x
Ubuntu 12.04, 14.04, 16.04, 18.04, 20.04
OracleLinux 6.1, 6.7, 6.8, 6.9, 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 7.8, 7.9, 8, 8.1, 8.3, 8.5
SUSE Linux 10, 11 SP4, 12 SP1, 12 SP2, 12 SP3, 12 SP4, 15 SP2, 15 SP3
Debian 7, 8, 9, 10, 11
Support Details
Server VMware Tools (10.2.1 and later) must be installed and running on servers you
requirements want to analyze.
Servers must have PowerShell version 2.0 or later installed.
WMI should be enabled and available on Windows servers.
vCenter The read-only account used by Azure Migrate for assessment must have
Server privileges for guest operations on VMware VMs.
account
Windows A user account (local or domain) with administrator permissions on servers.

server acesss
Linux server Sudo user account with permissions to execute ls and netstat commands. If
access you're providing a sudo user account, ensure that you have enabled NOPASSWD
for the account to run the required commands without prompting for a password
every time a sudo command is invoked.
Alternatively, you can create a user account that has the CAP_DAC_READ_SEARCH
and CAP_SYS_PTRACE permissions on /bin/netstat and /bin/ls files, set using the
following commands:
Port access The Azure Migrate appliance must be able to connect to TCP port 443 on ESXi
hosts running the servers that have dependencies you want to discover. The
server running vCenter Server returns an ESXi host connection to download the
file containing the dependency data.
Discovery Dependency information between servers is gathered by using VMware Tools

method installed on the server running vCenter Server.
The appliance gathers the information from the server by using vSphere APIs.
No agent is installed on the server, and the appliance doesn’t connect directly to
servers.
Dependency analysis requirements (agent-

based)
Dependency analysis helps you identify dependencies between on-premises servers that
you want to assess and migrate to Azure. The following table summarizes the
requirements for setting up agent-based dependency analysis:
Requirement Details
Before You should have a project in place, with the Azure Migrate: Discovery and
deployment assessment tool added to the project.
Deploy dependency visualization after setting up an Azure Migrate appliance to

discover your on-premises servers.
Learn how to create a project for the first time.

Learn how to add a discovery and assessment tool to an existing project.
Learn how to set up the Azure Migrate appliance for assessment of Hyper-V,
VMware, or physical servers.
Supported Supported for all servers in your on-premises environment.

servers
Log Analytics Azure Migrate uses the Service Map solution in Azure Monitor logs for
dependency visualization.
You associate a new or existing Log Analytics workspace with a project. You can't
modify the workspace for a project after the workspace is added.
The workspace must be in the same subscription as the project.
The workspace must be located in the East US, Southeast Asia, or West Europe
regions. Workspaces in other regions can't be associated with a project.
The workspace must be in a region in which Service Map is supported.
In Log Analytics, the workspace that's associated with Azure Migrate is tagged
with the project key and project name.
Required On each server that you want to analyze, install the following agents:
agents - Microsoft Monitoring Agent (MMA)
- Dependency agent
If on-premises servers aren't connected to the internet, download and install the
Log Analytics gateway on them.
Learn more about installing the Dependency agent and the MMA.
Log Analytics The workspace must be in the same subscription as the project.
workspace
Azure Migrate supports workspaces that are located in the East US, Southeast
Asia, and West Europe regions.
The workspace for a project can't be modified after the workspace is added.
Requirement Details
Cost The Service Map solution doesn't incur any charges for the first 180 days (from
the day you associate the Log Analytics workspace with the project).
After 180 days, standard Log Analytics charges apply.
Using any solution other than Service Map in the associated Log Analytics
workspace incurs standard charges for Log Analytics.
When the project is deleted, the workspace isn't automatically deleted. After
deleting the project, Service Map usage isn't free, and each node will be charged
per the paid tier of Log Analytics workspace.
If you have projects that you created before Azure Migrate general availability
(February 28, 2018), you might have incurred additional Service Map charges. To
ensure that you're charged only after 180 days, we recommend that you create a
new project. Workspaces that were created before GA are still chargeable.
Management When you register agents to the workspace, use the ID and key provided by the
project.
You can use the Log Analytics workspace outside Azure Migrate.
If you delete the associated project, the workspace isn't deleted automatically.
Delete it manually.
Don't delete the workspace created by Azure Migrate, unless you delete the
project. If you do, the dependency visualization functionality doesn't work as
expected.
Internet If servers aren't connected to the internet, install the Log Analytics gateway on
connectivity the servers.
Azure Agent-based dependency analysis isn't supported.

Government
Next steps
Review assessment best practices.
Learn how to prepare for a VMware assessment.
Support matrix for Hyper-V assessment
Article • 05/15/2023
This article summarizes prerequisites and support requirements when you discover and
assess on-premises servers running in a Hyper-V environment for migration to Azure,
using the Azure Migrate: Discovery and assessment tool. If you want to migrate servers
running on Hyper-V to Azure, review the migration support matrix.
To set up discovery and assessment of servers running on Hyper-V, you create a project,
and add the Azure Migrate: Discovery and assessment tool to the project. After the tool
is added, you deploy the Azure Migrate appliance. The appliance continuously discovers
on-premises servers and sends server metadata and performance data to Azure. After
discovery is complete, you gather discovered servers into groups, and run an
assessment for a group.
Limitations
Support Details
Assessment You can discover and assess up to 35,000 servers in a single project.
limits
Project You can create multiple projects in an Azure subscription. In addition to servers on
limits Hyper-V, a project can include servers on VMware and physical servers, up to the
assessment limits for each.
Discovery The Azure Migrate appliance can discover up to 5000 servers running on Hyper-V.
The appliance can connect to up to 300 Hyper-V hosts.
You can assess up to 35,000 servers in a single assessment for a group.
Hyper-V host requirements

Support Details
Support Details
Hyper-V The Hyper-V host can be standalone or deployed in a cluster.

host
The Hyper-V host can run Windows Server 2019, Windows Server 2016, or
Windows Server 2012 R2. Server core installations of these operating systems are
also supported.
You can't assess servers located on Hyper-V hosts running Windows Server 2012.
Permissions You need Administrator permissions on the Hyper-V host.

If you don't want to assign Administrator permissions, create a local or domain user
account, and add the user account to these groups- Remote Management Users,
Hyper-V Administrators, and Performance Monitor Users.
PowerShell PowerShell remoting must be enabled on each Hyper-V host.

remoting
Hyper-V If you use Hyper-V Replica (or you have multiple servers with the same server
Replica identifiers), and you discover both the original and replicated servers using Azure
Migrate, the assessment generated by Azure Migrate might not be accurate.
Server requirements
Support Details
Operating All operating systems can be assessed for migration.

system
Integration Hyper-V Integration Services must be running on servers that you assess, in order
Services to capture operating system information.
Storage Local Disk, DAS, JBOD, Storage Spaces, CSV, SMB. These Hyper-V Host storages on
which VHD/VHDX are stored are supported.
IDE and SCSI virtual controllers are supported

Azure Migrate uses the Azure Migrate appliance for discovery and assessment. You can
deploy the appliance using a compressed Hyper-V VHD that you download from the
portal or using a PowerShell script.
Learn about appliance requirements for Hyper-V.

Learn about URLs that the appliance needs to access in public and government
clouds.
In Azure Government, you must deploy the appliance using the script.
Port access
The following table summarizes port requirements for assessment.
Device Connection
Appliance Inbound connections on TCP port 3389 to allow remote desktop connections to
the appliance.
Inbound connections on port 44368 to remotely access the appliance management

app using the URL: https://<appliance-ip-or-name>:44368
Outbound connections on ports 443 (HTTPS), to send discovery and performance

Hyper-V Inbound connection on WinRM port 5985 (HTTP) to pull metadata and
host/cluster performance data for servers on Hyper-V, using a Common Information Model
(CIM) session.
Servers For Windows server, need access on port 5985 (HTTP) and for Linux servers, need
access on port 22 (TCP) to perform software inventory and agentless dependency
analysis

helps you to identify and plan a migration path tailored for your on-premises workloads.
Support Details
Supported You can perform software inventory on up to 5,000 servers running across Hyper-
servers V host(s)/cluster(s) added to each Azure Migrate appliance.
Operating All Windows and Linux versions with Hyper-V integration services enabled.
systems
Support Details
Server Windows servers must have PowerShell remoting enabled and PowerShell version
requirements 2.0 or later installed.
Linux servers must have SSH connectivity enabled and ensure that the following
commands can be executed on the Linux servers to pull the application data: list,
tail, awk, grep, locate, head, sed, ps, print, sort, uniq. Based on OS type and the
type of package manager being used, here are some additional commands:
rpm/snap/dpkg, yum/apt-cache, mssql-server.
Server access You can add multiple domain and non-domain (Windows/Linux) credentials in the
appliance configuration manager for software inventory.
You must have a guest user account for Windows servers and a standard user
account (non- sudo access) for all Linux servers.
Port access For Windows server, need access on port 5985 (HTTP) and for Linux servers, need
access on port 22(TCP).
Discovery Software inventory is performed by directly connecting to the servers using the
server credentials added on the appliance.
The appliance gathers the information about the software inventory from
Windows servers using PowerShell remoting and from Linux servers using SSH
connection.
Software inventory is agentless. No agent is installed on the servers.

requirements
attempts to connect to respective SQL Server instances through the Windows
authentication or SQL Server authentication credentials that are provided in the
appliance configuration manager. Appliance can connect to only those SQL Server
instances to which it has network line of sight, whereas software inventory by itself may
not need network line of sight.
Server instances and databases. SQL Server configuration data is updated once every 24
hours. Performance data is captured every 30 seconds.
Support Details
Supported Supported only for servers running SQL Server in your VMware, Microsoft

servers
manager.

versions
editions

supported.

SQL services
７ Note

SQL

use master;
ELSE
GO
use master;
GO

use master;
GO

use master;
GO

use msdb;
GO
-- Clean up
--use master;
--GO
SQL

use master;
IF (@SID = N'')
BEGIN
END
ELSE
BEGIN
, SID = @SID
END
name = 'evaluator'
ELSE
GO
use master;
GO

use master;
GO

use master;
GO

use msdb;
GO
-- Clean up
--use master;
--GO

found to have a web server installed, Azure Migrate discovers web apps on the server.
The user can add both domain and non-domain credentials on the appliance. Ensure
that the account used has local admin privileges on source servers. Azure Migrate
automatically maps credentials to the respective servers, so one doesn’t have to map
them manually. Most importantly, these credentials are never sent to Microsoft and
remain on the appliance running in the source environment. After the appliance is
connected, it gathers configuration data for ASP.NET web apps(IIS web server) and Java
web apps(Tomcat servers). Web apps configuration data is updated once every 24 hours.

Physical servers



server
versions

privileges
７ Note

servers, which can be easily visualized with a map view in Azure Migrate project and can
be used to group related servers for migration to Azure. The following table summarizes
Support Details
Supported You can enable agentless dependency analysis on up to 1000 servers (across
servers multiple Hyper-V hosts/clusters), discovered per appliance.
Operating All Windows and Linux versions with Hyper-V integration services enabled.
systems
commands can be executed on the Linux servers: touch, chmod, cat, ps, grep,
echo, sha256sum, awk, netstat, ls, sudo, dpkg, rpm, sed, getcap, which, date.

server access
Support Details
every time sudo command is invoked.
following commands:
Discovery Agentless dependency analysis is performed by directly connecting to the servers

method using the server credentials added on the appliance.
The appliance gathers the dependency information from Windows servers using
PowerShell remoting and from Linux servers using SSH connection.
No agent is installed on the servers to pull dependency data.
Agent-based dependency analysis

requirements
Dependency analysis helps you to identify dependencies between on-premises servers
that you want to assess and migrate to Azure. The table summarizes the requirements
for setting up agent-based dependency analysis. Hyper-V currently only supports agent-
based dependency visualization.
Requirement Details
You deploy dependency visualization after setting up an Azure Migrate appliance

to discover your on-premises servers.

Learn how to add Azure Migrate: Discovery and assessment tool to an existing
project.
Learn how to set up the appliance for discovery and assessment of servers on
Hyper-V.
Requirement Details
Azure Dependency visualization isn't available in Azure Government.

Government
You associate a new or existing Log Analytics workspace with a project. The
workspace for a project can't be modified after it's added.
The workspace must reside in the East US, Southeast Asia, or West Europe
In Log Analytics, the workspace associated with Azure Migrate is tagged with the
Migration Project key, and the project name.
Required On each server you want to analyze, install the following agents:
agents
The Microsoft Monitoring agent (MMA).
The Dependency agent.
If on-premises servers aren't connected to the internet, you need to download

and install Log Analytics gateway on them.
Learn more about installing the Dependency agent and MMA.
Log Analytics The workspace must be in the same subscription as the project.
workspace
Azure Migrate supports workspaces residing in the East US, Southeast Asia, and
West Europe regions.
The workspace for a project can't be modified after it's added.

Requirement Details
Costs The Service Map solution doesn't incur any charges for the first 180 days (from
the day that you associate the Log Analytics workspace with the project)/
After 180 days, standard Log Analytics charges will apply.
workspace will incur standard charges for Log Analytics.
When the project is deleted, the workspace isn't deleted along with it. After
as per the paid tier of Log Analytics workspace/
(GA- 28 February 2018), you might have incurred additional Service Map charges.
To ensure payment after 180 days only, we recommend that you create a new
project, since existing workspaces before GA are still chargeable.
Management When you register agents to the workspace, you use the ID and key provided by
the project.
Delete it manually.
project. If you do, the dependency visualization functionality won't work as
expected.
Internet If servers aren't connected to the internet, you need to install the Log Analytics
connectivity gateway on them.

Government
Next steps
Prepare for assessment of servers running on Hyper-V.
Support matrix for physical server
discovery and assessment
Article • 05/15/2023
This article summarizes prerequisites and support requirements when you assess
physical servers for migration to Azure, using the Azure Migrate: Discovery and
assessment tool. If you want to migrate physical servers to Azure, review the migration
support matrix.
To assess physical servers, you create a project, and add the Azure Migrate: Discovery
and assessment tool to the project. After adding the tool, you deploy the Azure Migrate
appliance. The appliance continuously discovers on-premises servers, and sends servers
metadata and performance data to Azure. After discovery is complete, you gather
discovered servers into groups, and run an assessment for a group.
Limitations
Support Details
Assessment You can discover and assess up to 35,000 physical servers in a single project.
limits
Project You can create multiple projects in an Azure subscription. In addition to physical
limits servers, a project can include servers on VMware and on Hyper-V, up to the
assessment limits for each.
Discovery The Azure Migrate appliance can discover up to 1000 physical servers.
You can assess up to 35,000 servers in a single assessment.
Physical server requirements

Physical server deployment: The physical server can be standalone or deployed in a
cluster.
Type of servers: Bare metal servers, virtualized servers running on-premises or other
clouds like AWS, GCP, Xen etc.
７ Note
Currently, Azure Migrate does not support the discovery of para-virtualized servers.
Operating system: All Windows and Linux operating systems can be assessed for
migration.
Permissions for Windows server

For Windows servers, use a domain account for domain-joined servers, and a local
account for servers that aren't domain-joined. The user account can be created in one of
the two ways:
Option 1
Create an account that has administrator privileges on the servers. Use this account
to pull configuration and performance data through CIM connection and perform
software inventory (discovery of installed applications) and enable agentless
dependency analysis using PowerShell remoting.
７ Note

enable agentless dependency analysis on Windows servers, it recommended to use
Option 1.
Option 2
Add the user account to these groups: Remote Management Users, Performance
Monitor Users, and Performance Log Users.
If Remote management Users group isn't present, then add user account to the
group: WinRMRemoteWMIUsers_.
The account needs these permissions for appliance to create a CIM connection
with the server and pull the required configuration and performance metadata
from the WMI classes listed here.
In some cases, adding the account to these groups may not return the required
data from WMI classes as the account might be filtered by UAC. To overcome the
UAC filtering, user account needs to have necessary permissions on CIMV2
Namespace and sub-namespaces on the target server. You can follow the steps
here to enable the required permissions.
７ Note
For Windows Server 2008 and 2008 R2, ensure that WMF 3.0 is installed on the
servers.
７ Note
To discover SQL Server databases on Windows Servers, both Windows and SQL
Server authentication are supported. You can provide credentials of both
authentication types in the appliance configuration manager. Azure Migrate
requires a Windows user account that is a member of the sysadmin server role.
Permissions for Linux server

For Linux servers, based on the features you want to perform, you can create a user
account in one of two ways:
Option 1
You need a sudo user account on the servers that you want to discover. Use this
account to pull configuration and performance metadata, perform software
inventory (discovery of installed applications) and enable agentless dependency
analysis using SSH connectivity.
You need to enable sudo access on /usr/bin/bash to execute the commands listed
here. In addition to these commands, the user account also needs to have
permissions to execute ls and netstat commands to perform agentless dependency
analysis.
Make sure that you have enabled NOPASSWD for the account to run the required
commands without prompting for a password every time sudo command is
invoked.
Azure Migrate supports the following Linux OS distributions for discovery using an
account with sudo access:
Operating system Versions

Operating system Versions
Red Hat Enterprise Linux 5.1, 5.3, 5.11, 6.x, 7.x, 8.x
Cent OS 5.1, 5.9, 5.11, 6.x, 7.x, 8.x
Ubuntu 12.04, 14.04, 16.04, 18.04, 20.04
Oracle Linux 6.1, 6.7, 6.8, 6.9, 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 7.8, 7.9, 8, 8.1, 8.3, 8.5
SUSE Linux 10, 11 SP4, 12 SP1, 12 SP2, 12 SP3, 12 SP4, 15 SP2, 15 SP3
Debian 7, 8, 9, 10, 11
Amazon Linux 2.0.2021
CoreOS Container 2345.3.0
７ Note

enable agentless dependency analysis on Linux servers, it's recommended to use
Option 1.
Option 2
If you can't provide root account or user account with sudo access, then you can
set 'isSudo' registry key to value '0' in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AzureAppliance registry on
appliance server and provide a non-root account with the required capabilities
using the following commands:
Command Purpose
setcap CAP_DAC_READ_SEARCH+eip /usr/sbin/fdisk To collect

disk
setcap CAP_DAC_READ_SEARCH+eip /sbin/fdisk (if /usr/sbin/fdisk is not present) configuration
data
setcap To collect
"cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_setuid, disk
cap_setpcap,cap_net_bind_service,cap_net_admin,cap_sys_chroot,cap_sys_admin, performance
cap_sys_resource,cap_audit_control,cap_setfcap=+eip" /sbin/lvm data
Command Purpose
setcap CAP_DAC_READ_SEARCH+eip /usr/sbin/dmidecode To collect

BIOS serial
number
chmod a+r /sys/class/dmi/id/product_uuid To collect

BIOS GUID
To perform agentless dependency analysis on the server, ensure that you also set
the required permissions on /bin/netstat and /bin/ls files by using the following
commands:

Azure Migrate uses the Azure Migrate appliance for discovery and assessment. The
appliance for physical servers can run on a VM or a physical server.
Learn about appliance requirements for physical servers.

clouds.
You set up the appliance using a PowerShell script that you download from the
Azure portal. In Azure Government, deploy the appliance using this script.
Port access
The following table summarizes port requirements for assessment.
Device Connection
Appliance Inbound connections on TCP port 3389, to allow remote desktop connections to the
appliance.
Inbound connections on port 44368, to remotely access the appliance management

app using the URL: https://<appliance-ip-or-name>:44368
Outbound connections on ports 443 (HTTPS), to send discovery and performance

Device Connection
Physical Windows: Inbound connection on WinRM port 5985 (HTTP) to pull configuration and
servers performance metadata from Windows servers.
Linux: Inbound connections on port 22 (TCP), to pull configuration and performance

metadata from Linux servers.

helps you to identify and plan a migration path tailored for your on-premises workloads.
Support Details
Supported You can perform software inventory on up to 1,000 servers discovered from each
servers Azure Migrate appliance.
Operating Servers running all Windows and Linux versions that meet the server
systems requirements and have the required access permissions are supported.
commands can be executed on the Linux servers to pull the application data: list,
tail, awk, grep, locate, head, sed, ps, print, sort, uniq. Based on the OS type and
the type of package manager used, here are some additional commands:
rpm/snap/dpkg, yum/apt-cache, mssql-server.
Windows A guest user account for Windows servers

server access
Linux server A standard user account (non- sudo access) for all Linux servers
access
Support Details
Discovery Software inventory is performed by directly connecting to the servers using the
server credentials added on the appliance.
The appliance gathers the information about the software inventory from
Windows servers using PowerShell remoting and from Linux servers using SSH
connection.
Software inventory is agentless. No agent is installed on the servers.

requirements
attempts to connect to respective SQL Server instances through the Windows
authentication or SQL Server authentication credentials provided in the appliance
configuration manager. Appliance can connect to only those SQL Server instances to
which it has network line of sight, whereas software inventory by itself may not need
network line of sight.
Server instances and databases. The appliance updates the SQL Server configuration
data once every 24 hours and captures the Performance data every 30 seconds.
Support Details
Supported supported only for servers running SQL Server in your VMware, Microsoft

servers
manager.
Support Details

versions
editions

supported.

SQL services
７ Note

SQL
use master;
ELSE
GO
use master;
GO

use master;
GO

use master;
GO

use msdb;
GO
-- Clean up
--use master;
--GO
SQL

use master;
IF (@SID = N'')
BEGIN
END
ELSE
BEGIN
, SID = @SID
END
name = 'evaluator'
ELSE
GO
use master;
GO

use master;
GO

use master;
GO

use msdb;
GO
-- Clean up
--use master;
--GO

found to have a web server installed, Azure Migrate discovers web apps on the server.
The user can add both domain and non-domain credentials on the appliance. Ensure
automatically maps credentials to the respective servers, so one doesn’t have to map
them manually. Most importantly, these credentials are never sent to Microsoft and
remain on the appliance running in the source environment. After the appliance is
connected, it gathers configuration data for ASP.NET web apps(IIS web server) and Java
web apps(Tomcat servers). Web apps configuration data is updated once every 24 hours.

Physical servers



server
versions

privileges
７ Note

servers, which can be easily visualized with a map view in Azure Migrate project and can
be used to group related servers for migration to Azure. The following table summarizes
Support Details
Supported You can enable agentless dependency analysis on up to 1000 servers, discovered
servers per appliance.
Operating Servers running all Windows and Linux versions that meet the server
systems requirements and have the required access permissions are supported.
commands can be executed on the Linux servers: touch, chmod, cat, ps, grep,
echo, sha256sum, awk, netstat, ls, sudo, dpkg, rpm, sed, getcap, which, date

server access
every time sudo command is invoked.
following commands:
sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep usr/bin/ls

sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep usr/bin/netstat
Support Details
Discovery Agentless dependency analysis is performed by directly connecting to the servers

method using the server credentials added on the appliance.
The appliance gathers the dependency information from Windows servers using
PowerShell remoting and from Linux servers using SSH connection.
No agent is installed on the servers to pull dependency data.
Agent-based dependency analysis

requirements
Dependency analysis helps you to identify dependencies between on-premises servers
that you want to assess and migrate to Azure. The table summarizes the requirements
for setting up agent-based dependency analysis. Currently only agent-based
dependency analysis is supported for physical servers.
Requirement Details
You deploy dependency visualization after setting up an Azure Migrate appliance

to discover your on-premises servers

Learn how to add an assessment tool to an existing project.
Learn how to set up the Azure Migrate appliance for assessment of Hyper-V,
VMware, or physical servers.
Azure Dependency visualization isn't available in Azure Government.

Government
Requirement Details
You associate a new or existing Log Analytics workspace with a project. The
workspace for a project can't be modified after it's added.
In Log Analytics, the workspace associated with Azure Migrate is tagged with the
Migration Project key, and the project name.
Required On each server you want to analyze, install the following agents:
agents
The Microsoft Monitoring agent (MMA).
The Dependency agent.
If on-premises servers aren't connected to the internet, you need to download

and install Log Analytics gateway on them.
Learn more about installing the Dependency agent and MMA.
Log Analytics The workspace must be in the same subscription a project.

workspace
Azure Migrate supports workspaces residing in the East US, Southeast Asia, and
West Europe regions.
The workspace for a project can't be modified after adding it.

Requirement Details
Costs The Service Map solution doesn't incur any charges for the first 180 days (from
the day that you associate the Log Analytics workspace with the project).
After 180 days, standard Log Analytics charges will apply.
workspace incurs standard charges for Log Analytics.
When the project is deleted, the workspace isn't deleted along with it. After
as per the paid tier of Log Analytics workspace/
(GA - 28 February 2018), you might have incurred additional Service Map charges.
To ensure payment after 180 days only, we recommend that you create a new
project since existing workspaces before GA are still chargeable.
Management When you register agents to the workspace, you use the ID and key provided by
the project.
Delete it manually.
project. If you do, the dependency visualization functionality won't work as
expected.
Internet If servers aren't connected to the internet, you need to install the Log Analytics
connectivity gateway on them.

Government
Next steps
Prepare for physical Discovery and assessment.
Azure Migrate appliance
This article summarizes the prerequisites and support requirements for the Azure
Migrate appliance.
Deployment scenarios
The Azure Migrate appliance is used in the following scenarios.
Scenario Tool Used to
Discovery and Azure Discover servers running in your VMware

assessment of servers Migrate: environment
running in VMware Discovery and
environment assessment Perform discovery of installed software inventory,
ASP.NET web apps, SQL Server instances and
databases, and agentless dependency analysis.
Collect server configuration and performance

metadata for assessments.
Agentless migration of Migration and Discover servers running in your VMware

servers running in modernization environment.
VMware environment
Replicate servers without installing any agents on
them.
Discovery and Azure Discover servers running in your Hyper-V

assessment of servers Migrate: environment.
running in Hyper-V Discovery and
environment assessment Perform discovery of installed software inventory,
SQL Server instances and databases, and agentless
dependency analysis.

Discovery and Azure Discover physical or virtualized servers on-premises.

assessment of physical or Migrate:
virtualized servers on- Discovery and Perform discovery of installed software inventory,
premises assessment ASP.NET web apps, SQL Server instances and
databases, and agentless dependency analysis.

Deployment methods
The appliance can be deployed using a couple of methods:
The appliance can be deployed using a template for servers running in VMware or
Hyper-V environment (OVA template for VMware or VHD for Hyper-V).
If you don't want to use a template, you can deploy the appliance for VMware or
Hyper-V environment using a PowerShell installer script.
In Azure Government, you should deploy the appliance using a PowerShell installer
script. Refer to the steps of deployment here.
For physical or virtualized servers on-premises or any other cloud, you always
deploy the appliance using a PowerShell installer script.Refer to the steps of
deployment here.
Download links are available in the tables below.
７ Note
Don't install any other components, such as the Microsoft Monitoring Agent
(MMA) or Replication appliance, on the same server hosting the Azure Migrate
appliance. If you install the MMA agent, you can face problems like "Multiple
custom attributes of the same type found". It's recommended to have a dedicated
server to deploy the appliance.
Appliance services
The appliance has the following services:
Appliance configuration manager: This is a web application, which can be

configured with source details to start the discovery and assessment of servers.
Discovery agent: The agent collects server configuration metadata, which can be
used to create as on-premises assessments.
Assessment agent: The agent collects server performance metadata, which can be
used to create performance-based assessments.
Auto update service: The service keeps all the agents running on the appliance
up-to-date. It automatically runs once every 24 hours.
SQL discovery and assessment agent: sends the configuration and performance
metadata of SQL Server instances and databases to Azure.
DRA agent: Orchestrates server replication, and coordinates communication
between replicated servers and Azure. Used only when replicating servers to Azure
using agentless migration.
Gateway: Sends replicated data to Azure. Used only when replicating servers to
Azure using agentless migration.
Web apps discovery and assessment agent: sends the web apps configuration
data to Azure.
７ Note
The last 3 services are available in the appliance used for discovery and assessment
of servers running in your VMware VMs, Hyper-V VMs, bare-metal servers, and
servers running on other public clouds like AWS, GCP etc.
Appliance - VMware
The following table summarizes the Azure Migrate appliance requirements for VMware.
Requirement VMware
Permissions To access the appliance configuration manager locally or remotely, you need to
have a local or domain user account with administrative privileges on the
appliance server.
Appliance The appliance has the following services:

services
- Appliance configuration manager: This is a web application that can be
- VMware discovery agent: The agent collects server configuration metadata
that can be used to create as on-premises assessments.
- VMware assessment agent: The agent collects server performance metadata
that can be used to create performance-based assessments.
- Auto update service: The service keeps all the agents running on the appliance
up to date. It automatically runs once every 24 hours.
- DRA agent: Orchestrates server replication, and coordinates communication
between replicated servers and Azure. Used only when replicating servers to
- Gateway: Sends replicated data to Azure. Used only when replicating servers to
- SQL discovery and assessment agent: sends the configuration and
performance metadata of SQL Server instances and databases to Azure.
- Web apps discovery and assessment agent: sends the web apps configuration
data to Azure.
Project limits An appliance can only be registered with a single project.

A single project can have multiple registered appliances.
Requirement VMware
Discovery An appliance can discover up to 10,000 severs running across multiple vCenter
limits Servers.
A single appliance can connect to up to 10 vCenter Servers.
Supported Deploy as new server running on vCenter Server using OVA template.
deployment
Deploy on an existing server running Windows Server 2016 using PowerShell
installer script.
OVA template Download from project or from here
Download size is 11.9 GB.
The downloaded appliance template comes with a Windows Server 2016

evaluation license, which is valid for 180 days.
If the evaluation period is close to expiry, we recommend that you download and
deploy a new appliance using OVA template, or you activate the operating
system license of the appliance server.
OVA Verify the OVA template downloaded from project by checking the hash values.
verification
PowerShell Refer to this article on how to deploy an appliance using the PowerShell installer
script script.
Hardware The appliance should run on server with Windows Server 2016, 32-GB RAM, 8
and network vCPUs, around 80 GB of disk storage, and an external virtual switch.
requirements The appliance requires internet access, either directly or through a proxy.
If you deploy the appliance using OVA template, you need enough resources on
the vCenter Server to create a server that meets the hardware requirements.
If you run the appliance on an existing server, make sure that it is running
Windows Server 2016, and meets hardware requirements.
(Currently the deployment of appliance is only supported on Windows Server
2016.)
VMware If you deploy the appliance as a server on vCenter Server, it must be deployed on
requirements a vCenter Server running 5.5, 6.0, 6.5, 6.7 or 7.0 and an ESXi host running version
5.5 or later.
VDDK To use the appliance for agentless migration of servers, the VMware vSphere
(agentless VDDK must be installed on the appliance server.
migration)
Appliance - Hyper-V
Requirement Hyper-V
appliance server.

services
- Discovery agent: The agent collects server configuration metadata that can be
used to create as on-premises assessments.
- Assessment agent: The agent collects server performance metadata that can be
used to create performance-based assessments.
- Auto update service: The service keeps all the agents running on the appliance
up to date. It automatically runs once every 24 hours.
- SQL discovery and assessment agent: sends the configuration and performance
metadata of SQL Server instances and databases to Azure.

Discovery An appliance can discover up to 5000 servers running in Hyper-V environment.

limits An appliance can connect to up to 300 Hyper-V hosts.
Supported Deploy as server running on a Hyper-V host using a VHD template.

deployment
Deploy on an existing server running Windows Server 2016 using PowerShell
installer script.
VHD Zip file that includes a VHD. Download from project or from here .
template
Download size is 8.91 GB.
The downloaded appliance template comes with a Windows Server 2016

evaluation license, which is valid for 180 days. If the evaluation period is close to
expiry, we recommend that you download and deploy a new appliance, or that
you activate the operating system license of the appliance server.
VHD Verify the VHD template downloaded from project by checking the hash values.
verification
PowerShell Refer to this article on how to deploy an appliance using the PowerShell installer
script script.
Requirement Hyper-V
Hardware The appliance should run on server with Windows Server 2016, 16-GB RAM, 8
and network vCPUs, around 80 GB of disk storage, and an external virtual switch.
requirements The appliance needs a static or dynamic IP address, and requires internet access,
either directly or through a proxy.
If you run the appliance as a server running on a Hyper-V host, you need enough
resources on the host to create a server that meets the hardware requirements.
(Currently the deployment of appliance is only supported on Windows Server 2016.)
Hyper-V If you deploy the appliance with the VHD template, the appliance provided by
requirements Azure Migrate is Hyper-V VM version 5.0.
The Hyper-V host must be running Windows Server 2012 R2 or later.
Appliance - Physical
Requirement Physical
appliance server.

services
- Discovery agent: The agent collects server configuration metadata that can
be used to create as on-premises assessments.
- Assessment agent: The agent collects server performance metadata that can
be used to create performance-based assessments.
- Auto update service: The service keeps all the agents running on the
appliance up to date. It automatically runs once every 24 hours.
- SQL discovery and assessment agent: sends the configuration and
performance metadata of SQL Server instances and databases to Azure.

Discovery limits An appliance can discover up to 1000 physical servers.
Supported Deploy on an existing server running Windows Server 2016 using PowerShell
deployment installer script.
Requirement Physical
PowerShell Download the script (AzureMigrateInstaller.ps1) in a zip file from the project or
script from here . Learn more.
Download size is 85.8 MB.
Script Verify the PowerShell installer script downloaded from project by checking the
verification hash values.
Hardware and The appliance should run on server with Windows Server 2016, 16-GB RAM, 8
network vCPUs, around 80 GB of disk storage.
requirements The appliance needs a static or dynamic IP address, and requires internet
access, either directly or through a proxy.
(Currently the deployment of appliance is only supported on Windows Server
2016.)
URL access
The Azure Migrate appliance needs connectivity to the internet.
When you deploy the appliance, Azure Migrate does a connectivity check to the
required URLs.
You need to allow access to all URLs in the list. If you're doing assessment only,
you can skip the URLs that are marked as required for VMware agentless
migration.
If you're using a URL-based proxy to connect to the internet, make sure that the
proxy resolves any CNAME records received while looking up the URLs.
Public cloud URLs
URL Details
*.portal.azure.com Navigate to the Azure portal.

URL Details
*.windows.net Used for access control and identity management

*.msftauth.net by Azure Active Directory
*.msauth.net
*.microsoft.com
*.live.com
*.office.com
*.microsoftonline.com
*.microsoftonline-p.com
*.microsoftazuread-sso.com
management.azure.com Used for resource deployments and management

operations
*.services.visualstudio.com Upload appliance logs used for internal

monitoring.
*.vault.azure.net Manage secrets in the Azure Key Vault.

Note: Ensure servers to replicate have access to
this.
aka.ms/* Allow access to these links; used to download and

install the latest updates for appliance services.
download.microsoft.com/download Allow downloads from Microsoft download

center.
*.servicebus.windows.net Communication between the appliance and the

Azure Migrate service.
*.discoverysrv.windowsazure.com Connect to Azure Migrate service URLs.

*.migration.windowsazure.com
*.hypervrecoverymanager.windowsazure.com Used for VMware agentless migration
Connect to Azure Migrate service URLs.
*.blob.core.windows.net Used for VMware agentless migration
Upload data to storage for migration.
Government cloud URLs
URL Details
*.portal.azure.us Navigate to the Azure portal.

URL Details
graph.windows.net Sign in to your Azure subscription.

graph.microsoftazure.us
login.microsoftonline.us Used for access control and identity management

by Azure Active Directory.
management.usgovcloudapi.net Used for resource deployments and management

operations.
*.services.visualstudio.com Upload appliance logs used for internal monitoring.
*.vault.usgovcloudapi.net Manage secrets in the Azure Key Vault.
aka.ms/* Allow access to these links; used to download and

install the latest updates for appliance services.
download.microsoft.com/download Allow downloads from Microsoft download center.
*.servicebus.usgovcloudapi.net Communication between the appliance and the

*.discoverysrv.windowsazure.us Connect to Azure Migrate service URLs.

*.migration.windowsazure.us
*.hypervrecoverymanager.windowsazure.us Used for VMware agentless migration
*.blob.core.usgovcloudapi.net Used for VMware agentless migration
*.applicationinsights.us Upload appliance logs used for internal monitoring.
Public cloud URLs for private link connectivity

The appliance needs access to the following URLs (directly or via proxy) over and above
private link access.
URL Details

URL Details
*.windows.net Used for access control and identity management by Azure

*.msftauth.net Active Directory
*.msauth.net
*.microsoft.com
*.live.com
*.office.com
*.microsoftazuread-sso.com
management.azure.com Used for resource deployments and management

operations

(optional)
aka.ms/* (optional) Allow access to these links; used to download and install
the latest updates for appliance services.
*.blob.core.windows.net (optional) This is optional and is not required if the storage account
has a private endpoint attached.
Government cloud URLs for private link connectivity
URL Details
*.portal.azure.us Navigate to the Azure portal.
graph.windows.net Sign in to your Azure subscription.
login.microsoftonline.us Used for access control and identity management by Azure

Active Directory.
management.usgovcloudapi.net Used for resource deployments and management

operations.

(optional)
aka.ms/* (optional) Allow access to these links; used to download and install
the latest updates for appliance services.
*.blob.core.usgovcloudapi.net This is optional and is not required if the storage account

(optional) has a private endpoint attached.
URL Details
*.applicationinsights.us (optional) Upload appliance logs used for internal monitoring.
Azure China 21Vianet (Azure China) URLs
URL Details
*.portal.azure.cn Navigate to the Azure portal.
graph.chinacloudapi.cn Sign in to your Azure subscription.
login.microsoftonline.cn Used for access control and identity

management by Azure Active Directory.
management.chinacloudapi.cn Used for resource deployments and

management operations

monitoring.
*.vault.chinacloudapi.cn Manage secrets in the Azure Key Vault.
aka.ms/* Allow access to these links; used to download

and install the latest updates for appliance
services.

center.
*.servicebus.chinacloudapi.cn Communication between the appliance and the

*.discoverysrv.cn2.windowsazure.cn Connect to Azure Migrate service URLs.

*.cn2.prod.migration.windowsazure.cn
*.cn2.hypervrecoverymanager.windowsazure.cn Used for VMware agentless migration.
*.blob.core.chinacloudapi.cn Used for VMware agentless migration.
*.applicationinsights.azure.cn Upload appliance logs used for internal

monitoring.
Azure China URLs

URL Details
*.portal.azure.cn Navigate to the Azure portal.
graph.chinacloudapi.cn Sign in to your Azure subscription.
login.microsoftonline.cn Used for access control and identity

management by Azure Active Directory.
management.chinacloudapi.cn Used for resource deployments and

management operations

monitoring.
*.vault.chinacloudapi.cn Manage secrets in the Azure Key Vault.
aka.ms/* Allow access to these links; used to download

and install the latest updates for appliance
services.

center.
*.servicebus.chinacloudapi.cn Communication between the appliance and the

*.discoverysrv.cn2.windowsazure.cn Connect to Azure Migrate service URLs.

*.cn2.prod.migration.windowsazure.cn
*.cn2.hypervrecoverymanager.windowsazure.cn Used for VMware agentless migration.
*.blob.core.chinacloudapi.cn Used for VMware agentless migration.
*.applicationinsights.azure.cn Upload appliance logs used for internal

monitoring.
Discovery and collection process

The appliance communicates with the discovery sources using the following process.
Process VMware appliance Hyper-V appliance Physical appliance
Start The appliance The appliance The appliance

discovery communicates with the communicates with communicates with
vCenter server on TCP port the Hyper-V hosts Windows servers over
443 by default. If the on WinRM port 5985 WinRM port 5985 (HTTP)
vCenter server listens on a (HTTP). with Linux servers over port
different port, you can 22 (TCP).
configure it in the
appliance configuration
manager.
Gather The appliance collects the The appliance The appliance collects
configuration metadata of servers collects the metadata from Windows
and running on vCenter metadata of servers servers using Common
performance Server(s) using vSphere running on Hyper-V Information Model (CIM)
metadata APIs by connecting on port hosts using a session with servers on
443 (default port) or any Common port 5985 and from Linux
other port each vCenter Information Model servers using SSH
Server listens on. (CIM) session with connectivity on port 22.
hosts on port 5985.
Send The appliance sends the The appliance sends The appliance sends the
discovery collected data to Azure the collected data to collected data to Azure
data Migrate: Discovery and Azure Migrate: Migrate: Discovery and
assessment and Migration Discovery and assessment over SSL port
and modernization over assessment over SSL 443.
SSL port 443. port 443.
The appliance can connect
The appliance can connect The appliance can to Azure over the internet
to Azure over the internet connect to Azure or via ExpressRoute private
or via ExpressRoute private over the internet or peering or Microsoft
peering or Microsoft via ExpressRoute peering circuits.
peering circuits. private peering or
Microsoft peering
circuits.
Data Configuration metadata is Configuration Configuration metadata is

collection collected and sent every 15 metadata is collected and sent every 3
frequency minutes. collected and sent hours.
every 30 minutes.
Performance metadata is Performance metadata is
collected every 50 minutes Performance collected every 5 minutes
to send a data point to metadata is to send a data point to
Azure. collected every 30 Azure.
seconds and is
Software inventory data is aggregated to send Software inventory data is
sent to Azure once every a data point to Azure sent to Azure once every
24 hours. every 15 minutes. 24 hours.
Agentless dependency Software inventory Agentless dependency data

data is collected every 5 data is sent to Azure is collected every 5
minutes, aggregated on once every 24 hours. minutes, aggregated on
appliance and sent to appliance and sent to
Azure every 6 hours. Agentless Azure every 6 hours.
dependency data is
The SQL Server collected every 5 The SQL Server
configuration data is minutes, aggregated configuration data is
updated once every 24 on appliance and updated once every 24
hours and the performance sent to Azure every 6 hours and the performance
data is captured every 30 hours. data is captured every 30
seconds. seconds.
The SQL Server
The web apps configuration data is
configuration data is updated once every
updated once every 24 24 hours and the
hours. Performance data is performance data is
not captured for web apps. captured every 30
seconds.
Assess and You can create assessments You can create You can create assessments
migrate from the metadata assessments from from the metadata
collected by the appliance the metadata collected by the appliance
using Azure Migrate: collected by the using Azure Migrate:
Discovery and assessment appliance using Discovery and assessment
tool. Azure Migrate: tool.
Discovery and
In addition, you can also assessment tool.
start migrating servers
running in your VMware
environment using the
Migration and
modernization tool to
orchestrate agentless
server replication.
Appliance upgrades
The appliance is upgraded as the Azure Migrate services running on the appliance are
updated. This happens automatically, because auto-update is enabled on the appliance
by default. You can change this default setting, to update the appliance services
manually.
Turn off auto-update

1. On the server running the appliance, open the Registry Editor.
2. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AzureAppliance.
3. To turn off auto-update, create a registry key AutoUpdate key with DWORD value
of 0.
Turn on auto-update
You can turn on auto-update using either of these methods:
By deleting the AutoUpdate registry key from

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AzureAppliance.
Click on View appliance services from the latest update checks in the Set up
prerequisites panel to turn on auto-update.
To delete the registry key:
1. On the server running the appliance, open the Registry Editor.

2. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AzureAppliance.
3. Delete the registry key AutoUpdate, that was previously created to turn off auto-
update.
To turn on from Appliance Configuration Manager, after discovery is complete:
1. On the appliance configuration manager, go to Set up prerequisites panel
2. In the latest updates check, click on View appliance services and click on the link
to turn on auto-update.
Check the appliance services version
You can check the appliance services version using either of these methods:
In Appliance configuration manager, go to Set up prerequisites panel.

On the appliance, in the Control Panel > Programs and Features.
To check in the Appliance configuration manager:
1. On the appliance configuration manager, go to Set up prerequisites panel
2. In the latest updates check, click on View appliance services.
To check in the Control Panel:
1. On the appliance, click Start > Control Panel > Programs and Features
2. Check the appliance services versions in the list.

Manually update an older version
If you are running an older version for any of the services, you must uninstall the service,
and manually update to the latest version.
1. To check for the latest appliance service versions, download the

LatestComponents.json file.
2. After downloading, open the LatestComponents.json file in Notepad.
3. Find the latest service version in the file, and the download link for it. For example:
"Name": "ASRMigrationWebApp", "DownloadLink":

"https://download.microsoft.com/download/f/3/4/f34b2eb9-cc8d-4978-9ffb-
17321ad9b7ed/MicrosoftAzureApplianceConfigurationManager.msi", "Version":
"6.0.211.2", "Md5Hash": "e00a742acc35e78a64a6a81e75469b84"
4. Download the latest version of an outdated service, using the download link in the
file.
5. After downloading, run the following command in an administrator command

window, to verify the integrity of the downloaded MSI.
C:\> Get-FileHash -Path <file_location> -Algorithm [Hashing Algorithm]
For example:
C:\> CertUtil -HashFile

C:\Users\public\downloads\MicrosoftAzureApplianceConfigurationManager.MSI MD5
6. Check that the command output matches the hash value entry for the service in
the file (for example, the MD5 hash value above).
7. Now, run the MSI to install the service. It's a silent install, and the installation
window closes after it's done.
8. After installation is complete, check the version of the service in Control panel >
Programs and Features. The service version should now be upgraded to the latest
shown in the json file.
Next steps
Learn how to set up the appliance for VMware.
Learn how to set up the appliance for Hyper-V.
Learn how to set up the appliance for physical servers.
Metadata discovered by Azure Migrate
appliance
This article provides details of the metadata discovered by Azure Migrate appliance.
The Azure Migrate appliance is a lightweight appliance that the Azure Migrate: Discovery
and assessment tool uses to discover servers running in your environment and send server
configuration and performance metadata to Azure.
Metadata discovered by the Azure Migrate appliance helps you to assess server readiness
for migration to Azure, right-size servers and plans costs. Microsoft doesn't use this data in
any license compliance audit.
Collected metadata for VMware servers

The appliance collects configuration, performance metadata, data about installed
applications, roles and features (software inventory) and dependency data (if agentless
dependency analysis is enabled) from servers running in your VMware environment.
Here's the full list of server metadata that the appliance collects and sends to Azure:
DATA COUNTER
Server details
Server ID vm.Config.InstanceUuid
Server name vm.Config.Name
vCenter Server ID VMwareClient.Instance.Uuid
Server description vm.Summary.Config.Annotation
License product name vm.Client.ServiceContent.About.LicenseProductName
Operating system type vm.SummaryConfig.GuestFullName
Boot type vm.Config.Firmware
Number of cores vm.Config.Hardware.NumCPU
Memory (MB) vm.Config.Hardware.MemoryMB
Number of disks vm.Config.Hardware.Device.ToList().FindAll(x => is VirtualDisk).count
Disk size list vm.Config.Hardware.Device.ToList().FindAll(x => is VirtualDisk)

DATA COUNTER
Network adapters list vm.Config.Hardware.Device.ToList().FindAll(x => is

VirtualEthernet).count
CPU utilization cpu.usage.average
Memory utilization mem.usage.average
Processor model/name vm.Config.Hardware.CpuModel
Number of Sockets in a vm.Config.Hardware.NumCpuPkgs

Processor
Per disk details
Disk key value disk.Key
Dikunit number disk.UnitNumber
Disk controller key value disk.ControllerKey.Value
Gigabytes provisioned virtualDisk.DeviceInfo.Summary
Disk name Value generated using disk.UnitNumber, disk.Key,

disk.ControllerKey.VAlue
Read operations per second virtualDisk.numberReadAveraged.average
Write operations per second virtualDisk.numberWriteAveraged.average
Read throughput (MB per virtualDisk.read.average

second)
Write throughput (MB per virtualDisk.write.average

second)
Per NIC details
Network adapter name nic.Key
MAC address ((VirtualEthernetCard)nic).MacAddress
IPv4 addresses vm.Guest.Net
IPv6 addresses vm.Guest.Net
Read throughput (MB per net.received.average

second)
Write throughput (MB per net.transmitted.average

second)
Inventory path details

DATA COUNTER
Name container.GetType().Name
Type of child object container.ChildType
Reference details container.MoRef
Parent details Container.Parent
Folder details per server ((Folder)container).ChildEntity.Type
Datacenter details per server ((Datacenter)container).VmFolder
Datacenter details per host ((Datacenter)container).HostFolder

folder
Cluster details per host ((ClusterComputeResource)container).Host
Host details per server ((HostSystem)container).VM
Performance metadata
Here's the performance data that an appliance collects for a server running on VMware and
sends to Azure:
Data Counter Assessment impact
CPU utilization cpu.usage.average Recommended server

size/cost
Memory utilization mem.usage.average Recommended server

size/cost
Disk read throughput (MB virtualDisk.read.average Calculation for disk size,

per second) storage cost, server size
Disk writes throughput (MB virtualDisk.write.average Calculation for disk size,

per second) storage cost, server size
Disk read operations per virtualDisk.numberReadAveraged.average Calculation for disk size,

second storage cost, server size
Disk writes operations per virtualDisk.numberWriteAveraged.average Calculation for disk size,

second storage cost, server size
NIC read throughput (MB per net.received.average Calculation for server size
second)
NIC writes throughput (MB net.transmitted.average Calculation for server size

per second)
Collected metadata for Hyper-V servers
dependency analysis is enabled) from servers running in your Hyper-V environment.
Here's the full list of server metadata that the appliance collects and sends to Azure.
Data WMI class WMI class property
Server details
Serial number of BIOS Msvm_BIOSElement BIOSSerialNumber
Server type (Gen 1 or 2) Msvm_VirtualSystemSettingData VirtualSystemSubType
Server display name Msvm_VirtualSystemSettingData ElementName
Server version Msvm_ProcessorSettingData VirtualQuantity
Memory (bytes) Msvm_MemorySettingData VirtualQuantity
Maximum memory that Msvm_MemorySettingData Limit

can be consumed by
server
Dynamic memory Msvm_MemorySettingData DynamicMemoryEnabled

enabled
Operating system Msvm_KvpExchangeComponent GuestIntrinsicExchangeItems

name/version/FQDN Name Data
Server power status Msvm_ComputerSystem EnabledState
Per disk details
Disk identifier Msvm_VirtualHardDiskSettingData VirtualDiskId
Virtual hard disk type Msvm_VirtualHardDiskSettingData Type
Virtual hard disk size Msvm_VirtualHardDiskSettingData MaxInternalSize
Virtual hard disk parent Msvm_VirtualHardDiskSettingData ParentPath
Per NIC details
IP addresses (synthetic Msvm_GuestNetworkAdapterConfiguration IPAddresses

NICs)
DHCP enabled (synthetic Msvm_GuestNetworkAdapterConfiguration DHCPEnabled

NICs)
NIC ID (synthetic NICs) Msvm_SyntheticEthernetPortSettingData InstanceID

NIC MAC address Msvm_SyntheticEthernetPortSettingData Address

(synthetic NICs)
NIC ID (legacy NICs) MsvmEmulatedEthernetPortSetting Data InstanceID
NIC MAC ID (legacy NICs) MsvmEmulatedEthernetPortSetting Data Address
Performance data
Here's the server performance data that the appliance collects and sends to Azure.
Performance counter class Counter Assessment impact
Hyper-V Hypervisor Virtual % Guest Run Time Recommended server size/cost

Processor
Hyper-V Dynamic Memory Current Pressure (%) Recommended server size/cost

Server Guest Visible Physical
Memory (MB)
Hyper-V Virtual Storage Read Bytes/Second Calculation for disk size, storage cost,
Device server size
Hyper-V Virtual Storage Write Bytes/Second Calculation for disk size, storage cost,
Device server size
Hyper-V Virtual Network Bytes Received/Second Calculation for server size

Adapter
Hyper-V Virtual Network Bytes Sent/Second Calculation for server size

Adapter
CPU utilization is the sum of all usage, for all virtual processors attached to a server.
Memory utilization is (Current Pressure * Guest Visible Physical Memory) / 100.
Disk and network utilization values are collected from the listed Hyper-V performance
counters.
Collected data for Physical servers

dependency analysis is enabled) from physical servers or server running on other clouds like
AWS, GCP, etc.
Windows server metadata

Here's the full list of Windows server metadata that the appliance collects and sends to
Azure.
FQDN Win32_ComputerSystem Domain, Name, PartOfDomain
Processor core Win32_PRocessor NumberOfCores

count
Memory Win32_ComputerSystem TotalPhysicalMemory

allocated
BIOS serial Win32_ComputerSystemProduct IdentifyingNumber

number
BIOS GUID Win32_ComputerSystemProduct UUID
Boot type Win32_DiskPartition Check for partition with Type =

GPT:System for EFI/BIOS
OS name Win32_OperatingSystem Caption
OS version Win32_OperatingSystem Version
OS architecture Win32_OperatingSystem OSArchitecture
Disk count Win32_DiskDrive Model, Size, DeviceID, MediaType, Name
Disk size Win32_DiskDrive Size
NIC list Win32_NetworkAdapterConfiguration Description, Index
NIC IP address Win32_NetworkAdapterConfiguration IPAddress
NIC MAC address Win32_NetworkAdapterConfiguration MACAddress
Windows server performance data

Here's the Windows server performance data that the appliance collects and sends to Azure.
CPU usage Win32_PerfFormattedData_PerfOS_Processor PercentIdleTime
Memory Win32_PerfFormattedData_PerfOS_Memory AvailableMBytes

usage
NIC count Win32_PerfFormattedData_Tcpip_NetworkInterface Get the network device count.
Data received Win32_PerfFormattedData_Tcpip_NetworkInterface BytesReceivedPerSec

per NIC
Data BWin32_PerfFormattedData_Tcpip_NetworkInterface BytesSentPersec

transmitted
per NIC
Disk count BWin32_PerfFormattedData_PerfDisk_PhysicalDisk Count of disks
Disk details Win32_PerfFormattedData_PerfDisk_PhysicalDisk DiskWritesPerSec,

DiskWriteBytesPerSec,
DiskReadsPerSec,
DiskReadBytesPerSec.
Linux server metadata

Here's the full list of Linux server metadata that the appliance collects and sends to Azure.
Data Commands
FQDN cat /proc/sys/kernel/hostname, hostname -f
Processor core count cat/proc/cpuinfo | awk '/^processor/{print $3}' | wc -l
Memory allocated cat /proc/meminfo | grep MemTotal | awk '{printf "%.0f", $2/1024}'
BIOS serial number lshw | grep "serial:" | head -n1 | awk '{print $2}'
/usr/sbin/dmidecode -t 1 | grep 'Serial' | awk '{ $1="" ; $2=""; print}'
BIOS GUID cat /sys/class/dmi/id/product_uuid
Boot type [ -d /sys/firmware/efi ] && echo EFI || echo BIOS
OS name/version We access these files for the OS version and name:
/etc/os-release
/usr/lib/os-release
/etc/enterprise-release
/etc/redhat-release
/etc/oracle-release
/etc/SuSE-release
/etc/lsb-release
/etc/debian_version
OS architecture uname -m
Disk count fdisk -l | egrep 'Disk.*bytes' | awk '{print $2}' | cut -f1 -d ':'
Boot disk df /boot | sed -n 2p | awk '{print $1}'
Disk size fdisk -l | egrep 'Disk.*bytes' | egrep $disk: | awk '{print $5}'
NIC list ip -o -4 addr show | awk '{print $2}'

Data Commands
NIC IP address ip addr show $nic | grep inet | awk '{print $2}' | cut -f1 -d "/"
NIC MAC address ip addr show $nic | grep ether | awk '{print $2}'
Linux server performance data

Here's the Linux server performance data that the appliance collects and sends to Azure.
Data Commands
CPU usage cat /proc/stat/ | grep 'cpu' /proc/stat
Memory usage free | grep Mem | awk '{print $3/$2 * 100.0}'
NIC count lshw -class network | grep eth[0-60] | wc -l
Data received per NIC cat /sys/class/net/eth$nic/statistics/rx_bytes
Data transmitted per NIC cat /sys/class/net/eth$nic/statistics/tx_bytes
Disk count fdisk -l | egrep 'Disk.*bytes' | awk '{print $2}' | cut -f1 -d ':'
Disk details cat /proc/diskstats
Software inventory data

The appliance collects data about installed applications, roles and features (software
inventory) from servers running in VMware environment/Hyper-V environment/physical
servers or servers running on other clouds like AWS, GCP etc.
Windows server applications data

Here's the software inventory data that the appliance collects from each discovered
Windows server:
Data Registry Location Key
Application HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall* DisplayName

Name HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall*
Version HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall* DisplayVersion

HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall*
Provider HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall* Publisher

HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall*
Windows server features data
Here's the features data that the appliance collects from each discovered Windows server:
Data PowerShell cmdlet Property
Name Get-WindowsFeature Name
Feature Type Get-WindowsFeature FeatureType
Parent Get-WindowsFeature Parent
Windows server operating system data

Here's the operating system data that the appliance collects from each discovered Windows
server:
Data WMI class WMI Class Property
Name Win32_operatingsystem Caption
Version Win32_operatingsystem Version
Architecture Win32_operatingsystem OSArchitecture
SQL Server metadata

Here's the SQL Server data that the appliance collects from each discovered Windows server:
Data Registry Location Key
Name HKLM:\SOFTWARE\Microsoft\Microsoft SQL Server\Instance Names\SQL installedInstance
Edition HKLM:\SOFTWARE\Microsoft\Microsoft SQL Server\ Edition

<InstanceName>\Setup
Service HKLM:\SOFTWARE\Microsoft\Microsoft SQL Server\ SP

Pack <InstanceName>\Setup
Version HKLM:\SOFTWARE\Microsoft\Microsoft SQL Server\ Version

<InstanceName>\Setup
Linux server application data

Here's the software inventory data that the appliance collects from each discovered Linux
server. Based on the operating system of the server, one or more of the commands are run.
Data Commands
Name rpm, dpkg-query, snap
Version rpm, dpkg-query, snap
Provider rpm, dpkg-query, snap
Linux server operating system data

Here's the operating system data that the appliance collects from each discovered Linux
server:
Data Commands
Name Gathered from one or more of the following files:

version
/etc/os-release
/usr/lib/os-release
/etc/enterprise-release
/etc/redhat-release
/etc/oracle-release
/etc/SuSE-release
/etc/lsb-release
/etc/debian_version
Architecture uname
SQL Server instances and databases data

Azure Migrate appliance used for discovery of VMware VMs can also collect data on SQL
Server instances and databases.
SQL database metadata
Database Metadata Views/ SQL Server properties
Unique identifier of the database sys.databases
Server defined database ID sys.databases
Name of the database sys.databases
Compatibility level of database sys.databases
Collation name of database sys.databases
State of the database sys.databases

Database Metadata Views/ SQL Server properties
Size of the database (in MBs) sys.master_files
Drive letter of location containing data SERVERPROPERTY, and

files Software\Microsoft\MSSQLServer\MSSQLServer
List of database files sys.databases, sys.master_files
Service broker is enabled or not sys.databases
Database is enabled for change data sys.databases

capture or not
Always On Availability Group databases sys.dm_hadr_database_replica_states

and states
SQL Server metadata
Server Metadata Views/ SQL server properties
Server name SERVERPROPERTY
FQDN Connection string derived from discovery of installed applications
Install ID sys.dm_server_registry
Server version SERVERPROPERTY
Server edition SERVERPROPERTY
Server host platform SERVERPROPERTY

(Windows/Linux)
Product level of the server SERVERPROPERTY

(RTM SP CTP)
Default Backup path SERVERPROPERTY
Default path of the data files SERVERPROPERTY, and

Software\Microsoft\MSSQLServer\MSSQLServer
Default path of the log files SERVERPROPERTY, and

Software\Microsoft\MSSQLServer\MSSQLServer
No. of cores on the server sys.dm_os_schedulers, sys.dm_os_sys_info
Server collation name SERVERPROPERTY
No. of cores on the server with sys.dm_os_schedulers

VISIBLE ONLINE status
Unique Server ID sys.dm_server_registry

Server Metadata Views/ SQL server properties
HA enabled or not SERVERPROPERTY
Buffer Pool Extension enabled sys.dm_os_buffer_pool_extension_configuration

or not
Failover cluster configured or SERVERPROPERTY

not
Server using Windows SERVERPROPERTY

Authentication mode only
Server installs PolyBase SERVERPROPERTY
No. of logical CPUs on the sys.dm_server_registry, sys.dm_os_sys_info

system
Ratio of the no of logical or sys.dm_os_schedulers, sys.dm_os_sys_info

physical cores that are exposed
by one physical processor
package
No of physical CPUs on the sys.dm_os_schedulers, sys.dm_os_sys_info

system
Date and time server last sys.dm_server_registry

started
Max server memory use (in sys.dm_os_process_memory

MBs)
Total no. of users across all sys.databases, sys.logins

databases
Total size of all user databases sys.databases
Size of temp database sys.master_files, sys.configurations, sys.dm_os_sys_info
No. of logins sys.logins
List of linked servers sys.servers
List of agent job [msdb].[dbo].[sysjobs], [sys].[syslogins], [msdb].[dbo].[syscategories]
Always On Availability Groups, sys.availability_groups, sys.dm_hadr_availability_group_states,

Replicas, and their states sys.availability_group_listeners,
sys.availability_group_listener_ip_addresses, sys.availability_replicas,
sys.dm_hadr_availability_replica_states
Always On Failover Clustered sys.dm_hadr_cluster, sys.dm_hadr_cluster_members,

Instance sys.dm_hadr_cluster_networks
Performance metadata
Performance Views/ SQL server properties Assessment Impact
SQL Server CPU sys.dm_os_ring_buffers Recommended SKU size (CPU

utilization dimension)
SQL logical CPU count sys.dm_os_sys_info Recommended SKU size (CPU

dimension)
SQL physical memory in sys.dm_os_process_memory Unused

use
SQL memory utilization sys.dm_os_process_memory Unused

percentage
Database CPU utilization sys.dm_exec_query_stats, Recommended SKU size (CPU

sys.dm_exec_plan_attributes dimension)
Database memory in use sys.dm_os_buffer_descriptors Recommended SKU size (Memory

(buffer pool) dimension)
File read/write IO sys.dm_io_virtual_file_stats, Recommended SKU size (IO

sys.master_files dimension)
File num of reads/writes sys.dm_io_virtual_file_stats, Recommended SKU size

sys.master_files (Throughput dimension)
File IO stall read/write sys.dm_io_virtual_file_stats, Recommended SKU size (IO

(ms) sys.master_files latency dimension)
File size sys.master_files Recommended SKU size (Storage

dimension)
ASP.NET web apps data

Azure Migrate appliance used for discovery of VMware VMs can also collect data on
ASP.NET web applications.
７ Note
Currently this feature is only available for servers running in your VMware environment.
Here's the web apps configuration data that the appliance collects from each Windows
server discovered in your VMware environment.
Entity Data
Entity Data
Web apps Application Name

Configuration Path
Frontend Bindings
Enabled Frameworks
Hosting Web Server
Sub-Applications and virtual applications
Application Pool name
Runtime version
Managed pipeline mode
Web server Server Name

Server Type (currently only IIS)
Configuration Location
Version
FQDN
Credentials used for discovery
List of Applications
Application dependency data

Azure Migrate appliance can collect data about inter-server dependencies for servers
running in your VMware environment/Hyper-V environment/ physical servers or servers
running on other clouds like AWS, GCP etc.
Windows server dependencies data

Here's the connection data that the appliance collects from each Windows server, which has
been enabled for agentless dependency analysis from portal:
Data Commands
Local port netstat
Local IP address netstat
Remote port netstat
Remote IP address netstat
TCP connection state netstat
Process ID netstat
Number of active connections netstat

Process name Win32_Process ExecutablePath
Process Win32_Process CommandLine

arguments
Application name Win32_Process VersionInfo.ProductName parameter of ExecutablePath

property
Linux server dependencies data

Here's the connection data that the appliance collects from each Linux server, which has
been enabled for agentless dependency analysis.
Data Commands
Local port netstat
Local IP address netstat
Remote port netstat
Remote IP address netstat
TCP connection state netstat
Number of active connections netstat
Process ID netstat
Process name ps
Process arguments ps
Application name dpkg or rpm
Next steps
Learn how to set up the appliance for VMware.
Learn how to set up the appliance for Hyper-V.
Learn how to set up the appliance for physical servers.
 Documentation
Set the scope for discovery of servers on VMware with Azure Migrate - Azure Migrate
Describes how to set the discovery scope for servers hosted on VMware assessment and migration with
Azure Migrate.
VMware server discovery support in Azure Migrate - Azure Migrate

Learn about Azure Migrate discovery and assessment support for servers in a VMware environment.

Set up agent-based dependency analysis in Azure Migrate - Azure Migrate

This article describes how to set up agent-based dependency analysis in Azure Migrate.
Support for physical discovery and assessment in Azure Migrate - Azure Migrate
Learn about support for physical discovery and assessment with Azure Migrate Discovery and assessment

Questions about discovery, assessment, and dependency analysis in Azure Migrate -

Azure Migrate
Get answers to common questions about discovery, assessment, and dependency analysis in Azure
Migrate.
Show 4 more
Dependency analysis
This article describes dependency analysis in Azure Migrate: Discovery and assessment.
Dependency analysis identifies dependencies between discovered on-premises servers.

It provides these advantages:
You can gather servers into groups for assessment, more accurately, with greater
confidence.
You can identify servers that must be migrated together. This is especially useful if
you're not sure which servers are part of an app deployment that you want to
migrate to Azure.
You can identify whether servers are in use, and which servers can be
decommissioned instead of migrated.
Analyzing dependencies helps ensure that nothing is left behind, and thus avoids
surprise outages after migration.
Review common questions about dependency analysis.
Analysis types
There are two options for deploying dependency analysis
Option Details Public Azure

cloud Government
Agentless Generally available for VMware VMs, Hyper-V VMs, Supported Supported
bare-metal servers, and servers running on other public
clouds like AWS, GCP etc.
Agent- Uses the Service Map solution in Azure Monitor, to Supported Not
based enable dependency visualization and analysis. supported.
analysis
You need to install agents on each on-premises server
that you want to analyze.
Agentless analysis
Agentless dependency analysis works by capturing TCP connection data from servers for
which it's enabled. No agents are installed on servers. Connections with the same source
server and process, and destination server, process, and port are grouped logically into a
dependency. You can visualize captured dependency data in a map view, or export it as
a CSV. No agents are installed on servers you want to analyze.
Dependency data
After discovery of dependency data begins, polling begins:
The Azure Migrate appliance polls TCP connection data from servers every five
minutes to gather data.
Polling gathers this data:

Name of processes that have active connections.
Name of application that run processes that have active connections.
Destination port on the active connections.
The gathered data is processed on the Azure Migrate appliance, to deduce identity
information, and is sent to Azure Migrate every six hours.
Agent-based analysis
For agent-based analysis, Azure Migrate: Discovery and assessment uses the Service
Map solution in Azure Monitor. You install the Microsoft Monitoring Agent/Log
Analytics agent and the Dependency agent, on each server you want to analyze.
Dependency data
Agent-based analysis provides this data:
Source server name, process, application name.

Destination server name, process, application name, and port.
Number of connections, latency, and data transfer information are gathered and
available for Log Analytics queries.
Compare agentless and agent-based

The differences between agentless visualization and agent-based visualization are
summarized in the table.

Support Available for VMware In general availability (GA).

VMs in general
availability (GA).
Available for Hyper-V

VMs and physical
servers in public
preview.
Agent No agents needed on Agents required on each on-premises server that you
servers you want to want to analyze.
analyze.
Log Not required. Azure Migrate uses the Service Map solution in Azure
Analytics Monitor logs for dependency analysis.
You associate a Log Analytics workspace with a project.

The workspace must reside in the East US, Southeast
Asia, or West Europe regions. The workspace must be in
a region in which Service Map is supported.
Process Captures TCP Service Map agents installed on a server gather data
connection data. After about TCP processes, and inbound/outbound
discovery, it gathers connections for each process.
data at intervals of five
minutes.
Data Source server name, Source server name, process, application name.
process, application
name. Destination server name, process, application name, and
port.
Destination server
name, process, Number of connections, latency, and data transfer
application name, and information are gathered and available for Log Analytics
port. queries.
Visualization Dependency map of Dependency map of a single server.

single server can be
viewed over a duration Dependency map of a group of servers.
of one hour to 30
days. Map can be viewed over an hour only.
Add and remove servers in a group from the map view.
Data export Last 30 days data can Data can be queried with Log Analytics.
be downloaded in a
CSV format.
Next steps
Set up agent-based dependency visualization.
Try out agentless dependency visualization for servers on VMware.
Review common questions about dependency visualization.
 Documentation






Azure Migrate support matrix - Azure Migrate

Provides a summary of support settings and limitations for the Azure Migrate service.
Show 5 more
Business case (preview) overview
Article • 04/25/2023
This article provides an overview of assessments in the Azure Migrate: Discovery and
assessment tool. The tool can assess on-premises servers in VMware virtual and Hyper-V
environment, and physical servers for migration to Azure.
What's a business case?


for cloud.
and SQL versions.
Other key features:
This capability can only be used to create Business cases in public cloud regions. For
Azure Government, you can use the existing assessment capability.
Migration strategies in a business case

Business case:

Strategy
Strategy
For web apps, sizing and cost comes from

Azure App Service assessment is picked.
For general servers, sizing and cost comes

as a Service)
PaaS recommendation that means, the from the Recommended report with
(Platform as a logic identifies workloads best fit optimization strategy - Modernize to PaaS
Service) for PaaS targets. from Azure SQL assessment.
General servers are recommended For web apps, sizing and cost comes from
with a quick lift and shift Azure App Service assessment. For
recommendation to Azure IaaS. general servers, sizing and cost comes
Although the Business case picks Azure recommendations from certain assessments,
you won't be able to access the assessments directly. To deep dive into sizing, readiness,
and Azure cost estimates, you can create respective assessments for the servers or
workloads.
How do I build a business case?

Currently, you can create a Business case with the two discovery sources:

collected sends metadata and performance (resource utilization) Service), Modernize to
via Azure data to Azure Migrate. Learn more. PaaS (Platform as a
Migrate Service)
appliance
quick and import in Azure Migrate to get a quick business case (Infrastructure as a
business based on the provided inputs. You don't need to set up Service)
case using the Azure Migrate appliance to discover servers for this
the servers option.
imported
via a .csv
file
How do I use the appliance?

If you're deploying an Azure Migrate appliance to discover on-premises servers, do the
following steps:
1. Set up Azure and your on-premises environment to work with Azure Migrate.
2. For your first Business case, create an Azure project and add the Discovery and
assessment tool to it.
3. Deploy a lightweight Azure Migrate appliance. The appliance continuously
discovers on-premises servers and sends server metadata and performance data to
Azure Migrate. Deploy the appliance as a VM. You don't need to install anything on
servers that you want to assess.
After the appliance begins server discovery, you can start building your Business case.
Follow our tutorials for VMware or Hyper-V or Physical/Bare-metal or other clouds to try
out these steps.
We recommend that you wait at least a day after starting discovery before you build a
Business case so that enough performance/resource utilization data points are collected.
Also, review the notifications/resolve issues blades on Azure Migrate hub to identify any
discovery related issues prior to Business case computation. It ensures that the IT estate
in your datacenter is represented more accurately and the Business case
recommendations are more valuable.
If you're using the Azure Migrate appliance, learn about the metadata and performance
data that's collected for:
VMware.
Hyper-V
Physical
How does the appliance calculate performance

data?
If you use the appliance for discovery, it collects performance data for compute settings
with these steps:
1. The appliance collects a real-time sample point.
VMware VMs: A sample point is collected every 20 seconds.

Hyper-V VMs: A sample point is collected every 30 seconds.
Physical servers: A sample point is collected every five minutes.
2. The appliance combines the sample points to create a single data point every 10
minutes for VMware and Hyper-V servers, and every 5 minutes for physical servers.
To create the data point, the appliance selects the peak values from all samples. It
then sends the data point to Azure.
3. The assessment service stores all the 10-minute data points for the last month.
4. When you create a Business case, multiple assessments are triggered in the
background.
5. The assessments identify the appropriate data point to use for rightsizing.
Identification is based on the percentile values for performance history and
percentile utilization.
For example, if the performance history is one week and the percentile
utilization is the 95th percentile, the assessment sorts the 10-minute sample
points for the last week. It sorts them in ascending order and picks the 95th
percentile value for rightsizing.
The 95th percentile value makes sure you ignore any outliers, which might be
included if you picked the 99th percentile.
6. This value is multiplied by the comfort factor to get the effective performance
utilization data for these metrics that the appliance collects.
How are utilization insights derived?

It covers which servers are ideal for cloud, servers that can be decommissioned on-
premises, and servers that can't be classified based on resource utilization/performance
data:
Ideal for cloud: These servers are best fit for migrating to Azure and comprises of
active and idle servers:
Active servers: These servers delivered business value by being on and had their
CPU and memory utilization above 5% and network utilization above 2%.
Idle servers: These servers were on but didn't deliver business value by having
their CPU and memory utilization below 5% and network utilization below 2%.
Decommission: These servers were expected to deliver business value, but didn't
and can be decommissioned on-premises and recommended to not migrate to
Azure:
Zombie: The CPU, memory and network utilization were 0% with no
performance data collection issues.
These servers were on but don't have adequate metrics available:
Unknown: Many servers can land in this section if the discovery is still ongoing
or has some unaddressed discovery issues.
What comprises a business case?

There are four major reports that you need to review:
Overview: This report is an executive summary of the Business case and covers:
Potential savings (TCO).
Estimated year on year cashflow savings based on the estimated migration
completed that year.
Savings from unique Azure benefits like Azure Hybrid Benefit.
Discovery insights covering the scope of the Business case.
On-premises vs Azure: This report covers the breakdown of the total cost of
ownership by cost categories and insights on savings.
Azure IaaS: This report covers the Azure and on-premises footprint of the servers
and workloads recommended for migrating to Azure IaaS.
Azure PaaS: This report covers the Azure and on-premises footprint of the
workloads recommended for migrating to Azure PaaS.
What's in a business case?
Here's what's included in a business case:
Total cost of ownership (steady state)
On-premises cost
Cost components for running on-premises servers. For TCO calculations, an annual cost
is computed for the following heads:
Cost Category Component Logic

heads
Compute Hardware Server Total hardware acquisition cost is calculated using a

Hardware cost per core linear regression formula: Cost per
(Host core = 16.232*(Hyperthreaded core: memory in GB
machines) ratio) + 113.87. Hyperthreaded cores = 2*(cores)
Software - License cost Calculated per two core pack license pricing of 2019
SQL Server Enterprise or Standard.
licensing
Software Calculated per year as in settings.

Assurance
Software - License cost Calculated per two core pack license pricing of
Windows Windows Server.
Server
licensing
Software Calculated per year as in settings.

Assurance
Virtualization Virtualization License cost for vSphere Standard license +

software for Software Production support for vSphere Standard license +
servers (VMware Management software cost for VSphere Standard +
running in license cost + production support cost of management software.
VMware support + Not included- other hypervisor software cost or
environment management Antivirus / Monitoring Agents.
software cost)
heads
Virtualization Virtualization Management software cost for System Center +

software for Software software assurance. Not included- other hypervisor
servers (management software cost or Antivirus / Monitoring Agents.
running in software cost
Microsoft + software
Hyper-V assurance)
environment
Storage Storage The total storage hardware acquisition cost is

Hardware calculated by multiplying the Total volume of
storage attached to per GB cost. Default is USD 2
per GB per month.
Storage Default is 10% of storage hardware acquisition cost.

Maintenance
Network Network Network As an industry standard and used by sellers in

Hardware equipment Business cases, it's a % of compute and storage cost.
and software (Cabinets, Default is 10% of storage and compute cost.
switches,
routers, load
balancers etc.)
and software
Maintenance Maintenance Defaulted to 15% of network hardware and software

cost.
Facilities Facilities & DC Facilities – Facilities cost hasn't been added by default in the
Infrastructure Lease and on-premises cost calculations. Any
Power lease/colocation/power cost specified here will be
included as part of the Business case.
Labor Labor IT admin DC admin cost = ((Number of virtual machines) /

(Avg. # of virtual machines that can be managed by
a full-time administrator)) * 730 * 12
Azure cost

heads
Compute Compute (IaaS) Azure VM, SQL Server Compute cost (with AHUB) from Azure
on Azure VM VM assessment, Compute cost (with
AHUB) from Azure SQL assessment
heads
Compute Azure SQL MI or Azure Compute cost (with AHUB) from Azure
(PaaS) SQL DB SQL assessment.
Compute(PaaS) Azure App Service Plan cost from Azure App Service.
Storage Storage (IaaS) Azure VM - Managed Storage cost from Azure VM

disks, Server on Azure assessment/Azure SQL assessment.
VM - Managed disk
Storage (PaaS) Azure SQL MI or Azure Storage cost from Azure SQL assessment.
SQL DB - Managed
disks
Storage (PaaS) N/A N/A
Network Network Network equipment As an industry standard and used by

Hardware and (Cabinets, switches, sellers in Business cases, it's a % of
software routers, load balancers compute and storage cost. Default is 10%
etc.) and software of storage and compute cost.
Maintenance Maintenance Defaulted to 15% of network hardware

and software cost.
Facilities Facilities & DC Facilities - Lease Facilities cost isn't applicable for Azure
Infrastructure and Power cost.
Labor Labor IT admin DC admin cost = ((Number of virtual

machines) / (Avg. # of virtual machines
that can be managed by a full-time
administrator)) * 730 * 12
Year on Year costs
Current state (on-premises)
Component Year 0 Year 1 Year 2 Year 3 Year 4
CAPEX Total CAPEX Y1 CAPEX = Y2 CAPEX = Y3 CAPEX = Y4 CAPEX =

(A) Total CAPEX Y1 CAPEX (A) Y2 CAPEX (A) * Y3 CAPEX (A) *
(A) * (1+server * (1+server (1+server (1+server
growth rate%) growth rate%) growth rate%) growth rate%)
OPEX Total OPEX Y1 OPEX = Y2 OPEX = Y1 Y3 OPEX = Y2 Y4 OPEX = Y3

(B) Total OPEX (B) OPEX (B) * OPEX (B) * OPEX (B) *
* (1+server (1+server (1+server (1+server
growth rate%) growth rate%) growth rate%) growth rate%)
Status Quo Y0 Cashflow Y1 Cashflow= Y2 Cashflow= Y3 Cashflow= Y4 Cashflow=

Cash Flow = Total Y1 CAPEX+ Y1 Y2 CAPEX + Y3 CAPEX (A) Y4 CAPEX (A)
CAPEX (A) + OPEX Y2 OPEX + Y3 OPEX (B) + Y4 OPEX (B)
Total OPEX
(B)
CAPEX & OPEX
Component Sub component Assumptions Azure retained
Capital
Asset
Expense
(CAPEX) (A)
Server (Total server Depreciable life =

Depreciation hardware acquisition 4 years
cost)/(Depreciable
life)
Storage (Total storage Depreciable life =

Depreciation hardware acquisition 4 years
cost)/(Depreciable
life)
Fit out and (Total network Depreciable life =

Networking hardware acquisition 5 years
Equipment cost)/(Depreciable
life)
License (virtualization cost + Depreciable life = VMware licenses are not retained;
Amortization Windows Server + 5 years Windows, SQL and Hyper-V
SQL Server + Linux management software licenses are
OS)/(Depreciable retained based on AHUB option in
life) Azure).
Operating
Asset
Expense
(OPEX) (B)
Network Per year

maintenance
Component Sub component Assumptions Azure retained
Storage Per year Power draw per

maintenance Server, Average
price per KW per
month based on
location.
License License support cost VMware licenses are not retained;

Support for virtualization + Windows, SQL and Hyper-V
Windows Server + management software licenses are
SQL Server + Linux retained based on AHUB option in
OS Azure).
Datacenter Number of people * Cost per hour

Admin cost hourly cost * 730 based on location.
hours
Future state (on-premises + Azure)

It assumes that the customer does a phased migration to Azure with following % of
servers migrated every year:
Year 0 Year 1 Year 2 Year 3
0% 20% 50% 100%
You can override the above values in the assumptions section of the Business case.
In Azure, there's no CAPEX, the yearly Azure cost is an OPEX
CAPEX Total Y1 CAPEX Azure Y2 CAPEX Azure Y3 CAPEX Y4 CAPEX =

CAPEX =80%* (Y1 CAPEX =50%* (Y2 CAPEX Azure =0%* 0%* (Y4
(A) On-premises) On-premises) (Y3 CAPEX CAPEX On-
On- premises)
premises)
OPEX Total Y1 OPEX Azure = Y2 OPEX Azure = Y3 OPEX Y4 OPEX

OPEX 80%* (Y1 OPEX 50%* (Y2 OPEX Azure = Azure =
(B) On- On- 100%* 100%*
premises)+20%* premises)+50%* (Azure Yearly (Azure Yearly
(Azure Yearly cost) (Azure Yearly cost) cost) * cost) *
* (1+server growth * (1+server growth (1+server (1+server
rate%) rate%) growth growth
rate%) rate%)
Future state Y0 Cash Y1 Cash Flow= Y1 Y2 Cash Flow= Y2 Y3 Cash Y4 Cash

Cash Flow Flow= CAPEX + Y1 OPEX CAPEX + Y2 OPEX Flow= Y3 Flow= Y4
Total CAPEX + Y3 CAPEX + Y4
CAPEX OPEX OPEX
(A) +
Total
OPEX
(B)
Glossary
Term Details
Business A Business case provides justification for a go/no go for a project. It evaluates the
case benefit, cost and risk of alternative options and provides a rationale for the
preferred solution.
Total cost TCO (Total cost of ownership) is a financial estimate to help companies calculate
of precisely, the economic impact during the whole life cycle of IT projects.
ownership
(TCO)
Return on A project’s expected return in percentage terms. ROI is calculated by dividing net
Investment benefits (benefits less costs) by costs.
(ROI)
Cash flow It explains how much cash went out and in the door for a business.
statement
Net cash It's the difference between the money coming in and the money coming out of your
flow (NCF) business for a specific period.
Net The present or current value of (discounted) future net cash flows given an interest
Present rate (the discount rate). A positive project NPV normally indicates that the
Value investment should be made unless other projects have higher NPVs.
(NPV)
Payback The breakeven point for an investment. It's the point in time at which net benefits
period (benefits minus costs) equal initial investment or cost.
Capital Up front investments in assets that are capitalized and put into the balance sheet.
Expense
(CAPEX)
Operating Running expenses of a business.

Expense
(OPEX)
Next steps
Learn more about Azure Migrate.
Assessment overview (migrate to Azure
VMs)
This article provides an overview of assessments in the Azure Migrate: Discovery and
assessment tool. The tool can assess on-premises servers in VMware virtual and Hyper-V
environment, and physical servers for migration to Azure.
What's an assessment?
An assessment with the Discovery and assessment tool measures the readiness and
estimates the effect of migrating on-premises servers to Azure.
７ Note
In Azure Government, review the supported target assessment locations. Note that
VM size recommendations in assessments will use the VM series specifically for
Government Cloud regions. Learn more about VM types.
Types of assessments
There are three types of assessments you can create using Azure Migrate: Discovery and
assessment.
Assessment Details
Type
Azure VM Assessments to migrate your on-premises servers to Azure virtual machines. You
can assess your on-premises servers in VMware and Hyper-V environment, and
physical servers for migration to Azure VMs using this assessment type.
Azure SQL Assessments to migrate your on-premises SQL servers from your VMware
environment to Azure SQL Database or Azure SQL Managed Instance.
Azure App Assessments to migrate on-premises web apps from your VMware environment to
Service Azure App Service.
Azure Assessments to migrate your on-premises servers to Azure VMware Solution (AVS).
VMware You can assess your on-premises VMware VMs for migration to Azure VMware
Solution Solution (AVS) using this assessment type. Learn more
(AVS)
７ Note
If the number of Azure VM or AVS assessments are incorrect on the Discovery and
assessment tool, click on the total number of assessments to navigate to all the
assessments and recalculate the Azure VM or AVS assessments. The Discovery and
Assessments you create with Azure Migrate are a point-in-time snapshot of data. An
Azure VM assessment provides two sizing criteria options:
Assessment Details Data

type
Performance- Assessments that The VM size recommendation is based on CPU and RAM-
based make utilization data.
recommendations
based on collected The disk-type recommendation is based on the
performance data input/output operations per second (IOPS) and throughput
of the on-premises disks. Disk types are Azure Standard
HDD, Azure Standard SSD, Azure Premium disks, and Azure
Ultra disks.
As-is on- Assessments that The VM size recommendation is based on the on-premises
premises don't use server size.
performance data
to make The recommended disk type is based on the selected
recommendations storage type for the assessment.
How do I run an assessment?

There are a couple of ways to run an assessment.
Assess servers by using server metadata collected by a lightweight Azure Migrate

appliance. The appliance discovers on-premises servers. It then sends server
Assess servers by using server metadata that's imported in a comma-separated
values (CSV) format.
How do I assess with the appliance?

following steps:
2. For your first assessment, create an Azure project and add the Discovery and
discovers on-premises servers and sends server metadata and performance data to
Azure Migrate. Deploy the appliance as a VM or a physical server. You don't need
to install anything on servers that you want to assess.
After the appliance begins server discovery, you can gather servers you want to assess
into a group and run an assessment for the group with assessment type Azure VM.
Follow our tutorials for VMware, Hyper-V, or physical servers to try out these steps.
How do I assess with imported data?

If you're assessing servers by using a CSV file, you don't need an appliance. Instead, do
the following steps:
1. Set up Azure to work with Azure Migrate

3. Download a CSV template and add server data to it.
4. Import the template into Azure Migrate
5. Discover servers added with the import, gather them into a group, and run an
assessment for the group with assessment type Azure VM.

If you're using the Azure Migrate appliance for assessment, learn about the metadata
and performance data that's collected for VMware and Hyper-V.

data?
with these steps:
VMware VMs: A sample point is collected every 20 seconds.

Hyper-V VMs: A sample point is collected every 30 seconds.
Physical servers: A sample point is collected every five minutes.
minutes for VMware and Hyper-V servers, and every 5 minutes for physical servers.
To create the data point, the appliance selects the peak values from all samples. It
then sends the data point to Azure.
3. The assessment stores all the 10-minute data points for the last month.
4. When you create an assessment, the assessment identifies the appropriate data
point to use for rightsizing. Identification is based on the percentile values for
performance history and percentile utilization.
If you want to pick the peak usage for the period and don't want to miss any
outliers, select the 99th percentile for percentile utilization.
utilization data for these metrics that the appliance collects:
CPU utilization
RAM utilization
Disk IOPS (read and write)
Disk throughput (read and write)
Network throughput (in and out)
How are Azure VM assessments calculated?

The assessment uses the on-premises servers' metadata and performance data to
calculate assessments. If you deploy the Azure Migrate appliance, assessment uses the
data the appliance collects. But if you run an assessment imported using a CSV file, you
provide the metadata for the calculation.
Calculations occur in these three stages:
1. Calculate Azure readiness: Assess whether servers are suitable for migration to
Azure.
2. Calculate sizing recommendations: Estimate compute, storage, and network
sizing.
3. Calculate monthly costs: Calculate the estimated monthly compute and storage
costs for running the servers in Azure after migration.
Calculations are in the preceding order. A server moves to a later stage only if it passes
the previous one. For example, if a server fails the Azure readiness stage, it's marked as
unsuitable for Azure. Sizing and cost calculations aren't done for that server.
What's in an Azure VM assessment?

Here's what's included in an Azure VM assessment:
Setting Details
Target The location to which you want to migrate. The assessment currently supports
location these target Azure regions:
Australia Central, Australia Central 2, Australia East, Australia Southeast, Brazil

South, Canada Central, Canada East, Central India, Central US, China East, China
East 2, China North, China North 2, East Asia, East US, East US 2, France Central,
France South, Germany North, Germany West Central, Japan East, Japan West,
Korea Central, Korea South, North Central US, North Europe, Norway East,
Norway West, South Africa North, South Africa West, South Central US,
Southeast Asia, South India, Switzerland North, Switzerland West, UAE Central,
UAE North, UK South, UK West, West Central US, West Europe, West India, West
US, West US 2, JioIndiaCentral, JioIndiaWest, US Gov Arizona, US Gov Iowa, US
Gov Texas, US Gov Virginia.
Target storage The type of disk to use for storage in Azure.

disk (as-is
sizing) Specify the target storage disk as Premium-managed, Standard SSD-managed,
Standard HDD-managed, or Ultra disk.
Setting Details
Target storage Specifies the type of target storage disk as automatic, Premium-managed,
disk Standard HDD-managed, Standard SSD-managed, or Ultra disk.
(performance-
based sizing) Automatic: The disk recommendation is based on the performance data of the
disks, meaning the IOPS and throughput.
Premium or Standard or Ultra disk: The assessment recommends a disk SKU

within the storage type selected.
If you want a single-instance VM service-level agreement (SLA) of 99.9%,

consider using Premium-managed disks. This use ensures that all disks in the
assessment are recommended as Premium-managed disks.
If you're looking to run data-intensive workloads that need high throughput,

high IOPS, and consistent low latency disk storage, consider using Ultra disks.
Azure Migrate supports only managed disks for migration assessment.
Savings Specify the savings option that you want the assessment to consider to help
options optimize your Azure compute cost.
(compute)
Azure reservations (1 year or 3 year reserved) are a good option for the most
consistently running resources.
Azure Savings Plan (1 year or 3 year savings plan) provide additional flexibility
and automated cost optimization. Ideally post migration, you could use Azure
reservation and savings plan at the same time (reservation will be consumed
first), but in the Azure Migrate assessments, you can only see cost estimates of 1
savings option at a time.
When you select 'None', the Azure compute cost is based on the Pay as you go
rate or based on actual usage.
You need to select pay-as-you-go in offer/licensing program to be able to use

Reserved Instances or Azure Savings Plan. When you select any savings option
other than 'None', the 'Discount (%)' and 'VM uptime' properties are not
applicable.The monthly cost estimates are calculated by multiplying 744 hours in
the VM uptime field with the hourly price of the recommended SKU.
Sizing criteria Used to rightsize the Azure VM.
Use as-is sizing or performance-based sizing.
Performance Used with performance-based sizing. Performance history specifies the duration
history used when performance data is evaluated.
Percentile Used with performance-based sizing. Percentile utilization specifies the

utilization percentile value of the performance sample used for rightsizing.
Setting Details
VM series The Azure VM series that you want to consider for rightsizing. For example, if
you don't have a production environment that needs A-series VMs in Azure, you
can exclude A-series from the list of series.
Comfort The buffer used during assessment. It's applied to the CPU, RAM, disk, and
factor network data for VMs. It accounts for issues like seasonal usage, short
For example, a 10-core VM with 20% utilization normally results in a two-core

VM. With a comfort factor of 2.0, the result is a four-core VM instead.
Offer The Azure offer in which you're enrolled. The assessment estimates the cost
for that offer.
Currency The billing currency for your account.
Discount (%) Any subscription-specific discounts you receive on top of the Azure offer. The
default setting is 0%.
VM uptime The duration in days per month and hours per day for Azure VMs that won't run
continuously. Cost estimates are based on that duration.
The default values are 31 days per month and 24 hours per day.
Azure Hybrid Specifies whether you have software assurance and are eligible for Azure Hybrid
Benefit Benefit . If the setting has the default value "Yes," Azure prices for operating
systems other than Windows are considered for Windows VMs.
EA Specifies that an Enterprise Agreement (EA) subscription is used for cost

subscription estimation. Takes into account the discount applicable to the subscription.
Leave the settings for reserved instances, discount (%) and VM uptime
properties with their default settings.
Review the best practices for creating an assessment with Azure Migrate.
Calculate readiness
Not all servers are suitable to run in Azure. An Azure VM Assessment assesses all on-
premises servers and assigns them a readiness category.
Ready for Azure: The server can be migrated as-is to Azure without any changes. It
will start in Azure with full Azure support.
Conditionally ready for Azure: The server might start in Azure but might not have
full Azure support. For example, Azure doesn't support a server that's running an
old version of Windows Server. You must be careful before you migrate these
servers to Azure. To fix any readiness problems, follow the remediation guidance
the assessment suggests.
Not ready for Azure: The server won't start in Azure. For example, if an on-
premises server's disk stores more than 64 TB, Azure can't host the server. Follow
the remediation guidance to fix the problem before migration.
Readiness unknown: Azure Migrate can't determine the readiness of the server
because of insufficient metadata.
To calculate readiness, the assessment reviews the server properties and operating
system settings summarized in the following tables.
Server properties
For an Azure VM Assessment, the assessment reviews the following properties of an on-
premises VM to determine whether it can run on Azure VMs.
Property Details Azure readiness status
Boot type Azure supports UEFI boot type for OS Not ready if the boot type is UEFI
mentioned here and Operating System running on
the VM is: Windows Server
2003/Windows Server 2003
R2/Windows Server 2008/Windows
Server 2008 R2
Cores Each server must have no more than 128 Ready if the number of cores is
cores, which is the maximum number an within the limit
Azure VM supports.
If performance history is available, Azure

Migrate considers the utilized cores for
comparison. If the assessment settings
specify a comfort factor, the number of
utilized cores is multiplied by the comfort
factor.
If there's no performance history, Azure

Migrate uses the allocated cores to apply
the comfort factor.
Property Details Azure readiness status
RAM Each server must have no more than 3,892 Ready if the amount of RAM is
GB of RAM, which is the maximum size an within the limit
Azure M-series Standard_M128m 2 VM
supports. Learn more.
If performance history is available, Azure

Migrate considers the utilized RAM for
comparison. If a comfort factor is specified,
the utilized RAM is multiplied by the
comfort factor.
If there's no history, the allocated RAM is

used to apply a comfort factor.
Storage The allocated size of a disk must be no Ready if the disk size and number
disk more than 64 TB. are within the limits
The number of disks attached to the server,

including the OS disk, must be 65 or fewer.
Networking A server must have no more than 32 Ready if the number of NICs is
network interfaces (NICs) attached to it. within the limit
Guest operating system

For an Azure VM Assessment, along with reviewing VM properties, the assessment looks
at the guest operating system of a server to determine whether it can run on Azure.
７ Note
To handle guest analysis for VMware VMs, the assessment uses the operating
system specified for the VM in vCenter Server. However, vCenter Server doesn't
provide the kernel version for Linux VM operating systems. To discover the version,
you need to set up application discovery. Then, the appliance discovers version
information using the guest credentials you specify when you set up app-discovery.
The assessment uses the following logic to identify Azure readiness based on the
operating system:
Operating system Details Azure readiness status

Windows Server Azure provides full support. Ready for Azure.

2016 and all SPs

2012 R2 and all
SPs

2012 and all SPs

2008 R2 with all
SPs

2008 (32-bit and
64-bit)
Windows Server These operating systems have passed their end- Conditionally ready for
2003 and of-support dates and need a Custom Support Azure. Consider
Windows Server Agreement (CSA) for support in Azure. upgrading the OS
2003 R2 before migrating to
Azure.
Windows 2000, These operating systems have passed their end- Conditionally ready for
Windows 98, of-support dates. The server might start in Azure, Azure. We recommend
Windows 95, but Azure provides no OS support. that you upgrade the
Windows NT, OS before migrating to
Windows 3.1, and Azure.
MS-DOS
Windows 7, Azure provides support with a Visual Studio Conditionally ready for
Windows 8, and subscription only. Azure.
Windows 10
Windows 10 Pro Azure provides support with Multitenant Hosting Conditionally ready for
Rights. Azure.
Windows Vista These operating systems have passed their end- Conditionally ready for
and Windows XP of-support dates. The server might start in Azure, Azure. We recommend
Professional but Azure provides no OS support. that you upgrade the
OS before migrating to
Azure.
Linux See the Linux operating systems that Azure Ready for Azure if the
endorses. Other Linux operating systems might version is endorsed.
start in Azure. But we recommend that you
upgrade the OS to an endorsed version before Conditionally ready if
you migrate to Azure. the version isn't
endorsed.
Other operating Azure doesn't endorse these operating systems. Conditionally ready for
systems like The server might start in Azure, but Azure Azure. We recommend
Oracle Solaris, provides no OS support. that you install a
Apple macOS, and supported OS before
FreeBSD migrating to Azure.
OS specified as Azure Migrate can't identify the OS in this case. Unknown readiness.
Other in vCenter Ensure that Azure
Server supports the OS running
inside the VM.
32-bit operating The server might start in Azure, but Azure might Conditionally ready for
systems not provide full support. Azure. Consider
upgrading to a 64-bit
OS before migrating to
Azure.
Calculating sizing
After the server is marked as ready for Azure, the assessment makes sizing
recommendations in the Azure VM assessment. These recommendations identify the
Azure VM and disk SKU. Sizing calculations depend on whether you're using as-is on-
premises sizing or performance-based sizing.
Calculate sizing (as-is on-premises)

If you use as-is on-premises sizing, the assessment doesn't consider the performance
history of the VMs and disks in the Azure VM assessment.
Compute sizing: The assessment allocates an Azure VM SKU based on the size
allocated on-premises.
Storage and disk sizing: The assessment looks at the storage type specified in
assessment properties and recommends the appropriate disk type. Possible
storage types are Standard HDD, Standard SSD, Premium, and Ultra disk. The
default storage type is Premium.
Network sizing: The assessment considers the network adapter on the on-
premises server.
Calculate sizing (performance-based)

If you use performance-based sizing in an Azure VM assessment, the assessment makes
sizing recommendations as follows:
The assessment considers the performance (resource utilization) history of the

server along with the processor benchmark to identify the VM size and disk type in
Azure.
７ Note
If you import servers by using a CSV file, the performance values you specify (CPU
utilization, Memory utilization, Disk IOPS and throughput) are used if you choose
performance-based sizing. You will not be able to provide performance history and
percentile information.
This method is especially helpful if you've overallocated the on-premises server,

utilization is low, and you want to right-size the Azure VM to save costs.
If you don't want to use the performance data, reset the sizing criteria to as-is on-
premises, as described in the previous section.
Calculate storage sizing
For storage sizing in an Azure VM assessment, Azure Migrate tries to map each disk that
is attached to the server to an Azure disk. Sizing works as follows:
1. Assessment adds the read and write IOPS of a disk to get the total IOPS required.
Similarly, it adds the read and write throughput values to get the total throughput
of each disk. In the case of import-based assessments, you have the option to
provide the total IOPS, total throughput and total no. of disks in the imported file
without specifying individual disk settings. If you do this, individual disk sizing is
skipped and the supplied data is used directly to compute sizing, and select an
appropriate VM SKU.
2. If you've specified the storage type as automatic, the selected type is based on the
effective IOPS and throughput values. The Assessment determines whether to map
the disk to a Standard HDD, Standard SSD, Premium disk, or Ultra disk in Azure. If
the storage type is set to one of those disk types, the assessment tries to find a
disk SKU within the storage type selected.
3. Disks are selected as follows:
If assessment can't find a disk with the required IOPS and throughput, it
marks the server as unsuitable for Azure.
If assessment finds a set of suitable disks, it selects the disks that support the
location specified in the assessment settings.
If there are multiple eligible disks, assessment selects the disk with the lowest
cost.
If performance data for any disk is unavailable, the configuration disk size is
used to find a Standard SSD disk in Azure.
Ultra disk sizing
For Ultra disks, there is a range of IOPS and throughput that is allowed for a particular
disk size, and thus the logic used in sizing is different from Standard and Premium disks:
1. Three Ultra disk sizes are calculated:
One disk (Disk 1) is found that can satisfy the disk size requirement
One disk (Disk 2) is found that can satisfy total IOPS requirement
IOPS to be provisioned = (source disk throughput) *1024/256
One disk (Disk 3) is found that can satisfy total throughput requirement
2. Out of the three disks, one with the max disk size is found and is rounded up to
the next available Ultra disk offering. This is the provisioned Ultra disk size.
3. Provisioned IOPS is calculated using the following logic:
If source throughput discovered is in the allowable range for the Ultra disk
size, provisioned IOPS is equal to source disk IOPS
Else, provisioned IOPS is calculated using IOPS to be provisioned = (source
disk throughput) *1024/256
4. Provisioned throughput range is dependent on provisioned IOPS
Calculate network sizing

For an Azure VM assessment, assessment tries to find an Azure VM that supports the
number and required performance of network adapters attached to the on-premises
server.
To get the effective network performance of the on-premises server, assessment
aggregates the data transmission rate out of the server (network out) across all
network adapters. It then applies the comfort factor. It uses the resulting value to
find an Azure VM that can support the required network performance.
Along with network performance, assessment also considers whether the Azure
VM can support the required number of network adapters.
If network performance data is unavailable, assessment considers only the network
adapter count for VM sizing.
Calculate compute sizing

After it calculates storage and network requirements, the assessment considers CPU and
RAM requirements to find a suitable VM size in Azure.
Azure Migrate looks at the effective utilized cores (including processor benchmark)
and RAM to find a suitable Azure VM size.
If no suitable size is found, the server is marked as unsuitable for Azure.
If a suitable size is found, Azure Migrate applies the storage and networking
calculations. It then applies location and pricing-tier settings for the final VM size
recommendation.
If there are multiple eligible Azure VM sizes, the one with the lowest cost is
recommended.
Confidence ratings (performance-based)

Each performance-based Azure VM assessment in Azure Migrate is associated with a
confidence rating. The rating ranges from one (lowest) to five (highest) stars. The
confidence rating helps you estimate the reliability of the size recommendations Azure
Migrate provides.
The confidence rating is assigned to an assessment. The rating is based on the

availability of data points that are needed to compute the assessment.
For performance-based sizing, the assessment needs:
The utilization data for CPU and RAM.
The disk IOPS and throughput data for every disk attached to the server.
The network I/O to handle performance-based sizing for each network adapter
attached to a server.
If any of these utilization numbers isn't available, the size recommendations might be
unreliable.
７ Note
Confidence ratings aren't assigned for servers assessed using an imported CSV file.
Ratings also aren't applicable for as-is on-premises assessment.
Ratings
This table shows the assessment confidence ratings, which depend on the percentage of
available data points:
Availability of data points Confidence rating
0-20% 1 star
21-40% 2 stars
41-60% 3 stars
61-80% 4 stars
81-100% 5 stars
Low confidence ratings

Here are a few reasons why an assessment could get a low confidence rating:
assessment. For example, if you create the assessment with performance duration
set to one day, you must wait at least a day after you start discovery for all the data
points to get collected.
Assessment is not able to collect the performance data for some or all the servers
in the assessment period. For a high confidence rating, ensure that:
Servers are powered on for the duration of the assessment
For Hyper-V servers, dynamic memory is enabled
Some servers were created during the time for which the assessment was
calculated. For example, assume you created an assessment for the performance
history of the last month, but some servers were created only a week ago. In this
case, the performance data for the new servers will not be available for the entire
duration and the confidence rating would be low.
７ Note
If the confidence rating of any assessment is less than five stars, we recommend
that you wait at least a day for the appliance to profile the environment and then
recalculate the assessment. Otherwise, performance-based sizing might be
unreliable. In that case, we recommend that you switch the assessment to on-
premises sizing.
Calculate monthly costs

After sizing recommendations are complete, an Azure VM assessment in Azure Migrate
calculates compute and storage costs for after migration.
Compute cost
Azure Migrate uses the recommended Azure VM size and the Azure Billing API to
calculate the monthly cost for the server.
The calculation takes into account the:
Operating system
Software assurance
Reserved instances
VM uptime
Location
Currency settings
The assessment aggregates the cost across all servers to calculate the total monthly
compute cost.
Storage cost
The monthly storage cost for a server is calculated by aggregating the monthly cost of
all disks that are attached to the server.
Standard and Premium disk

The cost for Standard or Premium disks is calculated based on the
selected/recommended disk size.
Ultra disk
The cost for Ultra disk is calculated based on the provisioned size, provisioned IOPS and
provisioned throughput. Learn more
Cost is calculated using the following logic:
Cost of disk size is calculated by multiplying provisioned disk size by hourly price
of disk capacity
Cost of provisioned IOPS is calculated by multiplying provisioned IOPS by hourly
provisioned IOPS price
Cost of provisioned throughput is calculated by multiplying provisioned
throughput by hourly provisioned throughput price
The Ultra disk VM reservation fee is not added in the total cost. Learn More
Assessment calculates the total monthly storage costs by aggregating the storage costs
of all servers. Currently, the calculation doesn't consider offers specified in the
assessment settings.
Costs are displayed in the currency specified in the assessment settings.
Next steps
Review best practices for creating assessments.
Learn about running assessments for servers running in VMware and Hyper-V
environment, and physical servers.
Learn about assessing servers imported with a CSV file.
Learn about setting up dependency visualization.
Assessment Overview (migrate to Azure
SQL)
This article provides an overview of assessments for migrating on-premises SQL Server
instances from a VMware, Microsoft Hyper-V, and Physical environment to SQL Server
on Azure VM or Azure SQL Database or Azure SQL Managed Instance using the Azure
Migrate: Discovery and assessment tool.
An assessment with the Discovery and assessment tool is a point in time snapshot of
data and measures the readiness and estimates the effect of migrating on-premises
servers to Azure.
There are three types of assessments that you can create using the Azure Migrate:
Discovery and assessment tool.
Assessment Details
Type
Azure VM Assessments to migrate your on-premises servers to Azure virtual machines.
You can assess your on-premises servers in VMware and Hyper-V environment, and
physical servers for migration to Azure VMs using this assessment type.
Azure SQL Assessments to migrate your on-premises SQL servers from your VMware,
Microsoft Hyper-V, and Physical environments to SQL Server on Azure VM, or
Azure SQL Database, or Azure SQL Managed Instance.
Azure App Assessments to migrate your on-premises ASP.NET web apps, running on IIS web
Service servers, from your VMware environment to Azure App Service.
Azure Assessments to migrate your on-premises servers to Azure VMware Solution (AVS).
VMware
Solution You can assess your on-premises VMware VMs for migration to Azure VMware
(AVS) Solution (AVS) using this assessment type. Learn more.
７ Note
assessment tool then shows the correct count for that assessment type.
An Azure SQL assessment provides one sizing criteria:
Sizing criteria Details Data
Performance- Assessments that The Azure SQL configuration is based on performance

based make data of SQL instances and databases, which includes CPU
recommendations utilization, Memory utilization, IOPS (Data and Log files),
based on collected throughput, and latency of IO operations.
performance data
How do I assess my on-premises SQL servers?

You can assess your on-premises SQL Server instances by using the configuration and
utilization data collected by a lightweight Azure Migrate appliance. The appliance
discovers on-premises SQL server instances and databases and sends the configuration
and performance data to Azure Migrate. Learn More.

following steps:
2. For your first assessment, create an Azure Migrate project and add the Azure
Migrate: Discovery and assessment tool to it.
discovers on-premises servers and sends configuration and performance data to
After the appliance begins discovery, you can gather servers you want to assess into a
group and run an assessment for the group with assessment type Azure SQL.
Follow our tutorial for assessing SQL Server instances to try out these steps.
data for SQL instances and databases?
The appliance collects performance data for compute settings with these steps:
1. The appliance collects a real-time sample point. For SQL servers, it collects a
sample point every 30 seconds.
2. The appliance aggregates the sample data points collected every 30 seconds over
10 minutes. To create the data point, the appliance selects the peak values from all
samples. It sends the max, mean and variance for each counter to Azure.
3. Azure Migrate stores all the 10-minute data points for the last month.
4. When you create an assessment, Azure Migrate identifies the appropriate data
CPU utilization (%)

Memory utilization (%)
Read IO/s and Write IO/s (Data and Log files)
Read MB/s and Write MB/s (Throughput)
Latency of IO operations
What properties are used to create and

customize an Azure SQL assessment?
The Azure SQL assessment properties include:

settings
Target and Offer/Licensing The Azure offer if you're enrolled. Currently, the field is Pay-as-
pricing program you-go by default, which gives you retail Azure prices.
settings
You can avail additional discount by applying reserved capacity
and Azure Hybrid Benefit on top of Pay-as-you-go offer.
You can apply Azure Hybrid Benefit on top of Pay-as-you-go
offer and Dev/Test environment. The assessment doesn't support
applying Reserved Capacity on top of Pay-as-you-go offer and
Dev/Test environment.
If the offer is set to Pay-as-you-go and Reserved capacity is set to
No reserved instances, the monthly cost estimates are calculated
by multiplying the number of hours chosen in the VM uptime
field with the hourly price of the recommended SKU.
Target and Savings Specify the reserved capacity savings option that you want the
pricing options - Azure assessment to consider to help optimize your Azure compute
settings SQL MI and DB cost.
(PaaS)
Azure reservations (1 year or 3 year reserved) are a good option
for the most consistently running resources.
When you select 'None', the Azure compute cost is based on the
Pay as you go rate or based on actual usage.
You need to select pay-as-you-go in offer/licensing program to

be able to use Reserved Instances. When you select any savings
option other than 'None', the 'Discount (%)' and "VM uptime"
settings aren't applicable. The monthly cost estimates are
calculated by multiplying 744 hours with the hourly price of the
recommended SKU.
settings Server on
Azure VM Azure reservations (1 year or 3 year reserved) are a good option
(IaaS) for the most consistently running resources.

additional flexibility and automated cost optimization. Ideally
post migration, you could use Azure reservation and savings plan
at the same time (reservation is consumed first), but in the Azure
Migrate assessments, you can only see cost estimates of 1
When you select 'None', the Azure compute cost is based on the
Pay as you go rate or based on actual usage.
You need to select pay-as-you-go in offer/licensing program to

be able to use Reserved Instances or Azure Savings Plan. When
you select any savings option other than 'None', the 'Discount
(%)' and "VM uptime" settings aren't applicable. The monthly
cost estimates are calculated by multiplying 744 hours in the VM
uptime field with the hourly price of the recommended SKU.

pricing
settings
Target and Discount (%) Any subscription-specific discounts you receive on top of the
pricing Azure offer. The default setting is 0%.
settings
pricing servers/VMs run. This is useful for computing cost estimates for
settings SQL Server on Azure VM where you're aware that Azure VMs
might not run continuously.
Cost estimates for servers where recommended target is SQL
Server on Azure VM are based on the duration specified. Default
is 31 days per month/24 hours per day.
Target and Azure Hybrid Specify whether you already have a Windows Server and/or SQL
pricing Benefit Server license. Azure Hybrid Benefit is a licensing benefit that
settings helps you to significantly reduce the costs of running your
workloads in the cloud. It works by letting you use your on-
premises Software Assurance-enabled Windows Server and SQL
Server licenses on Azure. For example, if you have a SQL Server
license and they're covered with active Software Assurance of
SQL Server Subscriptions, you can apply for the Azure Hybrid
Benefit when you bring licenses to Azure.
Assessment Sizing criteria Set to Performance-based by default, which means Azure Migrate
criteria collects performance metrics pertaining to SQL instances and the
databases managed by it to recommend an optimal-sized SQL
Server on Azure VM and/or Azure SQL Database and/or Azure
SQL Managed Instance configuration.
Assessment Comfort factor Indicate the buffer you want to use during assessment. This
criteria accounts for issues like seasonal usage, short performance
history, and likely increases in future usage.
Assessment Optimization Specify the preference for the recommended assessment report.
criteria preference Selecting Minimize cost would result in the Recommended
assessment report recommending those deployment types that
have least migration issues and are most cost effective, whereas
selecting Modernize to PaaS would result in Recommended
assessment report recommending PaaS(Azure SQL MI or DB)
deployment types over IaaS Azure(VMs), wherever the SQL
Server instance is ready for migration to PaaS irrespective of cost.
Managed accommodate your business needs for migration to Azure SQL
Instance Managed Instance:
sizing
Select Recommended if you want Azure Migrate to recommend
the best suited service tier for your servers. This can be General
purpose or Business critical.
Select General Purpose if you want an Azure SQL configuration

designed for budget-oriented workloads.
Select Business Critical if you want an Azure SQL configuration

designed for low-latency workloads with high resiliency to
failures and fast failovers.

Managed
Instance
sizing

Managed
Instance
sizing
SQL Server VM series Specify the Azure VM series you want to consider for SQL Server
on Azure on Azure VM sizing. Based on the configuration and performance
VM sizing requirements of your SQL Server or SQL Server instance, the
assessment recommends a VM size from the selected list of VM
series.
You can edit settings as needed. For example, if you don't want
to include D-series VM, you can exclude D-series from this list.
As Azure SQL assessments intend to give the best performance
for your SQL workloads, the VM series list only has VMs that are
optimized for running your SQL Server on Azure Virtual
Machines (VMs). Learn more.
on Azure recommends the best suited Azure Managed Disk based on the
VM sizing chosen environment type, on-premises disk size, IOPS and
throughput.
Database accommodate your business needs for migration to Azure SQL
sizing Database:
Select Recommended if you want Azure Migrate to recommend

the best suited service tier for your servers. This can be General
purpose or Business critical.
Select General Purpose if you want an Azure SQL configuration

designed for budget-oriented workloads.
Select Business Critical if you want an Azure SQL configuration

designed for low-latency workloads with high resiliency to
failures and fast failovers.

Database
sizing

Database model
sizing

Database
sizing

availability recovery location. In an unlikely event when the chosen Target location
and region doesn't yet have such a pair, the specified Target location itself is
disaster chosen as the default disaster recovery region.
recovery
properties

availability intent
disaster replication where some replication delays are tolerable. This
recovery allows higher durability using geo-redundancy. In the event of
Select High availability if you desire the data replication to be

synchronous and no data loss due to replication delay is
allowable. This setting allows assessment to leverage built-in
high availability options in Azure SQL Databases and Azure SQL
Managed Instances, and availability zones and zone-redundancy
in Azure Virtual Machines to provide higher availability. In the
event of failover, no data is lost.

availability
and Select Available if you allow outbound Internet access from
disaster Azure VMs. This allows the use of Cloud Witness which is the
recovery recommended approach for Windows Server Failover Clusters in
properties Azure Virtual Machines.
Select Not available if the Azure VMs have no outbound Internet

access. This requires the use of a Shared Disk as a witness for
Windows Server Failover Clusters in Azure Virtual Machines.

and Select Disaster recovery if you're using asynchronous commit
disaster availability mode to enable higher durability for the data without
recovery affecting performance. In the event of failover, data that hasn't
properties yet been replicated may be lost.
Select High availability if you're using asynchronous commit

data availability mode to improve availability and scale out read
traffic. This setting allows assessment to leverage built-in high
availability features in Azure SQL Databases, Azure SQL Managed
Instances, and Azure Virtual Machines to provide higher
availability and scale out.
Calculate readiness
７ Note
The assessment only includes databases that are in online status. In case the
database is in any other status, the assessment ignores the readiness, sizing and
cost calculation for such databases. In case you wish to assess such databases,
change the status of the database and recalculate the assessment in some time.
Azure SQL readiness

Readiness checks for different migration strategies:
Recommended deployment, Instances to SQL Server on Azure VM,

Instances to Azure SQL MI, Database to Azure SQL DB:
Azure SQL readiness for SQL instances and databases is based on a feature compatibility
check with SQL Server on Azure VM, Azure SQL Database, and Azure SQL Managed
Instance:
1. The Azure SQL assessment considers the SQL Server instance features that are
currently used by the source SQL Server workloads (SQL Agent jobs, linked servers,
etc.) and the user databases schemas (tables, views, triggers, stored procedures
etc.) to identify compatibility issues.
2. If there are no compatibility issues found, the instance is marked as Ready for the
target deployment type (SQL Server on Azure VM or Azure SQL Database or Azure
SQL Managed Instance)
3. If there are non-critical compatibility issues, such as deprecated or unsupported
features that don't block the migration to a specific target deployment type, the
instance is marked as Ready (hyperlinked) with warning details and recommended
remediation guidance. This includes the situation where the source data has an
Always On Availability Group configuration and the required replicas exceed those
available with the specific target deployment type.
4. If there are any compatibility issues that may block the migration to a specific
target deployment type, the instance is marked as Ready with conditions with
issue details and recommended remediation guidance.
In the Recommended deployment, Instances to Azure SQL MI, and Instances
to SQL Server on Azure VM readiness reports, if there's even one database in
a SQL instance, which isn't ready for a particular target deployment type, the
instance is marked as Ready with conditions for that deployment type.
5. Not ready: The assessment couldn't find a SQL Server on Azure VM/Azure SQL
MI/Azure SQL DB configuration meeting the desired configuration and
performance characteristics. Review the recommendation to make the
instance/server ready for the desired target deployment type.
6. If the discovery is still in progress or there are any discovery issues for a SQL
instance or database, the instance is marked as Unknown as the assessment
couldn't compute the readiness for that SQL instance.
７ Note
In the recommended deployment strategy, migrating instances to SQL Server on

Azure VM is the recommended strategy for migrating SQL Server instances.
Though, when SQL Server credentials are not available, the Azure SQL assessment
provides right-sized lift-and-shift ie "Server to SQL Server on Azure VM"
recommendations.
All servers to SQL Server on Azure VM:
Refer to readiness here.
Recommended deployment type

For the recommended deployment migration strategy, the assessment recommends an
Azure SQL deployment type that is the most compatible with your SQL instance and is
the most cost-effective. Migrating to a Microsoft-recommended target reduces your
overall migration effort. If your instance is ready for SQL Server on Azure VM, Azure SQL
Managed Instance, and Azure SQL Database, the target deployment type, which has the
least migration readiness issues and is the most cost-effective is recommended. If you
select the target deployment type as Recommended in the Azure SQL assessment
properties, Azure Migrate recommends an Azure SQL deployment type that is
compatible with your SQL instance. Migrating to a Microsoft-recommended target
reduces your overall migration effort.
７ Note
In the recommended deployment strategy, if the source SQL Server is good fit for
all three deployment targets- SQL Server on Azure VM, Azure SQL Managed
Instance and Azure SQL Database, the assessment recommends a specific option
that optimizes your cost and fits within the size and performance boundaries.
Calculate sizing
Instances to Azure SQL MI and Databases to Azure SQL

DB configuration
After the assessment determines the readiness and the recommended Azure SQL
deployment type, it computes a specific service tier and Azure SQL configuration (SKU
size) that can meet or exceed the on-premises SQL instance performance:
1. During the discovery process, Azure Migrate collects SQL instance configuration
and performance that includes:
vCores (allocated) and CPU utilization (%)

CPU utilization for a SQL instance is the percentage of allocated CPU
utilized by the instance on the SQL server
CPU utilization for a database is the percentage of allocated CPU utilized
by the database on the SQL instance
Memory (allocated) and memory utilization (%)
Read IO/s and Write IO/s at a SQL instance level is calculated by adding
the Read IO/s and Write IO/s of all databases discovered in that instance.
Total DB size and database file organizations
Database size is calculated by adding all the data and log files.
Always On Failover Cluster Instance network subnet configuration (Single
Subnet or Multi-Subnet)
Always On Availability Group configurations
Network configuration of participating instances (Single Subnet or Multi-
Subnet)
Number and type of secondary replicas
Availability Mode: Synchronous Commit vs Asynchronous Commit
Connection Mode: Read-only vs None
2. The assessment aggregates all the configuration and performance data and tries to
find the best match across various Azure SQL service tiers and configurations and
picks a configuration that can match or exceed the SQL instance performance
requirements, optimizing the cost.
Instances to SQL Server on Azure VM configuration

Instance to SQL Server on Azure VM assessment report covers the ideal approach for
migrating SQL Server instances and databases to SQL Server on Azure VM, adhering to
the best practices. Learn more.
If the source is a SQL Server Always On Failover Cluster Instance (FCI), the assessment
report covers the approach for migrating to a two-node SQL Server Failover Cluster
Instance. This preserves the high availability and disaster recovery intents while adhering
to the best practices. Learn more.
Storage sizing
For storage sizing, the assessment maps each of the instance disk to an Azure disk.
Sizing works as follows:
Assessment adds the read and write IOPS of a disk to get the total IOPS required.
Similarly, it adds the read and write throughput values to get the total throughput
of each disk. The disk size needed for each of the disks is the size of SQL Data and
SQL Log drives.
The assessment recommends creating a storage disk pool for all SQL Log and SQL
Data drives. For temp drives, the assessment recommends storing the files in the
local drive.
If the assessment can't find a disk for the required size, IOPS and throughput, it
marks the instance as unsuitable for migrating to SQL Server on Azure VM
If the assessment finds a set of suitable disks, it selects the disks that support the
location specified in the assessment settings.
If the source is a SQL Server Always On Failover Cluster Instance, shared disk
configuration is selected.
If the environment type is Production, the assessment tries to find Premium disks
to map each of the disks, else it tries to find a suitable disk, which could either be
Premium or Standard SSD disk.
If there are multiple eligible disks, assessment selects the disk with the lowest
cost.
Compute sizing
After it calculates storage requirements, the assessment considers CPU and RAM
requirements of the instance to find a suitable VM size in Azure.
The assessment looks at the effective utilized cores and RAM to find a suitable
Azure VM size. Effective utilized RAM or memory for an instance is calculated by
aggregating the buffer cache (buffer pool size in MB) for all the databases running
in an instance.
If no suitable size is found, the server is marked as unsuitable for Azure.
If a suitable size is found, Azure Migrate applies the storage calculations. It then
applies location and pricing-tier settings for the final VM size recommendation.
If there are multiple eligible Azure VM sizes, the one with the lowest cost is
recommended.
If the source is a SQL Server Always On Failover Cluster Instance, the compute size
is used again for a second Azure VM to meet the need for two nodes.
７ Note
As Azure SQL assessments are intended to give the best performance for your SQL
workloads, the VM series list only has VMs that are optimized for running your SQL
Servers to SQL Server on Azure VM configuration

For All servers to SQL Server on Azure VM migration strategy, refer compute and storage
sizing here.
Confidence ratings
Each Azure SQL assessment is associated with a confidence rating. The rating ranges
from one (lowest) to five (highest) stars. The confidence rating helps you estimate the
reliability of the size recommendations Azure Migrate provides.
The confidence rating is assigned to an assessment. The rating is based on the

availability of data points that are needed to compute the assessment.
For performance-based sizing, the assessment collects performance data of all the
SQL instances and databases, which include:
CPU utilization (%)
Memory utilization (%)
If any of these utilization numbers isn't available, the size recommendations might be
unreliable. This table shows the assessment confidence ratings, which depend on the
percentage of available data points:
0%-20% 1 star
21%-40% 2 stars
41%-60% 3 stars
61%-80% 4 stars
81%-100% 5 stars

The Assessment isn't able to collect the performance data for some or all the
servers in the assessment period. For a high confidence rating, ensure that:
Servers are powered on for the duration of the assessment.
Outbound connections on ports 443 are allowed.
If Azure Migrate connection status of the SQL agent in Azure Migrate is
Connected, check the last heartbeat.
Azure Migrate connection status for all SQL instances is Connected in the
discovered SQL instance section.

Some databases or instances were created during the time for which the
assessment was calculated. For example, you created an assessment for the
performance history of the last month, but some databases or instances were
created only a week ago. In this case, the performance data for the new servers
won't be available for the entire duration and the confidence rating would be low.
７ Note
As Azure SQL assessments are performance-based assessments, if the confidence

rating of any assessment is less than five stars, we recommend that you wait at
least a day for the appliance to profile the environment and then recalculate the
assessment. Otherwise, performance-based sizing might be unreliable.
Recommendation details
Once the readiness and sizing calculation is complete, the optimization preference is
applied to arrive at a recommended target and configuration. The Recommendation
Details provide a detailed explanation of the readiness and sizing calculations behind
the recommendation.
Migration guidance
This section provides guidance to configure the target resource and steps to migrate.
The steps are specific to the source and the target deployment combinations. This
guidance is specifically useful for users who intend to migrate Always On Failover Cluster
Instances (FCI) and Availability Groups (AG).
Calculate monthly costs

After sizing recommendations are complete, Azure SQL assessment calculates the
compute and storage costs for the recommended Azure SQL configurations using an
internal pricing API. It aggregates the compute and storage cost across all instances to
calculate the total monthly compute cost.
Compute cost
To calculate the compute cost for an Azure SQL configuration, the assessment
considers the following properties:
Azure Hybrid Benefit for SQL and Windows licenses
Environment type
Reserved capacity
Azure target location
Currency
Offer/Licensing program
Discount (%)
Storage cost
The storage cost estimates only include data files and not log files.
For calculating storage cost for an Azure SQL configuration, the assessment
considers following properties:
Azure target location
Currency
Offer/Licensing program
Discount (%)
Backup storage cost isn't included in the assessment.
Azure SQL Database
A minimum of 5 GB storage cost is added in the cost estimate and additional
storage cost is added for storage in 1 GB increments. Learn More .
Azure SQL Managed Instance
There's no storage cost added for the first 32 GB/instance/month storage and
additional storage cost is added for storage in 32 GB increments. Learn More .
Next steps
Learn how to run an Azure SQL assessment.
App Service)
This article provides an overview of assessments for migrating on-premises ASP.NET

web apps to Azure App Service using the Azure Migrate: Discovery and assessment tool.
An assessment with the Discovery and assessment tool is a point in time snapshot of
data and measures the readiness and provides cost details to host on-premises servers,
databases, and web apps to Azure.
There are four types of assessments you can create using the Azure Migrate: Discovery
and assessment tool.
Assessment Details
Type
You can assess your on-premises servers in VMware and Hyper-V environment,
and physical servers for migration to Azure VMs using this assessment type.
Azure App Assessments to migrate your on-premises ASP.NET web apps running on IIS web
Service servers to Azure App Service.
Azure Assessments to migrate your on-premises servers to Azure VMware Solution

VMware (AVS).
Solution
(AVS) You can assess your on-premises VMware VMs for migration to Azure VMware
Solution (AVS) using this assessment type. Learn more
An Azure App Service assessment provides one sizing criteria:

Configuration- Assessments that make The Azure App Service assessment takes only
based recommendations based configuration data in to consideration for
on collected assessment calculation. Performance data for web
configuration data apps isn't collected.
How do I assess my on-premises ASP.NET web

apps?
You can assess your on-premises web apps by using the configuration data collected by
a lightweight Azure Migrate appliance. The appliance discovers on-premises web apps
and sends the configuration data to Azure Migrate. Learn More

following steps:
2. For your first assessment, create an Azure Migrate project. Azure Migrate:
Discovery and assessment tool gets added to the project by default.
discovers on-premises servers and sends configuration and performance data to
After the appliance begins discovery, you can gather servers (hosting web apps) you
want to assess into a group and run an assessment for the group with assessment type
Azure App Service.
Follow our tutorial for assessing ASP.NET web apps to try out these steps.
What properties are used to customize the

assessment?
Here's what's included in Azure App Service assessment properties:
Setting Details
Setting Details
Target The Azure region to which you want to migrate. Azure App Service configuration
location and cost recommendations are based on the location that you specify.
required environment in an Azure datacenter using Dv2-series VMs with faster processors,
SSD storage, and double the memory to core ratio compared to Standard plans.
(compute)
Azure Savings Plan (1 year or 3 year savings plan) provide additional flexibility and
automated cost optimization. Ideally post migration, you could use Azure
reservation and savings plan at the same time (reservation is consumed first), but
in the Azure Migrate assessments, you can only see cost estimates of 1 savings
option at a time.
When you select 'None', the Azure compute cost is based on the Pay as you go
rate or based on actual usage.
You need to select pay-as-you-go in offer/licensing program to be able to use

other than 'None', the 'Discount (%)' setting isn't applicable. The monthly cost
estimates are calculated by multiplying 744 hours with the hourly price of the
recommended SKU.
Offer The Azure offer in which you're enrolled. The assessment estimates the cost for
that offer.
Discount Any subscription-specific discounts you receive on top of the Azure offer. The
(%) default setting is 0%.

Leave the settings for reserved instances, discount (%) and VM uptime properties
with their default settings.
Calculate readiness
Azure App Service readiness for web apps is based on feature compatibility checks
between on-premises configuration of web apps and Azure App Service:
1. The Azure App Service assessment considers the web apps configuration data to
identify compatibility issues.
2. If there are no compatibility issues found, the readiness is marked as Ready for the
target deployment type.
3. If there are non-critical compatibility issues, such as degraded or unsupported
features that don't block the migration to a specific target deployment type, the
readiness is marked as Ready with conditions (hyperlinked) with warning details
4. If there are any compatibility issues that may block the migration to a specific
5. If the discovery is still in progress or there are any discovery issues for a web app,
the readiness is marked as Unknown as the assessment couldn't compute the
readiness for that web app.
Calculate sizing
Azure App Service SKU

After the assessment determines the readiness based on configuration data, it
determines the Azure App Service SKU that is suitable for running your apps in Azure
App Service. Premium plans are for production workloads and run on dedicated Virtual
Machine instances. Each instance can support multiple applications and domains. The
Isolated plans host your apps in a private, dedicated Azure environment and are ideal
for apps that require secure connections with your on-premises network.
７ Note
Currently, Azure Migrate only recommends I1, P1v2, and P1v3 SKUs. There are
more SKUs available in Azure App service. Learn more .
Azure App Service Plan

In App Service, an app always runs in an App Service plan. An App Service plan defines a
set of compute resources for a web app to run. At a high level, plan/SKU is determined
as per below table.
Yes Yes I1
Yes No I1
No Yes P1v3
No No P1v2

An App Service plan carries a charge on the compute resources it uses. In App Service,
you pay charges per App Service plans and not per web app. One or more apps can be
configured to run on the same computing resources (or in the same App Service plan).
Whatever apps you put into this App Service plan run on these compute resources as
defined by your App Service plan. To optimize cost, Azure Migrate assessment allocates
multiple web apps to each recommended App Service plan. Number of web apps
allocated to each plan instance is as per below table.
I1 8
P1v2 8
P1v3 16
７ Note
Your App Service plan can be scaled up and down at any time. Learn more.
Next steps
Learn how to run an Azure App Service assessment.
VMware Solution)
your on-premises apps and workloads. It also tracks your private and public cloud
instances to Azure. The hub offers Azure Migrate tools for assessment and migration, as
well as third-party independent software vendor (ISV) offerings.
Discovery and assessment tool in Azure Migrate assesses on-premises servers for
migration to Azure virtual machines and Azure VMware Solution. This article provides
information about how Azure VMware Solution assessments are calculated.
７ Note
Azure VMware Solution assessment can be created for VMware vSphere VMs only.
Assessments you create with Azure Migrate are a point-in-time snapshot of data. There
are two types of assessments you can create using Azure Migrate:
Assessment Details
Type
can assess your on-premises servers in VMware vSphere and Hyper-V environment,
Service servers, from your VMware vSphere environment to Azure App Service.
Azure Assessments to migrate your on-premises vSphere servers to Azure VMware

VMware Solution. You can assess your on-premises VMware vSphere VMs for migration to
Solution Azure VMware Solution using this assessment type. Learn more
(AVS)
７ Note
If the number of Azure VM or Azure VMware Solution assessments are incorrect on
the Discovery and assessment tool, click on the total number of assessments to
navigate to all the assessments and recalculate the Azure VM or Azure VMware
Solution assessments. The Discovery and assessment tool will then show the correct
count for that assessment type.
Azure VMware Solution assessment provides two sizing criteria options:
Performance- Assessments based on Recommended Node size: Based on CPU and memory
based collected performance utilization data along with node type, storage type,
data of on-premises and FTT setting that you select for the assessment.
VMs.
As on- Assessments based on Recommended Node size: Based on the on-premises

premises on-premises sizing. VM size along with the node type, storage type, and
FTT setting that you select for the assessment.
How do I run an assessment?

There are a couple of ways to run an assessment.
Assess servers by using server metadata collected by a lightweight Azure Migrate

appliance. The appliance discovers on-premises servers. It then sends server
metadata and performance data to Azure Migrate. This allows for more precision.
Assess servers by using server metadata that's imported in a comma-separated
values (CSV) format.

following steps:
discovers on-premises vSphere servers and sends server metadata and
performance data to Azure Migrate. Deploy the appliance as a VM. You don't need
After the appliance begins server discovery, you can gather servers you want to assess
into a group and run an assessment for the group with assessment type Azure VMware
Solution (AVS).
Create your first Azure VMware Solution assessment by following the steps here.
How do I assess with imported data?

If you're assessing servers by using a CSV file, you don't need an appliance. Instead, do
the following steps:
1. Set up Azure to work with Azure Migrate.

3. Download a CSV template and add server data to it.
4. Import the template into Azure Migrate.
5. Discover servers added with the import, gather them into a group, and run an
assessment for the group with assessment type Azure VMware Solution (AVS).

If you're using the Azure Migrate appliance for assessment, learn about the metadata
and performance data that's collected for VMware vSphere.

data?
with these steps:
VMware vSphere VMs: A sample point is collected every 20 seconds.
minutes. To create the data point, the appliance selects the peak values from all
samples. It then sends the data point to Azure.
3. Azure Migrate stores all the 10-minute data points for the last month.
4. When you create an assessment, the assessment identifies the appropriate data
CPU utilization
RAM utilization
The following performance data is collected but not used in sizing recommendations for
Azure VMware Solution assessments:
The disk IOPS and throughput data for every disk attached to the VM.
attached to a VM.
How are Azure VMware Solution assessments

calculated?
Azure VMware Solution assessment uses the on-premises vSphere servers' metadata
and performance data to calculate assessments. If you deploy the Azure Migrate
appliance, assessment uses the data the appliance collects. But if you run an assessment
imported using a CSV file, you provide the metadata for the calculation.
Calculations occur in these three stages:
1. Calculate Azure VMware Solution readiness: Whether the on-premises vSphere

VMs are suitable for migration to Azure VMware Solution.
2. Calculate number of Azure VMware Solution nodes and Utilization across nodes:
Estimated number of Azure VMware Solution nodes required to run the VMware
vSphere VMs and projected CPU, memory, and storage utilization across all nodes.
3. Monthly cost estimation: The estimated monthly costs for all Azure VMware
Solution nodes running the on-premises vSphere VMs.
Calculations are in the preceding order. A server moves to a later stage only if it passes
the previous one. For example, if a server fails the Azure VMware Solution readiness
stage, it's marked as unsuitable for Azure. Sizing and cost calculations aren't done for
that server
What's in an Azure VMware Solution

assessment?
Here's what's included in an Azure VMware Solution assessment:
Property Details
Target location Specifies the Azure VMware Solution private cloud location to which you
want to migrate.
Storage type Specifies the storage engine to be used in Azure VMware Solution. Azure
VMware Solution currently only supports vSAN as a default storage type but
more storage options will be coming as per roadmap.
Reserved This property helps you specify Reserved Instances in Azure VMware Solution
Instances (RIs) if purchased and the term of the Reserved Instance. Your cost estimates will
take the option chosen into account.Learn more
If you select reserved instances, you can't specify “Discount (%)”.
Node type Specifies the Azure VMware Solution Node type used to be used in Azure.
The default node type is AV36. More node types might be available in future.
Azure Migrate will recommend a required number of nodes for the VMs to be
migrated to Azure VMware Solution.
FTT Setting, Specifies the valid combination of Failures to Tolerate and Raid combinations.
RAID Level The selected FTT option combined with RAID level and the on-premises
vSphere VM disk requirement will determine the total vSAN storage required
in Azure VMware Solution. Total available storage after calculations also
includes a) space reserved for management objects such as vCenter Server
and b) 25% storage slack required for vSAN operations.
Sizing criterion Sets the criteria to be used to determine memory, cpu and storage
requirements for Azure VMware Solution nodes. You can opt for performance-
based sizing or as on-premises without considering the performance history.
To simply lift and shift, choose as on-premises. To obtain usage based sizing,
choose performance based.
Performance Sets the duration to consider in evaluating the performance data of servers.
history This property is applicable only when the sizing criteria is performance-based.
Property Details
Percentile Specifies the percentile value of the performance sample set to be considered
utilization for right-sizing. This property is applicable only when the sizing is
performance-based.
Comfort factor Azure Migrate considers a buffer (comfort factor) during assessment. This
buffer is applied on top of server utilization data for VMs (CPU, memory and
disk). The comfort factor accounts for issues such as seasonal usage, short
performance history, and likely increases in future usage. For example, a 10-
core VM with 20% utilization normally results in a 2-core VM. However, with a
comfort factor of 2.0x, the result is a 4-core VM instead.
Offer Displays the Azure offer you're enrolled in. Azure Migrate estimates the
cost accordingly.
Currency Shows the billing currency for your account.
Discount (%) Lists any subscription-specific discount you receive on top of the Azure offer.
The default setting is 0%.
Azure Hybrid Specifies whether you have software assurance and are eligible for Azure
Benefit Hybrid Benefit . Although it has no impact on Azure VMware Solution
pricing due to the node-based price, customers can still apply the on-
premises OS or SQL licenses (Microsoft based) in Azure VMware Solution
using Azure Hybrid Benefits. Other software OS vendors will have to provide
their own licensing terms, such as RHEL for example.
vCPU Specifies the ratio of number of virtual cores tied to one physical core in the
Oversubscription Azure VMware Solution node. The default value in the calculations is 4 vCPU:1
physical core in Azure VMware Solution. API users can set this value as an
integer. Note that vCPU Oversubscription > 4:1 may impact workloads
depending on their CPU usage. When sizing, we always assume 100%
utilization of the cores chosen.
Memory Specifies the ratio of memory overcommit on the cluster. A value of 1

overcommit represents 100% memory use, 0.5, for example is 50%, and 2 would be using
factor 200% of available memory. You can only add values from 0.5 to 10 up to one
decimal place.
Deduplication Specifies the anticipated deduplication and compression factor for your
and compression workloads. Actual value can be obtained from on-premises vSAN or storage
factor configurations. These vary by workload. A value of 3 would mean 3x so for
300GB disk only 100GB storage would be used. A value of 1 would mean no
deduplication or compression. You can only add values from 1 to 10 up to
one decimal place.
Azure VMware Solution suitability analysis

Azure VMware Solution assessments assess each on-premises vSphere VM for its
suitability for Azure VMware Solution by reviewing the server properties. It also assigns
each assessed server to one of the following suitability categories:
Ready for AVS: The server can be migrated as-is to Azure VMware Solution
without any changes. It will start in Azure VMware Solution with full support.
Ready with conditions: There might be some compatibility issues example internet
protocol or deprecated OS in VMware vSphere and need to be remediated before
migrating to Azure VMware Solution. To fix any readiness problems, follow the
remediation guidance the assessment suggests.
Not ready for AVS: The VM will not start in Azure VMware Solution. For example, if
the on-premises VMware vSphere VM has an external device attached, such as a
cd-rom, the VMware vMotion operation will fail (if using VMware vMotion).
Readiness unknown: Azure Migrate couldn't determine the readiness of the server
because of insufficient metadata collected from the on-premises environment.
The assessment reviews the server properties to determine the Azure readiness of the
on-premises vSphere server.
Server properties
The assessment reviews the following property of the on-premises vSphere VM to
determine whether it can run on Azure VMware Solution.
Property Details Azure

VMware
Solution
readiness
status
Internet Azure VMware Solution currently does not support end to end Unsupported
Protocol IPv6 internet addressing. Contact your local MSFT Azure VMware IPv6
Solution GBB team for guidance on remediation guidance if your
server is detected with IPv6.
Operating Support for certain Operating System versions have been

System deprecated by VMware and the assessment recommends you to
upgrade the operating system before migrating to Azure VMware
Solution. Learn more
Unsupported
OS
Sizing
After a vSphere server is marked as ready for Azure VMware Solution, Azure VMware
Solution Assessment makes node sizing recommendations, which involve identifying the
appropriate on-premises vSphere VM requirements and finding the total number of
Azure VMware Solution nodes required. These recommendations vary, depending on
the assessment properties specified.
If the assessment uses performance-based sizing, Azure Migrate considers the

performance history of the server to make the appropriate sizing recommendation
for Azure VMware Solution. This method is especially helpful if you've over-
allocated the on-premises vSphere VM, but utilization is low and you want to
right-size the VM in Azure VMware Solution to save costs. This method will help
you optimize the sizes during migration.
７ Note
If your import serves by using a CSV file, the performance values you specify (CPU
utilization, Memory utilization, Storage in use, Disk IOPS, and throughput) are used
if you choose performance-based sizing. You will not be able to provide
performance history and percentile information.
If you don't want to consider the performance data for VM sizing and want to take
the on-premises vSphere servers as-is to Azure VMware Solution, you can set the
sizing criteria to as on-premises. Then, the assessment will size the VMs based on
the on-premises vSphere configuration without considering the utilization data.
FTT Sizing Parameters

The storage engine used in Azure VMware Solution is vSAN. vSAN storage policies
define storage requirements for your servers. These policies guarantee the required level
of service for your VMs because they determine how storage is allocated to the VM. The
available FTT-Raid Combinations are:
Failures to Tolerate RAID Minimum Hosts Sizing consideration

(FTT) Configuration Required
1 RAID-1 (Mirroring) 3 A 100GB VM would consume

200GB.
1 RAID-5 (Erasure 4 A 100GB VM would consume

Coding) 133.33GB

300GB.

Coding) 150GB.

400GB.
Performance-based sizing
For performance-based sizing, Azure Migrate appliance profiles the on-premises
vSphere environment to collect performance data for CPU, memory and disk. Thus,
performance based sizing for Azure VMware Solution will take into consideration the
allocated disk space and using the chosen percentile utilization of memory and CPU. For
example if a VM has 4 vCPU allocated but only using 25% then Azure VMware Solution
will size for 1 vCPU for that VM.
Performance data collection steps:
1. For VMware vSphere VMs, the Azure Migrate appliance collects a real-time sample
point at every 20-second interval.
2. The appliance rolls up the sample points collected every 10 minutes and sends the
maximum value for the last 10 minutes to Azure Migrate.
3. Azure Migrate stores all the 10-minute sample points for the last one month. Then,
depending on the assessment properties specified for Performance history and
Percentile utilization, it identifies the appropriate data point to use for right-sizing.
For example, if the performance history is set to 1 day and the percentile utilization
is the 95th percentile, Azure Migrate uses the 10-minute sample points for the last
one day, sorts them in ascending order, and picks the 95th percentile value for
right-sizing.
utilization data for each metric (CPU utilization and memory utilization) that the
appliance collects.
After the effective utilization value is determined, the storage, network, and compute
sizing is handled as follows.
Storage sizing: Azure Migrate uses the total on-premises VM disk space as a calculation
parameter to determine Azure VMware Solution vSAN storage requirements in addition
to the customer-selected FTT setting. FTT - Failures to tolerate as well as requiring a
minimum number of nodes per FTT option will determine the total vSAN storage
required combined with the VM disk requirement. If your import serves by using a CSV
file, storage utilization is taken into consideration when you create a performance based
assessment. If you create an as-on-premises assessment, the logic only looks at
allocated storage per VM.
Network sizing: Azure VMware Solution assessments currently do not take any network
settings into consideration for node sizing. While migrating to Azure VMware Solution,
minimums and maximums as per VMware NSX- T Data Center standards are used.
Compute sizing: After it calculates storage requirements (FTT Sizing Parameters), Azure
VMware Solution assessment considers CPU and memory requirements to determine
the number of nodes required for Azure VMware Solution based on the node type.
Based on the sizing criteria, Azure VMware Solution assessment looks at either the
performance-based VM data or the on-premises vSphere VM configuration. The
comfort factor setting allows for specifying growth factor of the cluster. Currently
by default, hyperthreading is enabled and thus a 36 core nodes will have 72
vCores. 4 vCores per physical is used to determine CPU thresholds per cluster
using the VMware standard of not exceeding 80% utilization to allow for
maintenance or failures to be handled without compromising cluster availability.
There is currently no override available to change the oversubscription values and
we may have this in future versions.
As on-premises sizing
If you use as on-premises sizing, Azure VMware Solution assessment doesn't consider
the performance history of the VMs and disks. Instead, it allocates Azure VMware
Solution nodes based on the size allocated on-premises. The default storage type is
vSAN in Azure VMware Solution.
Learn more about how to review an Azure VMware Solution assessment.
CPU utilization on Azure VMware Solution nodes

CPU utilization assumes 100% usage of the available cores. To reduce the number of
nodes required, one can increase the oversubscription from 4:1 to say 6:1 based on
workload characteristics and on-premises vSphere experience. Unlike for disk, Azure
VMware Solution does not place any limits on CPU utilization. It's up to customers to
ensure their cluster performs optimally so if "running hot" is required, adjust
accordingly. To allow more room for growth, reduce the oversubscription or increase the
value for growth factor.
CPU utilization also already accounts for management overhead from vCenter Server,
NSX-T Manager and other smaller resources.
Memory utilization on Azure VMware Solution nodes

Memory utilization shows the total memory from all nodes vs. requirements from Server
or workloads. Memory can be over subscribed and again Azure VMware Solution places
no limits and it's up the customer to run optimal cluster performance for their
workloads.
Memory utilization also already accounts for management overhead from vCenter
Server, NSX-T Manager and other smaller resources.
Storage utilization on Azure VMware Solution nodes

Storage utilization is calculated based on the following sequence:
1. Size required for VMs (either allocated as is or performance based used space)
2. Apply growth factor if any
3. Add management overhead and apply FTT ratio
4. Apply deduplication and compression factor
5. Apply required 25% slack for vSAN
6. Result available storage for VMs out of total storage including management
overhead.
The available storage on a 3 node cluster will be based on the default storage policy,
which is Raid-1 and uses thick provisioning. When calculating for erasure coding or
Raid-5 for example, a minimum of 4 nodes is required. Note that in Azure VMware
Solution, the storage policy for customer workload can be changed by the administrator
or Run Command(Currently in Preview). [Learn more] (./azure-vmware/configure-
storage-policy.md)
Limiting factor
The limiting factor shown in assessments could be CPU or memory or storage resources
based on the utilization on nodes. It is the resource, which is limiting or determining the
number of hosts/nodes required to accommodate the resources. For example, in an
assessment if it was found that after migrating 8 VMware VMs to Azure VMware
Solution, 50% of CPU resources will be utilized, 14% of memory is utilized and 18% of
storage will be utilized on the 3 Av36 nodes and thus CPU is the limiting factor.
Confidence ratings
Each performance-based assessment in Azure Migrate is associated with a confidence
rating that ranges from one (lowest) to five stars (highest).
The confidence rating is assigned to an assessment based on the availability of

data points needed to compute the assessment.
The confidence rating of an assessment helps you estimate the reliability of the
size recommendations provided by Azure Migrate.
Confidence ratings aren't applicable for as on-premises assessments.
For performance-based sizing, Azure VMware Solution assessments need the

utilization data for CPU and VM memory. The following data is collected but not
used in sizing recommendations for Azure VMware Solution:
The disk IOPS and throughput data for every disk attached to the VM.
attached to a VM.
If any of these utilization numbers are unavailable in vCenter Server, the size
recommendation might not be reliable.
Depending on the percentage of data points available, the confidence rating for the
assessment goes as follows.
0-20% 1 star
21-40% 2 stars
41-60% 3 stars
61-80% 4 stars
81-100% 5 stars

Assessment is not able to collect the performance data for some or all the VMs in
the assessment period. For a high confidence rating, please ensure that:
VMs are powered on for the duration of the assessment
For Hyper-V VMs, dynamic memory is enabled
Please 'Recalculate' the assessment to reflect the latest changes in confidence

rating.
Some VMs were created during the time for which the assessment was calculated.
For example, assume you created an assessment for the performance history of the
last month, but some VMs were created only a week ago. In this case, the
performance data for the new VMs will not be available for the entire duration and
the confidence rating would be low.
７ Note
If the confidence rating of any assessment is less than five stars, we recommend
that you wait at least a day for the appliance to profile the environment, and then
recalculate the assessment. If you don't, performance-based sizing might not be
reliable. In that case, we recommend that you switch the assessment to on-
premises sizing.
Monthly cost estimation

After sizing recommendations are complete, Azure Migrate calculates the total cost of
running the on-premises vSphere workloads in Azure VMware Solution by multiplying
the number of Azure VMware Solution nodes required by the node price. The cost per
VM cost is calculated by dividing the total cost by the number of VMs in the assessment.
The calculation takes the number of nodes required, node type and location into
account.
It aggregates the cost across all nodes to calculate the total monthly cost.
Costs are displayed in the currency specified in the assessment settings.
As the pricing for Azure VMware Solution is per node, the total cost does not have
compute cost and storage cost distribution. Learn More
Migration Tool Guidance
In the Azure readiness report for Azure VMware Solution assessment, you can see the
following suggested tools:
VMware HCX or Enterprise: For VMware vSphere servers, VMware Hybrid Cloud
Extension (HCX) solution is the suggested migration tool to migrate your on-
premises vSphere workload to your Azure VMware Solution private cloud. Learn
More.
unknown. Though for VMware vSphere servers, it is recommended to use the
VMware Hybrid Cloud Extension (HCX) solution.
Next steps
Create an assessment for Azure VMware Solution VMs.
Best practices for creating assessments
Azure Migrate provides a hub of tools that help you to discover, assess, and migrate
apps, infrastructure, and workloads to Microsoft Azure. The hub includes Azure Migrate
tools, and third-party independent software vendor (ISV) offerings.
This article summarizes the best practices when creating assessments using the Azure
Migrate Discovery and assessment tool.
Assessments you create with Azure Migrate: Discovery and assessment tool are a point-
in-time snapshot of data. There are four types of assessments you can create using
Azure Migrate: Discovery and assessment:
Assessment Details
Type
You can assess your on-premises servers in VMware and Hyper-V environment,
and physical servers for migration to Azure using this assessment type. Learn
more
environment to Azure SQL Database or Azure SQL Managed Instance. Learn
More
Azure App Assessments to migrate your on-premises ASP.NET web apps running on IIS web
Service server, from your VMware environment to Azure App Service. Learn More

VMware (AVS).
Solution
(AVS) You can assess your on-premises VMware VMs for migration to Azure VMware
Solution (AVS) using this assessment type. Learn more
７ Note
Sizing criteria
Sizing criteria options in Azure Migrate assessments:
Performance- Assessments that Azure VM assessment: VM size recommendation is based

based make on CPU and memory utilization data.
recommendations
based on collected Disk type recommendation (standard HDD/SSD, premium-
performance data. managed or ultra disks) is based on the IOPS and
throughput of the on-premises disks.
Azure SQL assessment: The Azure SQL configuration is

based on performance data of SQL instances and
databases, which includes: CPU utilization, Memory
utilization, IOPS (Data and Log files), throughput, and
latency of IO operations
Azure VMware Solution (AVS) assessment: AVS nodes

recommendation is based on CPU and memory utilization
data.
As-is on- Assessments that Azure VM assessment: VM size recommendation is based

premises don't use on the on-premises VM size
performance data
to make The recommended disk type is based on what you select in
recommendations. the storage type setting for the assessment.
Azure App Service assessment: Assessment

recommendation is based on on-premises web apps
configuration data.

recommendation is based on the on-premises VM size.
Example
As an example, if you have an on-premises VM with four cores at 20% utilization, and
memory of 8 GB with 10% utilization, the Azure VM assessment will be as follows:
Performance-based assessment:
Identifies effective cores and memory based on core (4 x 0.20 = 0.8), and
memory (8 GB x 0.10 = 0.8) utilization.
Applies the comfort factor specified in assessment properties (let's say 1.3x) to
get the values to be used for sizing.
Recommends the nearest VM size in Azure that can support ~1.04 cores (0.8 x
1.3) and ~1.04 GB (0.8 x 1.3) memory.
As-is (as on-premises) assessment:

Recommends a VM with four cores; 8 GB of memory.
Best practices for creating assessments

The Azure Migrate appliance continuously profiles your on-premises environment, and
sends metadata and performance data to Azure. Follow these best practices for
assessments of servers discovered using an appliance:
Create as-is assessments: You can create as-is assessments immediately once your
servers show up in the Azure Migrate portal. You cannot create an Azure SQL
assessment with sizing criteria "As on-premises". Azure App Service assessment by
default is "As on-premises".
Create performance-based assessment: After setting up discovery, we
recommend that you wait at least a day before running a performance-based
assessment:
Collecting performance data takes time. Waiting at least a day ensures that
there are enough performance data points before you run the assessment.
When you're running performance-based assessments, make sure you profile
your environment for the assessment duration. For example, if you create an
assessment with a performance duration set to one week, you need to wait for
at least a week after you start discovery, for all the data points to be collected. If
you don't, the assessment won't get a five-star rating.
Recalculate assessments: Since assessments are point-in-time snapshots, they
aren't automatically updated with the latest data. To update an assessment with
the latest data, you need to recalculate it.
Follow these best practices for assessments of servers imported into Azure Migrate via
.CSV file:
Create as-is assessments: You can create as-is assessments immediately once your
servers show up in the Azure Migrate portal.
Create performance-based assessment: This helps to get a better cost estimate,
especially if you have overprovisioned server capacity on-premises. However, the
accuracy of the performance-based assessment depends on the performance data
specified by you for the servers.
Recalculate assessments: Since assessments are point-in-time snapshots, they
aren't automatically updated with the latest data. To update an assessment with
the latest imported data, you need to recalculate it.
FTT Sizing Parameters for AVS assessments
The storage engine used in AVS is vSAN. vSAN storage policies define storage
requirements for your virtual machines. These policies guarantee the required level of
service for your VMs because they determine how storage is allocated to the VM. These
are the available FTT-Raid Combinations:


200GB.

Coding) 133.33GB

300GB.

Coding) 150GB.

400GB.
Best practices for confidence ratings

When you run performance-based assessments, a confidence rating from 1-star (lowest)
to 5-star (highest) is awarded to the assessment. To use confidence ratings effectively:
Azure VM and AVS assessments need:

The CPU and memory utilization data for each of the servers
The read/write IOPS/throughput data for each disk attached to the on-premises
server
The network in/out data for each network adapter attached to the server.
Azure SQL assessments need the performance data of the SQL instances and
databases being assessed, which include:
The CPU and memory utilization data
The read/write IOPS/throughput data of data and Log files
The latency of IO operations
Depending on the percentage of data points available for the selected duration, the
confidence rating for an assessment is provided as summarized in the following table.
0%-20% 1 Star
21%-40% 2 Star
41%-60% 3 Star
61%-80% 4 Star
81%-100% 5 Star
Common assessment issues

Here's how to address some common environment issues that affect assessments.
Out-of-sync assessments
If you add or remove servers from a group after you create an assessment, the
assessment you created will be marked out-of-sync. Run the assessment again
(Recalculate) to reflect the group changes.
Outdated assessments
Azure VM assessment and AVS assessment

If there are changes on the on-premises servers that are in a group that's been assessed,
the assessment is marked outdated. An assessment can be marked as “Outdated”
because of one or more changes in below properties:
Number of processor cores

Allocated memory
Boot type or firmware
Operating system name, version and architecture
Number of disks
Number of network adaptor
Disk size change(GB Allocated)
Nic properties update. Example: Mac address changes, IP address addition etc.
Run the assessment again (Recalculate) to reflect the changes.

If there are changes to on-premises SQL instances and databases that are in a group
that's been assessed, the assessment is marked outdated. An assessment can be marked
as “Outdated” because of one or more reasons below:
SQL instance was added or removed from a server
SQL database was added or removed from a SQL instance
Total database size in a SQL instance changed by more than 20%
Change in number of processor cores
Change in allocated memory
Azure App Service assessment
If there are changes to on-premises web apps that are in a group that's been assessed,
the assessment is marked outdated. An assessment can be marked as “Outdated”
because of one or more reasons below:
Web apps were added or removed from a server
Configuration changes made to existing web apps.
Low confidence rating

An assessment might not have all the data points for many reasons:
You did not profile your environment for the duration for which you are creating
the assessment. For example, if you are creating an assessment with performance
discovery for all the data points to get collected. If you cannot wait for the
duration, please change the performance duration to a smaller period and
'Recalculate' the assessment.
Assessment is not able to collect the performance data for some or all the servers
in the assessment period. For a high confidence rating, please ensure that:
Servers are powered on during the assessment
For Hyper-V Servers dynamic memory is enabled
The connection status of agents in Azure Migrate are 'Connected' and check the
last heartbeat
instances is "Connected" in the discovered SQL instance blade
Please 'Recalculate' the assessment to reflect the latest changes in confidence

rating.
For Azure VM and AVS assessments, few servers were created after discovery had
started. For example, if you are creating an assessment for the performance history
of last one month, but few servers were created in the environment only a week
ago. In this case, the performance data for the new servers will not be available for
the entire duration and the confidence rating would be low.
discovery had started. For example, if you are creating an assessment for the
performance history of last one month, but few SQL instances or databases were
the new servers will not be available for the entire duration and the confidence
rating would be low.
Migration Tool Guidance for AVS assessments

In the Azure readiness report for Azure VMware Solution (AVS) assessment, you can see
the following suggested tools:
VMware HCX or Enterprise: For VMware servers, VMware Hybrid Cloud Extension
(HCX) solution is the suggested migration tool to migrate your on-premises
workload to your Azure VMware Solution (AVS) private cloud. Learn More.
unknown. Though, for servers in VMware environment, its is recommended to use
the VMware Hybrid Cloud Extension (HCX) solution.
Next steps
Learn how assessments are calculated.
Learn how to customize an assessment.
Build migration plan with Azure Migrate
Article • 05/05/2023
Follow this article to build your migration plan to Azure with Azure Migrate.
Define cloud migration goals

Before you start, understanding and evaluating your motivation for moving to the cloud
can contribute to a successful business outcome. As explained in the Cloud Adoption
Framework, there are a number of triggers and outcomes.
Business event Migration outcome
Datacenter exit Cost
Merger, acquisition, or divestiture Reduction in vendor/technical

complexity
Reduction in capital expenses Optimization of internal operations
End of support for mission-critical technologies Increase in business agility
Response to regulatory compliance changes Preparation for new technical capabilities
New data sovereignty requirements Scaling to meet market demands
Reduction in disruptions, and IT stability Scaling to meet geographic demands

improvements
Identifying your motivation helps you to pin down your strategic migration goals. The
next step is to identify and plan a migration path that's tailored for your workloads. The
Azure Migrate: Discovery and Assessment tool helps you to assess on-premises
workloads, and provides guidance and tools to help you migrate.
Understand your digital estate

Start by identifying your on-premises infrastructure, applications, and dependencies.
This helps you to identify workloads for migration to Azure, and to gather optimized
cost projections. The Discovery and assessment tool helps you to identify the workloads
you have in use, dependencies between workloads, and workload optimization.
Workloads in use
Azure Migrate uses a lightweight Azure Migrate appliance to perform agentless
discovery of on-premises VMware VMs, Hyper-V VMs, other virtualized servers, and
physical servers. Continuous discovery collects server configuration information, and
performance metadata, and application data. Here's what the appliance collects from
on-premises servers:
Server, disk, and NIC metadata.
Installed applications, roles, and features.
Performance data, including CPU and memory utilization, disk IOPS, and
throughput.
After collecting data, you can export the application inventory list to find apps, and SQL
Server instances running on your servers. You can use the Azure Migrate: Database
Assessment tool to understand SQL Server readiness.
Along with data discovered with the Discovery and assessment tool, you can use your
Configuration Management Database (CMDB) data to build a view of your server and
database estate, and to understand how your servers are distributed across business
units, application owners, geographies, etc. This helps decide which workloads to
prioritize for migration.
Dependencies between workloads

After server discovery, you can analyze dependencies, to visualize and identify cross-
server dependencies, and optimization strategies for moving interdependent servers to
Azure. The visualization helps to understand whether certain servers are in use, or if they
can be decommissioned, instead of being migrated. Analyzing dependencies helps
ensure that nothing is left behind, and to surprise outages during migration. With your
application inventory and dependency analysis done, you can create high-confidence
groups of servers, and start assessing them.
Optimization and sizing
Azure provides flexibility to resize your cloud capacity over time, and migration provides
an opportunity for you to optimize the CPU and memory resources allocated to your
servers. Creating an assessment on servers you've identity helps you to understand your
workload performance history. This is crucial for right sizing Azure VM SKUs, and disk
recommendations in Azure.
Assess migration readiness
Readiness/suitability analysis
You can export the assessment report, and filter on these categories to understand
Azure readiness:
Ready for Azure: Servers can be migrated as-is to Azure, without any changes.
Conditionally ready for Azure: Servers can be migrated to Azure, but need minor
changes, in accordance with the remediation guidance provided in the assessment.
Not ready for Azure: Servers can't be migrated to Azure as-is. Issues must be fixed
in accordance with remediation guidance, before migration.
Readiness unknown: Azure Migrate can't determine server readiness, because of
insufficient metadata.
Using database assessments, you can assess the readiness of your SQL Server data
estate for migration to Azure SQL Database, or Azure SQL Managed Instances. The
assessment shows migration readiness status percentage for each of your SQL server
instances. In addition, for each instance you can see the recommended target in Azure,
potential migration blockers, a count of breaking changes, readiness for Azure SQL DB
or Azure SQL VM, and a compatibility level. You can dig deeper to understand the
impact of migration blockers, and recommendations for fixing them.
Sizing Recommendations
After a server is marked as ready for Azure, Discovery and assessment makes sizing
recommendations that identify the Azure VM SKU and disk type for your servers. You
can get sizing recommendations based on performance history (to optimize resources
as you migrate), or based on on-premises server settings, without performance history.
In a database assessment, you can see recommendations for the database SKU, pricing
tier, and compute level.
Get compute costs

Performance-based sizing option in Azure Migrate assessments helps you to right-size
VMs, and should be used as a best practice for optimizing workloads in Azure. In
addition to right-sizing, there are a few other options to help save Azure costs:
Reserved Instances: With reserved instances(RI) , you can significantly reduce
costs compared to pay-as-you-go pricing .
Azure Hybrid Benefit: With Azure Hybrid Benefit , you can bring on-premises
Windows Server licenses with active Software Assurance, or Linux subscriptions, to
Azure, and combine with reserved instances options.
Enterprise Agreement: Azure Enterprise Agreements (EA) can offer savings for
Azure subscriptions and services.
Offers: There are multiple Azure Offers . For example, Pay-As-You-Go Dev/Test ,
or Enterprise Dev/Test offer , to provide lower rates for dev/test VMs
VM uptime: You can review days per month and hours per day in which Azure VMs
run. Shutting off servers when they're not in use can reduce your costs (not
applicable for RIs).
Target region: You can create assessments in different regions, to figure out
whether migrating to a specific region might be more cost effective.
Visualize data
You can view Discovery and assessment reports (with Azure readiness information, and
monthly cost distribution) in the portal. You can also export assessment, and enrich your
migration plan with additional visualizations. You can create multiple assessments, with
different combinations of properties, and choose the set of properties that work best for
your business.
Evaluate gaps/blockers
As you figure out the apps and workloads you want to migrate, identify downtime
constraints for them, and look for any operational dependencies between your apps and
the underlying infrastructure. This analysis helps you to plan migrations that meet your
recovery time objective (RTO), and ensure minimal to zero data loss. Before you migrate,
we recommend that you review and mitigate any compatibility issues, or unsupported
features that may block server/SQL database migration. The Azure Migrate Discovery
and assessment report, and Azure Migrate Database Assessment, can help with this.
Prioritize workloads
After you've collected information about your inventory, you can identify which apps
and workloads to migrate first. Develop an “apply and learn” approach to migrate apps
in a systematic and controllable way, so that you can iron out any flaws before starting a
full-scale migration.
To prioritize migration order, you can use strategic factors such as complexity, time-to-
migrate, business urgency, production/non-
production considerations, compliance, security requirements, application knowledge, etc.
A few recommendations:
Prioritize quick wins: Use the assessment reports to identify low-hanging fruit,
including servers and databases that are fully ready, and require minimal effort to
migrate to Azure. The table summarizes a few ways to do this.
State Action
Azure Export the assessment report, and filter all servers with state Ready for Azure.
ready VMs This might be the first group of servers that you lift and shift to Azure, using
the Migration and modernization tool.
End-of- Export the assessment report, and filter all servers running Windows
support Server 2008 R2/Windows Server 2008. These operating systems are at the end
operating of support, and only Azure provides a free three years of security updates
systems when you migrate them to Azure. If you combine Azure Hybrid Benefit, and
use RIs, the savings could be higher.
SQL Server Use the database assessment recommendations to migrate databases that
migration are ready for Azure SQL Database, using the Azure Migrate: Database
Migration tool. Migrate the databases ready for Azure SQL VM using the
End-of- Export your application inventory, and filter for any software/extensions that
support might be reaching end-of-support. Prioritize these applications for migration.
software
Under- Export the assessment report, and filter for servers with low CPU utilization
provisioned (%) and memory utilization (%). Migrate to a right-sized Azure VM, and save
servers on costs for underutilized resources.
State Action
Over- Export the assessment report and filter for servers with high CPU utilization
provisioned (%) and memory utilization (%). Solve capacity constraints, prevent
servers overstrained servers from breaking, and increase performance by migrating
these servers to Azure. In Azure, use autoscaling capabilities to meet
demand.
Analyze assessment reports to investigate storage constraints. Analyze disk

IOPS and throughput, and the recommended disk type.
Start small, then go big: Start by moving apps and workloads that present minimal
risk and complexity, to build confidence in your migration strategy. Analyze Azure
Migrate assessment recommendations together with your CMDB repository, to
find and migrate dev/test workloads that might be candidates for pilot migrations.
Feedback and learnings from pilot migrations can be helpful as you begin
migrating production workloads.
Comply: Azure maintains the largest compliance portfolio in the industry, in terms
of breadth and depth of offerings. Use compliance requirements to prioritize
migrations, so that apps and workloads comply with your national/regional and
industry-specific standards and laws. This is especially true for organizations that
deal with business-critical process, hold sensitive information, or are in heavily
regulated industries. In these types of organizations, standards and regulations
abound, and might change often, being difficult to keep up with.
Finalize the migration plan

Before finalizing your migration plan, make sure you consider and mitigate other
potential blockers, as follows:
Network requirements: Evaluate network bandwidth and latency constraints,

which might cause unforeseen delays and disruptions to migration replication
speed.
Testing/post-migration tweaks: Allow a time buffer to conduct performance and
user acceptance testing for migrated apps, or to configure/tweak apps post-
migration, such as updating database connection strings, configuring web servers,
performing cut-overs/cleanup etc.
Permissions: Review recommended Azure permissions, and server/database access
roles and permissions needed for migration.
Training: Prepare your organization for the digital transformation. A solid training
foundation is important for successful organizational change. Check out free
Microsoft Learn training, including courses on Azure fundamentals, solution
architectures, and security. Encourage your team to explore Azure certifications.
Implementation support: Get support for your implementation if you need it.
Many organizations opt for outside help to support their cloud migration. To move
to Azure quickly and confidently with personalized assistance, consider an Azure
Expert Managed Service Provider , or FastTrack for Azure .
Create an effective cloud migration plan that includes detailed information about the
apps you want to migrate, app/database availability, downtime constraints, and
migration milestones. The plan considers how long the data copy takes, and include a
realistic buffer for post-migration testing, and cut-over activities.
A post-migration testing plan should include functional, integration, security, and

performance testing and use cases, to ensure that migrated apps work as expected, and
that all database objects, and data relationships, are transferred successfully to the
cloud.
Build a migration roadmap, and declare a maintenance window to migrate your apps
and databases with minimal to zero downtime, and limit the potential operational and
business impact during migration.
Migrate
We recommend that you run a test migration in Azure Migrate, before starting a full-
scale migration. A test migration helps you to estimate the time involved, and tweak
your migration plan. It provides an opportunity to discover any potential issues, and fix
them before the full migration.
When you're ready for migration, use the Migration and modernization tool, and the
Azure Data Migration Service (DMS), for a seamless and integrated migration
experience, with end-to-end tracking.
With the Migration and modernization tool, you can migrate on-premises VMs and
servers, or VMs located in other private or public cloud (including AWS, GCP) with
around zero downtime.
Azure DMS provides a fully managed service that's designed to enable seamless
migrations from multiple database sources to Azure Data platforms, with minimal
downtime.
Next steps
Get a quick overview of Azure Migrate, and watch a getting started video .
Learn more about assessing VMs for migration to Azure VMs.
Support matrix for VMware vSphere
migration
This article summarizes support settings and limitations for migrating VMware vSphere
VMs with Migration and modernization . If you're looking for information about
assessing VMware vSphere VMs for migration to Azure, review the assessment support
matrix.
Migration options
You can migrate VMware vSphere VMs in a couple of ways:
Using agentless migration: Migrate VMs without needing to install anything on

them. You deploy the Azure Migrate appliance for agentless migration.
Using agent-based migration: Install an agent on the VM for replication. For
agent-based migration, you deploy a replication appliance.
Review this article to figure out which method you want to use.
Agentless migration
This section summarizes requirements for agentless VMware vSphere VM migration to
Azure.
VMware vSphere requirements (agentless)

The table summarizes VMware vSphere hypervisor requirements.
VMware Details
VMware Version 5.5, 6.0, 6.5, 6.7, 7.0.

vCenter
Server
VMware Version 5.5, 6.0, 6.5, 6.7, 7.0.

vSphere
ESXi host
VMware Details
vCenter Agentless migration uses the Migrate Appliance. The appliance needs these
Server permissions in vCenter Server:
permissions
- Datastore.Browse (Datastore -> Browse datastore): Allow browsing of VM log
files to troubleshoot snapshot creation and deletion.
- Datastore.FileManagement (Datastore -> Low level file operations): Allow

read/write/delete/rename operations in the datastore browser, to troubleshoot
snapshot creation and deletion.
- VirtualMachine.Config.ChangeTracking (Virtual machine -> Disk change

tracking): Allow enable or disable change tracking of VM disks, to pull changed
blocks of data between snapshots.
- VirtualMachine.Config.DiskLease (Virtual machine -> Disk lease): Allow disk lease

operations for a VM, to read the disk using the VMware vSphere Virtual Disk
Development Kit (VDDK).
- VirtualMachine.Provisioning.DiskRandomRead (Virtual machine -> Provisioning

-> Allow read-only disk access): Allow opening a disk on a VM, to read the disk
using the VDDK.
- VirtualMachine.Provisioning.DiskRandomAccess (Virtual machine ->

Provisioning -> Allow disk access): Allow opening a disk on a VM, to read the disk
using the VDDK.
- VirtualMachine.Provisioning.GetVmFiles (Virtual machine -> Provisioning ->

Allow virtual machine download): Allows read operations on files associated with a
VM, to download the logs and troubleshoot if failure occurs.
- VirtualMachine.State.* (Virtual machine -> Snapshot management): Allow

creation and management of VM snapshots for replication.
- VirtualMachine.Interact.PowerOff (Virtual machine > Interaction > Power off):

Allow the VM to be powered off during migration to Azure.
Multiple A single appliance can connect to up to 10 vCenter Servers.

vCenter
Servers
VM requirements (agentless)
The table summarizes agentless migration requirements for VMware vSphere VMs.
Support Details
Support Details
Supported operating You can migrate Windows and Linux operating systems supported by
systems Azure.
Windows VMs in You might need to make some changes on VMs before migration.
Azure
Linux VMs in Azure Some VMs might require changes so that they can run in Azure.
For Linux, Azure Migrate makes the changes automatically for these
operating systems:
- Red Hat Enterprise Linux 8.x, 7.x, 6.x
- Cent OS 8.x, 7.x, 6.x
- SUSE Linux Enterprise Server 15 SP0, 15 SP1, 12, 11 SP4, 11 SP3
- Ubuntu 20.04, 19.04, 19.10, 14.04LTS, 16.04LTS, 18.04LTS
- Debian 10, 9, 8, 7
- Oracle Linux 8, 7.7-CI, 7.7, 6
For other operating systems, you make the required changes manually.
The SELinux Enforced setting is currently not fully supported. It causes
Dynamic IP setup and Microsoft Azure Linux Guest agent
(waagent/WALinuxAgent) installation to fail. You can still migrate and
use the VM.
Boot requirements If /boot is on a dedicated partition, it should reside on the OS disk, and
not be spread across multiple disks.
If /boot is part of the root (/) partition, then the '/' partition should be
on the OS disk, and not span other disks.
UEFI boot Supported. UEFI-based VMs will be migrated to Azure generation 2

VMs.
Disk size Up to 2-TB OS disk for gen 1 VM and gen 2 VMs; 32 TB for data disks.
Disk limits Up to 60 disks per VM.
Encrypted VMs with encrypted disks/volumes aren't supported for migration.

disks/volumes
Shared disk cluster Not supported.
Independent disks Not supported.
RDM/passthrough If VMs have RDM or passthrough disks, these disks won't be replicated
disks to Azure.
NFS NFS volumes mounted as volumes on the VMs won't be replicated.
iSCSI targets VMs with iSCSI targets aren't supported for agentless migration.
Multipath IO Not supported.

Support Details
Storage vMotion Supported.
Teamed NICs Not supported.
IPv6 Not supported.
Target disk VMs can be migrated only to managed disks (standard HDD, standard
SSD, premium SSD) in Azure.
Simultaneous Up to 300 simultaneously replicating VMs per vCenter Server with one
replication appliance. Up to 500 simultaneously replicating VMs per vCenter Server
when an additional scale-out appliance is deployed.
Automatic installation Supported for Windows Server 2008 R2 onwards.

of Azure VM agent Supported for RHEL6, RHEL7, CentOS7, Ubuntu 14.04, Ubuntu 16.04,
(Windows and Linux Ubuntu18.04, Ubuntu 19.04, Ubuntu 19.10, Ubuntu 20.04.
Agent)
７ Note
Ensure that the following special characters are not passed in any credentials as
they are not supported for SSO passwords:
Non-ASCII characters. Learn more .

Ampersand (&)
Semicolon (;)
Double quotation mark (")
Single quotation mark (')
Circumflex (^)
Backslash (\)
Percentage (%)
Angle brackets (<,>)
Pound (£)
７ Note
In addition to the Internet connectivity, for Linux VMs, ensure that the following
packages are installed for successful installation of Microsoft Azure Linux agent
(waagent):
Python 2.6+
OpenSSL 1.0+
OpenSSH 5.3+
Filesystem utilities: sfdisk, fdisk, mkfs, parted
Password tools: chpasswd, sudo
Text processing tools: sed, grep
Network tools: ip-route
 Tip
Using the Azure portal you'll be able to select up to 10 VMs at a time to configure
replication. To replicate more VMs you can use the portal and add the VMs to be
replicated in multiple batches of 10 VMs, or use the Azure Migrate PowerShell
interface to configure replication. Ensure that you don't configure simultaneous
replication on more than the maximum supported number of VMs for simultaneous
replications.
Appliance requirements (agentless)

Agentless migration uses the Azure Migrate appliance. You can deploy the appliance as
a VMware vSphere VM using an OVA template, imported into vCenter Server, or using a
PowerShell script.
Learn about appliance requirements for VMware vSphere.

clouds.
In Azure Government, you must deploy the appliance using the script.
Port requirements (agentless)
Device Connection
Appliance Outbound connections on port 443 to upload replicated data to Azure, and to
communicate with Azure Migrate services orchestrating replication and migration.
vCenter Inbound connections on port 443 to allow the appliance to orchestrate replication -
Server create snapshots, copy data, release snapshots.
vSphere Inbound on TCP port 902 for the appliance to replicate data from snapshots.
ESXi host Outbound port 902 from ESXi host.
Agent-based migration
This section summarizes requirements for agent-based migration.
VMware vSphere requirements (agent-based)

This table summarizes assessment support and limitations for VMware vSphere
virtualization servers.
VMware Details
vSphere
requirements
VMware Version 5.5, 6.0, 6.5, or 6.7.

vCenter Server
VMware Version 5.5, 6.0, 6.5, 6.7 or 7.0.

vSphere ESXi
host
VMware Details
vSphere
requirements
vCenter Server VM discovery: At least a read-only user

permissions
Data Center object –> Propagate to Child Object, role=Read-only.
Replication: Create a role (Azure Site Recovery) with the required permissions,
and then assign the role to a VMware vSphere user or group
Data Center object –> Propagate to Child Object, role=Azure Site Recovery
Datastore -> Allocate space, browse datastore, low-level file operations, remove
file, update virtual machine files
Network -> Network assign
Resource -> Assign VM to resource pool, migrate powered off VM, migrate
powered on VM
Tasks -> Create task, update task
Virtual machine -> Configuration
Virtual machine -> Interact -> answer question, device connection, configure
CD media, configure floppy media, power off, power on, VMware tools install
Virtual machine -> Inventory -> Create, register, unregister
Virtual machine -> Provisioning -> Allow virtual machine download, allow
virtual machine files upload
Virtual machine -> Snapshots -> Remove snapshots.
Note:
User assigned at datacenter level, and has access to all the objects in the
datacenter.
To restrict access, assign the No access role with the Propagate to child object,
to the child objects (vSphere hosts, datastores, VMs, and networks).
VM requirements (agent-based)
The table summarizes VMware vSphere VM support for VMware vSphere VMs you want
to migrate using agent-based migration.
Support Details
Machine Azure Migrate supports migration of any workload (say Active Directory, SQL
workload server, etc.) running on a supported machine.
Operating For the latest information, review the operating system support for Site
systems Recovery. Azure Migrate provides identical VM operating system support.
Linux file For the latest information, review the Linux file system support for Site
system/guest Recovery. Azure Migrate has identical Linux file system support.
storage
Network/Storage For the latest information, review the network and storage prerequisites for
Site Recovery. Azure Migrate provides identical network/storage
requirements.
Azure For the latest information, review the Azure network, storage, and compute
requirements requirements for Site Recovery. Azure Migrate has identical requirements for
VMware migration.
Mobility service The Mobility service agent must be installed on each VM you want to
migrate.
UEFI boot Supported. UEFI-based VMs will be migrated to Azure generation 2 VMs.
UEFI - Secure Not supported for migration.

boot
Target disk VMs can only be migrated to managed disks (standard HDD, standard SSD,
premium SSD) in Azure.
Disk size up to 2-TB OS disk for gen 1 VM; up to 4-TB OS disk for gen 2 VM; 32 TB for
data disks.
Disk limits Up to 63 disks per VM.
Encrypted VMs with encrypted disks/volumes aren't supported for migration.

disks/volumes
Shared disk Not supported.

cluster
Independent Supported.
disks
Passthrough Supported.
disks
iSCSI targets Supported.

Support Details
Storage vMotion Supported
IPv6 Not supported.
Appliance requirements (agent-based)

When you set up the replication appliance using the OVA template provided in the
Azure Migrate hub, the appliance runs Windows Server 2016 and complies with the
support requirements. If you set up the replication appliance manually on a physical
server, then make sure that it complies with the requirements.
Learn about replication appliance requirements for VMware vSphere.

Install MySQL on the appliance. Learn about installation options.
Learn about URLs that the replication appliance needs to access in public and
government clouds.
Review the ports the replication appliance needs to access.
Port requirements (agent-based)
Device Connection
VMs The Mobility service running on VMs communicates with the on-premises
replication appliance (configuration server) on port HTTPS 443 inbound, for
replication management.
VMs send replication data to the process server (running on the configuration server
machine) on port HTTPS 9443 inbound. This port can be modified.
Replication The replication appliance orchestrates replication with Azure over port HTTPS 443
appliance outbound.
Process The process server receives replication data, optimizes, and encrypts it, and sends it
server to Azure storage over port 443 outbound.
By default the process server runs on the replication appliance.
Azure VM requirements
All on-premises VMs replicated to Azure (with agentless or agent-based migration) must
meet the Azure VM requirements summarized in this table.
Component Requirements
Guest Verifies supported VMware VM operating systems for migration.

operating You can migrate any workload running on a supported operating system.
system
Guest 64-bit.
operating
system
architecture
Operating Up to 2,048 GB.

system disk
size
Operating 1
system disk
count
Data disk 64 or less.

count
Data disk size Up to 32 TB
Network Multiple adapters are supported.

adapters
Shared VHD Not supported.
FC disk Not supported.
BitLocker Not supported.
BitLocker must be disabled before you migrate the machine.
VM name From 1 to 63 characters.
Restricted to letters, numbers, and hyphens.
The machine name must start and end with a letter or number.
Component Requirements
Connect after To connect to Azure VMs running Windows after migration:

migration-
Windows - Before migration, enable RDP on the on-premises VM.
Make sure that TCP and UDP rules are added for the Public profile, and that RDP
is allowed in Windows Firewall > Allowed Apps for all profiles.
For site-to-site VPN access, enable RDP and allow RDP in Windows Firewall >
Allowed apps and features for Domain and Private networks.
In addition, check that the operating system's SAN policy is set to OnlineAll.
Learn more.
Connect after To connect to Azure VMs after migration using SSH:

migration-
Linux Before migration, on the on-premises machine, check that the Secure Shell
service is set to Start, and that firewall rules allow an SSH connection.
After failover, on the Azure VM, allow incoming connections to the SSH port for
the network security group rules on the failed over VM, and for the Azure subnet
to which it's connected.
In addition, add a public IP address for the VM.
Next steps
Select a VMware vSphere migration option.
Support matrix for Hyper-V migration
This article summarizes support settings and limitations for migrating Hyper-V VMs with
Migration and modernization . If you're looking for information about assessing Hyper-
V VMs for migration to Azure, review the assessment support matrix.
Migration limitations
You can select up to 10 VMs at once for replication. If you want to migrate more
machines, replicate in groups of 10.
Hyper-V host requirements

Support Details
Deployment The Hyper-V host can be standalone or deployed in a cluster.

Azure Migrate replication software (Hyper-V Replication provider) is installed on
the Hyper-V hosts.
Permissions You need administrator permissions on the Hyper-V host.
Host Windows Server 2022, Windows Server 2019, Windows Server 2016, or Windows
operating Server 2012 R2 with latest updates. Note that Server core installation of these
system operating systems is also supported.
Other .NET Framework 4.7 or later

Software
requirements
Port access Outbound connections on HTTPS port 443 to send VM replication data.
Hyper-V VMs
Support Details
Operating system All Windows and Linux operating systems that are supported by Azure.
Windows Server For VMs running Windows Server 2003, you need to install Hyper-V
2003 Integration Services before migration.
Support Details
Linux VMs in Some VMs might require changes so that they can run in Azure.
Azure
For Linux, Azure Migrate makes the changes automatically for these
operating systems:
- Red Hat Enterprise Linux 8.x, 7.9, 7.8, 7.7, 7.6, 7.5, 7.4, 7.0, 6.x
- Cent OS 8.x, 7.7, 7.6, 7.5, 7.4, 6.x
- SUSE Linux Enterprise Server 15 SP0, 15 SP1, 12, 11 SP4, 11 SP3
- Ubuntu 20.04, 19.04, 19.10, 18.04LTS, 16.04LTS, 14.04LTS
- Debian 10, 9, 8, 7
- Oracle Linux 8, 7.7-CI, 7.7, 6
For other operating systems, you make the required changes manually.
Required changes Some VMs might require changes so that they can run in Azure. Make
for Azure adjustments manually before migration. The relevant articles contain
instructions about how to do this.
Linux boot If /boot is on a dedicated partition, it should reside on the OS disk, and not
be spread across multiple disks.
If /boot is part of the root (/) partition, then the '/' partition should be on the
OS disk, and not span other disks.
UEFI boot Supported. UEFI-based VMs will be migrated to Azure generation 2 VMs.

boot
Disk size Up to 2 TB OS disk for gen 1 VM; up to 4 TB OS disk for gen 2 VM; 32 TB for
data disks.
For existing Azure Migrate projects, you may need to upgrade the
replication provider on the Hyper-V host to the latest version to replicate
large disks up to 32 TB.
Disk number A maximum of 16 disks per VM.
Encrypted Not supported for migration.

disks/volumes
RDM/passthrough Not supported for migration.

disks
Shared disk VMs using shared disks aren't supported for migration.
ISCSI VMs with iSCSI targets aren't supported for migration.
Target disk You can migrate to Azure VMs with managed disks only.
Support Details
IPv6 Not supported.
NIC teaming Not supported.
Azure Site You can't replicate using Migration and modernization if the VM is enabled
Recovery for replication with Azure Site Recovery.
Ports Outbound connections on HTTPS port 443 to send VM replication data.
URL access (public cloud)

The replication provider software on the Hyper-V hosts will need access to these URLs.
URL Details
login.microsoftonline.com Access control and identity management using

Active Directory.
backup.windowsazure.com Replication data transfer and coordination.
*.hypervrecoverymanager.windowsazure.com Used for replication management.
*.blob.core.windows.net Upload data to storage accounts.
dc.services.visualstudio.com Upload app logs used for internal monitoring.
time.windows.com Verifies time synchronization between system and

global time.
URL access (Azure Government)

The replication provider software on the Hyper-V hosts will need access to these URLs.
URL Details
login.microsoftonline.us Access control and identity management using

Active Directory.
backup.windowsazure.us Replication data transfer and coordination.
*.hypervrecoverymanager.windowsazure.us Used for replication management.
*.blob.core.usgovcloudapi.net Upload data to storage accounts.
dc.services.visualstudio.com Upload app logs used for internal monitoring.

URL Details
time.nist.gov Verifies time synchronization between system and

global time.
７ Note
If your Migrate project has private endpoint connectivity, the replication provider
software on the Hyper-V hosts will need access to these URLs for private link
support.
*.blob.core.windows.com - To access storage account that stores replicated

data. This is optional and is not required if the storage account has a private
endpoint attached.
login.windows.net for access control and identity management using Active
Directory.
Replication storage account requirements

This table summarizes support for the replication storage account for Hyper-V VM
migrations.
Setting Support Details
General Supported GPv2 storage accounts may incur higher transaction costs than V1
purpose V2 storage accounts.
storage
accounts
(Hot and
Cool tier)
Premium Supported However, standard storage accounts are recommended to help

storage optimize costs.
Region Same Storage account should be in the same region as the virtual machine
region as being protected.
virtual
machine
Setting Support Details
Subscription Can be The Storage account need not be in the same subscription as the
different source virtual machine(s).
from
source
virtual
machines
Azure Supported If you are using firewall enabled replication storage account or target
Storage storage account, ensure you Allow trusted Microsoft services. Also,
firewalls for ensure that you allow access to at least one subnet of source VNet.
virtual You should allow access from All networks for public endpoint
networks connectivity.
Soft delete Not Soft delete is not supported because once it is enabled on replication
supported storage account, it increases cost. Azure Migrate performs very
frequent creates/deletes of log files while replicating causing costs to
increase.
Private Supported Follow the guidance to set up Azure Migrate with private endpoints.
endpoint
All on-premises VMs replicated to Azure must meet the Azure VM requirements
summarized in this table.
Component Requirements Details
Operating Up to 2,048 GB. Check fails if

system disk unsupported.
size
Operating 1 Check fails if

count
Data disk 16 or less. Check fails if

count unsupported.
Data disk Up to 4,095 GB Check fails if

size unsupported.

adapters
Shared VHD Not supported. Check fails if

unsupported.
FC disk Not supported. Check fails if

unsupported.
BitLocker Not supported. BitLocker must

be disabled
before you
enable
replication for a
machine.
VM name From 1 to 63 characters. Update the value

Restricted to letters, numbers, and hyphens. in the machine
properties in Site
The machine name must start and end with a letter or number. Recovery.
Connect To connect to Azure VMs running Windows after migration:

after
migration- - Before migration, enable RDP on the on-premises VM. Make
Windows sure that TCP, and UDP rules are added for the Public profile,
and that RDP is allowed in Windows Firewall > Allowed Apps,
for all profiles.
- For site-to-site VPN access, enable RDP and allow RDP in

Windows Firewall -> Allowed apps and features for Domain
and Private networks. In addition, check that the operating
system's SAN policy is set to OnlineAll. Learn more.
Connect To connect to Azure VMs after migration using SSH:

after
migration- - Before migration, on the on-premises machine, check that
Linux the Secure Shell service is set to Start, and that firewall rules
allow an SSH connection.
- After migration, on the Azure VM, allow incoming

connections to the SSH port for the network security group
rules on the failed over VM, and for the Azure subnet to which
it's connected. In addition, add a public IP address for the VM.
Next steps
Migrate Hyper-V VMs for migration.
Support matrix for migration of physical
servers, AWS VMs, and GCP VMs
This article summarizes support settings and limitations for migrating physical servers,
AWS VMs, and GCP VMs to Azure with Migration and modernization . If you're looking
for information about assessing physical servers for migration to Azure, review the
assessment support matrix.
Migrating machines as physical

You can migrate on-premises machines as physical servers, using agent-based
replication. Using this tool, you can migrate a wide range of machines to Azure:
On-premises physical servers.

VMs virtualized by platforms such as Xen, KVM.
Hyper-V VMs or VMware VMs if for some reason you don't want to use the
standard Hyper-V or VMware flows.
VMs running in private clouds.
VMs running in public clouds, including Amazon Web Services (AWS) or Google
Cloud Platform (GCP).
Migration limitations
You can select up to 10 machines at once for replication. If you want to migrate more
machines, then replicate in groups of 10.
Physical server requirements

The table summarizes support for physical servers, AWS VMs, and GCP VMs that you
want to migrate using agent-based migration.
Support Details
Machine Azure Migrate supports migration of any workload (say Active Directory, SQL
workload server, etc.) running on a supported machine.
Operating For the latest information, review the operating system support for Site
systems Recovery. Azure Migrate provides identical operating system support.
Support Details
Linux file For the latest information, review the Linux file system support for Site
system/guest Recovery. Azure Migrate provides identical Linux file system support.
storage
Network/Storage For the latest information, review the network and storage prerequisites for
Site Recovery. Azure Migrate provides identical network/storage
requirements.
Azure For the latest information, review the Azure network, storage, and compute
requirements requirements for Site Recovery. Azure Migrate has identical requirements for
physical server migration.
Mobility service Install the Mobility service agent on each machine you want to migrate.
UEFI boot Supported. UEFI-based machines will be migrated to Azure generation 2 VMs.
The OS disk should have up to four partitions, and volumes should be

formatted with NTFS.

boot
Target disk Machines can be migrated only to managed disks (standard HDD, standard
SSD, premium SSD) in Azure.
Disk size up to 2-TB OS disk for gen 1 VM; up to 4-TB OS disk for gen 2 VM; 32 TB for
data disks.
Disk limits Up to 63 disks per machine.
Encrypted Machines with encrypted disks/volumes aren't supported for migration.

disks/volumes
Shared disk Not supported.

cluster
Independent Supported.
disks
Passthrough Supported.
disks
NFS NFS volumes mounted as volumes on the machines won't be replicated.
iSCSI targets Machines with iSCSI targets aren't supported for agentless migration.

Support Details
IPv6 Not supported.
PV drivers / Not supported.

XenServer tools
Replication appliance requirements

If you set up the replication appliance manually, then make sure that it complies with
the requirements summarized in the table. When you set up the Azure Migrate
replication appliance as an VMware VM using the OVA template provided in the Azure
Migrate hub, the appliance is set up with Windows Server 2016, and complies with the
support requirements.
Learn about replication appliance requirements.

Install MySQL on the appliance. Learn about installation options.
Learn about URLs the replication appliance needs to access.
All on-premises VMs replicated to Azure must meet the Azure VM requirements
summarized in this table. When Site Recovery runs a prerequisites check for replication,
the check fails if some of the requirements aren't met.
Guest Verifies supported operating systems. Check fails if

operating You can migrate any workload running on a supported unsupported.
system operating system.
Guest 64-bit. Check fails if

operating unsupported.
system
architecture
Operating Up to 2,048 GB. Check fails if

size
Operating 1 Check fails if

count
Data disk 64 or less. Check fails if

count unsupported.
Data disk Up to 32 TB Check fails if

size unsupported.

adapters
Shared VHD Not supported. Check fails if

unsupported.
FC disk Not supported. Check fails if

unsupported.
BitLocker Not supported. Disable

BitLocker
before you
enable
replication for a
machine.
VM name From 1 to 63 characters. Update the

Restricted to letters, numbers, and hyphens. value in the
machine
The machine name must start and end with a letter or number. properties in
Site Recovery.
Connect To connect to Azure VMs running Windows after migration:

after - Before migration enables RDP on the on-premises VM. Make
migration- sure that TCP, and UDP rules are added for the Public profile,
Windows and that RDP is allowed in Windows Firewall > Allowed Apps,
for all profiles.
For site-to-site VPN access, enable RDP and allow RDP in
Windows Firewall -> Allowed apps and features for Domain
and Private networks. In addition, check that the operating
system's SAN policy is set to OnlineAll. Learn more.
Connect To connect to Azure VMs after migration using SSH:

after Before migration, on the on-premises machine, check that the
migration- Secure Shell service is set to Start, and that firewall rules allow
Linux an SSH connection.
After failover, on the Azure VM, allow incoming connections to
the SSH port for the network security group rules on the failed
over VM, and for the Azure subnet to which it's connected. In
addition, add a public IP address for the VM.
Next steps
Migrate physical servers.
 Documentation

Troubleshoot Azure Migrate issues - Azure Migrate

Provides an overview of known issues in the Azure Migrate service, as well as troubleshooting tips for
common errors.
Support for VMware migration in Azure Migrate - Azure Migrate

Learn about support for VMware VM migration in Azure Migrate.
Learn about support for physical discovery and assessment with Azure Migrate Discovery and
assessment


Support for Hyper-V migration in Azure Migrate - Azure Migrate

Learn about support for Hyper-V migration with Azure Migrate.
Troubleshoot the Azure Migrate appliance - Azure Migrate

Get help to troubleshoot problems that might occur with the Azure Migrate appliance.
Show 5 more
 Training
Learning path
Migrate application workloads and data to Azure - Learn
Replication appliance
This article describes the replication appliance used by the Migration and modernization
tool when migrating VMware VMs, physical machines, and private/public cloud VMs to
Azure, using agent-based migration.
Overview
The replication appliance is deployed when you set up agent-based migration of
VMware VMs or physical servers. It's deployed as a single on-premises machine, either
as a VMware VM or a physical server. It runs:
Replication appliance: The replication appliance coordinates communications, and

manages data replication, for on-premises VMware VMs and physical servers
replicating to Azure.
Process server: The process server, which is installed by default on the replication
appliance, and does the following:
Replication gateway: It acts as a replication gateway. It receives replication data
from machines enabled for replication. It optimizes replication data with
caching, compression, and encryption, and sends it to Azure.
Agent installer: Performs a push installation of the Mobility Service. This service
must be installed and running on each on-premises machine that you want to
replicate for migration.
Appliance deployment
Used for Details
VMware VM You download OVA template from the Azure Migrate hub, and import to vCenter
agent-based Server to create the appliance VM.
migration
Physical If you don't have a VMware infrastructure, or if you can't create a VMware VM
machine using an OVA template, you download a software installer from the Azure
agent-based Migrate hub, and run it to set up the appliance machine.
migration
７ Note
If you're deploying in Azure Government, use the installation file to deploy the
replication appliance.
Appliance requirements
When you set up the replication appliance using the OVA template provided in the
Azure Migrate hub, the appliance runs Windows Server 2016 and complies with the
support requirements. If you set up the replication appliance manually on a physical
server, then make sure that it complies with the requirements.
Component Requirement
VMware
VM
appliance
PowerCLI PowerCLI version 6.0 should be installed if the replication appliance is running
on a VMware VM.
NIC type VMXNET3 (if the appliance is a VMware VM)
Hardware
settings
CPU cores 8
RAM 16 GB
Number of Two: The OS disk and the process server cache disk.
disks
Free disk 600 GB

space
(cache)
Software
settings
Operating Windows Server 2016 or Windows Server 2012 R2

system
License The appliance comes with a Windows Server 2016 evaluation license, which is valid
for 180 days.
If the evaluation period is close to expiry, we recommend that you download and
deploy a new appliance, or that you activate the operating system license of the
appliance VM.
Component Requirement
Operating English (en-us)

system
locale
TLS TLS 1.2 should be enabled.
.NET .NET Framework 4.6 or later should be installed on the machine (with strong
Framework cryptography enabled.
MySQL MySQL should be installed on the appliance.

MySQL should be installed. You can install manually, or Azure Migrate can install it
during appliance deployment.
Other apps Don't run other apps on the replication appliance.
Windows Don't enable these roles:

Server roles - Active Directory Domain Services
- Internet Information Services
- Hyper-V
Group Don't enable these group policies:

policies - Prevent access to the command prompt.
- Prevent access to registry editing tools.
- Trust logic for file attachments.
- Turn on Script Execution.
Learn more.
IIS - No pre-existing default website

- No pre-existing website/application listening on port 443
- Enable anonymous authentication
- Enable FastCGI setting
Network
settings
IP address Static
type
Ports 443 (Control channel orchestration)

9443 (Data transport)
IP address Make sure that configuration server and process server have a static IPv4 address,
and don't have NAT configured.
NIC type VMXNET3
MySQL installation
MySQL must be installed on the replication appliance machine. It can be installed using
one of these methods.
Method Details
Download and Download the MySQL application & place it in the folder C:\Temp\ASRSetup,
install manually then install manually.
When you set up the appliance, MySQL shows as already installed.
Without online Place the MySQL installer application in the folder C:\Temp\ASRSetup. When
download you install the appliance and select download and install MySQL, setup uses
the installer you added.
Download and When you install the appliance and are prompted for MySQL, select Download
install in Azure and install.
Migrate
URL access
The replication appliance needs access to these URLs in the Azure public cloud.
URL Details
*.backup.windowsazure.com Used for replicated data transfer

and coordination
*.store.core.windows.net Used for replicated data transfer

and coordination
*.blob.core.windows.net Used to access storage account

that stores replicated data
*.hypervrecoverymanager.windowsazure.com Used for replication management

operations and coordination
https://management.azure.com Used for replication management

operations and coordination.
*.services.visualstudio.com (Optional) Used for logging

purposes.
time.windows.com Used to check time

synchronization between system
and global time.
URL Details
https://login.microsoftonline.com Appliance setup needs access to

https://login.live.com these URLs. They're used for
https://graph.windows.net access control and identity
https://login.windows.net management by Azure Active
https://www.live.com Directory.
https://www.microsoft.com
https://dev.mysql.com/get/Downloads/MySQLInstaller/mysql- To complete MySQL download.

installer-community-5.7.20.0.msi In a few regions, the download
might be redirected to the CDN
URL. Ensure that the CDN URL is
also allowed if needed.
Azure Government URL access

The replication appliance needs access to these URLs in Azure Government.
URL Details
*.backup.windowsazure.us Used for replicated data transfer

and coordination
*.store.core.windows.net Used for replicated data transfer

and coordination
*.blob.core.windows.net Used to access storage account

that stores replicated data
*.hypervrecoverymanager.windowsazure.us Used for replication management

https://management.usgovcloudapi.net Used for replication management


purposes.
time.nist.gov Used to check time

and global time.
https://login.microsoftonline.com Appliance setup with OVA needs

https://login.live.com access to these URLs. They're
https://graph.windows.net used for access control and
https://login.windows.net identity management by Azure
https://www.live.com Active Directory.
URL Details

７ Note
If your Migrate project has private endpoint connectivity, you will need access to
the following URLs over and above private link access:
*.blob.core.windows.com - To access storage account that stores replicated

data. This is optional and is not required if the storage account has a private
endpoint attached.
https://management.azure.com for replication management operations
and coordination.
https://login.microsoftonline.com
https://login.windows.net
https://www.live.com and
https://www.microsoft.com for access control and identity management by
Azure Active Directory
Azure China 21Vianet (Azure China) URL access

The replication appliance needs access to these URLs.
URL Details
*.backup.windowsazure.cn Used for replicated data transfer

and coordination.
*.store.core.chinacloudapi.cn Used for replicated data transfer

and coordination.
*.blob.core.chinacloudapi.cn Used to access storage account

that stores replicated data.
*.hypervrecoverymanager.windowsazure.cn Used for replication management

URL Details
https://management.chinacloudapi.cn Used for replication management


purposes.
time.windows.cn Used to check time

and global time.
https://login.microsoftonline.cn Appliance setup with OVA needs

https://secure.aadcdn.microsoftonline-p.cn access to these URLs. They're
https://login.live.com used for access control and
https://graph.chinacloudapi.cn identity management by Azure
https://login.chinacloudapi.cn Active Directory.
https://www.live.com

Port access
Device Connection
VMs The Mobility service running on VMs communicates with the on-premises
replication appliance (configuration server) on port HTTPS 443 inbound, for
replication management.
VMs send replication data to the process server (running on the configuration server
machine) on port HTTPS 9443 inbound. This port can be modified.
appliance outbound.
Process The process server receives replication data, optimizes, and encrypts it, and sends it
By default the process server runs on the replication appliance.
Replication process
1. When you enable replication for a VM, initial replication to Azure storage begins,
using the specified replication policy.
2. Traffic replicates to Azure storage public endpoints over the internet. Replicating
traffic over a site-to-site virtual private network (VPN) from an on-premises site to
Azure isn't supported.
3. After initial replication finishes, delta replication begins. Tracked changes for a
machine are logged.
4. Communication happens as follows:
VMs communicate with the replication appliance on port HTTPS 443 inbound,
for replication management.
The replication appliance orchestrates replication with Azure over port HTTPS
443 outbound.
VMs send replication data to the process server (running on the replication
appliance) on port HTTPS 9443 inbound. This port can be modified.
The process server receives replication data, optimizes, and encrypts it, and
sends it to Azure storage over port 443 outbound.
5. The replication data logs first land in a cache storage account in Azure. These logs
are processed and the data is stored in an Azure managed disk.
Appliance upgrades
The appliance is upgraded manually from the Azure Migrate hub. We recommend that
you always run the latest version.
1. In Azure Migrate > Servers > Azure Migrate: Server Assessment, Infrastructure
servers, select Configuration servers.
2. In Configuration servers, a link appears in Agent Version when a new version of
the replication appliance is available.
3. Download the installer to the replication appliance machine, and install the
upgrade. The installer detects the version current running on the appliance.
Next steps
Learn how to set up the replication appliance for agent-based VMware VM
migration.
Learn how to set up the replication appliance for physical servers.
 Documentation




Prepare machines for agentless migration with Azure Migrate - Azure Migrate
Learn how to prepare on-premises machines for agentless migration with Azure Migrate.
assessment
Troubleshoot the Azure Migrate appliance - Azure Migrate

Get help to troubleshoot problems that might occur with the Azure Migrate appliance.
Migrate VMware vSphere VMs with agent-based the Migration and modernization
tool - Azure Migrate
Show 5 more
Azure Migrate agentless migration of
VMware virtual machines
This article describes the replication concepts when migrating VMware VMs using the
Migration and modernization tool's agentless migration method.
Replication process
The agentless replication option works by using VMware snapshots and VMware
changed block tracking (CBT) technology to replicate data from virtual machine disks.
The following block diagram shows you various steps involved when you migrate your
virtual machines using the Migration and modernization tool.
data from the snapshot disks is replicated to managed disks in your target subscription.
After initial replication for the VM is complete, the replication process transitions to an
data changes that have occurred since the beginning of the last completed replication
cycle are replicated and written to the replica managed disks, thus keeping replication in
sync with changes happening on the VM.
VMware changed block tracking (CBT) technology is used to keep track of changes
and the last successfully replicated snapshot. Only the data that has changed since the
previous completed replication cycle is replicated to keep replication for the VM in sync.
At the end of each replication cycle, the snapshot is released, and snapshot
consolidation is performed for the virtual machine.
When you perform the migrate operation on a replicating virtual machine, there's an
on-demand delta replication cycle that replicates the remaining changes since the last
replication cycle. After the on-demand cycle completes, the replica managed disks
corresponding to the virtual machine are used to create the virtual machine in Azure.
Right before triggering migrate/failover, you must shut down the on-premises virtual
machine. Shutting down the virtual machine ensures zero data loss during migration.
Once the migration is successful and the VM boots up in Azure, ensure that you stop
the replication of the VM. Stopping the replication will delete the intermediate disks
(seed disks) that were created during data replication, and you'll also avoid incurring
extra charges associated with the storage transactions on these disks.
Replication cycles
Replication cycles refer to the periodic process of transferring data from on-premises
environment to Azure managed disks. A full replication cycle consists of the following
steps:
1. Create VMware snapshot for each disk associated with the VM

2. Upload data to log storage account in Azure
3. Release snapshot
4. Consolidate VMware disks
A cycle is said to be complete once the disks are consolidated.
Components involved in replication

On-premises components: Azure Migrate appliance has the following components that
are responsible for replication
DRA agent
Gateway agent
Azure components: The following table summarizes various Azure Artifacts that are
created while using the agentless method of VMware VM migration.
Component Region Subscription Description
Recovery Azure Azure Migrate Used to orchestrate data replication

services Migrate project's
vault project's subscription
region
Component Region Subscription Description
Service Bus Target region Azure Migrate Used for communication between cloud service
project's and Azure Migrate appliance
subscription
Log storage Target region Azure Migrate Used to store replication data, which is read by
account project's the service and applied on customer's
subscription managed disk
Gateway Target region Azure Migrate Used to store machine states during replication
storage project's
account subscription
Key vault Target region Azure Migrate Manages connection strings for service bus and
project's access keys for the log storage account
subscription
Azure Target region Target VM created in Azure when you migrate

Virtual subscription
Machine
Azure Target region Target Managed disks attached to Azure VMs

Managed subscription
Disks
Network Target region Target The NICs attached to the VMs created in Azure
interface subscription
cards
Permissions required
When you start replication for the first time, the logged-in user must be assigned the
following roles:
Owner or Contributor and User Access Administrator on the Azure Migrate

project's Resource Group and the target Resource Group
For the subsequent replications, the logged-in user must be assigned the following
roles:
Owner or Contributor on the Azure Migrate project's Resource Group and the
target Resource Group
In addition to the roles described above, the logged-in user would need the following
permission at a subscription level -
Microsoft.Resources/subscriptions/resourceGroups/read
Data integrity
There are two stages in every replication cycle that ensures data integrity between the
on-premises disk (source disk) and the replica disk in Azure (target disk).
1. First, we validate if every sector that has changed in the source disk is replicated to
the target disk. Validation is performed using bitmaps. Source disk is divided into
sectors of 512 bytes. Every sector in the source disk is mapped to a bit in the
bitmap. When data replication starts, bitmap is created for all the changed blocks
(in delta cycle) in the source disk that needs to be replicated. Similarly, when the
data is transferred to the target Azure disk, a bitmap is created. Once the data
transfer completes successfully, the cloud service compares the two bitmaps to
ensure no changed block is missed. In case there's any mismatch between the
bitmaps, the cycle is considered failed. As every cycle is resynchronization, the
mismatch will be fixed in the next cycle.
2. Next we ensure that the data that's transferred to the Azure disks is the same as
the data that was replicated from the source disks. Every changed block that is
uploaded is compressed and encrypted before it's written as a blob in the log
storage account. We compute the checksum of this block before compression. This
checksum is stored as metadata along with the compressed data. Upon
decompression, the checksum for the data is calculated and compared with the
checksum computed in the source environment. If there's a mismatch, the data
isn't written to the Azure disks, and the cycle is considered failed. As every cycle is
resynchronization, the mismatch will be fixed in the next cycle.
Security
The Azure Migrate appliance compresses data and encrypts before uploading. Data is
transmitted over a secure communication channel over https and uses TLS 1.2 or later.
Additionally, Azure Storage automatically encrypts your data when it is persisted it to
the cloud (encryption-at-rest).
Replication status
When a VM undergoes replication (data copy), there are a few possible states:
Initial replication queued: The VM is queued for replication (or migration) as there
may be other VMs that are consuming the on-premises resources (during
replication or migration). Once the resources are free, this VM will be processed.
Initial replication in progress: The VM is being scheduled for initial replication.
Initial replication: The VM is undergoing initial replication. When the VM is
undergoing initial replication, you can't proceed with test migration and migration.
You can only stop replication at this stage.
Initial replication (x%): The initial replication is active and has progressed by x%.
Delta sync: The VM may be undergoing a delta replication cycle that replicates the
remaining data churn since the last replication cycle.
Pause in progress: The VM is undergoing an active delta replication cycle and will
be paused in some time.
Paused: The replication cycles have been paused. The replication cycles can be
resumed by performing a resume replication operation.
Resume queued: The VM is queued for resuming replication as there are other
VMs that are currently consuming the on-premises resources.
Resume in progress (x%): The replication cycle is being resumed for the VM and
has progressed by x%.
Stop replication in progress: Replication cleanup is in progress. When you stop
replication, the intermediate managed disks (seed disks) created during replication
will be deleted. Learn more.
Complete migration in progress: Migration cleanup is in progress. When you
complete migration, the intermediate managed disks (seed disks) created during
replication will be deleted. Learn more.
– : When the VM has successfully migrated and/or when you have stopped
replication, the status changes to “-“. Once you stop replication / complete
migration and the operation finishes successfully, the VM will be removed from the
list of replicating machines. You can find the VM in the virtual machines tab in the
replicate wizard.
Other states
Initial replication failed: The initial data couldn't be copied for the VM. Follow the
remediation guidance to resolve.
Repair pending: There was an issue in the replication cycle. You can select the link
to understand possible causes and actions to remediate (as applicable). If you had
opted for Automatically repair replication by selecting Yes when you triggered
replication of VM, the tool will try to repair it for you. Else, select the VM, and
select Repair Replication. If you didn't opt for Automatically repair replication or
if the above step didn't work for you, then stop replication for the virtual machine,
reset the changed block tracking on the virtual machine, and then reconfigure the
replication.
Repair replication queued: The VM is queued for replication repair as there are
other VMs that are consuming the on-premises resources. Once the resources are
free, the VM will be processed for repair replication.
Resync (x%): The VM is undergoing a data resynchronization. This can happen if
there was some issue / mismatch during data replication.
Stop replication/complete migration failed: Select the link to understand the
possible causes for failure and actions to remediate (as applicable).
７ Note
Some VMs are put in queued state to ensure minimal impact on the source
environment due to storage IOPS consumption. These VMs are processed based on
the scheduling logic as described in the next section.
Migration/test migration status

Test migration pending: The VM is in delta replication phase, and you can now
perform test migration (or migration).
Test migration clean up pending: After test migration is complete, perform a test
migration clean up to avoid charges in Azure.
Ready to migrate: The VM is ready to be migrated to Azure.
Migration in progress queued: The VM is queued for migration as there are other
VMs that are consuming the on-premises resources during replication (or
migration). Once the resources are free, the VM will be processed.
Test migration/Migration in progress: The VM is undergoing a test
migration/migration. You can select the link to check the ongoing migration job.
Date, timestamp: The migration/test migration date and timestamp.
–: Initial replication is in progress. You can perform a migration or test migration
after the replication process transitions to a delta sync (incremental replication)
phase.
Other states
Completed with info: The migration/test migration job completed with
information. You can select the link to check the last migration job for possible
causes and actions to remediate (as applicable).
Failed: The migration/test migration job failed. You can select the link to check the
last migration job for possible causes and actions to remediate.
Scheduling logic
Initial replication is scheduled when replication is configured for a VM. It's followed by
incremental replications (delta replications).
Delta replication cycles are scheduled as follows:
First delta replication cycle is scheduled immediately after the initial replication
cycle completes
Next delta replication cycles are scheduled according to the following logic: max
[(Previous delta replication cycle time/2), 1 hour]
That is, next delta replication will be scheduled no sooner than one hour. For example, if
a VM takes four hours for a delta replication cycle, the next delta replication cycle is
scheduled in two hours, and not in the next hour.
７ Note
The scheduling logic is different after the initial replication completes. The first
delta cycle is scheduled immediately after the initial replication completes and
subsequent cycles follow the scheduling logic described above.
When you trigger migration, an on-demand delta replication cycle (pre-failover

delta replication cycle) is performed for the VM prior to migration.
Prioritization of VMs for various stages of replication
Ongoing VM replications are prioritized over scheduled replications (new

replications)
Pre-failover (on-demand delta replication) cycle has the highest priority followed
by initial replication cycle. Delta replication cycle has the least priority.
That is, whenever a migrate operation is triggered, the on-demand replication cycle for
the VM is scheduled and other ongoing replications take back seat if they're competing
for resources.
Constraints:
We use the following constraints to ensure that we don't exceed the IOPS limits on the
SANs.
Each Azure Migrate appliance supports replication of 52 disks in parallel

Each ESXi host supports 8 disks. Every ESXi host has a 32-MB NFC buffer. So, we
can schedule 8 disks on the host (Each disk takes up 4 MB of buffer for IR, DR).
Each datastore can have a maximum of 15 disk snapshots. The only exception is
when a VM has more than 15 disks attached to it.
Scale-out replication
Azure Migrate supports concurrent replication of 500 virtual machines. When you're
planning to replicate more than 300 virtual machines, you must deploy a scale-out
appliance. The scale-out appliance is similar to an Azure Migrate primary appliance but
consists only of gateway agent to facilitate data transfer to Azure. The following diagram
shows the recommended way to use the scale-out appliance.
You can deploy the scale-out appliance anytime after configuring the primary appliance,
but isn't required until there are 300 VMs replicating concurrently. When there are 300
VMs replicating concurrently, you must deploy the scale-out appliance to proceed.
Stop replication/Complete migration

When you stop replication, the intermediate managed disks (seed disks) created during
replication will be deleted. You can stop replication only during an active replication. You
can select Complete migration to stop the replication after the VM was migrated.
The VM for which the replication is stopped, can be replicated by enabling replication
again. If the VM was migrated, you can resume replication and migration again.
As a best practice, you should always complete the migration after the VM has migrated
successfully to Azure to ensure that you don't incur extra charges for storage
transactions on the intermediate managed disks (seed disks). In some cases, you'll
notice that stop replication takes time. It's because whenever you stop replication, the
ongoing replication cycle is completed (only when the VM is in delta sync) before
deleting the artifacts.
Impact of churn
We try to minimize the amount of data transfer in each replication cycle by allowing the
data to fold as much as possible before we schedule the next cycle. Because agentless
replication folds in data, the churn pattern is more important than the churn rate. When
a file is written again and again, the rate doesn't have much impact. However, a pattern
in which every other sector is written causes high churn in the next cycle.
Management of replication
Throttling
You can increase or decrease the replication bandwidth using the NetQosPolicy. The
AppNamePrefix to use in the NetQosPolicy is "GatewayWindowsService.exe".
You could create a policy on the Azure Migrate appliance to throttle replication traffic
from the appliance by creating a policy such as this one:
New-NetQosPolicy -Name "ThrottleReplication" -AppPathNameMatchCondition

"GatewayWindowsService.exe" -ThrottleRateActionBitsPerSecond 1MB
７ Note
This is applicable to all the replicating VMs from the Azure Migrate appliance
simultaneously.
You can also increase and decrease replication bandwidth based on a schedule using the
sample script.
Blackout window
Azure Migrate provides a configuration-based mechanism through which customers can
specify the time interval during which they don't want any replications to proceed. This
time interval is called the blackout window. The need for a blackout window can arise in
multiple scenarios such as when the source environment is resource constrained or
when customers want replication to go through only during non-business hours, etc.
７ Note
The existing replication cycles at the start of the blackout window will
complete before the replication pauses.
For any migration initiated during the blackout window, the final replication
will not run, causing the migration to fail.
A blackout window can be specified for the appliance by creating/updating the file
GatewayDataWorker.json in C:\ProgramData\Microsoft Azure\Config. A typical file
would be of the form:
{
"BlackoutWindows": "List of blackout windows"
The list of blackout windows is a "|" delimited string of the format

"DayOfWeek;StartTime;Duration". The duration can be specified in days, hours, and
minutes. For example, the blackout windows can be specified as:
"BlackoutWindows": "Monday;7:00;7h | Tuesday;8:00;1d7h |

Wednesday;16:00;1d | Thursday;18:00;5h | Friday;13:00;8m"
The first value in the above example indicates a blackout window starting every Monday
at 7:00 AM local time (time on the appliance) and lasting 7 hours.
Once the GatewayDataWorker.json is created/updated with these contents, the Gateway

service on the appliance needs to be restarted for these changes to take effect.
In the scale-out scenario, the primary appliance and the scale-out appliance honor the
blackout windows independently. As a best practice, we recommend keeping the
windows consistent across appliances.
Next steps
Migrate VMware VMs with agentless migration.
Prepare for VMware agentless migration
Article • 05/01/2023
This article provides an overview of the changes performed when you migrate VMware
VMs to Azure via the agentless migration method using the Migration and
modernization tool.
Before you migrate your on-premises VM to Azure, you may require a few changes to
make the VM ready for Azure. These changes are important to ensure that the migrated
VM can boot successfully in Azure and connectivity to the Azure VM can be
established-. Azure Migrate automatically handles these configuration changes for the
following operating system versions for both Linux and Windows. This process is called
Hydration.
Operating system versions supported for hydration
Windows Server 2008 or later

Red Hat Enterprise Linux 8.x, 7.9, 7.8, 7.7, 7.6, 7.5, 7.4, 7.0, 6.x
CentOS 8.x, 7.7, 7.6, 7.5, 7.4, 6.x
SUSE Linux Enterprise Server 15 SP0, 15 SP1, 12, 11 SP4, 11 SP3
Ubuntu 20.04, 19.04, 19.10, 18.04LTS, 16.04LTS, 14.04LTS
Debian 10, 9, 8, 7
Oracle Linux 8, 7.7-CI, 7.7, 6
You can also use this article to manually prepare the VMs for migration to Azure for
operating systems versions not listed above. At a high level, these changes include:
Validate the presence of the required drivers

Enable the serial console
Configure network settings
Install the VM guest agent
Hydration process
You have to make some changes to the VMs configuration before the migration to
ensure that the migrated VMs function properly on Azure. Azure Migrate handles these
configuration changes via the hydration process. The hydration process is only
performed for the versions of Azure supported operating systems given above. Before
you migrate, you may need to perform the required changes manually for other
operating system versions that aren't listed above. If the VM is migrated without the
required changes, the VM may not boot, or you may not have connectivity to the
migrated VM. The following diagram shows you that Azure Migrate performs the
hydration process.
When a user triggers Test Migrate or Migrate, Azure Migrate performs the hydration
process to prepare the on-premises VM for migration to Azure. To set up the hydration
process, Azure Migrate creates a temporary Azure VM and attaches the disks of the
source VM to perform changes to make the source VM ready for Azure. The temporary
Azure VM is an intermediate VM created during the migration process before the final
migrated VM is created. The temporary VM will be created with a similar OS type
(Windows/Linux) using one of the marketplace OS images. If the on-premises VM is
running Windows, the operating system disk of the on-premises VM will be attached as
a data disk to the temporary VM for performing changes. If it's a Linux server, all the
disks attached to the on-premises VM will be attached as data disks to the temporary
Azure VM.
Azure Migrate will create the network interface, a new virtual network, subnet, and a
network security group (NSG) to host the temporary VM. These resources are created in
the customer's subscription. If there are conflicting policies that prevent the creation of
the network artifacts, Azure Migrate will attempt to create the temporary Azure VM in
the virtual network and subnet provided as part of the replication target settings
options.
After the virtual machine is created, Azure Migrate will invoke the Custom Script
Extension on the temporary VM using the Azure Virtual Machine REST API. The Custom
Script Extension utility will execute a preparation script containing the required
configuration for Azure readiness on the on-premises VM disks attached to the
temporary Azure VM. The preparation script is downloaded from an Azure Migrate
owned storage account. The network security group rules of the virtual network will be
configured to permit the temporary Azure VM to access the Azure Migrate storage
account for invoking the script.
Changes performed during the hydration
process
The preparation script executes the following changes based on the OS type of the
source VM to be migrated. You can also use this section as a guide to manually prepare
the VMs for migration for operating systems versions not supported for hydration.
Changes performed on Windows servers

1. Discover and prepare the Windows OS volume
Before performing relevant configuration changes, the preparation script will

validate if the correct OS disk was selected for migration. The preparation script
will look through all the attached volumes visible to the system and look for the
SYSTEM registry hive file path to find the source OS volume.
The following actions are performed in this step:
Mounts each partition on the OS disk attached to the temporary VM.
Looks for \Windows\System32\Config\System registry files after mounting

the partition.
If the files aren't found, the partition is unmounted, and the search continues
for the correct partition.
If the files aren't present on any of the partitions, it could indicate that an
incorrect OS disk was selected, or the OS disk is corrupted. Azure Migrate will
fail the migration process with an appropriate error.
７ Note
This step isn't relevant if you’re manually preparing the servers for migration.
2. Make boot and connectivity related changes
After the source OS volume files are detected, the preparation script will load the
SYSTEM registry hive into the registry editor of the temporary Azure VM and
perform the following changes to ensure VM boot up and connectivity. You need
to configure these settings manually if the OS version isn't supported for
hydration.
a. Validate the presence of the required drivers
Ensure if the required drivers are installed and are set to load at boot start.
These Windows drivers allow the server to communicate with the hardware and
other connected devices.
IntelIde.sys
Atapi
Storfit
Storvsc
VMbus
b. Set storage area network (SAN) policy to Online All
This ensures that the Windows volumes in the Azure VM use the same drive
letter assignments as the on-premises VM. 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. 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
Online All.
To manually configure this setting:
On the on-premises server, open the command prompt with elevated

privileges and 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 that you can read and write to both
disks.
3. Set the DHCP start type
The preparation script will also set the DHCP service start type as Automatic. This
will enable the migrated VM to obtain an IP address and establish connectivity
post-migration. Make sure the DHCP service is configured, and the status is
running.
To edit the DHCP startup settings manually, run the following example in Windows
PowerShell:
PowerShell
Get-Service -Name Dhcp
Where-Object StartType -ne Automatic
Set-Service -StartupType Automatic
4. Disable VMware Tools
Make “VMware Tools” service start-type to disabled if it exists as they aren't

required for the VM in Azure.
７ Note
To connect to Windows Server 2003 VMs, Hyper-V Integration Services must

be installed on the Azure VM. Windows Server 2003 machines don't have this
installed by default. See this article to install and prepare for migration.
5. Install the Windows Azure Guest Agent
Azure Migrate will attempt to install the Microsoft Azure Virtual Machine Agent
(VM Agent), 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.
Azure Migrate automatically installs the Windows VM agent on Windows Server
2008 R2 and higher versions.
The Windows VM agent can be manually installed with a Windows installer

package. To manually install the Windows VM Agent, download the VM Agent
installer . You can also search for a specific version in the GitHub Windows IaaS
VM Agent releases . The VM Agent is supported on Windows Server 2008 (64 bit)
and later.
To check if the Azure VM Agent was successfully installed, open Task Manager,
select the Details tab, and look for the process name
WindowsAzureGuestAgent.exe. The presence of this process indicates that the VM
agent is installed. You can also use PowerShell to detect the VM agent.
After the aforementioned changes are performed, the system partition will be
unloaded. The VM is now ready for migration. Learn more about the changes for
Windows servers.
Changes performed on Linux servers

1. Discover and mount Linux OS partitions
Before performing relevant configuration changes, the preparation script will

validate if the correct OS disk was selected for migration. The script will collect
information on all partitions, their UUIDs, and mount points. The script will look
through all these visible partitions to locate the /boot and /root partitions.
The following actions are performed in this step:
Discover /root partition:

Mount each visible partition and look for etc/fstab.
If the fstab files aren't found, the partition is unmounted, and the search
continues for the correct partition.
If the fstab files are found, read the fstab content to identify the root
device and mount it as the base mount point.
Discover /boot and other system partitions:
Use fstab content to determine if /boot is a separate partition. If it’s a
separate partition, then obtain the boot partition device name from the
fstab content or look for the partition, which has the boot flag.
The script will proceed to discover and mount /boot, and other necessary
partitions on “/mnt/azure_sms_root” to build the root filesystem tree
required for chroot jail. Other necessary partitions include:
/boot/grub/menu.lst, /boot/grub/grub.conf, /boot/grub2/grub.cfg,
/boot/grub/grub.cfg, /boot/efi (for UEFI boot), /var, /lib, /etc, /usr, and
others.
2. Discover OS Version
Once the root partition is discovered, the script will use the following files to
determine the Linux Operating System distribution and version.
RHEL/CentOS: etc/redhat-release
OL: etc/oracle-release
SLES: etc/SuSE-release
Ubuntu: etc/lsb-release
Debian: etc/debian_version
3. Install Hyper-V Linux Integration Services and regenerate kernel image
The next step is to inspect the kernel image and rebuild the Linux init image so,
that it contains the necessary Hyper-V drivers (hv_vmbus, hv_storvsc, hv_netvsc)
on the initial ramdisk. Rebuilding the init image ensures that the VM will boot in
Azure.
Azure runs on the Hyper-V hypervisor. So, Linux requires certain kernel modules to
run in Azure. To prepare your Linux image, you need to rebuild the initrd so that at
least the hv_vmbus and hv_storvsc kernel modules are available on the initial
ramdisk. The mechanism for rebuilding the initrd or initramfs image may vary
depending on the distribution. Consult your distribution's documentation or
support for the proper procedure. Here's one example for rebuilding the initrd by
using the mkinitrd utility:
a. Find the list of kernels installed on the system (/lib/modules)
b. For each module, inspect if the Hyper-V drivers are already included.
c. If any of these drivers are missing, add the required drivers and regenerate the
image for the corresponding kernel version.
７ Note
This step may not apply to Ubuntu and Debian VMs as the Hyper-V drivers
are built-in by default. Learn more about the changes.
An illustrative example for rebuilding initrd
Back up the existing initrd image
Bash
cd /boot
sudo cp initrd-ùname -r`.img initrd-ùname -r`.img.bak
Rebuild the initrd with the hv_vmbus and hv_storvsc kernel modules:
Bash
sudo mkinitrd --preload=hv_storvsc --preload=hv_vmbus -v -f

initrd-ùname -r`.img ùname -r`
Most new versions of Linux distributions have this included by default. If not
included, install manually for all versions except those called out, using the
aforementioned steps.
4. Enable Azure Serial Console logging
The script will then make changes to enable Azure Serial Console logging. Enabling
console logging helps with troubleshooting issues on the Azure VM. Learn more
about Azure Serial Console for Linux Azure Serial Console for Linux - Virtual
Machines | Microsoft Docs.
Modify the kernel boot line in GRUB or GRUB2 to include the following
parameters, so that all console messages are sent to the first serial port. These
messages can assist Azure support with debugging any issues.
config
console=ttyS0,115200n8 earlyprintk=ttyS0,115200 rootdelay=300
We also recommend removing the following parameters if they exist.
config
rhgb quiet crashkernel=auto

Refer to this article for specific changes.
5. Network changes for connectivity
Based on the OS Version, the script will perform the required network changes for
connectivity to the migrated VM. The changes include:
a. Move (or remove) the udev rules to avoid generating static rules for the
Ethernet interface. These rules cause problems when you clone a virtual
machine in Azure.
An illustrative example for RedHat servers
Bash
sudo ln -s /dev/null /etc/udev/rules.d/75-persistent-net-

generator.rules
sudo rm -f /etc/udev/rules.d/70-persistent-net.rules
b. Remove Network Manager if necessary. Network Manager can interfere with the
Azure Linux agent for a few OS versions. It's recommended to make these
changes for servers running RedHat and Ubuntu distributions.
c. Uninstall this package by running the following command:
Bash
sudo rpm -e --nodeps NetworkManager
d. Backup existing NIC settings and create eth0 NIC configuration file with DHCP
settings. To do this, the script will create or edit the /etc/sysconfig/network-
scripts/ifcfg-eth0 file, and add the following text:
config
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
TYPE=Ethernet
USERCTL=no
PEERDNS=yes
IPV6INIT=no
PERSISTENT_DHCLIENT=yes
NM_CONTROLLED=yes
e. Reset etc/sysconfig/network file as follows:
config
NETWORKING=yes
HOSTNAME=localhost.localdomain
6. Fstab validation
Azure Migrate will validate the entries of the fstab file and replace fstab entries
with persistent volume identifiers, UUIDs wherever needed. This ensures the
drive/partition name remains constant no matter the system it's attached to.
If the device name is a standard device name (say /dev/sdb1), then:

If it’s a root or boot partition, then it's replaced with UUID.
If the partition coexists with either the root or boot partition as standard
partitions on the same disk, then it's replaced with UUID.
If the device name is UUID/LABEL/LV, then no changes will be done.
If it’s a network device (nfs, cifs, smbfs, and etc), then the script will comment
the entry. To access it, you can uncomment the same and reboot your Azure
VM.
7. Install the Linux Azure Guest Agent
Azure Migrate will attempt to install the Microsoft Azure Linux Agent (waagent), a
secure, lightweight process that manages Linux & FreeBSD provisioning, and VM
interaction with the Azure Fabric Controller. Learn more about the functionality
enabled for Linux and FreeBSD IaaS deployments via the Linux agent.
Review the list of required packages to install Linux VM agent. Azure Migrate
installs the Linux VM agent automatically for RHEL 8.x/7.x/6.x, CentOS 8.x/7.x/6.x,
Ubuntu 14.04/16.04/18.04/19.04/19.10/20.04, SUSE 15 SP0/15 SP1/12, Debian
9/8/7, and Oracle 7 when using the agentless method of VMware migration. Follow
these instructions to install the Linux Agent manually for other OS versions.
You can use the command to verify the service status of the Azure Linux Agent to
make sure it's running. The service name might be walinuxagent or waagent. Once
the hydration changes are done, the script will unmount all the partitions mounted,
deactivate volume groups, and then flush the devices.
Bash
sudo vgchange -an <vg-name>

sudo lockdev –flushbufs <disk-device-name>
Learn more on the changes for Linux servers.
Clean up the temporary VM

After the necessary changes are performed, Azure Migrate will spin down the temporary
VM and free the attached OS disks (and data disks). This marks the end of the hydration
process.
After this, the modified OS disk and the data disks that contain the replicated data are
cloned. A new virtual machine is created in the target region, virtual network, and
subnet, and the cloned disks are attached to the virtual machine. This marks the
completion of the migration process.
Learn more
Prepare on-premises machines for migration to Azure.
How does Hyper-V replication work?
This article provides an overview of the architecture and processes used when you
migrate Hyper-V VMs with the Migration and modernization tool.
your on-premises apps and workloads, and private/public cloud VMs, to Azure. The hub
provides Azure Migrate tools for assessment and migration, as well as third-party
independent software vendor (ISV) offerings.
Agentless migration
The Migration and modernization tool provides agentless replication for on-premises
Hyper-V VMs, using a migration workflow that's optimized for Hyper-V. You install a
software agent only on Hyper-V hosts or cluster nodes. Nothing needs to be installed
on Hyper-V VMs.
Migration and modernization and Azure Site

Recovery
Migration and modernization is a tool for migrating on-premises workloads, and cloud-
based VMs, to Azure. Site Recovery is a disaster recovery tool. The tools share some
common technology components used for data replication, but serve different
purposes.
Architectural components
Component Deployment
Replication The Microsoft Azure Site Recovery provider is installed on Hyper-V hosts, and
provider registered with the Migration and modernization tool.
The provider orchestrates replication for Hyper-V VMs.
Recovery The Microsoft Azure Recovery Service agent handles data replication. It works with
Services the provider to replicate data from Hyper-V VMs to Azure.
agent The replicated data is uploaded to a storage account in your Azure subscription.
The Migration and modernization tool the processes the replicated data, and
applies it to replica disks in the subscription. The replica disks are used to create
the Azure VMs when you migrate.
Components are installed by a single setup file, downloaded from the Migration
and modernization tool in the portal.
The provider and appliance use outbound HTTPS port 443 connections to
communicate with the Migration and modernization tool.
Communications from the provider and agent are secure and encrypted.
Replication process
1. When you enable replication for a Hyper-V VM, initial replication begins.
2. A Hyper-V VM snapshot is taken.
3. VHDs on the VM are replicated one-by-one, until they're all copied to Azure. Initial
replication time depends on the VM size, and network bandwidth.
4. Disk changes that occur during initial replication are tracked using Hyper-V
Replica, and stored in log files (hrl files).
Log files are in the same folder as the disks.

Each disk has an associated hrl file that's sent to secondary storage.
The snapshot and log files consume disk resources while initial replication is
in progress.
5. After initial replication finishes, the VM snapshot is deleted, and delta replication
begins.
6. Incremental disk changes are tracked in hrl files. Replication logs are periodically
uploaded to an Azure storage account by the Recovery Services agent.
Performance and scaling

Replication performance for Hyper-V is influenced by factors that include VM size, the
data change rate (churn) of the VMs, available space on the Hyper-V host for log file
storage, upload bandwidth for replication data, and target storage in Azure.
If you're replicating multiple machines at the same time, use the Azure Site
Recovery Deployment Planner for Hyper-V, to help optimize replication.
Plan your Hyper-V replication, and distribute replication over Azure storage
accounts, in accordance with capacity.
Control upload throughput

You can limit the amount of bandwidth used to upload data to Azure on each Hyper-V
host. Be careful. If you set the values too low it will adversely impact replication, and
delay migration.
1. Sign in to the Hyper-V host or cluster node.

2. Run C:\Program Files\Microsoft Azure Recovery Services
Agent\bin\wabadmin.msc, to open the Windows Azure Backup MMC snap-in.
3. In the snap-in, select Change Properties.
4. In Throttling, select Enable internet bandwidth usage throttling for backup
operations. Set the limits for work and non-work hours. Valid ranges are from 512
Kbps to 1,023 Mbps.
Influence upload efficiency

If you have spare bandwidth for replication, and want to increase uploads, you can
increase the number of threads allocated for the upload task, as follows:
1. Open the registry with Regedit.

2. Navigate to key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Azure
Backup\Replication\UploadThreadsPerVM
3. Increase the value for the number of threads used for data upload for each
replicating VM. The default value is 4 and the max value is 32.
Next steps
Try out Hyper-V migration using the Migration and modernization tool.
Agent-based migration architecture
This article provides an overview of the architecture and processes used for agent-based
replication of VMware VMs with the Migration and modernization tool.
Using the Migration and modernization tool, you can replicate VMware VMs with a
couple of options:
Migrate VMs using agent-based replication, as described in this article.

Migrate VMware VMs using agentless replication. This migrates VMs without
needing to install anything on them.
Learn more about selecting and comparing migration methods for VMware VMs.
Agent-based migration
Agent-based migration is used to migrate on-premises VMware VMs and physical
servers to Azure. It can also be used to migrate other on-premises virtualized servers, as
well as private and public cloud VMs, including AWS instances, and GCP VMs. Agent-
based migration in Azure Migrate uses some backend functionality from the Azure Site
Recovery service.
Architectural components
The diagram illustrates the components involved in agent-based migration.
The table summarizes the components used for agent-based migration.

Component Details Installation
Replication The replication appliance (configuration By default the process server

appliance server/process server) is an on-premises server is installed together with the
that acts as a bridge between the on-premises configuration server on the
environment, and the Migration and replication appliance.
modernization tool. The appliance discovers the
on-premises server inventory, so that the
Migration and modernization tool can
orchestrate replication and migration. The
appliance has two components:
Configuration server: Connects to the Migration

and modernization tool and coordinates
replication.
Process server: Handles data replication. The
process server receives server data, compresses
and encrypts it, and sends to Azure. In Azure, the
Migration and modernization tool writes the data
to managed disks.
Mobility The Mobility service is an agent installed on each Installation files for different
service server you want to replicate and migrate. It sends versions of the Mobility
replication data from the server to the process service are located on the
server. replication appliance. You
download and install the
agent you need, in accordance
with the operating system and
version of the server you want
to replicate.
Mobility service installation

You can deploy the Mobility Service using the following methods:
Push installation: The Mobility service is installed by the process server when you
enable protection for a server.
Install manually: You can install the Mobility service manually on each server
through UI or command prompt.
The Mobility service communicates with the replication appliance and replicated servers.
If you have antivirus software running on the replication appliance, process servers, or
servers being replicated, the following folders should be excluded from scanning:
C:\Program Files\Microsoft Azure Recovery Services Agent

C:\ProgramData\ASR
C:\ProgramData\ASRLogs
C:\ProgramData\ASRSetupLogs
C:\ProgramData\LogUploadServiceLogs
C:\ProgramData\Microsoft Azure Site Recovery
C:\Program Files (x86)\Microsoft Azure Site Recovery
C:\ProgramData\ASR\agent (on Windows servers with the Mobility service
installed)
Replication process
1. When you enable replication for a server, initial replication to Azure begins.
2. During initial replication, the Mobility service reads data from the server disks, and
sends it to the process server.
3. This data is used to seed a copy of the disk in your Azure subscription.
4. After initial replication finishes, replication of delta changes to Azure begins.
Replication is block-level, and near-continuous.
5. The Mobility service intercepts writes to disk memory, by integrating with the
storage subsystem of the operating system. This method avoids disk I/O
operations on the replicating server, for incremental replication.
6. Tracked changes for a server are sent to the process server on inbound port HTTPS
9443. This port can be modified. The process server compresses and encrypts it,
and sends it to Azure.
Ports
Device Connection
Replicating The Mobility service running on VMs communicates with the on-premises
servers replication appliance on port HTTPS 443 inbound, for replication management.
Servers send replication data to the process server on port HTTPS 9443 inbound.
This port can be modified.
appliance outbound.
Process The process server receives replication data, optimizes and encrypts it, and sends it
Performance and scaling

By default, you deploy a single replication appliance that runs both the configuration
server and the process server. If you're only replicating a few servers, this deployment is
sufficient. However, if you're replicating and migrating hundreds of servers, a single
process server might not be able to handle all the replication traffic. In this case, you can
deploy additional, scale-out process servers.
Plan VMware deployment

If you're replicating VMware VMs, you can use the Site Recovery Deployment Planner
for VMware, to help determine performance requirements, including the daily data
change rate, and the process servers you need.
Replication appliance capacity

Use the values in this table to figure out whether you need an additional process server
in your deployment.
If the daily change rate (churn rate) is over 2 TB, deploy an additional process
server.
If you're replicating more than 200 servers, deploy an additional replication
appliance.
CPU Memory Free space-data Churn rate Replication

caching limits
8 vCPUs (2 sockets * 4 cores @ 16 GB 300 GB 500 GB or < 100 servers

2.5 GHz) less
12 vCPUs (2 sockets * 6 cores @ 18 GB 600 GB 501 GB to 100-150

2.5 GHz) 1 TB servers.
16 vCPUs (2 sockets * 8 cores @ 32 GB 1 TB 1 TB to 2 151-200

2.5 GHz) TB servers.
Sizing scale-out process servers

If you need to deploy a scale-out process server, use this table to figure out server
sizing.
Process server Free space for data Churn rate Replication

caching limits
Process server Free space for data Churn rate Replication
caching limits
4 vCPUs (2 sockets * 2 cores @ 2.5 GHz), 8- 300 GB 250 GB or Up to 85

GB memory less servers
8 vCPUs (2 sockets * 4 cores @ 2.5 GHz), 12- 600 GB 251 GB to 86-150

GB memory 1 TB servers.
12 vCPUs (2 sockets * 6 cores @ 2.5 GHz), 1 TB 1-2 TB 151-225

24-GB memory servers.
Throttle upload bandwidth.

VMware traffic that replicates to Azure goes through a specific process server. You can
limit upload throughput by throttling bandwidth on the servers that are running as
process servers. You can influence bandwidth using this registry key:
The HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Azure

Backup\Replication\UploadThreadsPerVM registry value specifies the number of
threads that are used for data transfer (initial or delta replication) of a disk. A
higher value increases the network bandwidth that's used for replication. The
default value is four. The maximum value is 32. Monitor traffic to optimize the
value.
In addition, you can throttle bandwidth on the process server as follows:
1. On the process server, open the Azure Backup MMC snap-in. There's a
shortcut on the desktop or in the folder C:\Program Files\Microsoft Azure
Recovery Services Agent\bin.
2. In the snap-in, select Change Properties.
3. In Throttling, select Enable internet bandwidth usage throttling for backup
operations. Set the limits for work and non-work hours. Valid ranges are from
512 Kbps to 1,023 Mbps.
Next steps
Try out agent-based migration for VMware or physical servers.
 Documentation


Support for physical server migration in Azure Migrate - Azure Migrate

Learn about support for physical server migration in Azure Migrate.
Migrate VMware vSphere VMs with agent-based Azure Migrate Server Migration -
Azure Migrate
assessment

Troubleshoot Azure Migrate appliance diagnostic - Azure Migrate

Get help to diagnose and troubleshoot problems that might occur with the Azure Migrate appliance.
Show 5 more
Support matrix for web apps migration
This article summarizes support settings and limitations for agentless migration of web
apps to Azure App Service Azure Migrate: Migration and modernization . If you're
looking for information about assessing web apps for migration to Azure App Service,
review the assessment support matrix.
Migration options
You can perform agentless migration of ASP.NET web apps at-scale to Azure App
Service using Azure Migrate. However, agent based migration is not supported.
Limitations
Currently, At-Scale Discovery, Assessment and Migration is supported for ASP.NET
web apps deployed to on-premises IIS servers hosted on VMware Environment.
You can select up to five App Service Plans as part of single migration.
Currently, we do not support selecting existing App service plans during the
migration flow.
You can migrate web apps up to max 2 GB in size including content stored in
mapped virtual directory.
Currently, we do not support migrating UNC directory content.
You need Windows PowerShell 4.0 installed on VMs hosting the IIS web servers
from which you plan to migrate ASP.NET web apps to Azure App Services.
Currently, the migration flow does not support VNet integrated scenarios.
ASP.NET web apps migration requirements

Azure Migrate now supports agentless at-scale migration of ASP.NET web apps to Azure
App Service . Performing web apps assessment is mandatory for migration web apps
using the integrated flow in Azure Migrate.
Support Details
Supported Currently supported only for windows servers running IIS in your VMware
servers environment.
Windows Windows Server 2008 R2 and later are supported.

servers
Support Details
IIS access Web apps discovery requires a local admin user account.
IIS versions IIS 7.5 and later are supported.
PowerShell PowerShell 4.0

version
Next steps
App Service.
Once you have successfully completed migration, you may explore the following
steps based on web app specific requirement(s):
Securely connect to Azure resources.
Create and manage projects
Article • 04/19/2023
This article describes how to create, manage, and delete projects.
Classic Azure Migrate is retiring in Feb 2024. After Feb 2024, the classic version of Azure
Migrate will no longer be supported and the inventory metadata in the classic project
will be deleted. If you're using classic projects, delete those projects and follow the steps
to create a new project. You can't upgrade classic projects or components to Azure
Migrate. View FAQ before you start the creation process.
A project is used to store discovery, assessment, and migration metadata collected from
the environment you're assessing or migrating. In a project, you can track discovered
assets, create assessments, and orchestrate migrations to Azure.
Verify permissions
Ensure you have the correct permissions to create a project using the following steps:
1. In the Azure portal, open the relevant subscription, and select Access control
(IAM).
2. In Check access, find the relevant account, and select it and view permissions. You
should have Contributor or Owner permissions.
Create a project for the first time

Set up a new project in an Azure subscription.
1. In the Azure portal, search for Azure Migrate.
2. In Services, select Azure Migrate.
3. In Overview, select Discover, assess and migrate.


4. In Servers, databases and web apps, select Create project.
5. In Create project, select the Azure subscription and resource group. Create a
to create the project.
The geography is only used to store the metadata gathered from on-
premises servers. You can assess or migrate servers for any target region
regardless of the selected geography.
Review supported geographies for public and government clouds.
７ Note

with private endpoint connectivity. Learn more
7. Select Create.
Wait for a few minutes for the project to deploy.
Create a project in a specific region

In the portal, you can select the geography in which you want to create the project. If
you want to create the project within a specific Azure region, use the following API
command to create the project.
HTTP
PUT
/subscriptions/<subid>/resourceGroups/<rg>/providers/Microsoft.Migrate/Migra
teProjects/<mymigrateprojectname>?api-version=2018-09-01-preview "{location:
'centralus', properties: {}}"
Create additional projects

If you already have a project and you want to create an additional project, do the
following:
1. In the Azure public portal or Azure Government , search for Azure Migrate.
2. On the Azure Migrate dashboard, select Servers, databases and web apps >
Create project on the top left.
3. To create a new project, select Click here.
Find a project
Find a project as follows:
1. In the Azure portal , search for Azure Migrate.
2. In the Azure Migrate dashboard, select Servers, databases and web apps >
Current project in the upper-right corner.
3. Select the appropriate subscription and project.
Find a classic project

If you created the project in the previous version of Azure Migrate, find it as follows:
1. In the Azure portal , search for Azure Migrate.
2. In the Azure Migrate dashboard, if you've created a project in the previous version,
a banner referencing older projects appears. Select the banner.
3. Review the list of old projects.
Delete a project
To delete a project, follow these steps:
1. Open the Azure resource group in which the project was created.
2. In the resource group page, select Show hidden types.
3. Select the project that you want to delete and its associated resources.
The resource type is Microsoft.Migrate/migrateprojects.

If the resource group is exclusively used by the project, you can delete the
entire resource group.
Note that:
When you delete, both the project and the metadata about discovered servers are
deleted.
If you're using the older version of Azure Migrate, open the Azure resource group
in which the project was created. Select the project you want to delete (the
resource type is Migration project).
If you're using dependency analysis with an Azure Log Analytics workspace:
If you've attached a Log Analytics workspace to the Server Assessment tool, the
workspace isn't automatically deleted. The same Log Analytics workspace can
be used for multiple scenarios.
If you want to delete the Log Analytics workspace, do that manually.
Project deletion is irreversible. Deleted objects can't be recovered.
Delete a workspace manually

1. Browse to the Log Analytics workspace attached to the project.
If you haven't deleted the project, you can find the link to the workspace in
Essentials > Server Assessment.
If you've already deleted the project, select Resource Groups in the left pane
of the Azure portal and find the workspace.
2. Follow the instructions to delete the workspace.
Next steps
Add assessment or migration tools to projects.
Support requirements and
considerations for Private endpoint
connectivity
The article series describes how to use Azure Migrate to discover, assess, and migrate
servers over a private network by using Azure Private Link. You can use the Azure
Migrate: Discovery and assessment and Migration and modernization tools to connect
privately and securely to Azure Migrate over an Azure ExpressRoute private peering or a
site-to-site (S2S) VPN connection by using Private Link.
We recommend the private endpoint connectivity method when there's an

organizational requirement to access Azure Migrate and other Azure resources without
traversing public networks. By using Private Link, you can use your existing ExpressRoute
private peering circuits for better bandwidth or latency requirements.
Before you get started, review the required permissions and the supported scenarios
and tools.
Support requirements
Review the following required permissions and the supported scenarios and tools.
Supported geographies
The functionality is now in GA in supported public cloud and government cloud
geographies.
Required permissions
You must have Contributor + User Access Administrator or Owner permissions on the
subscription.
Supported scenarios and tools
Deployment Details Tools

Deployment Details Tools
Discovery Perform an agentless, at-scale discovery and assessment of your Azure

and servers running on any platform. Examples include hypervisor Migrate:
assessment platforms such as VMware vSphere or Microsoft Hyper-V, public Discovery and
clouds such as AWS or GCP, or even bare metal servers. assessment
Software Discover apps, roles, and features running on VMware VMs. Azure
inventory Migrate:
Discovery and
assessment
Dependency Use the dependency analysis capability to identify and Azure

visualization understand dependencies across servers. Migrate:
Agentless dependency visualization is supported natively with Discovery and
Azure Migrate private link support. assessment
Agent-based dependency visualization requires internet
connectivity. Learn how to use private endpoints for agent-based
Migration Perform agentless VMware migrations, agentless Hyper-V Migration and

migrations, or use the agent-based approach to migrate your modernization
VMware VMs, Hyper-V VMs, physical servers, VMs running on
AWS, VMs running on GCP, or VMs running on a different
virtualization provider.
Other integrated tools

Other migration tools might not be able to upload usage data to the Azure Migrate
project if the public network access is disabled. The Azure Migrate project should be
configured to allow traffic from all networks to receive data from other Microsoft or
external independent software vendor (ISV) offerings.
To enable public network access for the Azure Migrate project, sign in to the Azure
portal, go to the Azure Migrate Properties page in the portal, and select No > Save.
Other considerations
Considerations Details
Pricing For pricing information, see Azure Page Blobs pricing and Private Link
pricing .
Virtual The ExpressRoute/VPN gateway endpoint should reside in the selected virtual
network network or a virtual network connected to it. You might need about 15 IP
requirements addresses in the virtual network.
PowerShell PowerShell isn't supported. We recommend using the Azure portal or REST APIs
support for leveraging Azure Migrate Private Link support.
Next steps
Discover and assess servers for migration using Private Link
Migrate servers to Azure using Private Link
Troubleshoot common issues with private endpoint connectivity
Discover and assess servers for
migration using Private Link
This article describes how to create an Azure Migrate project, set up the Azure Migrate
appliance, and use it to discover and assess servers for migration using Azure Private
Link. You can use the Azure Migrate: Discovery and assessment tool to connect privately
and securely to Azure Migrate over an Azure ExpressRoute private peering or a site-to-
site (S2S) VPN connection by using Private Link.
Create a project with private endpoint

connectivity
To set up a new Azure Migrate project, see Create and manage projects.
７ Note
You can't change the connectivity method to private endpoint connectivity for
existing Azure Migrate projects.
In the Advanced configuration section, provide the following details to create a private
endpoint for your Azure Migrate project.
1. In Connectivity method, choose Private endpoint.
2. In Disable public endpoint access, keep the default setting No. Some migration
tools might not be able to upload usage data to the Azure Migrate project if public
network access is disabled. Learn more about other integrated tools.
3. In Virtual network subscription, select the subscription for the private endpoint
virtual network.
4. In Virtual network, select the virtual network for the private endpoint. The Azure
Migrate appliance and other software components that need to connect to the
Azure Migrate project must be on this network or a connected virtual network.
5. In Subnet, select the subnet for the private endpoint.

6. Select Create to create a migration project and attach a private endpoint to it. Wait
a few minutes for the Azure Migrate project to deploy. Don't close this page while
the project creation is in progress.
７ Note
If you've already created a project, you can use that project to register more
appliances to discover and assess more servers. Learn how to manage projects.

1. In Discover machines > Are your machines virtualized?, select the virtualization
server type.
2. In Generate Azure Migrate project key, provide a name for the Azure Migrate
appliance.
3. Select Generate key to create the required Azure resources.
） Important
Don't close the Discover machines page during the creation of resources.
At this step, Azure Migrate creates a key vault, a storage account, a Recovery
Services vault (only for agentless VMware migrations), and a few internal
resources. Azure Migrate attaches a private endpoint to each resource. The
private endpoints are created in the virtual network selected during the
project creation.
After the private endpoints are created, the DNS CNAME resource records for
the Azure Migrate resources are updated to an alias in a subdomain with the
prefix privatelink. By default, Azure Migrate also creates a private DNS zone
corresponding to the privatelink subdomain for each resource type and
inserts DNS A records for the associated private endpoints. This action
enables the Azure Migrate appliance and other software components that
reside in the source network to reach the Azure Migrate resource endpoints
on private IP addresses.
Azure Migrate also enables a managed identity for the migrate project and
the Recovery Services vault and grants permissions to the managed identity
to securely access the storage account.
4. After the key is successfully generated, copy the key details to configure and
register the appliance.
Download the appliance installer file

Azure Migrate: Discovery and assessment use a lightweight Azure Migrate appliance.
The appliance performs server discovery and sends server configuration and
performance metadata to Azure Migrate.
７ Note
If you have deployed an appliance using a template (OVA for servers on a VMware
environment and VHD for a Hyper-V environment), you can use the same appliance
and register it with an Azure Migrate project with private endpoint connectivity.
To set up the appliance:
1. Download the zipped file that contains the installer script from the portal.
2. Copy the zipped file on the server that will host the appliance.
3. After you download the zipped file, verify the file security.
4. Run the installer script to deploy the appliance.
Verify security
window.

Download Hash value
version
７ Note
The same script can be used to set up an appliance with private endpoint
connectivity for any of the chosen scenarios, such as VMware, Hyper-V, physical or
other to deploy an appliance with the desired configuration.
Make sure the server meets the hardware requirements for the chosen scenario, such as
VMware, Hyper-V, physical or other, and can connect to the required URLs.
Run the Azure Migrate installer script


command:
5. Select from the scenario, cloud and connectivity options to deploy an appliance
appliance to discover and assess servers running in your VMware environment to
an Azure Migrate project with private endpoint connectivity on Azure public
cloud.
７ Note
Configure the appliance and start continuous

discovery
Open a browser on any machine that can connect to the appliance server. Open the URL
of the appliance configuration manager, https://appliance name or IP address: 44368 .
Or, you can open the configuration manager from the appliance server desktop by
selecting the shortcut for the configuration manager.
Set up prerequisites
1. Read the third-party information, and accept the license terms.

steps:
uses a proxy:

７ Note

that's shown.
to see the prompt.
７ Note
e. After you successfully log in, return to the browser tab that displays the
appliance configuration manager. If the Azure user account that you used to log
in has the required permissions for the Azure resources that were created
4. Install VDDK: (Needed only for VMware appliance.) The appliance checks that the
VMware vSphere Virtual Disk Development Kit (VDDK) is installed. If it isn't
installed, download VDDK 6.7 from VMware. Extract the downloaded zipped
contents to the specified location on the appliance, as provided in the installation
instructions.
７ Note
If you get DNS resolution issues during appliance registration or at the time of
starting discovery, ensure that Azure Migrate resources created during the
Generate key step in the portal are reachable from the on-premises server that
hosts the Azure Migrate appliance. Learn more about how to verify network
connectivity.
Assess your servers for migration to Azure

After the discovery is complete, assess your servers, such as VMware VMs, Hyper-V VMs,
physical servers, AWS VMs, and GCP VMs, for migration to Azure VMs or Azure VMware
Solution by using the Azure Migrate: Discovery and assessment tool.
You can also assess your on-premises machines with the Azure Migrate: Discovery and
assessment tool by using an imported CSV file.
Next steps
Migrate servers to Azure using Private Link.
 Documentation

VPN connections.

Troubleshoot Azure Migrate projects - Azure Migrate

Helps you to troubleshoot issues with creating and managing Azure Migrate projects.
Troubleshoot issues with agentless and agent-based dependency analysis - Azure

Migrate
Get help with dependency visualization in Azure Migrate.

Support for physical server migration in Azure Migrate - Azure Migrate

Learn about support for physical server migration in Azure Migrate.

common errors.
Show 5 more
 Training
Module
Prepare on-premises workloads for migration to Azure - Training
Prepare on-premises workloads for migration to Azure
Migrate servers to Azure using Private
Link
This article describes how to use Azure Migrate to migrate servers over a private
network by using Azure Private Link. You can use the Migration and modernization tool
to connect privately and securely to Azure Migrate over an Azure ExpressRoute private
peering or a site-to-site (S2S) VPN connection by using Private Link.
This article shows how to migrate on-premises VMware VMs to Azure, using the
Migration and modernization tool, with agentless migration.

The Migration and modernization tool runs a lightweight VMware VM appliance to
enable the discovery, assessment, and agentless migration of VMware VMs. If you have
followed the Discovery and assessment tutorial, you've already set the appliance up. If
you didn't, set up and configure the appliance before you proceed.
Replicate VMs
After setting up the appliance and completing discovery, you can begin replicating
The following diagram illustrates the agentless replication workflow with private
endpoints by using the Migration and modernization tool.
Enable replication as follows:
modernization > Migration tools, select Replicate.
2. In Replicate > Basics > Are your machines virtualized?, select Yes, with VMware
vSphere.
3. In On-premises appliance, select the name of the Azure Migrate appliance. Select
OK.
4. In Virtual machines, select the machines you want to replicate. To apply VM sizing
and disk type from an assessment, in Import migration settings from an Azure
Migrate assessment?,
Select Yes, and select the VM group and assessment name.

Select No if you aren't using assessment settings.
5. In Virtual machines, select VMs you want to migrate. Then click Next.
6. In Target settings, select the target region in which the Azure VMs will reside after
migration.
7. In Replication storage account, use the dropdown list to select a storage account
to replicate over a private link.
７ Note
Only the storage accounts in the selected target region and Azure Migrate
project subscription are listed.
8. Next, create a private endpoint for the storage account to enable replications
over a private link. Ensure that the Azure Migrate appliance has network
connectivity to the storage account on its private endpoint. Learn how to verify
network connectivity.
７ Note
The storage account cannot be changed after you enable replication.

To orchestrate replications, Azure Migrate will grant the trusted
Microsoft services and the Recovery Services vault managed identity
access to the selected storage account.
 Tip
You can manually update the DNS records by editing the DNS hosts file on
the Azure Migrate appliance with the private link FQDNs and private IP
address of the storage account.
9. Select the Subscription and Resource group in which the Azure VMs reside after
migration.
10. In Virtual network, select the Azure VNet/subnet for the migrated Azure VMs.



７ Note
To replicate VMs with CMK, you'll need to create a disk encryption set under
the target Resource Group. A disk encryption set object maps Managed Disks
to a Key Vault that contains the CMK to use for SSE.

Select No if you don't want to apply Azure Hybrid Benefit and click Next.
the benefit to the machines you're migrating and click Next.

dropdown shows the recommended size. Otherwise, Azure Migrate picks a
７ Note
If you want to select a different availability option for a set of virtual machines,
go to step 1 and repeat the steps by selecting different availability options
after starting replication for one set of virtual machines.
the disk type (standard SSD/HDD or premium-managed disks) in Azure. Then click
Next.
16. In Tags, add tags to your migrated virtual machines, disks, and NICs.
initial replication for the servers. Next, follow the instructions to perform
migrations.
Provisioning for the first time
Azure Migrate does not create any additional resources for replications using Azure
Private Link (Service Bus, Key Vault, and storage accounts are not created). Azure
Migrate will make use of the selected storage account for uploading replication data,
state data, and orchestration messages.
Create a private endpoint for the storage

account
To replicate by using ExpressRoute with private peering, create a private endpoint for
the cache/replication storage account (target subresource: blob).
７ Note
You can create private endpoints only on a general-purpose v2 storage account.

For pricing information, see Azure Page Blobs pricing and Azure Private Link
pricing .
Create the private endpoint for the storage account in the same virtual network as the
Azure Migrate project private endpoint or another virtual network connected to this
network.
Select Yes and integrate with a private DNS zone. The private DNS zone helps in routing
the connections from the virtual network to the storage account over a private link.
Selecting Yes automatically links the DNS zone to the virtual network. It also adds the
DNS records for the resolution of new IPs and FQDNs that are created. Learn more
about private DNS zones.
If the user who created the private endpoint is also the storage account owner, the
private endpoint creation will be auto approved. Otherwise, the owner of the storage
account must approve the private endpoint for use. To approve or reject a requested
private endpoint connection, on the storage account page under Networking, go to
Private endpoint connections.
Review the status of the private endpoint connection state before you continue.
Ensure that the on-premises appliance has network connectivity to the storage account
via its private endpoint. To validate the private link connection, perform a DNS
resolution of the storage account endpoint (private link resource FQDN) from the on-
premises server hosting the Migrate appliance and ensure that it resolves to a private IP
address. Learn how to verify network connectivity.
Next steps
Migrate VMs
Complete the migration process.
Review the post-migration best practices.
 Documentation
Migrate VMware virtual machines to Azure with server-side encryption(SSE) and

customer-managed keys(CMK) using Azure Migrate Server Migration - Azure Migrate
Learn how to migrate VMware VMs to Azure with server-side encryption(SSE) and customer-
managed keys(CMK) using Azure Migrate Server Migration
Set up an Azure Migrate scale-out appliance for agentless VMware migration - Azure
Migrate
Learn how to set up an Azure Migrate scale-out appliance to migrate Hyper-V VMs.

Physical server to Azure disaster recovery architecture – Modernized - Azure Site

Recovery
This article provides an overview of components and architecture used when setting up disaster
recovery of on-premises Windows and Linux servers to Azure with Azure Site Recovery - Modernized

VMware disaster recovery-configuration server requirements in Azure Site Recovery. -

Azure Site Recovery
This article describes support and requirements when deploying the configuration server for VMware
disaster recovery to Azure with Azure Site Recovery.
Set up source settings for VMware disaster recovery to Azure with Azure Site
Recovery - Azure Site Recovery
This article describes how to set up your on-premises environment to replicate VMware VMs to
Azure with Azure Site Recovery.
Show 5 more
Troubleshoot network connectivity
This article helps you troubleshoot network connectivity issues using Azure Migrate with
private endpoints.
Validate private endpoints configuration

Make sure the private endpoint is an approved state.
1. Go to Azure Migrate: Discovery and Assessment and Migration and

modernization properties page.
2. The properties page contains the list of private endpoints and private link FQDNs
that were automatically created by Azure Migrate.
3. Select the private endpoint you want to diagnose.

a. Validate that the connection state is Approved.
b. If the connection is in a Pending state, you need to get it approved.
c. You may also navigate to the private endpoint resource and review if the virtual
network matches the Migrate project private endpoint virtual network.
Validate the data flow through the private

endpoints
Review the data flow metrics to verify the traffic flow through private endpoints. Select
the private endpoint in the Azure Migrate: Server Assessment and Migration and
modernization Properties page. This will redirect to the private endpoint overview
section in Azure Private Link Center. In the left menu, select Metrics to view the Data
Bytes In and Data Bytes Out information to view the traffic flow.
Verify DNS resolution
The on-premises appliance (or replication provider) will access the Azure Migrate
resources using their fully qualified private link domain names (FQDNs). You may require
additional DNS settings to resolve the private IP address of the private endpoints from
the source environment. See this article to understand the DNS configuration scenarios
that can help troubleshoot any network connectivity issues.
To validate the private link connection, perform a DNS resolution of the Azure Migrate
resource endpoints (private link resource FQDNs) from the on-premises server hosting
the Migrate appliance and ensure that it resolves to a private IP address.
To obtain the private endpoint details to verify DNS resolution:
1. The private endpoint details and private link resource FQDNs' information is
available in the Discovery and Assessment and Migration and modernization
properties pages. Select Download DNS settings to view the list. Note, only the
private endpoints that were automatically created by Azure Migrate are listed
below.
2. If you have created a private endpoint for the storage account(s) for replicating
over a private network, you can obtain the private link FQDN and IP address as
illustrated below.
Go to the Storage account > Networking > Private endpoint connections and
select the private endpoint created.
Go to Settings > DNS configuration to obtain the storage account FQDN and
private IP address.
An illustrative example for DNS resolution of the storage account private link FQDN.
Enter nslookup <storage-account-name>_.blob.core.windows.net. Replace

<storage-account-name> with the name of the storage account used for Azure
Migrate.
You'll receive a message like this:

A private IP address of 10.1.0.5 is returned for the storage account. This address
belongs to the private endpoint virtual network subnet.
You can verify the DNS resolution for other Azure Migrate artifacts using a similar
approach.
If the DNS resolution is incorrect, follow these steps:
Recommended: Manually update your source environment DNS records by editing the
DNS hosts file on your on-premises appliance with the private link resource FQDNs and
their associated private IP addresses.
If you use a custom DNS, review your custom DNS settings, and validate that the
DNS configuration is correct. For guidance, see private endpoint overview: DNS
configuration.
If you use Azure-provided DNS servers, refer to the below section for further
troubleshooting.
 Tip
For testing, you can manually update your source environment DNS records by
editing the DNS hosts file on your on-premises appliance with the private link
resource FQDNs and their associated private IP addresses.
Validate the Private DNS Zone

If the DNS resolution is not working as described in the previous section, there might be
an issue with your Private DNS Zone.
Confirm that the required Private DNS Zone resource

exists
By default, Azure Migrate also creates a private DNS zone corresponding to the
privatelink subdomain for each resource type. The private DNS zone will be created in
the same Azure resource group as the private endpoint resource group. The Azure
resource group should contain private DNS zone resources with the following format:
privatelink.vaultcore.azure.net for the key vault

privatelink.blob.core.windows.net for the storage account
privatelink.siterecovery.windowsazure.com for the recovery services vault (for
Hyper-V and agent-based replications)
privatelink.prod.migration.windowsazure.com - migrate project, assessment
project, and discovery site.
Azure Migrate automatically creates the private DNS zone (except for the
cache/replication storage account selected by the user). You can locate the linked
private DNS zone by navigating to the private endpoint page and selecting DNS
configurations. Here, you should see the private DNS zone under the private DNS
integration section.
If the DNS zone is not present (as shown below), create a new Private DNS Zone
resource.
Confirm that the Private DNS Zone is linked to the virtual

network
The private DNS zone should be linked to the virtual network that contains the private
endpoint for the DNS query to resolve the private IP address of the resource endpoint. If
the private DNS zone is not linked to the correct Virtual Network, any DNS resolution
from that virtual network will ignore the private DNS zone.
Navigate to the private DNS zone resource in the Azure portal and select the virtual
network links from the left menu. You should see the virtual networks linked.
This will show a list of links, each with the name of a virtual network in your subscription.
The virtual network that contains the Private Endpoint resource must be listed here. Else,
follow this article to link the private DNS zone to a virtual network.
Once the private DNS zone is linked to the virtual network, DNS requests originating
from the virtual network will look for DNS records in the private DNS zone. This is
required for correct address resolution to the virtual network where the private endpoint
was created.
Confirm that the private DNS zone contains the right A

records
Go to the private DNS zone you want to troubleshoot. The Overview page shows all
DNS records for that private DNS zone. Verify that a DNS A record exists for the
resource. The value of the A record (the IP address) must be the resources’ private IP
address. If you find the A record with the wrong IP address, you must remove the wrong
IP address and add a new one. It's recommended that you remove the entire A record
and add a new one, and do a DNS flush on the on-premises source appliance.
An illustrative example for the storage account DNS A record in the private DNS zone:
An illustrative example for the Recovery Services vault microservices DNS A records in
the private DNS zone:
７ Note
When you remove or modify an A record, the machine may still resolve to the old
IP address because the TTL (Time To Live) value might not have expired yet.
Items that may affect private link connectivity

This is a non-exhaustive list of items that can be found in advanced or complex
scenarios:
Firewall settings, either the Azure Firewall connected to the Virtual network or a
custom firewall solution deploying in the appliance machine.
Network peering, which may impact which DNS servers are used and how traffic is
routed.
Custom gateway (NAT) solutions may impact how traffic is routed, including traffic
from DNS queries.
For more information, review the troubleshooting guide for Private Endpoint
connectivity problems.
Common issues while using Azure Migrate with

private endpoints
In this section, we will list some of the commonly occurring issues and suggest do-it-
yourself troubleshooting steps to remediate the problem.
Appliance registration fails with the error
ForbiddenToAccessKeyVault
Azure Key Vault create or update operation failed for <KeyVaultName> due to the error
<ErrorMessage>
Possible causes:
This issue can occur if the Azure account being used to register the appliance doesn’t
have the required permissions or the Azure Migrate appliance cannot access the Key
Vault.
Remediation:
Steps to troubleshoot Key Vault access issues:
1. Make sure the Azure user account used to register the appliance has at least
Contributor permissions on the subscription.
2. Ensure that the user trying to register the appliance has access to the Key Vault
and has an access policy assigned in the Key Vault>Access Policy section. Learn
more
Learn more about the required Azure roles and permissions.
Steps to troubleshoot connectivity issues to the Key Vault: If you have enabled the
appliance for private endpoint connectivity, use the following steps to troubleshoot
network connectivity issues:
Ensure that the appliance is either hosted in the same virtual network or is
connected to the target Azure virtual network (where the Key Vault private
endpoint has been created) over a private link. The Key Vault private endpoint will
be created in the virtual network selected during the project creation experience.
You can verify the virtual network details in the Azure Migrate > Properties page.
Ensure that the appliance has network connectivity to the Key Vault over a private
link. To validate the private link connectivity, perform a DNS resolution of the Key
Vault resource endpoint from the on-premises server hosting the appliance and
ensure that it resolves to a private IP address.
Go to Azure Migrate: Discovery and assessment> Properties to find the details of

private endpoints for resources like the Key Vault created during the key
generation step.
Select Download DNS settings to download the DNS mappings.
Open the command line and run the following nslookup command to verify
network connectivity to the Key Vault URL mentioned in the DNS settings file.
Console
nslookup <your-key-vault-name>.vault.azure.net
If you run the ns lookup command to resolve the IP address of a key vault over a
public endpoint, you will see a result that looks like this:
Console
c:\ >nslookup <your-key-vault-name>.vault.azure.net

Non-authoritative answer:
Name:
Address: (public IP address)
Aliases: <your-key-vault-name>.vault.azure.net
If you run the ns lookup command to resolve the IP address of a key vault over a
private endpoint, you will see a result that looks like this:
Console
c:\ >nslookup your_vault_name.vault.azure.net
Name:
Address: 10.12.4.20 (private IP address)
Aliases: <your-key-vault-name>.vault.azure.net
<your-key-vault-name>.privatelink.vaultcore.azure.net
The nslookup command should resolve to a private IP address as mentioned

above. The private IP address should match the one listed in the DNS settings file.
1. Manually update the source environment DNS records by editing the DNS hosts
file on the on-premises appliance with the DNS mappings and the associated
private IP addresses. This option is recommended for testing.
2. If you use a custom DNS server, review your custom DNS settings, and validate
that the DNS configuration is correct. For guidance, see private endpoint overview:
DNS configuration.
3. Proxy server considerations: If the appliance uses a proxy server for outbound
connectivity, you may need to validate your network settings and configurations to
ensure the private link URLs are reachable and can be routed as expected.
If the proxy server is for internet connectivity, you may need to add traffic
forwarders or rules to bypass the proxy server for the private link FQDNs.
Learn more on how to add proxy bypass rules.
Alternatively, if the proxy server is for all outbound traffic, make sure the
proxy server can resolve the private link FQDNs to their respective private IP
addresses. For a quick workaround, you can manually update the DNS
records on the proxy server with the DNS mappings and the associated
private IP addresses, as shown above. This option is recommended for
testing.
4. If the issue still persists, refer to this section for further troubleshooting.
After you’ve verified the connectivity, retry the registration process.
Start Discovery fails with the error AgentNotConnected

The appliance could not initiate discovery as the on-premises agent is unable to
communicate to the Azure Migrate service endpoint: <URLname> in Azure.
Possible causes:
This issue can occur if the appliance is unable to reach the service endpoint(s)
mentioned in the error message.
Remediation:
Ensure that the appliance has connectivity either directly or via proxy and can resolve
the service endpoint provided in the error message.
If you have enabled the appliance for private endpoint connectivity, ensure that the
appliance is connected to the Azure virtual network over a private link and can resolve
the service endpoint(s) provided in the error message.
Steps to troubleshoot private link connectivity issues to Azure Migrate service

endpoints:
If you have enabled the appliance for private endpoint connectivity, use the following
steps to troubleshoot network connectivity issues:
Ensure that the appliance is either hosted in the same virtual network or is
connected to the target Azure virtual network (where the private endpoints have
been created) over a private link. Private endpoints for the Azure Migrate services
are created in the virtual network selected during the project creation experience.
You can verify the virtual network details in the Azure Migrate > Properties page.
Ensure that the appliance has network connectivity to the service endpoint URLs
and other URLs, mentioned in the error message, over a private link connection. To
validate private link connectivity, perform a DNS resolution of the URLs from the
on-premises server hosting the appliance and ensure that it resolves to private IP
addresses.
Go to Azure Migrate: Discovery and assessment> Properties to find the details of

private endpoints for the service endpoints created during the key generation step.
Select Download DNS settings to download the DNS mappings.
DNS mappings containing Private endpoint URLs Details
*.disc.privatelink.prod.migration.windowsazure.com Azure Migrate Discovery service endpoint
*.asm.privatelink.prod.migration.windowsazure.com Azure Migrate Assessment service endpoint
*.hub.privatelink.prod.migration.windowsazure.com Azure Migrate hub endpoint to receive data

from other Microsoft or external
independent software vendor (ISV) offerings
*.privatelink.siterecovery.windowsazure.com Azure Site Recovery service endpoint to

orchestrate replications
*.vault.azure.net Key Vault endpoint
*.blob.core.windows.net Storage account endpoint for dependency

and performance data
In addition to the URLs above, the appliance needs access to the following URLs over
Internet, directly or via proxy.
Other public cloud URLs Details

(Public endpoint URLs)
*.portal.azure.com Navigate to the Azure portal

Other public cloud URLs Details
(Public endpoint URLs)
*.windows.net Used for access control and identity management by Azure

*.msftauth.net Active Directory
*.msauth.net
*.microsoft.com
*.live.com
*.office.com
management.azure.com For triggering Azure Resource Manager deployments

(optional)
aka.ms/* (optional) Allow access to also know as links; used to download and
install the latest updates for appliance services
download.microsoft.com/download Allow downloads from Microsoft download center
Open the command line and run the following nslookup command to verify
privatelink connectivity to the URLs listed in the DNS settings file. Repeat this step
for all URLs in the DNS settings file.
Illustration: verifying private link connectivity to the discovery service endpoint
Console
nslookup 04b8c9c73f3d477e966c8d00f352889c-
agent.cus.disc.privatelink.prod.migration.windowsazure.com
If the request can reach the discovery service endpoint over a private endpoint,
you will see a result that looks like this:
Console
nslookup 04b8c9c73f3d477e966c8d00f352889c-
Name:
Address: 10.12.4.23 (private IP address)
Aliases: 04b8c9c73f3d477e966c8d00f352889c-
prod.cus.discoverysrv.windowsazure.com
The nslookup command should resolve to a private IP address as mentioned
above. The private IP address should match the one listed in the DNS settings file.
1. Manually update the source environment DNS records by editing the DNS hosts
file on the on-premises appliance with the DNS mappings and the associated
private IP addresses. This option is recommended for testing.
2. If you use a custom DNS server, review your custom DNS settings, and validate
that the DNS configuration is correct. For guidance, see private endpoint overview:
DNS configuration.
3. Proxy server considerations: If the appliance uses a proxy server for outbound
connectivity, you may need to validate your network settings and configurations to
ensure the private link URLs are reachable and can be routed as expected.
If the proxy server is for internet connectivity, you may need to add traffic
forwarders or rules to bypass the proxy server for the private link FQDNs.
Learn more on how to add proxy bypass rules.
Alternatively, if the proxy server is for all outbound traffic, make sure the
proxy server can resolve the private link FQDNs to their respective private IP
addresses. For a quick workaround, you can manually update the DNS
records on the proxy server with the DNS mappings and the associated
private IP addresses, as shown above. This option is recommended for
testing.
4. If the issue still persists, refer to this section for further troubleshooting.
After you’ve verified the connectivity, retry the discovery process.

Import/export request fails with the error "403: This
request is not authorized to perform this operation"
The export/import/download report request fails with the error "403: This request is not
authorized to perform this operation" for projects with private endpoint connectivity.
Possible causes:
This error may occur if the export/import/download request was not initiated from an
authorized network. This can happen if the import/export/download request was
initiated from a client that is not connected to the Azure Migrate service (Azure virtual
network) over a private network.
Remediation
Option 1 (recommended):
To resolve this error, retry the import/export/download operation from a client residing
in a virtual network that is connected to Azure over a private link. You can open the
Azure portal in your on-premises network or your appliance VM and retry the operation.
Option 2:
The import/export/download request makes a connection to a storage account for

uploading/downloading reports. You can also change the networking settings of the
storage account used for the import/export/download operation and allow access to the
storage account via other networks (public networks).
To set up the storage account for public endpoint connectivity,
1. Locate the storage account: The storage account name is available on the Azure
Migrate: Discovery and Assessment properties page. The storage account name
will have the suffix usa.
2. Navigate to the storage account and edit the storage account networking
properties to allow access from all/other networks.
3. Alternatively, you can limit the access to selected networks and add the public IP
address of the client from where you're trying to access the Azure portal.
Using private endpoints for replication requires the Azure
Migrate appliance services to be running on the
following versions
Possible causes:
This issue can occur if the services running on the appliance are not running on their
latest version. The DRA agent orchestrates server replication, and coordinates
communication between replicated servers and Azure. The gateway agent sends
replicated data to Azure.
７ Note
This error is only applicable for agentless VMware VM migrations.
Remediation:
1. Validate that the services running on the appliance are updated to the latest
versions.
To do so, launch the appliance configuration manager from your appliance server
and select View appliance services from the Setup prerequisites panel. The
appliance and its components are automatically updated. If not, follow the
instructions to update the appliance services manually.
Failed to save configuration: 504 gateway timeout

Possible causes:
This issue can occur if the Azure Migrate appliance cannot reach the service endpoint
provided in the error message.
Remediation:
To validate the private link connection, perform a DNS resolution of the Azure Migrate
service endpoints (private link resource FQDNs) from the on-premises server hosting the
Migrate appliance and ensure that they resolve to private IP addresses.
To obtain the private endpoint details to verify DNS resolution:
The private endpoint details and private link resource FQDN information are available in
the Discovery and Assessment and Migration and modernization properties pages.
Select Download DNS settings on both the properties pages to view the full list.
Next, refer to this guidance to verify the DNS resolution.
 Documentation

VPN connections.





Show 5 more
Prepare to work with an ISV tool or
Movere
If you've added an ISV tool or Movere to an Azure Migrate project, there are a few steps
to follow before you link the tool and send data to Azure Migrate.
Check Azure AD permissions

Your Azure user account needs these permissions:
Permission to register an Azure Active Directory (Azure AD) app with your Azure
tenant
Permission to allocate a role to the Azure AD app at the subscription level
Set permissions to register an Azure AD app

1. In Azure AD, check the role for your account.
2. If you have the user role, select User settings on the left and verify whether users
can register applications. If it's set to Yes, any users in the Azure AD tenant can
register an app. If it's set to No, then only admin users can register apps.
3. If you don't have permissions, an admin user can provide your user account with
the Application Administrator role, so that you can register the app.
4. After the tool is linked to Azure Migrate, the admin can remove the role from your
account.
Set permissions to assign a role to an Azure AD app

In your Azure subscription, your account needs Microsoft.Authorization/*/Write access
to assign a role to an Azure AD app.
1. In the Azure portal, open Subscriptions.

2. Select the relevant subscription. If you don't see it, select the global subscriptions
filter.
3. Select My permissions. Then, select Click here to view complete access details for
this subscription.
4. In Role assignments > View, check the permissions. If your account doesn't have
permissions, ask the subscription administrator to add you to User Access
Administrator role or the Owner role.
Allow access to URLs
For ISV tools and Azure Database Migration Assistant, allow access to the public cloud
URLs summarized in the table. If you're using a URL-based proxy to connect to the
internet, make sure that the proxy resolves any CNAME records received while looking
up the URLs.
URL Details
*.windows.net Sign in to your Azure subscription.

*.msftauth.net
*.msauth.net
*.microsoft.com
*.live.com
*.microsoftonline.com Create Azure Active Directory (AD) apps for the appliance to
*.microsoftonline-p.com communicate with Azure Migrate.
management.azure.com Make Azure Resource Manager calls to the Azure Migrate Project.
*.servicebus.windows.net Communication between the appliance and EventHub for sending the
messages.
Start using the tool

1. If you don't yet have a license or free trial for the tool, in the tool entry in Azure
Migrate, in Register, select Learn more.
2. In the tool, follow the instructions to link from the tool to the Azure Migrate
project, and to send data to Azure Migrate.
Next steps
Follow the instructions from your ISV or Movere to send data to Azure Migrate.
 Documentation

Migrate

Azure security baseline for Azure Migrate

The Azure Migrate security baseline provides procedural guidance and resources for implementing
the security recommendations specified in the Microsoft cloud security benchmark.



Show 5 more
 Training
Module
Set up Azure Migrate for server migration - Training
Learn how to check your prerequisite configurations in Azure and in your VMware vSphere
environment and then perform the initial steps in Azure Migrate to choose your assessment and
migration tools.
Certification
Microsoft Certified: Azure Data Fundamentals - Certifications
Azure Data Fundamentals validates foundational knowledge of core data concepts and how they are
implemented using Microsoft Azure data services.
Set up an appliance for servers in a
VMware environment
Article • 04/17/2023
This article describes how to set up the Azure Migrate appliance for assessment by using
the Azure Migrate: Discovery and assessment tool.
The Azure Migrate appliance is a lightweight appliance that the Azure Migrate:
Discovery and assessment tool uses to discover servers running in vCenter Server and to
send server configuration and performance metadata to Azure.

You can deploy the Azure Migration appliance using these methods:
Create a server on a vCenter Server VM using a downloaded OVA template. This

method is described in this article.
Set up the appliance on an existing server by using a PowerShell installer script.
You should run a PowerShell script if you can't use an OVA template or if you're in
Azure Government.
After you create the appliance, check if the appliance can connect to Azure Migrate:
Discovery and assessment, register the appliance with the project, and configure the
appliance to start discovery.
Deploy by using an OVA template

To set up the appliance by using an OVA template, you'll complete these steps, which
are described in detail in this section:
７ Note
OVA templates are not available for soverign clouds.

2. Download an OVA template file, and import it to vCenter Server. Verify that the
OVA is secure.
3. Create the appliance from the OVA file. Verify that the appliance can connect to
Azure Migrate.
4. Configure the appliance for the first time.
5. Register the appliance with the project by using the project key.
Discovery and assessment > Discover.
2. In Discover servers, select Are your servers virtualized? > Yes, with VMware
vSphere hypervisor.
you'll set up to discover servers in your VMware environment. The name should be
alphanumeric and 14 characters or fewer.
4. To start creating the required Azure resources, select Generate key. Don't close the
Discover pane while the resources are being created.
5. After the Azure resources are successfully created, a project key is generated.
6. Copy the key. You'll use the key to complete registration of the appliance when
you configure the appliance.
Download the OVA template

In 2: Download Azure Migrate appliance, select the OVA file, and select Download.
Verify security
Before you deploy the OVA file, verify that the file is secure:
1. On the server on which you downloaded the file, open a Command Prompt
window by using the Run as administrator option.
2. Run the following command to generate the hash for the OVA file:
Bash
C:\>CertUtil -HashFile <file_location> <hashing_agorithm>
For example:
Bash
C:\>CertUtil -HashFile
C:\Users\Administrator\Desktop\MicrosoftAzureMigration.ova SHA256
3. Verify the latest hash value by comparing the outcome of above command to the
value documented here.
Create the appliance server
Import the downloaded file, and create a server in the VMware environment:
1. In the vSphere Client console, select File > Deploy OVF Template.
2. In the Deploy OVF Template Wizard, select Source, and enter the location of the
OVA file.
3. In Name, enter a name for the server. In Location, select the inventory object in
which the server will be hosted.
4. In Host/Cluster, select the host or cluster on which the server will run.
5. In Storage, select the storage destination for the server.
6. In Disk Format, select the disk type and size.
7. In Network Mapping, select the network the server will connect to. The network
requires internet connectivity to send metadata to Azure Migrate.
8. Review and confirm the settings, and select Finish.

Make sure that the appliance server can connect to Azure URLs for public clouds and
government clouds.

To set up the appliance for the first time:
７ Note
If you set up the appliance by using a PowerShell script instead of a downloaded

OVA template, you can skip the first two steps.
1. In vSphere Client, right-click the server, and select Open Console.
2. Select or enter the language, time zone, and password for the appliance.
3. Open a browser on any server that can connect to the appliance server. Navigate
to the URL of the appliance configuration manager: https://appliance name or IP
address: 44368 .
Or, you can open the configuration manager from the appliance server desktop by
selecting the shortcut for the configuration manager.

In the configuration manager, select Set up prerequisites, and complete these steps:
uses a proxy:
Enter the credentials if the proxy needs authentication.
７ Note
７ Note

name you provided when you generated the project key, and copy the key
that's shown.
device code to authenticate with Azure) and open an Azure sign-in prompt in a
to see the prompt.
７ Note
e. After you successfully sign in, return to the browser tab that displays the
appliance configuration manager. If the Azure user account that you used to
sign in has the required permissions for the Azure resources that were created
After the appliance is successfully registered, select View details to see the
registration details.
4. Install the VDDK: The appliance checks that VMware vSphere Virtual Disk
Development Kit (VDDK) is installed. If the VDDK isn't installed, download VDDK
6.7 or 7.0 from VMware. Extract the downloaded zip file contents to the specified
location on the appliance, the default path is C:\Program Files\VMware\VMware
Virtual Disk Development Kit as indicated in the Installation instructions.
The Migration and modernization tool uses the VDDK to replicate servers during
migration to Azure.
Complete the setup steps in the appliance configuration manager to prepare for and
start discovery.
Provide vCenter Server details

The appliance must connect to vCenter Server to discover the configuration and
performance data of the servers:
1. In Step 1: Provide vCenter Server credentials, select Add credentials to enter a

name for the credentials. Add the username and password for the vCenter Server
account that the appliance will use to discover servers running on vCenter Server.
You should have set up an account with the required permissions as

described earlier in this article.
If you want to scope discovery to specific VMware objects (vCenter Server
datacenters, clusters, hosts, folders of clusters or hosts, or individual servers),
review the instructions to set discovery scope to restrict the account that
Azure Migrate uses.
If you want to add multiple credentials at once, select Add more to save and
add more credentials. Multiple credentials are supported for discovery of
servers across multiple vCenter Servers using a single appliance.
2. In Step 2: Provide vCenter Server details, select Add discovery source to add the
IP address or FQDN of a vCenter Server. You can leave the port as the default (443)
or specify a custom port on which vCenter Server listens. Select the friendly name
for credentials you would like to map to the vCenter Server and select Save.
Select on Add more to save the previous details and add more vCenter Server
details. You can add up to 10 vCenter Servers per appliance.
3. The appliance attempts to validate the connection to the vCenter Server(s) added
by using the credentials mapped to each vCenter Server. It displays the validation
status with the vCenter Server(s) IP address or FQDN in the sources table.
4. You can revalidate the connectivity to vCenter Server(s) anytime before starting
discovery.
In Step 3: Provide server credentials to perform software inventory, agentless
dependency analysis, discovery of SQL Server instances and databases and discovery
of ASP.NET web apps in your VMware environment., you can provide multiple server
credentials. If you don't want to use any of these appliance features, you can skip this
step and proceed with vCenter Server discovery. You can change this option at any time.
If you want to use these features, provide server credentials by completing the following
steps. The appliance attempts to automatically map the credentials to the servers to
perform the discovery features.
You can provide domain/, Windows(non-domain)/, Linux(non-domain)/, and SQL

Server authentication credentials. Learn how to provide credentials and how we
handle them.
A friendly name.
A username.
If you choose to use domain credentials, you also must enter the FQDN for the
domain. The FQDN is required to validate the authenticity of the credentials with
the Active Directory instance in that domain.
4. Review the required permissions on the account for Step 3: Provide server
credentials to perform software inventory, agentless dependency analysis,
discovery of SQL Server instances and databases and discovery of ASP.NET web
apps.
5. To add multiple credentials at once, select Add more to save credentials, and add
more credentials. When you select Save or Add more, the appliance validates the
domain credentials with the domain's Active Directory instance for authentication.
Validation is made after each addition to avoid account lockouts as the appliance
iterates to map credentials to respective servers.
In the configuration manager, in the credentials table, see the Validation status for
domain credentials. Only domain credentials are validated.
If validation fails, you can select a Failed status to see the validation error. Fix the issue,
and select Revalidate credentials to reattempt validation of the credentials.
７ Note
Ensure that the following special characters are not passed in any credentials as
they are not supported for SSO passwords:
Non-ASCII characters. Learn more .

Ampersand (&)
Semicolon (;)
Double quotation mark (")
Single quotation mark (')
Circumflex (^)
Backslash (\)
Percentage (%)
Angle brackets (<,>)
Pound (£)
Start discovery
To start vCenter Server discovery, in Step 3: Provide server credentials to perform
software inventory, agentless dependency analysis, discovery of SQL Server instances
and databases and discovery of ASP.NET web apps in your VMware environment.,
select Start discovery. After the discovery is successfully initiated, you can check the
discovery status by looking at the vCenter Server IP address or FQDN in the sources
table.
How discovery works

It takes approximately 20-25 minutes for the discovery of servers across 10 vCenter
Servers added to a single appliance.
If you have provided server credentials, software inventory (discovery of installed
applications) is automatically initiated when the discovery of servers running on
vCenter Server(s) is finished. Software inventory occurs once every 12 hours.
Software inventory identifies the SQL Server instances that are running on the
servers. Using the information it collects, the appliance attempts to connect to the
SQL Server instances through the Windows authentication credentials or the SQL
Server authentication credentials that are provided on the appliance. It gathers
data on SQL Server databases and their properties. The SQL Server discovery is
performed once every 24 hours.
Software inventory identifies the web server role on the servers. Using the
information it collects, the appliance attempts to connect to the IIS web server
through the Windows authentication credentials that are provided on the
appliance. It gathers data on web apps. The web app discovery is performed once
every 24 hours.
Discovery of installed applications might take longer than 15 minutes. The duration
depends on the number of discovered servers. For 500 servers, it takes
approximately one hour for the discovered inventory to appear in the Azure
Migrate project in the portal.
SQL Server instances and databases data and web apps data begin to appear in
the portal within 24 hours after you start discovery.
Next steps
Review the tutorials for VMware assessment and tutorials for agentless migration.
Set up an appliance for servers on
Hyper-V
Follow this article to set up the Azure Migrate appliance for discovery and assessment of
servers on Hyper-V with the Azure Migrate: Discovery and assessment tool.
The Azure Migrate appliance is a lightweight appliance used by Azure Migrate:

Discovery and assessment/ Migration to discover on-premises servers on Hyper-V, and
send server metadata/performance data to Azure.
You can deploy the appliance using a couple of methods:
Set up on a server on Hyper-V using a downloaded VHD. This method described in

the current article.
Set up on a server on Hyper-V or physical server with a PowerShell installer script.
This method should be used if you can't set up a server using a VHD, or if you're in
Azure Government.
After creating the appliance, you check that it can connect to Azure Migrate: Discovery
and assessment, configure it for the first time, and register it with the project.
７ Note
additional appliances to discover and assess more no of servers.Learn more
Appliance deployment (VHD)

To set up the appliance using a VHD template:
Provide an appliance name and generate a project key in the portal.

Download a compressed Hyper-V VHD from the Azure portal.
Create the appliance, and check that it can connect to Azure Migrate: Discovery
and assessment.
Configure the appliance for the first time, and register it with the project using the
project key.

2. In Discover servers > Are your servers virtualized?, select Yes, with Hyper-V.
you will set up for discovery of servers on Hyper-V. The name should be
4. Click on Generate key to start the creation of the required Azure resources. Do not
6. Copy the key as you will need it to complete the registration of the appliance
during its configuration.
Download the VHD

In 2: Download Azure Migrate appliance, select the .VHD file and click on Download.

Verify security
window.
2. Run the following command to generate the hash for the VHD
Example usage: C:\>Get-FileHash -Path

./AzureMigrateAppliance_v3.20.09.25.zip -Algorithm SHA256
Verify the latest hash value by comparing the outcome of above command to the value
documented here
Create the appliance

Import the downloaded file, and create an appliance.
1. Extract the zipped VHD file to a folder on the Hyper-V host that will host the
appliance. Three folders are extracted.
2. Open Hyper-V Manager. In Actions, click Import Virtual Machine.

3. In the Import Virtual Machine Wizard > Before you begin, click Next.
4. In Locate Folder, specify the folder containing the extracted VHD. Then click Next.
5. In Select Virtual Machine, click Next.
6. In Choose Import Type, click Copy the virtual machine (create a new unique ID).
Then click Next.
7. In Choose Destination, leave the default setting. Click Next.
8. In Storage Folders, leave the default setting. Click Next.
9. In Choose Network, specify the virtual switch that the server will use. The switch
needs internet connectivity to send data to Azure.
10. In Summary, review the settings. Then click Finish.
11. In Hyper-V Manager > Virtual Machines, start the VM.

clouds.

７ Note
If you set up the appliance using a PowerShell script instead of the downloaded
VHD, the first two steps in this procedure aren't relevant.
1. In Hyper-V Manager > Virtual Machines, right-click the server > Connect.
2. Provide the language, time zone, and password for the appliance.
3. Open a browser on any system that can connect to the appliance, and open the
Alternately, you can open the app from the appliance desktop by clicking the app
shortcut.
steps:
uses a proxy:

７ Note

that's shown.
to see the prompt.
７ Note

Delegate credentials for SMB VHDs

If you're running VHDs on SMBs, you must enable delegation of credentials from the
appliance to the Hyper-V hosts. To do this from the appliance:
1. On the appliance, run this command. HyperVHost1/HyperVHost2 are example host

names.
Enable-WSManCredSSP -Role Client -DelegateComputer
HyperVHost1.contoso.com, HyperVHost2.contoso.com, HyperVHost1,
HyperVHost2 -Force
2. Alternatively, do this in the Local Group Policy Editor on the appliance:
In Local Computer Policy > Computer Configuration, click Administrative

Templates > System > Credentials Delegation.
Double-click Allow delegating fresh credentials, and select Enabled.
In Options, click Show, and add each Hyper-V host you want to discover to
the list, with wsman/ as a prefix.
In Credentials Delegation, double-click Allow delegating fresh credentials
with NTLM-only server authentication. Again, add each Hyper-V host you
want to discover to the list, with wsman/ as a prefix.

Connect from the appliance to Hyper-V hosts or clusters, and start discovery.
Provide Hyper-V host/cluster details

1. In Step 1: Provide Hyper-V host credentials, click on Add credentials to specify a
friendly name for credentials, add Username and Password for a Hyper-V
host/cluster that the appliance will use to discover servers. Click on Save.
2. If you want to add multiple credentials at once, click on Add more to save and add
more credentials. Multiple credentials are supported for the discovery of servers on
Hyper-V.
3. In Step 2: Provide Hyper-V host/cluster details, click on Add discovery source to

specify the Hyper-V host/cluster IP address/FQDN and the friendly name for
credentials to connect to the host/cluster.
4. You can either Add single item at a time or Add multiple items in one go. There is
also an option to provide Hyper-V host/cluster details through Import CSV.
If you choose Add single item, you need to specify friendly name for
credentials and Hyper-V host/cluster IP address/FQDN and click on Save.
If you choose Add multiple items (selected by default), you can add multiple
records at once by specifying Hyper-V host/cluster IP address/FQDN with the
friendly name for credentials in the text box. Verify** the added records and
click on Save.
If you choose Import CSV, you can download a CSV template file, populate
the file with the Hyper-V host/cluster IP address/FQDN and friendly name for
credentials. You then import the file into the appliance, verify the records in
the file and click on Save.
5. On clicking Save, appliance will try validating the connection to the Hyper-V
hosts/clusters added and show the Validation status in the table against each
host/cluster.
For successfully validated hosts/clusters, you can view more details by
clicking on their IP address/FQDN.
If validation fails for a host, review the error by clicking on Validation failed in
the Status column of the table. Fix the issue, and validate again.
To remove hosts or clusters, click on Delete.
You can't remove a specific host from a cluster. You can only remove the
entire cluster.
You can add a cluster, even if there are issues with specific hosts in the
cluster.
6. You can revalidate the connectivity to hosts/clusters anytime before starting the
discovery.

In Step 3: Provide server credentials to perform software inventory and agentless
dependency analysis and to discover SQL Server instances and databases, you can
provide multiple server credentials. If you don't want to use any of these appliance
features, you can skip this step and proceed with discovery of servers running on Hyper-
V hosts/clusters. You can change this option at any time.
If you want to use these features, provide server credentials by completing the following
steps. The appliance attempts to automatically map the credentials to the servers to
perform the discovery features.

You can provide domain/, Windows(non-domain)/, Linux(non-domain) credentials.

Learn how to provide credentials and how we handle them.
A friendly name.
A username.
If you choose to use domain credentials, you also must enter the FQDN for the
domain. The FQDN is required to validate the authenticity of the credentials with
the Active Directory instance in that domain.
4. Review the required permissions on the account for discovery of installed

applications and agentless dependency analysis.
5. To add multiple credentials at once, select Add more to save credentials, and then
add more credentials. When you select Save or Add more, the appliance validates
the domain credentials with the domain's Active Directory instance for
authentication. Validation is made after each addition to avoid account lockouts as
during discovery, the appliance iterates to map credentials to respective servers.
In the configuration manager, in the credentials table, see the Validation status for
domain credentials. Only domain credentials are validated.
If validation fails, you can select the Failed status to see the validation error. Fix the
issue, and then select Revalidate credentials to reattempt validation of the credentials.
Start discovery
Click on Start discovery, to kick off server discovery from the successfully validated
host(s)/cluster(s). After the discovery has been successfully initiated, you can check the
discovery status against each host/cluster in the table.
How discovery works

It takes approximately 2 minutes per host for metadata of discovered servers to
If you have provided server credentials, software inventory (discovery of installed
applications) is automatically initiated when the discovery of servers running on
Hyper-V host(s)/cluster(s) is finished. Software inventory occurs once every 12
hours.

2. In Servers, databases and web apps > Azure Migrate: Discovery and assessment
page, click the icon that displays the count for Discovered servers.
Next steps
Try out Hyper-V assessment with Azure Migrate: Discovery and assessment.
 Documentation
Support for Hyper-V assessment in Azure Migrate - Azure Migrate

Learn about support for Hyper-V assessment with Azure Migrate Discovery and assessment
assessment
Migrate
Assess Hyper-V VMs for migration to Azure VMs with Azure Migrate - Azure Migrate
Learn how to assess Hyper-V VMs for migration to Azure VMs with Azure Migrate.


Provide server credentials to discover software inventory, dependencies, web apps,

and SQL Server instances and databases - Azure Migrate
Learn how to provide server credentials on appliance configuration manager
Show 5 more
Set up an appliance with a script
Follow this article to deploy an Azure Migrate appliance using a PowerShell script for:
discovery, assessment and agentless replication of servers running in VMware

environment
discovery and assessment of servers running in Hyper-V environment.
You can deploy the appliance for servers on VMware and on Hyper-V by either using a
script, or using a template (OVA/VHD) that you download from the Azure portal. Using a
script is useful if you're unable to create an appliance using the downloaded template.
To use a template, follow the tutorials for VMware and Hyper-V.

To set up an appliance for physical servers, you can only use a script. Follow this
article.
To set up an appliance in an Azure Government cloud, you can only use a script.
Follow this article.
Prerequisites
You can use the script to deploy the Azure Migrate appliance on an existing server in
your VMware or Hyper-V environment.
The server that hosts the appliance must meet the following hardware and OS
requirements:
Scenario Requirements
VMware Windows Server 2016, with 32 GB of memory, eight vCPUs, around 80 GB of disk
storage.
Hyper-V Windows Server 2016, with 16 GB of memory, eight vCPUs, around 80 GB of disk
storage.
The server also needs an external virtual switch. It requires a static or dynamic IP
address.
Before you deploy the appliance, review detailed appliance requirements for
VMware and Hyper-V.
If you run the script on a server with Azure Migrate appliance already set up, you
can choose to clean up the existing configuration and set up a fresh appliance of
the desired configuration. When you execute the script, you will get a notification
as shown below:
Set up the appliance for VMware

1. To set up the appliance, you download the zipped file named
AzureMigrateInstaller.zip either from the portal or from here .
2. Extract the contents on the server where you want to deploy the appliance.
4. Set up the appliance and configure it for the first time.
Verify security
window.

Download Hash value
version
７ Note
The same script can be used to set up VMware appliance for either Azure public or
Azure Government cloud.
Run the script

1. Extract the zipped file to a folder on the server that will host the appliance.
７ Note
Make sure you don't run the script on a server with an existing Azure Migrate
appliance. Running the script on the Azure Migrate appliance will remove the
working configuration and replace it with newly defined configuration.

command:
appliance to discover, assess and migrate servers running in your VMware
environment to an Azure Migrate project with default (public endpoint)
connectivity on Azure public cloud.

Install Windows roles, including Windows Activation Service, IIS, and PowerShell
ISE.
Config Files: %ProgramData%\Microsoft Azure\Config
Log Files: %ProgramData%\Microsoft Azure\Logs
７ Note
Verify access
Make sure that the appliance can connect to Azure URLs for the public cloud.
Set up the appliance for Hyper-V

Verify security
window.

Download Hash value
version
７ Note
The same script can be used to set up Hyper-V appliance for either Azure public or
Run the script

1. Extract the zipped file to a folder on the server that will host the appliance.
７ Note
Make sure you don't run the script on an existing Azure Migrate appliance. Running
the script on the Azure Migrate appliance will remove the working configuration
and replace it with newly defined configuration.

command:
appliance to discover and assess servers running in your Hyper-V environment to
an Azure Migrate project with default (public endpoint) connectivity on Azure
public cloud.

Install Windows roles, including Windows Activation Service, IIS, and
PowerShell ISE.
Migrate.
７ Note
Verify access
Make sure that the appliance can connect to Azure URLs for the public cloud.
Next steps
After deploying the appliance, you need to configure it for the first time, and register it
with project.
Set up the appliance for VMware.

Set up the appliance for Hyper-V.
Set up an appliance for physical servers
This article describes how to set up the Azure Migrate appliance if you're assessing
physical servers with the Azure Migrate: Discovery and assessment tool.
The Azure Migrate appliance is a lightweight appliance, used by Azure Migrate:

Discovery and assessment to do the following:

Send metadata and performance data for discovered servers to Azure Migrate:
Discovery and assessment.
After creating the appliance, you check that it can connect to Azure Migrate: Discovery
and assessment, configure it for the first time, and register it with the project.
７ Note
additional appliances to discover and assess more no of servers.Learn more
Appliance deployment steps

To set up the appliance you:

3. Extract the contents from the zipped file. Launch the PowerShell console with
administrative privileges.
5. Configure the appliance for the first time, and register it with the project using the
project key.

GCP, Xen, etc.).
you will set up for discovery of physical or virtual servers. The name should be
4. Click on Generate key to start the creation of the required Azure resources. Do not
6. Copy the key as you will need it to complete the registration of the appliance
during its configuration.
Download the installer script

In 2: Download Azure Migrate appliance, click on Download.
Verify security
window.

Download Hash value

Download Hash value
version
７ Note
The same script can be used to set up Physical appliance for either Azure public or
Run the Azure Migrate installer script


command:
endpoint) connectivity on Azure public cloud.

PowerShell ISE.
Migrate.
７ Note

clouds.

1. Open a browser on any machine that can connect to the appliance, and open the
Alternately, you can open the app from the desktop by clicking the app shortcut.

steps:
uses a proxy:

７ Note

that's shown.
to see the prompt.
７ Note

Now, connect from the appliance to the physical servers to be discovered, and start the
discovery.
1. In Step 1: Provide credentials for discovery of Windows and Linux physical or

virtual servers, click on Add credentials.
2. For Windows server, select the source type as Windows Server, specify a friendly
name for credentials, add the username and password. Click on Save.
3. If you are using password-based authentication for Linux server, select the source
type as Linux Server (Password-based), specify a friendly name for credentials,
add the username and password. Click on Save.
4. If you are using SSH key-based authentication for Linux server, you can select
source type as Linux Server (SSH key-based), specify a friendly name for
credentials, add the username, browse, and select the SSH private key file. Click on
Save.
Azure Migrate supports the SSH private key generated by ssh-keygen

command using RSA, DSA, ECDSA, and ed25519 algorithms.
Currently Azure Migrate does not support passphrase-based SSH key. Use an
SSH key without a passphrase.
Currently Azure Migrate does not support SSH private key file generated by
PuTTY.
Azure Migrate supports OpenSSH format of the SSH private key file as shown
below:
5. If you want to add multiple credentials at once, click on Add more to save and add
more credentials. Multiple credentials are supported for physical servers discovery.
７ Note
By default, the credentials will be used to gather data about the installed
applications, roles, and features, and also to collect dependency data from
Windows and Linux servers, unless you disable the slider to not perform these
features (as instructed in the last step).
6. In Step 2:Provide physical or virtual server details, click on Add discovery source
to specify the server IP address/FQDN and the friendly name for credentials to
connect to the server.
7. You can either Add single item at a time or Add multiple items in one go. There is
also an option to provide server details through Import CSV.
If you choose Add single item, you can choose the OS type, specify friendly
name for credentials, add server IP address/FQDN and click on Save.
If you choose Add multiple items, you can add multiple records at once by
specifying server IP address/FQDN with the friendly name for credentials in
the text box. Verify** the added records and click on Save.
If you choose Import CSV (selected by default), you can download a CSV
template file, populate the file with the server IP address/FQDN and friendly
name for credentials. You then import the file into the appliance, verify the
records in the file and click on Save.
8. On clicking Save, appliance will try validating the connection to the servers added
and show the Validation status in the table against each server.
If validation fails for a server, review the error by clicking on Validation failed
in the Status column of the table. Fix the issue, and validate again.
To remove a server, click on Delete.
9. You can revalidate the connectivity to servers anytime before starting the
discovery.
10. Before initiating discovery, you can choose to disable the slider to not perform
software inventory and agentless dependency analysis on the added servers. You
can change this option at any time.
11. To perform discovery of SQL Server instances and databases, you can add
additional credentials (Windows domain/non-domain, SQL authentication
credentials) and the appliance will attempt to automatically map the credentials to
the SQL servers. If you add domain credentials, the appliance will authenticate the
credentials against Active Directory of the domain to prevent any user accounts
from locking out. To check validation of the domain credentials, follow these steps:
In the configuration manager credentials table, see Validation status for domain
credentials. Only the domain credentials are validated.
If validation fails, you can select a Failed status to see the validation error. Fix the
issue, and then select Revalidate credentials to reattempt validation of the
credentials.
Start discovery
Click on Start discovery, to kick off discovery of the successfully validated servers. After
the discovery has been successfully initiated, you can check the discovery status against
each server in the table.
How discovery works

It takes approximately 2 minutes to complete discovery of 100 servers and their
metadata to appear in the Azure portal.
Software inventory (discovery of installed applications) is automatically initiated
when the discovery of servers is finished.
The time taken for discovery of installed applications depends on the number of
discovered servers. For 500 servers, it takes approximately one hour for the


2. In Servers, databases and web apps > Azure Migrate: Discovery and assessment
page, click the icon that displays the count for Discovered servers.
Next steps
Try out assessment of physical servers with Azure Migrate: Discovery and assessment.
Set up an appliance for Azure
Government cloud
Follow this article to deploy an Azure Migrate appliance for Azure Government cloud to
perform:
Discovery, assessment and agentless replication of servers running in VMware

environment
Discovery and assessment of servers running in Hyper-V environment
Discovery and assessment of physical servers or servers running on other clouds
like AWS, GCP, Xen etc.
If you want to set up an appliance in the public cloud, follow this article.
７ Note
The option to deploy an appliance using a template (for servers running in VMware
or Hyper-V environment) isn't supported in Azure Government. You need to use the
installer script only.
Prerequisites
You can use the script to deploy the Azure Migrate appliance on an existing physical or
a virtualized server.
The server that will act as the appliance must be running Windows Server 2016 and
meet other requirements for VMware, Hyper-V, and physical servers.
If you run the script on a server with Azure Migrate appliance already set up, you
can choose to clean up the existing configuration and set up a fresh appliance of
the desired configuration. When you execute the script, you will get a notification
as shown below:
Set up the appliance for VMware

Download the script

Discovery and assessment, click Discover.
2. In Discover server > Are your servers virtualized?, select Yes, with VMware
vSphere hypervisor.
4. Click Download, to download the zipped file.
Verify security
window.

Download Hash value
version
Run the script



command:
appliance to discover, assess and migrate servers running in your VMware
connectivity on Azure Government cloud.

PowerShell ISE.
Migrate.
Verify access
Make sure that the appliance can connect to Azure URLs for government clouds.
Set up the appliance for Hyper-V

Download the script

2. In Discover servers > Are your servers virtualized?, select Yes, with Hyper-V.
Verify security
window.

Download Hash value
version
Run the script

command:
appliance to discover and assess servers running in your Hyper-V environment to
an Azure Migrate project with default (public endpoint) connectivity on Azure
Government cloud.

PowerShell ISE.
Migrate.
Verify access
Set up the appliance for physical servers

Download the script

GCP, Xen etc.).
Verify security
window.

Download Hash value
version
７ Note
The same script can be used to set up Physical appliance for Azure Government
cloud with either public or private endpoint connectivity.
Run the script



command:
endpoint) connectivity on Azure Government cloud.

PowerShell ISE.
Migrate.
７ Note
Verify access
Next steps
After deploying the appliance, you need to configure it for the first time, and register it
with the project.
Set up the appliance for VMware.

Set up the appliance for Hyper-V.
Set up the appliance for physical servers.
Set discovery scope for servers in
VMware vSphere environment
This article describes how to limit the scope of discovery for servers in VMware vSphere
environment when you are:
Discovering servers with the Azure Migrate appliance when you're using the Azure
Discovering servers with the Azure Migrate appliance when you're using the
Migration and modernization tool, for agentless migration of servers from VMware
vSphere environment to Azure.
When you set up the appliance, it connects to vCenter Server and starts discovery.
Before you connect the appliance to vCenter Server, you can limit discovery to vCenter
Server datacenters, clusters, a folder of clusters, hosts, a folder of hosts, or individual
servers. To set the scope, you assign permissions on the account that the appliance uses
to access the vCenter Server.
Before you start

If you haven't set up a vCenter Server user account that Azure Migrate uses for
discovery, do that now for assessment or agentless migration.
Assign permissions and roles

You can assign permissions on VMware vSphere inventory objects using one of two
methods:
On the account used by the appliance, assign a role with the required permissions
on the objects you want to scope.
Alternatively, assign a role to the account at the data center level, and propagate
to the child objects. Then give the account a No access role, for every object that
you don't want in scope. We don't recommend this approach since it's
cumbersome, and might expose access controls, because every new child object is
automatically granted access inherited from the parent.
You can't scope inventory discovery at the vCenter Server folder level. If you need to
scope discover to servers in a folder, create a user and grant access individually to each
required server. Host and cluster folders are supported.
Assign a role for assessment
1. On the appliance vCenter Server account you're using for discovery, apply the
Read-only role for all parent objects that host servers you want to discover and
assess (host, cluster, hosts folder, clusters folder, up to datacenter).
2. Propagate these permissions to child objects in the hierarchy.
Assign a role for agentless migration

1. On the appliance vCenter Server account you're using for migration, apply a user-
defined role that has the permissions needed, to all parent objects that host
servers you want to discover and migrate.
2. You can name the role with something that's easier to identify. For example,
Azure_Migrate.
Work around for server folder restriction

Currently, the Azure Migrate: Discovery and assessment tool can't discover servers if
access is granted at the vCenter Server folder level. If you do want to scope your
discovery and assessment by server folders, use this workaround.
1. Assign read-only permissions on all servers located in the folders you want to
scope for discovery and assessment.
2. Grant read-only access to all the parent objects that host the servers host, cluster,
hosts folder, clusters folder, up to data center). You don't need to propagate the
permissions to all child objects.
3. To use the credentials for discovery, select the datacenter as Collection Scope.
The role-based access control setup ensures that the corresponding vCenter user
account has access to only tenant-specific servers.
Next steps
Provide server credentials to discover
software inventory, dependencies, web
apps, and SQL Server instances and
databases
Article • 04/13/2023
Follow this article to learn how to add multiple server credentials on the appliance
configuration manager to perform software inventory (discover installed applications),
agentless dependency analysis, and discover web apps, SQL Server instances and
databases.
The Azure Migrate appliance is a lightweight appliance used by Azure Migrate:

Discovery and assessment to discover on-premises servers and send server
configuration and performance metadata to Azure. The appliance can also be used to
perform software inventory, agentless dependency analysis and discover of web app,
and SQL Server instances and databases.
７ Note
Currently, the discovery of ASP.NET web apps is only available in the appliance
used for discovery and assessment of servers running in a VMware environment.
If you want to use these features, you can provide server credentials by following the
steps below. For servers running on vCenter Server(s) and Hyper-V host(s)/cluster(s), the
appliance will attempt to automatically map the credentials to the servers to perform
the discovery features.
Add server credentials
Types of server credentials supported

You can add multiple server credentials on the appliance configuration manager, which
can be domain, non-domain (Windows or Linux) or SQL Server authentication
credentials.
The types of server credentials supported are listed in the table below:
Type of Description
credentials
Domain You can add Domain credentials by selecting the option from the drop-down
credentials in the Add credentials modal.
To provide domain credentials, you need to specify the Domain name which
must be provided in the FQDN format (for example, prod.corp.contoso.com).
You also need to specify a friendly name for credentials, username, and
password. It's recommended to provide the credentials in the UPN format, for
example, user1@contoso.com.
The domain credentials added will be automatically validated for authenticity

against the Active Directory of the domain. This is to prevent any account
lockouts when the appliance attempts to map the domain credentials against
discovered servers.
To validate the domain credentials with the domain controller, the appliance
should be able to resolve the domain name. Ensure that you've provided the
correct domain name while adding the credentials else the validation will fail.
The appliance won't attempt to map the domain credentials that have failed
validation. You need to have at least one successfully validated domain
credential or at least one non-domain credential to start the discovery.
The domain credentials mapped automatically against the Windows servers

will be used to perform software inventory and can also be used to discover
web apps, and SQL Server instances and databases (if you've configured
Windows authentication mode on your SQL Servers).
Learn more about the types of authentication modes supported on SQL
Servers.
Non-domain You can add Windows (Non-domain) or Linux (Non-domain) by selecting

credentials the required option from the drop-down in the Add credentials modal.
(Windows/Linux)
You need to specify a friendly name for credentials, username, and password.
Type of Description
credentials
SQL Server You can add SQL Server Authentication credentials by selecting the option
Authentication from the drop-down in the Add credentials modal.
credentials
You need to specify a friendly name for credentials, username, and password.
You can add this type of credentials to discover SQL Server instances and
databases running in your VMware environment, if you've configured SQL
Server authentication mode on your SQL Servers.
Learn more about the types of authentication modes supported on SQL
Servers.
You need to provide at least one successfully validated domain credential or

at least one Windows (Non-domain) credential so that the appliance can
complete the software inventory to discover SQL installed on the servers
before it uses the SQL Server authentication credentials to discover the SQL
Check the permissions required on the Windows/Linux credentials to perform the

software inventory, agentless dependency analysis and discover web apps, and SQL
Required permissions
The table below lists the permissions required on the server credentials provided on the
appliance to perform the respective features:
Feature Windows Linux credentials

credentials
Software Guest user account Regular/normal user account (non-sudo access

inventory permissions)
Discovery User account that is a Not supported currently

of SQL member of the
Server sysadmin server role
instances or has these
and permissions for each
databases SQL Server instance.
Discovery Domain or non- Not supported currently

of ASP.NET domain (local)
web apps account with
administrative
permissions
Feature Windows Linux credentials
credentials
Agentless Domain or non- Sudo user account with permissions to execute ls and
dependency domain (local) netstat commands. If you are providing a sudo user
analysis account with account, ensure that you have enabled NOPASSWD for
administrative the account to run the required commands without
permissions prompting for a password every time the sudo command
is invoked.
Alternatively, you can create a user account that has the

CAP_DAC_READ_SEARCH and CAP_SYS_PTRACE
permissions on /bin/netstat and /bin/ls files, set using the
following commands:
sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep
/bin/ls
sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep
/bin/netstat
Recommended practices to provide credentials

It's recommended to create a dedicated domain user account with the required
permissions, which is scoped to perform software inventory, agentless dependency
analysis and discovery of web app, and SQL Server instances and databases on the
desired servers.
It's recommended to provide at least one successfully validated domain credential
or at least one non-domain credential to initiate software inventory.
To discover SQL Server instances and databases, you can provide domain
credentials, if you've configured Windows authentication mode on your SQL
Servers.
You can also provide SQL Server authentication credentials if you've configured
SQL Server authentication mode on your SQL Servers but it's recommended to
provide at least one successfully validated domain credential or at least one
Windows (Non-domain) credential so that the appliance can first complete the
software inventory.
Credentials handling on appliance

All the credentials provided on the appliance configuration manager are stored
locally on the appliance server and not sent to Azure.
The credentials stored on the appliance server are encrypted using Data Protection
API (DPAPI).
After you've added credentials, appliance attempts to automatically map the
credentials to perform discovery on the respective servers.
The appliance uses the credentials automatically mapped on a server for all the
subsequent discovery cycles until the credentials are able to fetch the required
discovery data. If the credentials stop working, appliance again attempts to map
from the list of added credentials and continue the ongoing discovery on the
server.
The domain credentials added will be automatically validated for authenticity
against the Active Directory of the domain. This is to prevent any account lockouts
when the appliance attempts to map the domain credentials against discovered
servers. The appliance won't attempt to map the domain credentials that have
failed validation.
If the appliance can't map any domain or non-domain credentials against a server,
you'll see "Credentials not available" status against the server in your project.
Next steps
Review the tutorials for discovery of servers running in your VMware environment or
Hyper-V environment or for discovery of physical servers.
Discover installed software inventory,
web apps, and SQL Server instances and
databases
This article describes how to discover installed software inventory, web apps, and SQL
Server instances and databases on servers running in your on-premises environment,
using the Azure Migrate: Discovery and assessment tool.
Performing software inventory helps identify and tailor a migration path to Azure for
your workloads. Software inventory uses the Azure Migrate appliance to perform
discovery, using server credentials. It's completely agentless - no agents are installed on
the servers to collect this data.
Before you start

Ensure that you've created a project with the Azure Migrate: Discovery and
assessment tool added to it.
Review the requirements based on your environment and the appliance you're
setting up to perform software inventory:
Environment Requirements
Servers running in VMware environment Review VMware requirements

Review appliance requirements
Review port access requirements
Review software inventory
requirements
Servers running in Hyper-V environment Review Hyper-V host requirements

requirements
Physical servers or servers running on other Review server requirements

clouds Review appliance requirements
requirements
Review the Azure URLs that the appliance needs to access in the public and
government clouds.
Deploy and configure the Azure Migrate

appliance
1. Deploy the Azure Migrate appliance to start discovery. To deploy the appliance,
you can use the deployment method as per your environment. After deploying the
appliance, you need to register it with the project and configure it to initiate the
discovery.
2. As you configure the appliance, you need to specify the following in the appliance
configuration manager:
The details of the source environment (vCenter Server(s) /Hyper-V host(s) or

cluster(s)/physical servers) which you want to discover.
Server credentials, which can be domain/ Windows (non-domain)/ Linux
(non-domain) credentials. Learn more about how to provide credentials and
how the appliance handles them.
Verify the permissions required to perform software inventory. You need a
guest user account for Windows servers, and a regular/normal user account
(non-sudo access) for all Linux servers.
Add credentials and initiate discovery

1. Open the appliance configuration manager, complete the prerequisite checks and
registration of the appliance.
2. Navigate to the Manage credentials and discovery sources panel.
3. In Step 1: Provide credentials for discovery source, select on Add credentials to
provide credentials for the discovery source that the appliance uses to discover
servers running in your environment.
4. In Step 2: Provide discovery source details, select Add discovery source to select
the friendly name for credentials from the drop-down, specify the IP
address/FQDN of the discovery source.
5. In Step 3: Provide server credentials to perform software inventory and

agentless dependency analysis, select Add credentials to provide multiple server
credentials to perform software inventory.
6. Select Start discovery, to initiate discovery.
After the server discovery is complete, appliance initiates the discovery of installed
applications, roles, and features (software inventory) on the servers. The duration
depends on the number of discovered servers. For 500 servers, it takes approximately
one hour for the discovered inventory to appear in the Azure Migrate portal. After the
initial discovery is complete, software inventory data is collected and sent to Azure once
every 24 hours.Review the data collected by appliance during software inventory.
Review and export the inventory

After software inventory has completed, you can review and export the inventory in the
Azure portal.
1. In Azure Migrate - Servers, databases and web apps > Azure Migrate: Discovery
and assessment, select the displayed count to open the Discovered servers page.
７ Note
At this stage you can optionally also enable dependency analysis for the
discovered servers, so that you can visualize dependencies across servers you
want to assess. Learn more about dependency analysis.
2. In Software inventory column, select the displayed count to review the discovered
applications, roles, and features.
3. To export the inventory, in Discovered Servers, select Export software inventory.
The software inventory is exported and downloaded in Excel format. The Software
Inventory sheet displays all the apps discovered across all the servers.
Discover SQL Server instances and databases

Software inventory also identifies the SQL Server instances running in your
VMware, Microsoft Hyper-V and Physical/ Bare-metal environments as well as IaaS
services of other public cloud.
If you haven't provided Windows authentication or SQL Server authentication

credentials on the appliance configuration manager, then add the credentials so
that the appliance can use them to connect to respective SQL Server instances.
７ Note
Appliance can connect to only those SQL Server instances to which it has
network line of sight, whereas software inventory by itself may not need
network line of sight.
The sign-in used to connect to a source SQL Server instance requires sysadmin role.
Once connected, the appliance gathers configuration and performance data of SQL
Server instances and databases. The SQL Server configuration data is updated once
every 24 hours and the performance data is captured every 30 seconds. Hence, any
change to the properties of the SQL Server instance and databases such as database
status, compatibility level etc. can take up to 24 hours to update on the portal.
Discover ASP.NET web apps

Software inventory identifies web server role existing on discovered servers. If a
server has web server role enabled, Azure Migrate performs web apps discovery on
the server.
User can add both domain and non-domain credentials on appliance. Make sure
automatically maps credentials to the respective servers, so one doesn’t have to
map them manually. Most importantly, these credentials are never sent to
Microsoft and remain on the appliance running in source environment.
After the appliance is connected, it gathers configuration data for IIS web server
and ASP.NET web apps. Web apps configuration data is updated once every 24
hours.
７ Note
Currently the discovery of ASP.NET web apps is only available with appliance used
for discovery of servers running in your VMware environment.
Next steps
Create an assessment for discovered servers.
Assess web apps for migration to Azure App Service.
Discover web apps and SQL Server
instances in an existing project
Article • 04/13/2023
This article describes how to discover web apps and SQL Server instances and databases
in an Azure Migrate project that was created before the preview of Azure SQL
assessment feature and/or before the preview of Azure App Service assessment feature.
Discovering web apps and SQL Server instances and databases running on on-premises
machines helps identify and tailor a migration path to Azure. The Azure Migrate
appliance performs this discovery using the Windows OS domain or non-domain
credentials or SQL Server authentication credentials that have access to the SQL Server
instances and databases running on the targeted servers. This discovery process is
agentless that is, nothing is installed on the target servers.
Before you start

Make sure you've:
Created an Azure Migrate project before the announcement of SQL and web
apps assessment feature for your region
Added the Azure Migrate: Discovery and assessment tool to a project
Review app-discovery support and requirements.
In case you're discovering assets on a VMware environment, make sure the servers
where you're running app discovery have PowerShell version 2.0 or later installed,
and VMware tools (later than 10.2.0) installed.
Check the requirements for deploying the Azure Migrate appliance.
Verify that you have the required roles in the subscription to create resources.
Ensure that your appliance has access to the internet
７ Note
Though the procedure described in this article is for VMware, the processes are
similar for Microsoft Hyper-V and Physical environments. Discovery and assessment
for SQL Server instances and databases is available across the Microsoft Hyper-V
and Physical environments.
Enable discovery of web apps and SQL Server
instances and databases
1. In your Azure Migrate project, either
Select Not enabled on the Hub tile, or
Select Not enabled on any entry in the Server discovery page under SQL
instances or Web apps column
2. To discover web apps and SQL Server instances and databases follow the steps
entailed:
Select Upgrade, to create the required resource.
Validate that the services running on the appliance are updated to the latest
versions. To do so, launch the Appliance configuration manager from your
appliance server and select view appliance services from the Setup
prerequisites panel.
Appliance and its components are automatically updated
In the manage credentials and discovery sources panel of the Appliance
configuration manager, add Domain or SQL Server Authentication credentials
that have Sysadmin access on the SQL Server instance and databases to be
discovered or have these permissions for each SQL Server instance.
Web apps discovery works with both domain and non-domain Windows OS
credentials as long as the account used has local admin privileges on servers.
You can leverage the automatic credential-mapping feature of the appliance,
as highlighted here.
Some points to note:
Ensure that software inventory is enabled already, or provide Domain or Non-

domain credentials to enable the same. Software inventory must be
performed to discover SQL Server instances and web apps.
Appliance will attempt to validate the Domain credentials with AD, as they're
added. Ensure that appliance server has network line of sight to the AD server
associated with the credentials. Non-domain credentials and credentials
associated with SQL Server Authentication aren't validated.
3. Once the desired credentials are added, select Start Discovery, to begin the scan.
７ Note
Allow web apps and SQL discovery to run for sometime before creating
assessments for Azure App Service or Azure SQL. If the discovery of web apps and
SQL Server instances and databases is not allowed to complete, the respective
instances are marked as Unknown in the assessment report.
Next steps
Learn how to create an Azure SQL assessment.
Learn more about Azure SQL assessments.
Learn how to create an Azure App Service assessment.
Learn more about Azure App Service assessments.
Set up dependency visualization
This article describes how to set up agent-based dependency analysis in Azure Migrate:
Discovery and assessment. Dependency analysis helps you to identify and understand
dependencies across servers you want to assess and migrate to Azure.
Before you start

Review the support and deployment requirements for agent-based dependency
analysis for:
Servers in VMware environment
Physical servers
Servers in Hyper-V environment
Make sure you:
Have an Azure Migrate project. If you don't, create one now.
Check that you've added the Azure Migrate: Discovery and assessment tool to
the project.
Set up an Azure Migrate appliance to discover on-premises servers. The
appliance discovers on-premises servers, and sends metadata and performance
data to Azure Migrate: Discovery and assessment. Set up an appliance for:
Servers in VMware environment
Servers in Hyper-V environment
Physical servers
To use dependency visualization, you associate a Log Analytics workspace with an
Azure Migrate project:
You can attach a workspace only after setting up the Azure Migrate appliance,
and discovering servers in the Azure Migrate project.
Make sure you have a workspace in the subscription that contains the Azure
Migrate project.
You can associate a new or existing Log Analytics workspace with an Azure
Migrate project.
You attach the workspace the first time that you set up dependency
visualization for a server. The workspace for an Azure Migrate project can't be
modified after it's added.
In Log Analytics, the workspace associated with Azure Migrate is tagged with
the Migration Project key, and the project name.
Associate a workspace
1. After you've discovered servers for assessment, in Servers > Azure Migrate:
Discovery and assessment, click Overview.
2. In Azure Migrate: Discovery and assessment, click Essentials.
3. In OMS Workspace, click Requires configuration.
4. In Configure OMS workspace, specify whether you want to create a new

workspace, or use an existing one.
You can select an existing workspace from all the workspaces in the project
subscription.
You need Reader access to the workspace to associate it.
5. If you create a new workspace, select a location for it.
７ Note
Learn how to configure the OMS workspace for private endpoint connectivity.
Download and install the VM agents
On each server you want to analyze, install the agents.
７ Note
For servers monitored by System Center Operations Manager 2012 R2 or later, you
don't need to install the MMA agent. Service Map integrates with Operations
Manager. Follow integration guidance.
1. In Azure Migrate: Discovery and assessment, click Discovered servers.
2. Click Columns to select Dependencies (Agent-based) to see the column on the

Discovered servers page.
3. For each server you want to analyze with dependency visualization, in the
Dependencies column, click Requires agent installation.
4. In the Dependencies page, download the MMA and Dependency agent for
Windows or Linux.
5. Under Configure MMA agent, copy the workspace ID and key. You need these
when you install the MMA agent.
Install the MMA
Install the MMA on each Windows or Linux server you want to analyze.
Install MMA on a Windows server

To install the agent on a Windows server:
1. Double-click the downloaded agent.

2. On the Welcome page, click Next. On the License Terms page, click I Agree to
accept the license.
3. In Destination Folder, keep or modify the default installation folder > Next.
4. In Agent Setup Options, select Azure Log Analytics > Next.
5. Click Add to add a new Log Analytics workspace. Paste in the workspace ID and
key that you copied from the portal. Click Next.
You can install the agent from the command line or using an automated method such as
Configuration Manager or Intigua.
Learn more about using these methods to install the MMA agent.
The MMA agent can also be installed using this script .
Learn more about the Windows operating systems supported by MMA.
Install MMA on a Linux server

To install the MMA on a Linux server:
1. Transfer the appropriate bundle (x86 or x64) to your Linux computer using
scp/sftp.
2. Install the bundle by using the --install argument.
sudo sh ./omsagent-<version>.universal.x64.sh --install -w <workspace id> -s

<workspace key>
Learn more about the list of Linux operating systems support by MMA.
Install the Dependency agent

1. To install the Dependency agent on a Windows server, double-click the setup file
and follow the wizard.
2. To install the Dependency agent on a Linux server, install as root using the
following command:
sh InstallDependencyAgent-Linux64.bin
Learn more about how you can use scripts to install the Dependency agent.
Learn more about the operating systems supported by the Dependency agent.
Create a group using dependency visualization

Now create a group for assessment.
７ Note
Groups for which you want to visualize dependencies shouldn't contain more than
10 servers. If you have more than 10 servers, split them into smaller groups.
2. In the Dependencies column, click View dependencies for each server you want to
review.
3. On the dependency map, you can see the following:
Inbound (clients) and outbound (servers) TCP connections, to and from the
server.
Dependent servers that don't have the dependency agents installed are
grouped by port numbers.
Dependent servers with dependency agents installed are shown as separate
boxes.
Processes running inside the server. Expand each server box to view the
processes.
Server properties (including FQDN, operating system, MAC address). Click on
each server box to view the details.
4. You can look at dependencies for different time durations by clicking on the time
duration in the time range label.
By default the range is an hour.

You can modify the time range, or specify start and end dates, and duration.
Time range can be up to an hour. If you need a longer range, use Azure
Monitor to query dependent data for a longer period.
5. After you've identified the dependent servers that you want to group together, use
Ctrl+Click to select multiple servers on the map, and click Group machines.
6. Specify a group name.
7. Verify that the dependent servers are discovered by Azure Migrate.
If a dependent server isn't discovered by Azure Migrate: Discovery and

assessment, you can't add it to the group.
To add a server, run discovery again, and verify that the server is discovered.
8. If you want to create an assessment for this group, select the checkbox to create a
new assessment for the group.
9. Click OK to save the group.
After creating the group, we recommend that you install agents on all the servers in the
group, and then visualize dependencies for the entire group.
Query dependency data in Azure Monitor

You can query dependency data captured by Service Map in the Log Analytics
workspace associated with the Azure Migrate project. Log Analytics is used to write and
run Azure Monitor log queries.
Learn how to search for Service Map data in Log Analytics.

Get an overview of writing log queries in Log Analytics.
Run a query for dependency data as follows:

1. After you install the agents, go to the portal and click Overview.
2. In Azure Migrate: Discovery and assessment, click Overview. Click the down arrow
to expand Essentials.
3. In OMS Workspace, click the workspace name.
4. On the Log Analytics workspace page > General, click Logs.
5. Write your query, and click Run.
Sample queries
Here are a few sample queries that you can use to extract dependency data.
You can modify the queries to extract your preferred data points.
Review a complete list of dependency data records.
Review additional sample queries.
Sample: Review inbound connections

Review inbound connections for a set of servers.
The records in the table for connection metrics (VMConnection) don't represent
individual physical network connections.
Multiple physical network connections are grouped into a logical connection.
Learn more about how physical network connection data is aggregated in
VMConnection.
// the servers of interest

let ips=materialize(ServiceMapComputer_CL
| summarize ips=makeset(todynamic(Ipv4Addresses_s)) by
MonitoredMachine=ResourceName_s
| mvexpand ips to typeof(string));
let StartDateTime = datetime(2019-03-25T00:00:00Z);
let EndDateTime = datetime(2019-03-30T01:00:00Z);
VMConnection
| where Direction == 'inbound'
| where TimeGenerated > StartDateTime and TimeGenerated < EndDateTime
| join kind=inner (ips) on $left.DestinationIp == $right.ips
| summarize sum(LinksEstablished) by Computer, Direction, SourceIp,
DestinationIp, DestinationPort
Sample: Summarize sent and received data

This sample summarizes the volume of data sent and received on inbound connections
between a set of servers.
// the servers of interest

VMConnection
| summarize sum(BytesSent), sum(BytesReceived) by Computer, Direction,
SourceIp, DestinationIp, DestinationPort
Next steps
Create an assessment for a group.
 Documentation

Set the scope for discovery of servers on VMware vSphere with Azure Migrate - Azure
Migrate
Describes how to set the discovery scope for servers hosted on VMware vSphere assessment and
migration with Azure Migrate.


assessment


Show 5 more
Analyze server dependencies (agentless)
This article describes how to set up agentless dependency analysis using Azure Migrate:
Discovery and assessment tool. Dependency analysis helps you to identify and
understand dependencies across servers for assessment and migration to Azure.
Current limitations
In the dependency analysis view, you currently cannot add or remove a server from
a group.
A dependency map for a group of servers isn't currently available.
In an Azure Migrate project, you can enable dependency data collection
concurrently for 1000 servers per appliance.
You can analyze more than 1000 servers per project either by enabling
dependency analysis concurrently on servers discovered by multiple appliances or
by sequencing in batches of 1000 for servers discovered from one appliance.
Before you start

Ensure that you have created a project with the Azure Migrate: Discovery and
Review the requirements based on your environment and the appliance you are
setting up to perform software inventory:
Servers running in VMware environment Review VMware requirements

Review agentless dependency analysis
requirements
Servers running in Hyper-V environment Review Hyper-V host requirements

requirements
Physical servers or servers running on other Review server requirements

clouds Review appliance requirements
requirements
Review the Azure URLs that the appliance will need to access in the public and
government clouds.
Deploy and configure the Azure Migrate

appliance
1. Deploy the Azure Migrate appliance to start discovery. To deploy the appliance,
you can use the deployment method as per your environment. After deploying the
appliance, you need to register it with the project and configure it to initiate the
discovery.
2. As you configure the appliance, you need to specify the following in the appliance
The details of the source environment (vCenter Server(s)/Hyper-V host(s) or

cluster(s)/physical servers) which you want to discover.
Server credentials, which can be domain/ Windows (non-domain)/ Linux
(non-domain) credentials. Learn more about how to provide credentials and
how the appliance handles them.
Verify the permissions required to perform agentless dependency analysis.
For Windows servers, you need to provide domain or non-domain (local)
account with administrative permissions. For Linux servers, provide a sudo
user account with permissions to execute ls and netstat commands or create
a user account that has the CAP_DAC_READ_SEARCH and CAP_SYS_PTRACE
permissions on /bin/netstat and /bin/ls files. If you're providing a sudo user
account, ensure that you have enabled NOPASSWD for the account to run
the required commands without prompting for a password every time sudo
command is invoked.
Add credentials and initiate discovery

1. Open the appliance configuration manager, complete the prerequisite checks and
registration of the appliance.
2. Navigate to the Manage credentials and discovery sources panel.
3. In Step 1: Provide credentials for discovery source, click on Add credentials to
provide credentials for the discovery source that the appliance will use to discover
servers running in your environment.
4. In Step 2: Provide discovery source details, click on Add discovery source to
select the friendly name for credentials from the drop-down, specify the IP
address/FQDN of the discovery source.
5. In Step 3: Provide server credentials to perform software inventory and

agentless dependency analysis, click Add credentials to provide multiple server
credentials to perform software inventory.
6. Click on Start discovery, to initiate discovery.
After the server discovery is complete, appliance initiates the discovery of installed
applications, roles and features (software inventory) on the servers. During software
inventory, the discovered servers are validated to check if they meet the prerequisites
and can be enabled for agentless dependency analysis.
７ Note
You can enable agentless dependency analysis for discovered servers from Azure
Migrate project. Only the servers where the validation succeeds can be selected to
enable agentless dependency analysis.
After servers have been enabled for agentless dependency analysis from portal,
appliance gathers the dependency data every 5 mins from the server and sends an
aggregated data point every 6 hours to Azure. Review the data collected by appliance
during agentless dependency analysis.
Start dependency discovery

Select the servers on which you want to enable dependency discovery.

2. Choose the Appliance name whose discovery you want to review.
3. You can see the validation status of the servers under Dependencies (agentless)
column.
4. Click the Dependency analysis drop-down.
5. Click Add servers.
6. In the Add servers page, select the servers where you want to enable dependency
analysis. You can enable dependency mapping only on those servers where
validation succeeded. The next validation cycle will run 24 hours after the last
validation timestamp.
7. After selecting the servers, click Add servers.
You can visualize dependencies around six hours after enabling dependency analysis on
servers. If you want to simultaneously enable multiple servers for dependency analysis,
you can use PowerShell to do so.
Visualize dependencies
3. Search for the server whose dependencies, you want to review.
4. Under the Dependencies (agentless) column, click View dependencies
5. Change the time period for which you want to view the map using the Time
duration dropdown.
6. Expand the Client group to list the servers with a dependency on the selected
server.
7. Expand the Port group to list the servers that have a dependency from the
selected server.
8. To navigate to the map view of any of the dependent servers, click on the server
name > Load server map
9. Expand the selected server to view process-level details for each dependency.
７ Note
Process information for a dependency is not always available. If it's not available,
the dependency is depicted with the process marked as "Unknown process".
Export dependency data

3. Click Export application dependencies.
4. In the Export application dependencies page, choose the appliance name that is
discovering the desired servers.
5. Select the start time and end time. Note that you can download the data only for
the last 30 days.
6. Click Export dependency.
The dependency data is exported and downloaded in a CSV format. The downloaded
file contains the dependency data across all servers enabled for dependency analysis.
Dependency information
Each row in the exported CSV corresponds to a dependency observed in the specified
time slot.
The following table summarizes the fields in the exported CSV. Note that server name,
application and process fields are populated only for servers that have agentless
dependency analysis enabled.
Field name Details
Timeslot The timeslot during which the dependency was observed.

Dependency data is captured over 6-hour slots currently.
Source server name Name of the source server
Source application Name of the application on the source server
Source process Name of the process on the source server

Field name Details
Destination server name Name of the destination server
Destination IP IP address of the destination server
Destination application Name of the application on the destination server
Destination process Name of the process on the destination server
Destination port Port number on the destination server
Stop dependency discovery

Select the servers on which you want to stop dependency discovery.

4. Click Remove servers.
5. In the Remove servers page, select the server, which you want to stop for
dependency analysis.
6. After selecting the servers,click Remove servers.
If you want to stop dependency simultaneously on multiple servers, you can use
PowerShell to do so.
Start or stop dependency analysis using

PowerShell
Download the PowerShell module from Azure PowerShell Samples repo on GitHub.
Log in to Azure
1. Log into your Azure subscription using the Connect-AzAccount cmdlet.
PowerShell
Connect-AzAccount
If using Azure Government, use the following command.
PowerShell
Connect-AzAccount -EnvironmentName AzureUSGovernment
2. Select the subscription in which you have created the project
PowerShell
select-azsubscription -subscription "Fabrikam Demo Subscription"
3. Import the downloaded AzMig_Dependencies PowerShell module
PowerShell
Import-Module .\AzMig_Dependencies.psm1
Enable or disable dependency data collection

1. Get the list of discovered servers in your project using the following commands. In
the example below, the project name is FabrikamDemoProject, and the resource
group it belongs to is FabrikamDemoRG. The list of servers will be saved in
FabrikamDemo_VMs.csv
PowerShell
Get-AzMigDiscoveredVMwareVMs -ResourceGroupName "FabrikamDemoRG" -

ProjectName "FabrikamDemoProject" -OutputCsvFile "FabrikamDemo_VMs.csv"
In the file, you can see the server display name, current status of dependency
collection and the ARM ID of all discovered servers.
2. To enable or disable dependencies, create an input CSV file. The file is required to
have a column with header "ARM ID". Any additional headers in the CSV file will be
ignored. You can create the CSV using the file generated in the previous step.
Create a copy of the file retaining the servers you want to enable or disable
dependencies on.
In the following example, dependency analysis is being enabled on the list of

servers in the input file FabrikamDemo_VMs_Enable.csv.
PowerShell
Set-AzMigDependencyMappingAgentless -InputCsvFile
.\FabrikamDemo_VMs_Enable.csv -Enable
In the following example, dependency analysis is being disabled on the list of
servers in the input file FabrikamDemo_VMs_Disable.csv.
PowerShell
Set-AzMigDependencyMappingAgentless -InputCsvFile
.\FabrikamDemo_VMs_Disable.csv -Disable
Visualize network connections in Power BI

Azure Migrate offers a Power BI template that you can use to visualize network
connections of many servers at once, and filter by process and server. To visualize, load
the Power BI with dependency data as per the below instructions.
1. Download the PowerShell module and the Power BI template from Azure
PowerShell Samples repo on GitHub.
2. Log in to Azure using the below instructions:
Log into your Azure subscription using the Connect-AzAccount cmdlet.
PowerShell
Connect-AzAccount
If using Azure Government, use the following command.
PowerShell
Connect-AzAccount -EnvironmentName AzureUSGovernment
Select the subscription in which you have created the project
PowerShell
select-azsubscription -subscription "Fabrikam Demo Subscription"
3. Import the downloaded AzMig_Dependencies PowerShell module
PowerShell
Import-Module .\AzMig_Dependencies.psm1
4. Run the following command. This command downloads the dependencies data in
a CSV and processes it to generate a list of unique dependencies that can be used
for visualization in Power BI. In the example below the project name is
FabrikamDemoProject, and the resource group it belongs to is FabrikamDemoRG.
The dependencies will be downloaded for servers discovered by
FabrikamAppliance. The unique dependencies will be saved in
FabrikamDemo_Dependencies.csv
PowerShell
Get-AzMigDependenciesAgentless -ResourceGroup FabrikamDemoRG -Appliance

FabrikamAppliance -ProjectName FabrikamDemoProject -OutputCsvFile
"FabrikamDemo_Dependencies.csv"
5. Open the downloaded Power BI template
6. Load the downloaded dependency data in Power BI.
Open the template in Power BI.

Click on Get Data on the tool bar.
Choose Text/CSV from Common data sources.
Choose the dependencies file downloaded.
Click Load.
You will see a table is imported with the name of the CSV file. You can see the
table in the fields bar on the right. Rename it to AzMig_Dependencies
Click on refresh from the tool bar.
The Network Connections chart and the Source server name, Destination server
name, Source process name, Destination process name slicers should light up with
the imported data.
7. Visualize the map of network connections filtering by servers and processes. Save
your file.
Next steps
Group servers for assessment.
 Documentation



Migrate



Show 5 more
Build a business case (preview)
Article • 04/28/2023
This article describes how to build a Business case for on-premises servers and
workloads in your datacenter with Azure Migrate: Discovery and assessment tool.
provides Azure tools for assessment and migration, and third-party independent
software vendor (ISV) offerings.
Prerequisites
Make sure you've created an Azure Migrate project. You can also reuse an existing
project to use this capability.
Once you've created a project, the Azure Migrate: Discovery and assessment tool is
automatically added to the project.
Before you build the Business case, you need to first discover your IT estate. You
can choose one of the two discovery sources based on your use case:

collected sends metadata and performance (resource Service), Modernize
via Azure utilization) data to Azure Migrate. Learn more. to PaaS (Platform as a
Migrate Service)
appliance
quick and import in Azure Migrate to get a quick business (Infrastructure as a
business case based on the provided inputs. You don't need to Service)
case using set up the Azure Migrate appliance to discover
the servers for this option.
servers
imported
via a .csv
file
Business case overview


for cloud.
and SQL versions.
Other key features:
Business case:

Strategy
Strategy
For web apps, sizing and cost comes

from Azure App Service assessment is
picked.
For general servers, sizing and cost

comes from Azure VM assessment.
as a Service)
PaaS recommendation that means, the from the Instance to Azure SQL MI report.
(Platform as a logic identifies workloads best fit for
Service) PaaS targets. For web apps, sizing and cost comes
from Azure App Service assessment.
General servers are recommended
with a quick lift and shift For general servers, sizing and cost
recommendation to Azure IaaS. comes from Azure VM assessment.
７ Note

Build a business case

assess and migrate.

2. In Azure Migrate: Discovery and assessment, select Build business case.
We recommend that you wait at least a day after starting discovery before you
build a Business case so that enough performance/resource utilization data points
are collected. Also, review the Notifications/Resolve issues blades on the Azure
Migrate hub to identify any discovery related issues prior to Business case
computation. It ensures that the IT estate in your datacenter is represented more
accurately and the Business case recommendations are more valuable.
3. In Business case name, specify a name for the Business case. Make sure the
Business case name is unique within a project, else the previous Business case with
the same name gets recomputed.
4. In Target location, specify the Azure region to which you want to migrate.
Azure SKU size and cost recommendations are based on the location that you
specify.
5. In Discovery source, specify the discovery source on which you wish to create the
business case. The options to build the business case using data discovered via the
appliance or imported via a .csv file is present based on the type of discovered
servers present in your project. The discovery source will be defaulted to the
option chosen by you while building the business case and you won't be able to
update this field later.
6. In Migration strategy, specify the migration strategy for your Business case:
With the default Azure recommended approach to minimize cost, you can get
the most cost-efficient and compatible target recommendation in Azure
across Azure IaaS and Azure PaaS targets.
With Migrate to all IaaS (Infrastructure as a Service), you can get a quick lift
and shift recommendation to Azure IaaS.
With Modernize to PaaS (Platform as a Service), you can get cost effective
recommendations for Azure IaaS and more PaaS preferred targets in Azure
PaaS.
7. In Savings options, specify the savings options combination that you want to be
considered while optimizing your Azure costs and maximize savings. Based on the
availability of the savings option in the chosen region and the targets, the business
case recommends the appropriate savings options to maximize your savings on
Azure.
Choose 'Reserved Instance', if your datacenter comprises most consistently

running resources.
Choose 'Reserved Instance + Azure Savings Plan', if you want additional
flexibility and automated cost optimization for workloads applicable for
Azure Savings Plan (Compute targets including Azure VM and Azure App
Service).
8. In Discount (%) on Pay as you go, add any subscription-specific discounts you
receive on top of the Azure offer. The default setting is 0%. The discount isn't
applicable on top of reserved instance savings option.
9. Currency is defaulted to USD and can't be edited.
10. Review the chosen inputs, and select Build business case.
11. You're directed to the newly created Business case with a banner that says that
your Business case is computing. The computation might take some time,
depending on the number of servers and workloads in the project. You can come
back to the Business case page after ~30 minutes and select Refresh.
Next steps
View a business case (preview)
Article • 04/25/2023
This article describes how to review the business case reports for on-premises servers
and workloads in your datacenter with Azure Migrate: Discovery and assessment tool.
provides Azure tools for assessment and migration, as well as third-party Independent
Software Vendor (ISV) offerings.
Prerequisites
Build a business case if you have not built one already.
Review the business case

There are four major reports that you need to review:
Overview: This report is an executive summary of the business case and covers:
Potential savings (TCO).
Estimated year on year cashflow savings based on the estimated migration
completed that year.
Savings from unique Azure benefits like Azure Hybrid Benefit.
Discovery insights covering the scope of the business case.
On-premises vs Azure: This report covers the breakdown of the total cost of
ownership by cost categories and insights on savings.
Azure IaaS: This report covers the Azure and on-premises footprint of the servers
and workloads recommended for migrating to Azure IaaS.
Azure PaaS: This report covers the Azure and on-premises footprint of the
workloads recommended for migrating to Azure PaaS.
View a business case

select the number below Total migration business cases.
2. In Business Case, select a business case to open it. As an example (estimations and

Overview report
Potential savings
This card covers your potential total cost of ownership savings based on the chosen
migration strategy. It includes one year savings from compute, storage, network, labor,
and facilities cost (based on assumptions) to help you envision how Azure benefits can
turn into cost savings. You can see the insights of different cost categories in the On-
premises vs Azure report.
Estimated on-premises cost

It covers the cost of running all the servers scoped in the business case using some of
the industry benchmarks. It doesn't cover Facilities (lease/colocation/power) cost by
default, but you can edit it in the on-premises cost assumptions section. It includes one
time cost for some of the capital expenditures like hardware acquisition etc., and annual
cost for other components that you might pay as operating expenses like maintenance
etc.
Estimated Azure cost

It covers the cost of all servers and workloads that have been identified as ready for
migration/modernization as per the recommendation. Refer to the respective Azure IaaS
and Azure PaaS report for details. The Azure cost is calculated based on the right sized
Azure configuration, ideal migration target and most suitable pricing offers for your
workloads. You can override the migration strategy, target location or other settings in
the 'Azure cost' assumptions to see how your savings could change by migrating to
Azure.
YoY estimated current vs future state cost

As you plan to migrate to Azure in phases, this line chart shows your cashflow per year
based on the estimated migration completed that year. By default, it's assumed that
you'll migrate 0% in the current year, 20% in Year 1, 50% in Year 2, and 100% in Year 3.
Current state cost shows how your net cashflow will be on-premises, given your
infrastructure is growing 5% per year.
The future state cost shows how your net cashflow will be as you migrate some
percentage to Azure per year as in the 'Azure cost' assumptions, while your
infrastructure is growing 5% per year.
Savings with Azure Hybrid Benefits

Currently, this card shows a static percentage of max savings you could get with Azure
hybrid Benefits.
Discovery insights
It covers the total severs scoped in the business case computation, virtualization
distribution, utilization insights and distribution of servers based on workloads running
on them.
Utilization insights
It covers which servers are ideal for cloud, servers that can be decommissioned on-
premises, and servers that can't be classified based on resource utilization/performance
data:
Ideal for cloud: These servers are best fit for migrating to Azure and comprises of
active and idle servers:
Active servers: These servers delivered business value by being on and had their
CPU and memory utilization above 5% and network utilization above 2%.
Idle servers: These servers were on but didn't deliver business value by having
their CPU and memory utilization below 5% and network utilization below 2%.
Decommission: These servers were expected to deliver business value, but didn't
and can be decommissioned on-premises and recommended to not migrate to
Azure:
Zombie: The CPU, memory and network utilization were 0% with no
performance data collection issues.
These servers were on but don't have adequate metrics available:
Unknown: Many servers can land in this section if the discovery is still ongoing
or has some unaddressed discovery issues.
On-premises vs Azure report

It covers cost components for on-premises and Azure, savings, and insights to
understand the savings better.
Azure IaaS report

Azure tab
This section contains the cost estimate by recommended target (Annual cost and also
includes Compute, Storage, Network, labor components) and savings from Hybrid
benefits.
Azure VM:
Estimated cost by savings options: This card includes compute cost for Azure
VMs. It is recommended that all idle servers are migrated via Pay as you go
Dev/Test and others (Active and unknown) are migrated using 3 year Reserved
Instance or 3 year Azure Savings Plan to maximize savings.
Recommended VM family: This card covers the VM sizes recommended. The
ones marked Unknown are the VMs that have some readiness issues and no
SKUs could be found for them.
Recommended storage type: This card covers the storage cost distribution
across different recommended storage types.
SQL Server on Azure VM: This section assumes instance to SQL Server on Azure
VM migration recommendation, and the number of VMs here are the number of
instances recommended to be migrated as SQL Server on Azure VM:
Estimated cost by savings options: This card includes compute cost for SQL
Server on Azure VMs. It is recommended that all idle servers are migrated via
Pay as you go Dev/Test and others (Active and unknown) are migrated using 3
year Reserved Instance or 3 year Azure Savings Plan to maximize savings.
Recommended VM family: This card covers the VM sizes recommended. The
ones marked Unknown are the VMs that have some readiness issues and no
SKUs could be found for them.
Recommended storage type: This card covers the storage cost distribution
across different recommended storage types.
On-premises tab
On-premises footprint of the servers recommended to be migrated to Azure IaaS.

Contribution of Zombie servers in the on-premises cost.
Distribution of servers by OS, virtualization, and activity state.
Azure PaaS report

Azure tab
This section contains the cost estimate by recommended target (Annual cost and also
includes Compute, Storage, Network, labor components) and savings from Hybrid
benefits.
Azure SQL:
Estimated cost by savings options: This card includes compute cost for Azure
SQL MI. It is recommended that all idle SQL instances are migrated via Pay as
you go Dev/Test and others (Active and unknown) are migrated using 3 year
Reserved Instance to maximize savings.
Distribution by recommended service tier : This card covers the recommended
service tier.
Azure App Service:
Estimated cost by savings options: This card includes Azure App Service Plans
cost. It is recommended that the web apps are migrated using 3 year Reserved
Instance or 3 year Savings Plan to maximize savings.
Distribution by recommended plans : This card covers the recommended App
Service plan.
On-premises tab
On-premises footprint of the servers recommended to be migrated to Azure PaaS.

Contribution of Zombie SQL instances in the on-premises cost.
Distribution of SQL instances by SQL version and activity state.
Next steps
Learn more about how business cases are calculated.
Add assessment tools
This article describes how to add assessment tools in Azure Migrate.
If you want to add an assessment tool and you don't yet have an Azure Migrate
project, follow this article.
If you've added an ISV tool, or Movere, for assessment, follow the steps, to prepare
to work with the tool.
Select an assessment scenario

1. In the Azure Migrate project, click Overview.
2. Select the assessment scenario:
To discover, assess and migrate servers (physical or virtual) from your

datacenter or other clouds to Azure, select Discover, assess and migrate. You
can now also discover and assess SQL Server from your VMware environment
using this migration goal.
To assess on-premises SQL Server databases, select Assess and migrate
databases.
To assess or migrate on-premises web apps, select Explore more > Web
Apps.
To assess your virtual desktop infrastructure, select Explore more > Virtual
Desktop Infrastructure.
Select a discovery and assessment tool
1. Add a tool:
If you created an Azure Migrate project using the Assess and migrate servers
option in the portal, the Azure Migrate Discovery and assessment tool is
automatically added to the project. To add additional assessment tools, in
Windows, Linux and SQL Server, next to Assessment tools, select Add more
tools.
If you created a project using a different option, and don't yet have any
assessment tools, in Windows, Linux and SQL Server > Assessment tools,
select Click here.
2. In Azure Migrate > Add tools, select the tools you want to add. Then select Add
tool.
Select a database assessment tool
1. Add a tool:
If you created an Azure Migrate project using the Assess and migrate
database option in the portal, the Database Assessment tool is automatically
added to the project. To add additional assessment tools, in Databases, next
to Assessment tools, select Add more tools.
database assessment tools, in Databases > Assessment tools, select Click
here.
tool.
Select a web app assessment tool
If you created an Azure Migrate project using the Explore more > WebApps option in
the portal, the Web App Assessment tool is automatically added to the project.
1. If the Web App Assessment tool isn't in the project, in Web Apps > Assessment
tools, select Click here.
2. In Azure Migrate > Add tools, select the Web app assessment tool. Then select
Add tool.
Next steps
Discover on-premises servers for assessment using Azure Migrate Discovery and
assessment tool for VMware, Hyper-V, or physical servers
Create a group for assessment
This article describes how to create groups of servers for assessment with Azure
Migrate: Discovery and assessment.
Azure Migrate helps you to migrate to Azure. Azure Migrate provides a centralized hub
to track discovery, assessment, and migration of on-premises infrastructure,
applications, and data to Azure. The hub provides Azure tools for assessment and
migration, as well as third-party independent software vendor (ISV) offerings.
Grouping servers
You gather servers into groups to assess whether they're suitable for migration to Azure,
and to get Azure sizing and cost estimations for them. There are a couple of ways to
create groups:
If you know the servers that need be migrated together, you can manually create
the group in Azure Migrate.
If you are not sure about the servers that need to be grouped together, you can
use the dependency visualization functionality in Azure Migrate to create groups.
７ Note
The dependency visualization functionality is not available in Azure Government.
Create a group manually

You can create a group at the same time that you create an assessment.
If you want to create a group manually outside of creating an assessment, do the

following:
1. In the Azure Migrate project > Overview, click Assess and migrate servers. In
Azure Migrate: Discovery and assessment, click Groups
If you haven't yet added the Azure Migrate: Discovery and assessment tool,
click to add it. Learn more.
If you haven't yet created an Azure Migrate project, learn more.
2. Click the Group icon.
3. In Create group, specify a group name, and in Appliance name, select the Azure
Migrate appliance you're using for server discovery.
4. From the server list, select the servers you want to add to the group > Create.
You can now use this group when you create an Azure VM assessment or an Azure
VMware Solution (AVS) assessment or an Azure SQL assessment or an Azure App Service
assessment.
Refine a group with dependency mapping

Dependency mapping helps you to visualize dependencies across servers. You typically
use dependency mapping when you want to assess server groups with higher levels of
confidence.
It helps you to cross-check server dependencies, before you run an assessment.

It also helps to effectively plan your migration to Azure, by ensuring that nothing is
left behind, and thus avoiding surprise outages during migration.
You can discover interdependent systems that need to migrate together, and
identify whether a running system is still serving users, or is a candidate for
decommissioning instead of migration.
If you've already set up dependency mapping, and want to refine an existing group, do
the following:
1. In the Servers tab, in Azure Migrate: Discovery and assessment tile, click Groups.
2. Click the group you want to refine.
If you haven't yet set up dependency mapping, the Dependencies column

will show a Requires installation status. For each server for which you want to
visualize dependencies, click Requires installation. Install a couple of agents
on each server, before you can map the server dependencies. Learn more.
If you've already set up dependency mapping, on the group page, click View
dependencies to open the group dependency map.
3. After clicking View dependencies, the group dependency map shows the
following:
Inbound (clients) and outbound (servers) TCP connections to and from all
servers in the group that have the dependency agents installed.
Dependent servers that don't have the dependency agents installed are
grouped by port numbers.
Dependent servers with dependency agents installed are shown as separate
boxes.
Processes running inside the server. Expand each server box to view the
processes.
Server properties (including FQDN, operating system, MAC address). Click on
each server box to view the details.
4. To view dependencies in a time interval of your choice, modify the time range (an
hour by default) by specifying start and end dates, or the duration.
７ Note
Time range can be up to an hour. If you need a longer range, use Azure
Monitor to query dependent data for a longer period.
5. After you've identified the dependencies you would like to add to or remove from
the group, you can modify the group. Use Ctrl+Click to add or remove servers
from the group.
You can only add servers that have been discovered.

Adding and removing servers invalidates past assessments for a group.
You can optionally create a new assessment when you modify the group.
Next steps
Learn how to set up and use dependency mapping to create high confidence groups.
Create an Azure VM assessment
This article describes how to create an Azure VM assessment for on-premises servers in
your VMware, Hyper-V or physical/other cloud environments with Azure Migrate:
Discovery and assessment.
migration, as well as third-party Independent Software Vendor (ISV) offerings.
Before you start

Make sure you've created an Azure Migrate project.
If you've already created a project, make sure you've added the Azure Migrate:
To create an assessment, you need to set up an Azure Migrate appliance for
VMware or Hyper-V. The appliance discovers on-premises servers, and sends
metadata and performance data to Azure Migrate: Discovery and assessment.
Learn more.
Azure VM Assessment overview

There are two types of sizing criteria that you can use to create an Azure VM assessment
using Azure Migrate: Discovery and assessment.
Performance- Assessments based Recommended VM size: Based on CPU and memory

based on collected utilization data.
performance data.
Recommended disk type (standard or premium
managed disk): Based on the IOPS and throughput of
the on-premises disks.
As on- Assessments based Recommended VM size: Based on the on-premises VM

premises on on-premises size.
sizing.
Recommended disk type: Based on the storage type
setting you select for the assessment.
Run an assessment
assess and migrate.
2. In Azure Migrate: Discovery and assessment, select Assess and select Azure VM.
3. The Create assessment wizard appears with Azure VM as the Assessment type.
Once you change the target location from default, you'll be prompted to
In Azure Government, you can target assessments in these regions.
In Storage type,
Automatic for Azure Migrate to recommend a storage type, based on disk
migrate it.
assessment to consider to help optimize your Azure compute cost. - Azure
reservations (1 year or 3 year reserved) are a good option for the most consistently
running resources. - Azure Savings Plan (1 year or 3 year savings plan) provide
additional flexibility and automated cost optimization. Ideally post migration, you
could use Azure reservation and savings plan at the same time (reservation will be
consumed first), but in the Azure Migrate assessments, you can only see cost
estimates of 1 savings option at a time. - When you select 'None', the Azure
compute cost is based on the Pay as you go rate or based on actual usage. - You
need to select pay-as-you-go in offer/licensing program to be able to use
other than 'None', the 'Discount (%)' and 'VM uptime' properties are not
applicable.
1. In VM Size:
In Sizing criterion, select if you want to base the assessment on server

performance data:
base the assessment.
In VM Series, specify the Azure VM series that you want to consider.

value for you.
Tweak the settings as needed. For example, if you don't have a production
two:
Cores 2 4
Memory 8 GB 16 GB
2. In Pricing:

In VM Uptime, specify the duration (days per month/hour per day) that the
VMs will run.
assessment.
Next.
10. Select the name of the assessment that you want to view.
11. Select Export assessment to download it as an Excel file.

７ Note

Review an Azure VM assessment

An Azure VM assessment describes:
Azure readiness: Whether servers are suitable for migration to Azure.

View an Azure VM assessment

select the number next to Azure VM.

Review Azure readiness

1. In Azure readiness, verify whether servers are ready for migration to Azure.
2. Review the server status:
Ready: Azure Migrate recommends a VM size and cost estimates for VMs in
the assessment.
Not ready: Shows issues and suggested remediation.
Readiness unknown: Used when Azure Migrate can't assess readiness, due to
data availability issues.
3. Select an Azure readiness status. You can view server readiness details and drill
down to see server details, including compute, storage, and network settings.
Review cost details

This view shows the estimated compute and storage cost of running VMs in Azure.
1. Review the monthly compute and storage costs. Costs are aggregated for all
servers in the assessed group.
Cost estimates are based on the size recommendations for a server, and its
disks and properties.
The cost estimation is for running the on-premises servers as IaaS VMs. Azure
VM assessment doesn't consider PaaS or SaaS costs.
2. You can review monthly storage cost estimates. This view shows aggregated
storage costs for the assessed group, split over different types of storage disks.
3. You can drill down to see details for specific servers.

When you run performance-based assessments, a confidence rating is assigned to the
assessment.
A rating from 1-star (lowest) to 5-star (highest) is awarded.

The confidence rating helps you estimate the reliability of the size
recommendations provided by the assessment.
The confidence rating is based on the availability of data points needed to
compute the assessment.
Confidence ratings for an assessment are as follows.
0%-20% 1 Star
21%-40% 2 Star
41%-60% 3 Star
61%-80% 4 Star
81%-100% 5 Star
Next steps
Learn how to use dependency mapping to create high confidence groups.
Learn more about how assessments are calculated.
Create an Azure SQL assessment
shows you how to assess discovered SQL instances in preparation for migration to Azure
SQL, using the Azure Migrate: Discovery and assessment tool.
Before you start

Make sure you've created an Azure Migrate project and have the Azure Migrate:
Discovery and assessment tool added.
VMware, Hyper-V or Physical environment, whichever applicable. The appliance
discovers on-premises servers, and sends metadata and performance data to
Azure Migrate. Learn more.
Azure SQL assessment overview

You can create an Azure SQL assessment with sizing criteria as Performance-based.
Performance- Assessments The recommended Azure SQL configuration is based on

based based on performance data of SQL instances and databases, which includes
collected CPU usage, core counts, database file organizations and sizes, file
performance IOs, batch query per second and memory size and usage by each
data of the database.
Learn more about Azure SQL assessments.
Run an assessment
migrate servers.

appliance.
settings
settings prices.

offer.
recommended SKU.
(PaaS)


settings Server on




pricing
settings
settings

configuration.
GB.

sizing



Managed
Instance
sizing

Managed
Instance
sizing
from this list.




Database
sizing

Database model
sizing

Database
sizing

recovery region.
properties

availability intent
be lost.


availability

Virtual Machines.


out.

assessment.
select Next.
latest updates.
７ Note



Discovered entities
this assessment.

conditions:


Managed Instances.
More.
７ Note

Instance.
on Azure VM.
Review readiness




MI

on Azure VM

on Azure VM

SQL DB

deployment type.

assessed group.

example:

recommended.

0%-20% 1 star
21%-40% 2 stars
41%-60% 3 stars
61%-80% 4 stars
81%-100% 5 stars

Next steps
Service.
 Documentation
Assess SQL Server readiness to migrate to Azure SQL Database - Data Migration
Assistant
Learn how to use Data Migration Assistant to migrate a SQL Server data estate for migration to
Azure SQL Database
Get Azure recommendations for your SQL Server migration

Learn how to use the Azure SQL Migration extension in Azure Data Studio to get SKU
recommendation when you migrate SQL Server databases to the Azure SQL Managed Instance, SQL
Server on Azure Virtual Machines, or Azure SQL Database.
Save and load assessments with Data Migration Assistant - SQL Server
Learn how to use Data Migration Assistant to save and load assessments.
Azure SQL assessments in Azure Migrate Discovery and assessment tool - Azure
Migrate
Learn about Azure SQL assessments in Azure Migrate Discovery and assessment tool
DMACMD: Assess SQL Server readiness to migrate to Azure SQL - Data Migration
Assistant
Learn how to use Data Migration Assistant command line tool (DMACMD) to assess a SQL Server
data estate for migration to Azure SQL
Tutorial to assess SQL instances for migration to SQL Server on Azure VM, Azure SQL
Managed Instance and Azure SQL Database - Azure Migrate
Learn how to create assessment for Azure SQL in Azure Migrate
Migrate availability group - SQL Server on Azure VMs

Learn how to lift and shift your Always On availability group high availability solution to SQL Server
on Azure VMs using Azure Migrate.
SQL Server to SQL Server on Azure VM (Migration overview) - SQL Server on Azure
VMs
Learn about the different migration strategies when you want to migrate your SQL Server to SQL
Server on Azure VMs.
Show 5 more
 Training
Learning path
Plan and implement data platform resources - Training
Plan and implement data platform resources
Certification
Create an Azure App Service assessment
shows you how to assess discovered ASP.NET web apps for migration to Azure App
Service, using the Azure Migrate: Discovery and assessment tool.
７ Note
Discovery and assessment of ASP.NET web apps is now in preview. If you want to
try out this feature in an existing project, please ensure that you have completed
the prerequisites in this article.
Before you start

Make sure you've created an Azure Migrate project and have the Azure Migrate:
Discovery and assessment tool added.
To create an assessment, you need to set up an Azure Migrate appliance. The
appliance discovers on-premises servers, and sends metadata and performance
data to Azure Migrate. The same appliance discovers ASP.NET web apps running in
your environment.
Azure App Service assessment overview

An Azure App Service assessment provides one sizing criteria:
Configuration- Assessment that makes The Azure App Service assessment takes only
based recommendations based configuration data in to consideration for
on collected assessment calculation. Performance data for web
configuration data apps isn't collected.
Learn more about Azure App Service assessments.
Run an assessment
and migrate.
3. In Create assessment, you'll see the assessment type pre-selected as Azure App
Service and the discovery source defaulted to Servers discovered from Azure
Migrate appliance.

Property Details
specify.
Isolation Select Yes if you want your web apps to run in a private and dedicated
required environment in an Azure datacenter using Dv2-series VMs. It provides faster
Standard plans.
(compute)
Azure Savings Plan (1 year or 3 year savings plan) provide more flexibility
and automated cost optimization. Ideally post migration, you could use
Azure reservation and savings plan at the same time (reservation is first), but
in the Azure Migrate assessments, you can only see cost estimates of 1
When you select 'None', the Azure compute cost is based on the Pay as you
go rate or based on actual usage.

use Reserved Instances or Azure Savings Plan. When you select any savings
option other than 'None', the 'Discount (%)' setting isn't applicable. The
monthly cost estimates are calculated by multiplying 744 hours with the
hourly price of the recommended SKU.
Offer The Azure offer in which you're enrolled. The assessment estimates the
cost for that offer.
Property Details
Discount Any subscription-specific discounts you receive on top of the Azure offer.
(%) The default setting is 0%.

assessment.
9. Select the appliance, and select the servers you want to add to the group. Select
Next.
Migrate: Discovery and assessment tile and refresh the tile data by clicking on the
Refresh option on top of the tile. Wait for data to get refreshed.
13. Select the assessment name that you wish to view.
select the number next to Azure App Service assessment.
2. Select the assessment name that you wish to view.

This card indicates the distribution of assessed web apps. You can drill down to
understand details around migration issues/warnings that you can remediate before
migration to Azure App Service. Learn More You can also review the recommended App
Service SKU for migrating to Azure App Service.
Review readiness
app, the readiness is marked as Unknown as the assessment couldn't compute
3. Review the recommended SKU for the web apps that is determined as per the
matrix below:
Yes Yes I1
Yes No I1
No Yes P1v3
No No P1v2
Ready Yes Yes
Not ready No No
Unknown No No
1. Select the App Service plan hyperlink in table to see the App Service plan details
such as compute resources, and other web apps that are part of the same plan.

in the same App Service plan). Whatever apps you put into this App Service plan run on
these compute resources as defined by your App Service plan. To optimize cost, Azure
plan. Number of web apps allocated to each plan instance is as per the table below:
I1 8
P1v2 8
P1v3 16
Next steps
 Documentation
Azure App Service assessments in Azure Migrate Discovery and assessment tool -
Azure Migrate
Learn about Azure App Service assessments in Azure Migrate Discovery and assessment tool
Tutorial to assess web apps for migration to Azure App Service - Azure Migrate
Learn how to create assessment for Azure App Service in Azure Migrate
Prepare Azure Migrate to work with an ISV tool/Movere - Azure Migrate

This article describes how to prepare Azure Migrate to work with an ISV tool or Movere, and then
how to start using the tool.

Review a business case with Azure Migrate - Azure Migrate
Describes how to review a business case with Azure Migrate

Enterprise-scale disaster recovery - Azure Architecture Center

This large-enterprise architecture for SharePoint, Dynamics CRM, and Linux web servers runs on an
on-premises datacenter and fails over to Azure infrastructure.
Build high availability into your BCDR strategy - Azure Architecture Center
Learn how to build high availability of services into your business continuity and disaster recovery
strategy.
Show 5 more
 Training
Module
Migrate an on-premises web application to Azure App Service - Training
Use the Azure App Service Migration Assistant to assess the readiness of a web app to be deployed
on App Service, and perform the migration.
Create an Azure VMware Solution
assessment
Article • 04/18/2023
This article describes how to create an Azure VMware Solution assessment for on-
premises VMs in a VMware vSphere environment with Azure Migrate: Discovery and
assessment.
migration, as well as third-party independent software vendor (ISV) offerings.
Before you start

Make sure you've created an Azure Migrate project.
If you've already created a project, make sure you've added the Azure Migrate:
VMware vSphere, which discovers the on-premises servers, and sends metadata
and performance data to Azure Migrate: Discovery and assessment. Learn more.
You could also import the server metadata in comma-separated values (CSV)
format.
Azure VMware Solution (AVS) Assessment

overview
There are three types of assessments you can create using Azure Migrate: Discovery and
assessment.
*Assessment Details
Type
can assess your on-premises VMs in VMware vSphere and Hyper-V environment,
*Assessment Details
Type
Service servers, from your VMware vSphere environment to Azure App Service.

VMware (AVS). You can assess your on-premises VMs in VMware vSphere environment for
Solution migration to Azure VMware Solution (AVS) using this assessment type. Learn more
(AVS)
７ Note
Azure VMware Solution (AVS) assessment can be created for virtual machines in
VMware vSphere environment only.
There are two types of sizing criteria that you can use to create Azure VMware Solution
(AVS) assessments:
Performance- Assessments based on Recommended Node size: Based on CPU and

based collected performance memory utilization data along with node type,
data of on-premises storage type, and FTT setting that you select for the
servers. assessment.
As on- Assessments based on Recommended Node size: Based on the on-premises

premises on-premises sizing. server size along with the node type, storage type,
and FTT setting that you select for the assessment.
Run an Azure VMware Solution (AVS)

assessment
1. On the Overview page > Servers, databases and web apps, click Assess and
migrate servers.
2. In Azure Migrate: Discovery and assessment, click Assess.
3. In Assess servers > Assessment type, select Azure VMware Solution (AVS).
5. Click Edit to review the assessment properties.
The Storage type is defaulted to vSAN. This is the default storage type for an
Azure VMware Solution private cloud.
In Reserved Instances, specify whether you want to use reserve instances for
Azure VMware Solution nodes when you migrate your VMs.
If you select to use a reserved instance, you can't specify 'Discount (%)
Learn more
7. In VM Size:
The Node type is defaulted to AV36. Azure Migrate recommends the number
of nodes needed to migrate the servers to Azure VMware Solution.
In FTT setting, RAID level, select the Failure to Tolerate and RAID
combination. The selected FTT option, combined with the on-premises server
disk requirement, determines the total vSAN storage required in AVS.
In CPU Oversubscription, specify the ratio of virtual cores associated with
one physical core in the AVS node. Oversubscription of greater than 4:1
might cause performance degradation, but can be used for web server type
workloads.
In Memory overcommit factor, specify the ratio of memory over commit on
the cluster. A value of 1 represents 100% memory use, 0.5 for example is 50%,
and 2 would be using 200% of available memory. You can only add values
from 0.5 to 10 up to one decimal place.
In Dedupe and compression factor, specify the anticipated deduplication
and compression factor for your workloads. Actual value can be obtained
from on-premises vSAN or storage config and this may vary by workload. A
value of 3 would mean 3x so for 300GB disk only 100GB storage would be
used. A value of 1 would mean no dedupe or compression. You can only add
values from 1 to 10 up to one decimal place.
8. In Node Size:
In Sizing criterion, select if you want to base the assessment on static

metadata, or on performance-based data. If you use performance data:
base the assessment
two:
Cores 2 4
Memory 8 GB 16 GB
9. In Pricing:
In Offer, Azure offer you're enrolled in is displayed. The Assessment

10. Click Save if you make changes.

11. In Assess Servers, click Next.
assessment.
14. Select the appliance, and select the servers you want to add to the group. Then
click Next.
15. In Review + create assessment, review the assessment details, and click Create
７ Note

Review an Azure VMware Solution (AVS)

assessment
An Azure VMware Solution (AVS) assessment describes:
Azure VMware Solution (AVS) readiness: Whether the on-premises VMs are
suitable for migration to Azure VMware Solution (AVS).
Number of Azure VMware Solution nodes: Estimated number of Azure VMware
Solution nodes required to run the servers.
Utilization across AVS nodes: Projected CPU, memory, and storage utilization
across all nodes.
Utilization includes up front factoring in the following cluster management
overheads such as the vCenter Server, NSX Manager (large), NSX Edge, if HCX is
deployed also the HCX Manager and IX appliance consuming ~ 44vCPU (11
CPU), 75GB of RAM and 722GB of storage before compression and
deduplication.
Limiting factor determines the number of hosts/nodes required to
accommodate the resources.
Monthly cost estimation: The estimated monthly costs for all Azure VMware
Solution (AVS) nodes running the on-premises VMs.
You can click on Sizing assumptions to understand the assumptions that went in node
sizing and resource utilization calculations. You can also edit the assessment properties,
or recalculate the assessment.
View an assessment
1. In Windows, Linux and SQL Server > Azure Migrate: Discovery and assessment,
click the number next to ** Azure VMware Solution**.

3. Review the assessment summary. You can click on Sizing assumptions to

understand the assumptions that went in node sizing and resource utilization
calculations. You can also edit the assessment properties, or recalculate the
assessment.
Review Azure VMware Solution (AVS) readiness
1. In Azure readiness, verify whether servers are ready for migration to AVS.
2. Review the server status:
Ready for AVS: The server can be migrated as-is to Azure (AVS) without any
changes. It will start in AVS with full AVS support.
Ready with conditions: There might be some compatibility issues example
internet protocol or deprecated OS in VMware and need to be remediated
before migrating to Azure VMware Solution. To fix any readiness problems,
follow the remediation guidance the assessment suggests.
Not ready for AVS: The VM will not start in AVS. For example, if the on-
premises VMware VM has an external device attached such as a cd-rom the
VMware vMotion operation will fail (if using VMware vMotion).
Readiness unknown: Azure Migrate couldn't determine the readiness of the
server because of insufficient metadata collected from the on-premises
environment.
3. Review the Suggested tool:
VMware HCX Advanced or Enterprise: For VMware vSphere VMs, VMware

Hybrid Cloud Extension (HCX) solution is the suggested migration tool to
migrate your on-premises workload to your Azure VMware Solution (AVS)
private cloud. Learn More.
unknown. Though for VMware vSphere VMs, it is suggested to use the
VMware Hybrid Cloud Extension (HCX) solution.
4. Click on an AVS readiness status. You can view VM readiness details, and drill
down to see VM details, including compute, storage, and network settings.
Review cost details

This view shows the estimated cost of running servers in Azure VMware Solution.
1. Review the monthly total costs. Costs are aggregated for all servers in the assessed
group.
Cost estimates are based on the number of AVS nodes required considering
the resource requirements of all the servers in total.
As the pricing for Azure VMware Solution is per node, the total cost does not
have compute cost and storage cost distribution.
The cost estimation is for running the on-premises servers in AVS. AVS
assessment doesn't consider PaaS or SaaS costs.
2. You can review monthly storage cost estimates. This view shows aggregated
storage costs for the assessed group, split over different types of storage disks.
3. You can drill down to see details for specific servers.

When you run performance-based assessments, a confidence rating is assigned to the
assessment.
A rating from 1-star (lowest) to 5-star (highest) is awarded.

The confidence rating helps you estimate the reliability of the size
recommendations provided by the assessment.
The confidence rating is based on the availability of data points needed to
compute the assessment.
For performance-based sizing, AVS assessments need the utilization data for CPU
and server memory. The following performance data is collected but not used in
sizing recommendations for AVS assessments:
The disk IOPS and throughput data for every disk attached to the server.
attached to a server.
Confidence ratings for an assessment are as follows.
0%-20% 1 Star
21%-40% 2 Star
41%-60% 3 Star
61%-80% 4 Star
81%-100% 5 Star
Learn more about performance data
Next steps
Learn how to use dependency mapping to create high confidence groups.
Learn more about how Azure VMware Solution assessments are calculated.
Assess the readiness of a SQL Server
data estate migrating to Azure SQL
Database using the Data Migration
Assistant
Article • 03/03/2023
Migrating hundreds of SQL Server instances and thousands of databases to Azure SQL
Database or Azure SQL Managed Instance, our Platform as a Service (PaaS) offerings, is a
considerable task. To streamline the process as much as possible, you need to feel
confident about your relative readiness for migration. Identifying low-hanging fruit,
including the servers and databases that are fully ready or that require minimal effort to
prepare for migration, eases and accelerates your efforts.
This article provides step-by-step instructions for leveraging the Data Migration
Assistant to summarize readiness results and surface them on the Azure Migrate hub.
７ Note
If you are assessing the entire SQL Server data estate at scale on VMware, use
Azure Migrate to get Azure SQL deployment recommendations, target sizing, and
monthly estimates.
https://channel9.msdn.com/Shows/Data-Exposed/Data-Migration-Assistant/player?
WT.mc_id=dataexposed-c9-niner&nocookie=true&locale=en-
us&embedUrl=%2Fsql%2Fdma%2Fdma-assess-sql-data-estate-to-sqldb
Create a project and add a tool

Set up a new Azure Migrate project in an Azure subscription, and then add a tool.
An Azure Migrate project is used to store discovery, assessment, and migration

metadata collected from the environment you're assessing or migrating. You also use a
project to track discovered assets and to orchestrate assessment and migration.
1. Sign in to the Azure portal, select All services, and then search for Azure Migrate.

3. On the Overview page, select Assess and migrate databases.
4. In Databases, under Getting started, select Add tool(s).

5. On the Migrate project tab, select your Azure subscription and resource group (if
you don't already have a resource group, create one).
6. Under Project Details, specify the project name and the geography in which you
want to create the project.
You can create an Azure Migrate project in any of these geographies.
Geography Storage location region
Asia Southeast Asia or East Asia
Europe South Europe or West Europe
United Kingdom UK South or UK West

Geography Storage location region
United States Central US or West US 2
The geography specified for the project is only used to store the metadata
gathered from on-premises VMs. You can select any target region for the actual
migration.
7. Select Next, and then add an assessment tool.
７ Note
When you create a project, you must add at least one assessment or
migration tool.
8. On the Select assessment tool tab, Azure Migrate: Database Assessment appears
as the assessment tool to add. If you don't currently need an assessment tool,
select the Skip adding an assessment tool for now check box. Select Next.
9. On the Select migration tool tab, Azure Migrate: Database Migration appears as
the migration tool to add. If you don't currently need a migration tool, select the
Skip adding a migration tool for now. Select Next.
10. In Review + add tools, review the settings, and the select Add tools.
After creating the project, you can select additional tools for assessment and
migration of servers and workloads, databases, and web apps.
Assess and upload assessment results

After you successfully create a migration project, under Assessment tools, in the Azure
Migrate: Database Assessment box, instructions for downloading and using the Data
Migration Assistant tool display.
1. Download Data Migration Assistant using the link provided, and then install it on a
computer with access to your source SQL Server instances.
2. Start Data Migration Assistant.
Create an assessment
1. On the left, select the + icon, and then select the assessment Project type
2. Specify the project name, and then select the source server and target server types.
If you're upgrading your on-premises SQL Server instance to a later version of SQL
Server or to SQL Server hosted on an Azure VM, set the source and target server
type to SQL Server. Set the target server type to Azure SQL Managed Instance for
an Azure SQL Database (PaaS) target readiness assessment.
3. Select Create.
Choose assessment options
1. Select the report type.
You can choose one or both of the following report types:
Check database compatibility

Check feature parity
2. Select Next.
Add databases to assess
1. Select Add Sources to open the connection fly out menu.
2. Enter the SQL server instance name, choose the authentication type, set the correct
connection properties, and then select Connect.
3. Select the databases to assess, and then select Add.
７ Note
You can remove multiple databases by selecting them while holding the Shift
or Ctrl key, and then clicking Remove Sources. You can also add databases
from multiple SQL Server instances by using the Add Sources button.
4. Select Next to start the assessment.
5. After the assessment completes, select Upload to Azure Migrate.

6. Sign in to the Azure portal.
7. Select the subscription and Azure Migrate project into which you want to upload
the assessment results, and then select Upload.
Wait for the Assessment upload confirmation.
View target readiness assessment results

1. Sign in the Azure portal, search for Azure migrate, and the select Azure Migrate.
2. Select Assess and migrate databases to get to the assessment results.
You can view the SQL Server readiness summary, make sure that you are on the
right migration project, otherwise, use change option to select a different
migration project.
Each time you update the assessment results to Azure migrate project, Azure
migrate hub consolidate all the results and provide the summary report. You can
execute several Data Migration Assistant assessments in parallel and upload the
results to the single migration project to get the consolidated readiness report.
Assessed database instances: The number of SQL Server instances assessed so far.
Assessed databases: Total number of databases assessed across one or more SQL
Server instances assessed Databases ready for SQL Database: Number of
databases ready to migrate to Azure SQL Database (PaaS). Databases ready for
Azure SQL VM: Number of databases consist one or more migration blockers to
Azure SQL Database (PaaS), but ready to migrate to Azure SQL Server VMs.
3. Select Assessed database instances to get to SQL Server instance level view.
You can find the percentage readiness status of each SQL Server instance
migrating to Azure SQL Database (PaaS).
4. Select a specific instance to get to the database readiness view.

You can see the number of migration blockers per each database, the
recommended target per each database in the above view.
5. Review the DMA assessment results to get more details around the migration
blockers.
See also
Data Migration Assistant (DMA)
Data Migration Assistant: Configuration settings
Data Migration Assistant: Best Practices
Customize an assessment
This article describes how to customize assessments created by Azure Migrate Discovery
your on-premises apps and workloads, and private/public cloud VMs, to Azure. The hub
provides Azure Migrate tools for assessment and migration, as well as third-party
independent software vendor (ISV) offerings.
You can use the Azure Migrate Discovery and assessment tool to create assessments for
on-premises VMware VMs and Hyper-V VMs, in preparation for migration to Azure. The
Discovery and assessment tool assesses on-premises servers for migration to Azure IaaS
virtual machines and Azure VMware Solution (AVS).
About assessments
Assessments that you create with the Discovery and assessment tool are a point-in-time
snapshot of data. There are two types of assessments that you can create using Azure
Migrate: Discovery and assessment.
Assessment Details
Type
You can assess your on-premises VMware VMs, Hyper-V VMs, and physical
servers for migration to Azure using this assessment type.Learn more.
Azure VMware Assessments to migrate your on-premises servers to Azure VMware Solution
Solution (AVS) (AVS).
You can assess your on-premises VMware VMs for migration to Azure VMware
Solution (AVS) using this assessment type.Learn more.
Sizing criteria options in Azure Migrate assessments:

Performance- Assessments that Azure VM assessment: VM size recommendation is based

based make on CPU and memory utilization data.
recommendations
based on collected Disk type recommendation (standard HDD/SSD or
performance data. premium-managed disks) is based on the IOPS and
throughput of the on-premises disks.
Azure SQL assessment: The Azure SQL configuration is

based on performance data of SQL instances and
databases, which includes CPU utilization, Memory
utilization, IOPS (Data and Log files), throughput, and
latency of IO operations

recommendation is based on CPU and memory utilization
data.
As-is on- Assessments that Azure VM assessment: VM size recommendation is based

premises don't use on the on-premises VM size
performance data
to make The recommended disk type is based on what you select in
recommendations. the storage type setting for the assessment.

recommendation is based on the on-premises VM size.
How is an assessment done?

An assessment done in Azure Migrate Discovery and assessment has three stages.
Assessment starts with a suitability analysis, followed by sizing, and lastly, a monthly
cost estimation. A machine only moves along to a later stage if it passes the previous
one. For example, if a machine fails the Azure suitability check, it’s marked as unsuitable
for Azure, and sizing and costing won't be done. Learn more.
What's in an Azure VM assessment?

Property Details
Property Details
Target The Azure location to which you want to migrate.

location Azure VM assessment currently supports these target regions: Australia East,
Australia Southeast, Brazil South, Canada Central, Canada East, Central India,
Central US, China East, China North, East Asia, East US, East US2, Germany Central,
Germany Northeast, Japan East, Japan West, Korea Central, Korea South, North
Central US, North Europe, South Central US, Southeast Asia, South India, UK
South, UK West, US Gov Arizona, US Gov Texas, US Gov Virginia, West Central US,
West Europe, West India, West US, and West US2.
Storage type You can use this property to specify the type of disks you want to move to, in
Azure.
For as-on-premises sizing, you can specify the target storage type either as
Premium-managed disks, Standard SSD-managed disks or Standard HDD-
managed disks. For performance-based sizing, you can specify the target disk type
either as Automatic, Premium-managed disks, Standard HDD-managed disks, or
Standard SSD-managed disks.
When you specify the storage type as automatic, the disk recommendation is
done based on the performance data of the disks (IOPS and throughput). If you
specify the storage type as premium/standard, the assessment will recommend a
disk SKU within the storage type selected. If you want to achieve a single instance
VM SLA of 99.9%, you may want to specify the storage type as Premium-managed
disks. This ensures that all disks in the assessment are recommended as Premium-
managed disks. Azure
Reserved This property helps you specify if you have Reserved Instances in Azure, cost
Instances estimations in the assessment are then done taking into RI discounts. Reserved
(RI) instances are currently only supported for Pay-As-You-Go offer in Azure Migrate.
Sizing The criterion to be used to right-size VMs for Azure. You can either do
criterion performance-based sizing or size the VMs as on-premises, without considering the
performance history.
Performance The duration to consider for evaluating the performance data of machines. This
history property is only applicable when sizing criterion is performance-based.
Percentile The percentile value of the performance sample set to be considered for right-
utilization sizing. This property is only applicable when sizing is performance-based.
VM series You can specify the VM series that you would like to consider for right-sizing. For
example, if you have a production environment that you do not plan to migrate to
A-series VMs in Azure, you can exclude A-series from the list or series and the
right-sizing is done only in the selected series.
Property Details
Comfort Azure VM assessment considers a buffer (comfort factor) during assessment. This
factor buffer is applied on top of machine utilization data for VMs (CPU, memory, disk,
and network). The comfort factor accounts for issues such as seasonal usage, short
For example, a 10-core VM with 20% utilization normally results in a 2-core VM.
However, with a comfort factor of 2.0x, the result is a 4-core VM instead.
Offer The Azure offer you're enrolled to. Azure Migrate estimates the cost
accordingly.
Currency Billing currency.
Discount (%) Any subscription-specific discount you receive on top of the Azure offer.
VM uptime If your VMs are not going to be running 24x7 in Azure, you can specify the
duration (number of days per month and number of hours per day) for which they
would be running and the cost estimations would be done accordingly.
The default value is 31 days per month and 24 hours per day.
Azure Specify whether you have software assurance and are eligible for Azure Hybrid
Hybrid Benefit . If set to Yes, non-Windows Azure prices are considered for Windows
Benefit VMs. By default, Azure Hybrid Benefit is set to Yes.
What's in an Azure VMware Solution (AVS)

assessment?
Here's what's included in an AVS assessment:
Property Details
Target location Specifies the AVS private cloud location to which you want to migrate.
AVS Assessment currently supports these target regions: East US, West
Europe, and West US.
Storage type Specifies the storage engine to be used in AVS.
Note that AVS assessments only support vSAN as a default storage type.
Reserved This property helps you specify Reserved Instances in AVS. RIs are currently
Instances (RIs) not supported for AVS nodes.
Property Details
Node type Specifies the AVS Node type used to map the on-premises VMs. Note that
default node type is AV36.
Azure Migrate will recommend a required number of nodes for the VMs to be
migrated to AVS.
FTT Setting, Specifies the applicable Failure to Tolerate (FTT) and Raid combinations. The
RAID Level selected FTT option combined with the on-premises VM disk requirement will
determine the total vSAN storage required in AVS.
Sizing criterion Sets the criteria to be used to right-size VMs for AVS. You can opt for
performance-based sizing or as on-premises without considering the
performance history.
Performance Sets the duration to consider in evaluating the performance data of machines.
history This property is applicable only when the sizing criteria is performance-based.
Percentile Specifies the percentile value of the performance sample set to be considered
utilization for right-sizing. This property is applicable only when the sizing is
performance-based.
Comfort factor Azure Migrate considers a buffer (comfort factor) during assessment. This
buffer is applied on top of machine utilization data for VMs (CPU, memory,
disk, and network). The comfort factor accounts for issues such as seasonal
usage, short performance history, and likely increases in future usage.
For example, a 10-core VM with 20% utilization normally results in a 2-core

VM. However, with a comfort factor of 2.0x, the result is a 4-core VM instead.
Offer Displays the Azure offer you're enrolled in. Azure Migrate estimates the
cost accordingly.
Currency Shows the billing currency for your account.
Discount (%) Lists any subscription-specific discount you receive on top of the Azure offer.
Azure Hybrid Specifies whether you have software assurance and are eligible for Azure
Benefit Hybrid Benefit . Although this has no impact on the Azure VMware
solution's pricing due to the node-based price, customers can still apply their
on-premises OS licenses (Microsoft-based) in AVS using Azure Hybrid
Benefits. Other software OS vendors such as RHEL, for example, will have to
provide their own licensing terms.
Property Details
vCPU Specifies the ratio of number of virtual cores tied to 1 physical core in the AVS
Oversubscription node. The default value in the calculations is 4 vCPU : 1 physical core in AVS.
API users can set this value as an integer. Note that vCPU Oversubscription >
4:1 may begin to cause performance degradation but can be used for web
server type workloads.
What properties are used to create and

customize an Azure SQL assessment?
Here's what's included in Azure SQL assessment properties:
Property Details
Target location The Azure region to which you want to migrate. Azure SQL configuration and
cost recommendations are based on the location that you specify.
Target The target deployment type you want to run the assessment on:
deployment
type Select Recommended if you want Azure Migrate to assess the readiness of
your SQL servers for migrating to Azure SQL MI and Azure SQL DB, and
recommend the best suited target deployment option, target tier, Azure SQL
configuration, and monthly estimates.
Select Azure SQL DB if you want to assess your SQL servers for migrating to
Azure SQL Databases only and review the target tier, Azure SQL DB
Select Azure SQL MI if you want to assess your SQL servers for migrating to
Azure SQL Databases only and review the target tier, Azure SQL MI
Reserved Specifies reserved capacity so that cost estimations in the assessment take
capacity them into account.
If you select a reserved capacity option, you can't specify “Discount (%)”.
Sizing criteria This property is used to right-size the Azure SQL configuration.
It is defaulted to Performance-based which means the assessment will collect

the SQL Server instances and databases performance metrics to recommend an
optimal-sized Azure SQL Managed Instance and/or Azure SQL Database
tier/configuration recommendation.
Property Details
Performance Performance history specifies the duration used when the performance data is
history evaluated.
Percentile Percentile utilization specifies the percentile value of the performance sample
utilization used for rightsizing.
Comfort factor The buffer used during assessment. It accounts for issues like seasonal usage,
short performance history, and likely increases in future usage.
For example, a 10-core instance with 20% utilization normally results in a two-
core instance. With a comfort factor of 2.0, the result is a four-core instance
instead.
Offer/Licensing The Azure offer in which you're enrolled. Currently, you can only choose from
program Pay-as-you-go and Pay-as-you-go Dev/Test. Note that you can avail additional
discount by applying reserved capacity and Azure Hybrid Benefit on top of Pay-
as-you-go offer.
Service tier The most appropriate service tier option to accommodate your business needs
for migration to Azure SQL Database and/or Azure SQL Managed Instance:
Recommended if you want Azure Migrate to recommend the best suited

service tier for your servers. This can be General purpose or Business critical.
General Purpose If you want an Azure SQL configuration designed for budget-
oriented workloads. Learn More
Business Critical If you want an Azure SQL configuration designed for low-
latency workloads with high resiliency to failures and fast failovers. Learn More
Discount (%) Any subscription-specific discounts you receive on top of the Azure offer. The
default setting is 0%.
Azure Hybrid Specifies whether you already have a SQL Server license.
Benefit
If you do and they're covered with active Software Assurance of SQL Server
Subscriptions, you can apply for the Azure Hybrid Benefit when you bring
licenses to Azure.
Edit assessment properties

To edit assessment properties after creating an assessment, do the following:
1. In the Azure Migrate project, select Servers, databases and web apps.
2. In Azure Migrate: Discovery and assessment, select the assessments count.
3. In Assessment, select the relevant assessment > Edit properties.
4. Customize the assessment properties in accordance with the tables above.
5. Select Save to update the assessment.
You can also edit the assessment properties when you're creating an assessment.
Next steps
Learn more about how Azure VM assessments are calculated.
Learn more about how AVS assessments are calculated.
Assess large numbers of servers in
VMware environment for migration to
Azure
This article describes how to assess large numbers (1000-35,000) of on-premises servers
in a VMware environment for migration to Azure, using the Azure Migrate Discovery
In this article, you learn how to:
＂ Plan for assessment at scale.

＂ Configure Azure permissions and prepare VMware for assessment.
＂ Create an Azure Migrate project and create an assessment.
＂ Review the assessment as you plan for migration.
７ Note
If you want to try out a proof-of-concept to assess a couple of servers before

assessing at scale, follow our tutorial series.
Plan for assessment

When planning for assessment of large number of servers in VMware environment,
there are a couple of things to think about:
Plan Azure Migrate projects: Figure out how to deploy Azure Migrate projects. For
example, if your data centers are in different geographies, or you need to store
discovery, assessment, or migration-related metadata in a different geography, you
might need multiple projects.
Plan appliances: Azure Migrate uses an on-premises Azure Migrate appliance,
deployed as a VMware VM, to continually discover servers. The appliance monitors
environment changes such as adding servers, disks, or network adapters. It also
sends metadata and performance data about them to Azure. You need to figure
out how many appliances you need to deploy.
Plan accounts for discovery: The Azure Migrate appliance uses an account with
access to vCenter Server in order to discover servers for assessment and migration.
If you're discovering more than 10,000 servers, set up multiple accounts as it is
necessary that there is no overlap among servers discovered from any two
appliances in a project.
７ Note
If you are setting up multiple appliances, ensure there is no overlap among the
servers on the vCenter accounts provided. A discovery with such an overlap is an
unsupported scenario. If a server is discovered by more than one appliance, this
results in duplicates in discovery and in issues while enabling replication for the
server using the Azure portal in the Migration and modernization tool.
Planning limits
Use the limits summarized in this table for planning.
Planning Limits
Azure Migrate projects Assess up to 35,000 servers in a project.
Azure Migrate An appliance can discover up to 10,000 servers on a vCenter Server.

appliance An appliance can connect to upto 10 vCenter Servers.
An appliance can only be associated with a single Azure Migrate
project.
Any number of appliances can be associated with a single Azure
Migrate project.
Group You can add up to 35,000 servers in a single group.
Azure Migrate You can assess up to 35,000 servers in a single assessment.

assessment
With these limits in mind, here are some example deployments:
vCenter Servers to Recommendation Action

server be
discovered
server be
discovered
One < 10,000 One Azure Set up an appliance to discover servers from up to
Migrate project. 10 vCenter Servers mapped to one or more vCenter
Server accounts, scoped to discover less than 10,000
One appliance servers.
can discover up
to 10,000 servers You can analyze dependencies on servers across
running on up to vCenter Servers discovered from the same
10 vCenter appliance.
Servers.
Provide one or
more vCenter
Server accounts
for discovery.
One > 10,000 One Azure Set up an appliance to connect up to 10 vCenter

Migrate project. Servers mapped to one or more vCenter Server
accounts, scoped to discover less than 10,000
One appliance servers. You need to deploy additional appliances
can discover up for every 10,000 servers.
to 10,000 servers
running on up to If the number of servers is greater than 10,000, set
10 vCenter up additional appliances with the vCenter Server
Servers. accounts scoped accordingly.
Provide one or You can analyze dependencies on servers across

more vCenter vCenter Servers discovered from the same
Server accounts appliance.
for discovery.
Ensure there is no overlap among the servers on the
vCenter accounts provided. A discovery with such an
overlap is an unsupported scenario. If a server is
discovered by more than one appliance, this results
in a duplicate in discovery and in issues while
enabling replication for the server using the Azure
portal in the Migration and modernization tool.
server be
discovered
Multiple < 10,000 One Azure Set up an appliance to connect up to 10 vCenter

Migrate project. Servers mapped to one or more vCenter Server
accounts, scoped to discover less than 10,000
One appliance servers.
can discover up
to 10,000 servers You need to deploy additional appliances for every
running on up to 10 vCenter Servers.
10 vCenter
Servers. You can analyze dependencies on servers across
vCenter Servers discovered from the same
Provide one or appliance.
more vCenter
Server accounts
for discovery.
Multiple > 10,000 One Azure Set up an appliance to discover VMs from up to 10
Migrate project. vCenter Servers mapped to one or more vCenter
Server accounts, scoped to discover less than 10,000
One appliance servers. You need to deploy additional appliances
can discover up for every 10 vCenter Servers.
to 10,000 servers
running on up to If the number of servers is greater than 10,000, set
10 vCenter up additional appliances with the vCenter Server
Servers. accounts scoped accordingly.
Provide one or You can analyze dependencies on servers across

more vCenter vCenter Servers discovered from the same
Server accounts appliance.
for discovery.
Ensure there is no overlap among the servers on the
vCenter accounts provided. A discovery with such an
overlap is an unsupported scenario. If a server is
discovered by more than one appliance, this results
in a duplicate in discovery and in issues while
enabling replication for the server using the Azure
portal in the Migration and modernization tool.
Plan discovery in a multi-tenant environment

If you're planning for a multi-tenant environment, you can scope the discovery on the
vCenter Server.
You can set the appliance discovery scope to a vCenter Server data centers,
clusters, or folder of clusters, hosts or folder of hosts, or individual servers.
If your environment is shared across tenants and you want to discover each tenant
separately, you can scope access to the vCenter account that the appliance uses
for discovery.
You may want to scope by VM folders if the tenants share hosts. Azure Migrate
can't discover servers if the vCenter account has access granted at the vCenter
VM folder level. If you are looking to scope your discovery by VM folders, you
can do so by ensuring the vCenter account has read-only access assigned at a
server level. Learn more.
Prepare for assessment

Prepare Azure and VMware for Discovery and assessment tool:
1. Verify VMware support requirements and limitations.

2. Set up permissions for your Azure account to interact with Azure Migrate.
3. Prepare VMware for assessment.
Follow the instructions in this tutorial to configure these settings.
Create a project
In accordance with your planning requirements, do the following:
1. Create an Azure Migrate projects.

2. Add the Azure Migrate Discovery and assessment tool to the projects.
Learn more about creating a project.
Create and review an assessment

1. Create assessments for servers in VMware environment.
2. Review the assessments in preparation for migration planning.
Next steps
In this article, you:
＂ Planned to scale Azure Migrate assessments for servers in VMware environment
＂ Prepared Azure and VMware for assessment
＂ Created an Azure Migrate project and ran assessments
＂ Reviewed assessments in preparation for migration.
Now, learn how assessments are calculated, and how to modify assessments.
 Documentation


Questions about discovery, assessment, and dependency analysis in Azure Migrate -

Azure Migrate
Get answers to common questions about discovery, assessment, and dependency analysis in Azure
Migrate.



Migrate
Prepare Azure VMware Solution for disaster recovery to Azure Site Recovery - Azure
Site Recovery
Learn how to prepare Azure VMware Solution servers for disaster recovery to Azure using the Azure
Site Recovery service.
Show 5 more
Assess large numbers of servers in
Hyper-V environment for migration to
Azure
This article describes how to assess large numbers of on-premises servers in Hyper-V
environment for migration to Azure, using the Azure Migrate: Discovery and assessment
tool.

＂ Configure Azure permissions and prepare Hyper-V for assessment.
＂ Create an Azure Migrate project and create an assessment.
７ Note

Plan for assessment

When planning for assessment of a large number of servers in Hyper-V environment,
there are a couple of things to think about:
example, if your data centers are in different geographies, or if you need to store
deployed as a Hyper-V VM, to continually discover servers for assessment and
migration. The appliance monitors environment changes such as adding servers,
disks, or network adapters. It also sends metadata and performance data about
them to Azure. You need to figure out how many appliances to deploy.
Planning limits
Planning Limits
Azure Migrate An appliance can discover up to 5000 servers.

appliance An appliance can connect to up to 300 Hyper-V hosts.
An appliance can only be associated with a single Azure Migrate
project.
Migrate project.

assessment
Other planning considerations

To start discovery from the appliance, you must select each Hyper-V host.
If you're running a multi-tenant environment, you can't currently discover only
servers that belong to a specific tenant.

Prepare Azure and Hyper-V for the Discovery and assessment tool:
1. Verify Hyper-V support requirements and limitations.

3. Prepare Hyper-V hosts and servers.
Create a project
1. Create an Azure Migrate projects.

Learn more about creating a project.

1. Create assessments for servers in a Hyper-V environment.
Learn more about creating and reviewing assessments.
Next steps
＂ Planned to scale Azure Migrate assessments for servers in Hyper-V environment

＂ Prepared Azure and Hyper-V for assessment
＂ Created an Azure Migrate project and ran assessments
Now, learn how assessments are calculated, and how to modify assessments
 Documentation


Assess large numbers of servers in VMware environment for migration to Azure with
Azure Migrate - Azure Migrate
Describes how to assess large numbers of servers in VMware environment for migration to Azure
using the Azure Migrate service.
Automate migration of machines in Azure Migrate - Azure Migrate

Describes how to use scripts to migrate a large number of machines in Azure Migrate

Discover AWS instances with Azure Migrate Discovery and assessment - Azure
Migrate

Show 5 more
 Training
Module
Assess large numbers of physical servers
for migration to Azure
This article describes how to assess large numbers of on-premises physical servers for

＂ Configure Azure permissions and prepare physical servers for assessment.
＂ Create an Azure Migrate project, and create an assessment.
７ Note

Plan for assessment

When planning for assessment of large number of physical servers, there are a couple of
things to think about:
example, if your data centers are in different geographies, or you need to store
deployed on a Windows server, to continually discover servers for assessment and
migration. The appliance monitors environment changes such as adding servers,
disks, or network adapters. It also sends metadata and performance data about
them to Azure. You need to figure out how many appliances to deploy.
Planning limits
Planning Limits
Azure Migrate An appliance can discover up to 1000 servers.

appliance An appliance can only be associated with a single Azure Migrate
project.
Migrate project.

assessment
Other planning considerations

To start discovery from the appliance, you must select each physical server.

Prepare Azure and physical servers for Discovery and assessment tool:
1. Verify physical server support requirements and limitations.

3. Prepare the physical servers.
Create a project
1. Create an Azure Migrate project.

Learn more about creating projects.

1. Create assessments for physical servers.
Learn more about creating and reviewing assessments.
Next steps
＂ Planned to scale Azure Migrate assessments for physical servers.

＂ Prepared Azure and physical servers for assessment.
＂ Created an Azure Migrate project and ran assessments.
Now, learn how assessments are calculated, and how to modify assessments.
 Training
Module
Add migration tools
This article describes how to add migration tools in Azure Migrate.
If you want to add a migration tool and haven't yet set up an Azure Migrate
project, follow this article.
If you've added an ISV tool for migration, follow the steps, to prepare to work with
the tool.
Select a migration scenario

1. In the Azure Migrate project, click Overview.
2. Select the migration scenario you want to use:
To migrate machines and workloads to Azure, select Assess and migrate

servers.
To migrate on-premises databases, select Assess and migrate databases.
To migrate on-premises web apps, select Explore more > Web Apps.
To migrate data to Azure using Data box, select Explore more > Data box.
Select a migration tool

1. Add a tool:
If you created an Azure Migrate project using the Assess and migrate servers
option in the portal, the Migration and modernization tool is automatically
added to the project. To add additional migration tools, in Servers, next to
Migration tools, select Add more tools.
migration tools, in Servers > Migration tools, select Click here.
tool.
Select a database migration tool
If you created an Azure Migrate project using the Assess and migrate database option
in the portal, the Database Migration tool is automatically added to the project.
1. If the Database Migration tool isn't in the project, in Databases > Assessment
2. In Azure Migrate > Add tools, select the Database Migration tool. Then select Add
tool.
Select a web app migration tool

If you created an Azure Migrate project using the Explore more > WebApps option in
the portal, the Web app migration tool is automatically added to the project.
1. If the Web app migration tool isn't in the project, in Web apps > Assessment
2. In Azure Migrate > Add tools, select the Web App Migration tool. Then select Add
tool.
Order an Azure Data Box
To migrate large amounts of data to Azure, you can order an Azure Data Box for offline
data transfer.
1. In Overview, select Explore more.

2. In Explore more, select Data box.
3. In Get started with Data Box, select the subscription and resource group you want
to use when ordering a Data Box.
4. The Transfer type is an import to Azure. Specify the country in which the data
resides, and the Azure region to which you want to transfer the data.
5. Click Apply to save the settings.
Next steps
Try out a migration using the Migration and modernization tool for Hyper-V or VMware
VMs.
 Documentation





Dependency analysis in Azure Migrate Discovery and assessment - Azure Migrate

Describes how to use dependency analysis for assessment using Azure Migrate Discovery and
assessment.
Show 5 more
 Training

Set up Azure Migrate for server migration - Training
Learn how to check your prerequisite configurations in Azure and in your VMware vSphere
environment and then perform the initial steps in Azure Migrate to choose your assessment and
migration tools.
Replicate data over ExpressRoute for
Azure Migrate projects with public
endpoint connectivity
Article • 04/25/2023
In this article, you'll learn how to configure the Migration and modernization tool to
replicate data over an Azure ExpressRoute circuit while you migrate servers to Azure.
This document is to be referenced if you want to use ExpressRoute for your replications
when using an Azure Migrate project with public endpoint connectivity. To use private
endpoint support, create a new Azure Migrate project with private endpoint
connectivity. See Using Azure Migrate with private endpoints.
Understand Azure ExpressRoute circuits

An ExpressRoute circuit connects your on-premises infrastructure to Microsoft through a
connectivity provider. You can configure ExpressRoute circuits to use private peering,
Microsoft peering, or both. To learn more about the peering options with ExpressRoute,
see ExpressRoute circuits and peering.
The Migration and modernization tool helps you migrate on-premises servers and
servers from other clouds to Azure Virtual Machines. The tool sets up an ongoing
replication stream to replicate data from the servers to be migrated to managed disks in
your Azure subscription. When you're ready to migrate the servers, the replicated data
in Azure is used to migrate the servers.
You can configure the data replicated from your on-premises servers to be sent to your
Azure subscription over the internet or an ExpressRoute connection. Data sent over the
internet uses a secure encrypted connection. If you have many servers to migrate, using
ExpressRoute for replication can help you migrate more efficiently by using the
provisioned bandwidth available with your ExpressRoute circuit.
In this article, you'll learn how to replicate data by using:
＂ An ExpressRoute circuit with private peering.

＂ An ExpressRoute circuit with Microsoft peering.
） Important
This document is to be referenced if you want to use ExpressRoute for your
replications when using an Azure Migrate project with public endpoint connectivity.
To use private endpoint support end-to-end, create a new Azure Migrate project
with private endpoint connectivity. See Using Azure Migrate with private
endpoints.
Replicate data by using an ExpressRoute circuit

with private peering
In the agentless method for migrating VMware virtual machines to Azure, the Azure
Migrate appliance first uploads replication data to a storage account (cache storage
account) in your subscription. Azure Migrate then moves the replicated data from the
cache storage account to replica-managed disks in your subscription.
To use a private peering circuit for replication, you'll create and attach a private
endpoint to the cache storage account. Private endpoints use one or more private IP
addresses from your virtual network, which effectively brings the storage account into
your Azure virtual network. The private endpoint allows the Azure Migrate appliance to
connect to the cache storage account by using ExpressRoute private peering. Data can
then be transferred directly on the private IP address.
） Important
In addition to replication data, the Azure Migrate appliance communicates

with the Azure Migrate service for its control plane activities. These activities
include orchestrating replication. Control plane communication between the
Azure Migrate appliance and the Azure Migrate service continues to happen
over the internet on the Azure Migrate service's public endpoint.
The private endpoint of the storage account should be accessible from the
network where the Azure Migrate appliance is deployed.
DNS must be configured to resolve DNS queries by the Azure Migrate
appliance for the cache storage account's blob service endpoint to the private
IP address of the private endpoint attached to the cache storage account.
The cache storage account must be accessible on its public endpoint. Azure
Migrate uses the cache storage account's public endpoint to move data from
the storage account to replica-managed disks.
Prerequisites
You need the following permissions on the resource group and virtual network where
the private endpoint will be created.
Use case Permissions
Create and Microsoft.Network/privateEndpoint/write/action

manage Microsoft.Network/privateEndpoint/read/action
private
endpoints.
Attach a Microsoft.Network/virtualNetworks/subnet/join/action
private Microsoft.Network/virtualNetworks/join/action
endpoint
to a virtual
network or
subnet.
This
permission
is required
on the
virtual
network
where the
private
endpoint
will be
created.
Link the Microsoft.Microsoft.Storage/storageAccounts/privateEndpointConnectionApproval/action

private Microsoft.Microsoft.Storage/storageAccounts/privateEndpointConnections/read
endpoint
to a
storage
account.
Use case Permissions
Create a Microsoft.Network/networkInterfaces/read
network Microsoft.Network/networkInterfaces/subnets/write
interface Microsoft.Network/networkInterfaces/subnets/read
and join it Microsoft.Network/networkSecurityGroups/join/action (optional)
to a
network
security
group.
Create and Private DNS Zone Contributor role

manage Or
private Microsoft.Network/privateDnsZones/A/*
DNS Microsoft.Network/privateDnsZones/write Microsoft.Network/privateDnsZones/read
zones. Microsoft.Network/privateEndpoints/privateDnsZoneGroups/write
Microsoft.Network/privateEndpoints/privateDnsZoneGroups/read
Microsoft.Network/privateDnsZones/virtualNetworkLinks/write
Microsoft.Network/privateDnsZones/virtualNetworkLinks/read
Microsoft.Network/virtualNetworks/join/action
Identify the cache storage account

Azure Migrate automatically creates a cache storage account when you configure
replication (using the Azure portal experience) for a virtual machine for the first time in
an Azure Migrate project. The storage account is created in the same subscription and
resource group where you created the Azure Migrate project.
To create and locate the storage account:
1. Use the Azure portal to replicate one or more virtual machines in the Azure
Migrate project.
2. Go to the resource group of the Azure Migrate project.
3. Locate the cache storage account by identifying the prefix lsa in the storage
account name.
 Tip
If you have more than one storage account with the prefix lsa in your resource
group, you can verify the storage account by navigating to the replication settings
and target configuration menu for any of the replicating VMs in the project.
Upgrade the cache storage account to general-purpose

v2
You can create private endpoints only on a general-purpose v2 storage account. If the
cache storage account isn't a general-purpose v2 storage account, upgrade it.
1. Go to your storage account.
2. Select Configuration.
3. Under Account kind, select Upgrade.
4. Under Confirm upgrade, enter the name of your account.
5. Select Upgrade at the bottom of the page.
Create a private endpoint for the storage account

1. Go to your storage account, select Networking from the left menu, and select the
Private endpoint connections tab.
2. Select + Private endpoint.
a. In the Create a private endpoint window, select the Subscription and Resource
group. Enter a name for your private endpoint, and select the storage account
region.
b. On the Resource tab, enter the Subscription name that the storage account is
in. Select Microsoft.Storage/storageAccounts as the Resource type. In
Resource, enter the name of the general-purpose v2 type replication storage
account. Select blob as the Target sub-resource.
c. On the Configuration tab, select the Virtual network and Subnet for the
storage account's private endpoint.
７ Note
The virtual network must contain the ExpressRoute gateway endpoint or be

connected to the virtual network with the ExpressRoute gateway.
In the Private DNS integration section, select Yes and integrate with a private
DNS zone. Selecting Yes automatically links the DNS zone to the selected virtual
network. It also adds the DNS records that are required for DNS resolution of
new IPs and fully qualified domain names (FQDNs) created for the private
endpoint. Learn more about private DNS zones.
d. You can also add Tags for your private endpoint.
e. After you're finished entering details, select the Review + create tab. After the
validation completes, select Create to create the private endpoint.
７ Note
If the user who created the private endpoint is also the owner of the storage
account, the private endpoint will be autoapproved. Otherwise, the owner must
approve the private endpoint for use.
Create private DNS zones and add DNS records manually (optional)
If you didn't select the option to integrate with a private DNS zone at the time of the
private endpoint creation, you need to manually create a private DNS zone.
７ Note
If you selected Yes to integrate with a private DNS zone, you can skip this section.
To manually create a private DNS zone:
1. Select Private DNS zones.
a. On the Private DNS zones page, select + Add to create a new zone.
b. On the Create private DNS zone page, fill in the required details. Enter the
name of the private DNS zone as privatelink.blob.core.windows.net.
c. On the Review + create tab, review and create the DNS zone.
2. Link the private DNS zone to your virtual network. The private DNS zone you
created must be linked to the virtual network that the private endpoint is attached
to.
a. Go to the private DNS zone created in the previous step, and go to virtual
network links on the left side of the page. Select + Add.
b. Fill in the required details. The Subscription and Virtual network fields must be
filled with the corresponding details of the virtual network where your private
endpoint is attached. The other fields can be left as is.
3. The next step is to add DNS records to the DNS zone. Add an entry for the storage
account's FQDN in your private DNS zone.
a. Go to your private DNS zone, and go to the Overview section on the left side of
the page. Select + Record to start adding records.
b. On the Add record set page, add an entry for the FQDN and private IP as an A
type record.
） Important
You might require additional DNS settings to resolve the private IP address of the
storage account's private endpoint from the source environment. To understand
the DNS configuration needed, see Azure private endpoint DNS configuration.
Verify network connectivity to the storage account
To validate the private link connection, perform a DNS resolution of the cache storage
account resource endpoint from the on-premises VM hosting the Azure Migrate
appliance and ensure that it resolves to a private IP address.
An illustrative example for DNS resolution of the cache storage account.
Enter nslookup storageaccountname.blob.core.windows.net. Replace <storage-

account-name> with the name of the cache storage account created by Azure
Migrate.
You'll receive a message like this:
A private IP address of 10.1.0.5 is returned for the storage account. This address
should belong to the private endpoint of the storage account.
Tip: You can manually update your source environment DNS records by editing the
DNS hosts file on your on-premises appliance with the storage account FQDN link,
storageaccountname.blob.core.windows.net, and the associated private IP address.
This option is recommended only for testing.
If you use a custom DNS, review your custom DNS settings, and validate that the
DNS configuration is correct. For guidance, see private endpoint overview: DNS
configuration.
If you use Azure-provided DNS servers, use this guide as a reference for further
troubleshooting for further troubleshooting.
Configure proxy bypass rules on the Azure Migrate

appliance (for ExpressRoute private peering connectivity)
For proxy bypass, you can add a proxy bypass rule for the cache storage account as
follows
storageaccountname.blob.core.windows.net.
） Important
Do not bypass *.blob.core.windows.net as Azure Migrate makes use of another

storage account, which needs internet access. This storage account, gateway
storage account, is only used to store state information about the VMs being
replicated. You can locate the gateway storage account by identifying the prefix
gwsa in the storage account name in the Azure Migrate project resource group.
Replicate data by using an ExpressRoute circuit

with Microsoft peering
You can use Microsoft peering or an existing public peering domain (deprecated for new
ExpressRoute connections) to route your replication traffic through an ExpressRoute
circuit.
Even with replication data going over the Microsoft peered circuit, you still need internet
connectivity from the on-premises site for control plane traffic and other URLs that
aren't reachable over ExpressRoute. The replication appliance or Hyper-V host needs
access to the URLs to orchestrate the replication process. Review the URL requirements
based on the migration scenario, either VMware agentless migrations or agent-based
migrations.
For replication data transfer over Microsoft peering, configure route filters to advertise
routes for the Azure Storage endpoints. This would be the regional BGP communities for
the target Azure region (region for migration). To route control plane traffic over
Microsoft peering, configure route filters to advertise routes for other public endpoints
as required.
Regional BGP community for the source Azure region (Azure Migrate Project
region)
Regional BGP community for the target Azure region (region for migration)
BGP community for Azure Active Directory (12076:5060)
Learn more about route filters and the list of BGP communities for ExpressRoute.
Proxy configuration for ExpressRoute Microsoft peering

If the appliance uses a proxy for internet connectivity, you may need to configure proxy
bypass for certain URLs to route them via the Microsoft peering circuit.
Configure proxy bypass rules for ExpressRoute Microsoft peering

on the Azure Migrate appliance (for VMware agentless migrations)
1. Sign in via Remote Desktop to the Azure Migrate appliance.
2. Open the file C:/ProgramData/MicrosoftAzure/Config/appliance.json by using

Notepad.
3. In the file, change the line that says "EnableProxyBypassList": "false" to

"EnableProxyBypassList": "true" . Save the changes, and restart the appliance.
4. After you restart, when you open the appliance configuration manager, you'll see
the proxy bypass option in the web app UI.
5. For replication traffic, you can configure a proxy bypass rule for
“.*.blob.core.windows.net”. You can configure proxy bypass rules for other control
plane endpoints as required. These endpoints include:
.*.vault.azure.net
.*.servicebus.windows.net
.*.discoverysrv.windowsazure.com
.*.migration.windowsazure.com
.*.hypervrecoverymanager.windowsazure.com
７ Note
Following URLs are not accessible over ExpressRoute and require Internet
connectivity: *.portal.azure.com, *.windows.net, *.msftauth.net, *.msauth.net,
*.microsoft.com, *.live.com, *.office.com, *.microsoftonline.com, *.microsoftonline-
p.com, *.microsoftazuread-sso.com, management.azure.com,
.services.visualstudio.com (optional), aka.ms/ (optional),
download.microsoft.com/download.
Configure proxy bypass rules ExpressRoute Microsoft peering on
the replication appliance (for agent-based migrations)
To configure the proxy bypass list on the configuration server and process servers:
1. Download the PsExec tool to access system user context.
2. Open Internet Explorer in system user context by running the following command
line: psexec -s -i "%programfiles%\Internet Explorer\iexplore.exe" .
3. Add proxy settings in Internet Explorer.
4. For replication traffic, you can configure a proxy bypass rule for
".*.blob.core.windows.net". You can configure proxy bypass rules for other control
plane endpoints as required. These endpoints include:
.*.backup.windowsazure.com
.*.hypervrecoverymanager.windowsazure.com
The bypass rules for the Azure Storage endpoint will ensure that the replication traffic
can flow through ExpressRoute while the control plane communication can go through
the proxy for the internet.
７ Note
Following URLs are not accessible over ExpressRoute and require Internet
connectivity: *.portal.azure.com, *.windows.net, *.msftauth.net, *.msauth.net,
*.microsoft.com, *.live.com, *.office.com, *.microsoftonline.com, *.microsoftonline-
p.com, *.microsoftazuread-sso.com, management.azure.com,
.services.visualstudio.com (optional), aka.ms/ (optional),
download.microsoft.com/download, dev.mysql.com.
Next steps
See the following articles to learn more about:
ExpressRoute circuits
ExpressRoute routing domains
Private endpoints
Prepare on-premises machines for
migration to Azure
Article • 04/25/2023
This article describes how to prepare on-premises machines before you migrate them to
Azure using the Migration and modernization tool.
＂ 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 Discover and Discover up to 10,000 Agentless migration: you can

vSphere assess up to VMware vSphere VMs simultaneously replicate a maximum of
VMs 35,000 VMs in a with a single Azure 500 VMs across multiple vCenter
single Azure Migrate appliance for Servers (discovered from one
Migrate project. VMware vSphere. appliance) using a scale-out appliance.
The appliance supports Agent-based migration: you can scale
adding multiple vCenter out the replication appliance to
Servers. You can add up replicate large numbers of VMs.
to 10 vCenter Servers
per appliance. In the portal, you can select up to 10
machines at once for replication. To
replicate more machines, add in
batches of 10.
Scenario Project Discovery/Assessment Migration
Hyper-V Discover and Discover up to 5,000 An appliance isn't used for Hyper-V
VMs assess up to Hyper-V VMs with a migration. Instead, the Hyper-V
35,000 VMs in a single Azure Migrate Replication Provider runs on each
single Azure appliance Hyper-V host.
Migrate project.
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
batches of 10.
Physical Discover and Discover up to 250 You can scale out the replication
machines assess up to physical servers with a appliance to replicate large numbers of
35,000 single Azure Migrate servers.
machines in a appliance for physical
single Azure servers. In the portal, you can select up to 10
Migrate project. machines at once for replication. To
batches of 10.
Select a VMware vSphere migration method

If you're migrating VMware vSphere VMs to Azure, compare the agentless and agent-
based migration methods, to decide what works best for you.
Verify hypervisor requirements

Verify VMware agentless, or VMware vSphere agent-based requirements.
Verify Hyper-V host requirements.
Verify operating system requirements

Verify supported operating systems for migration:
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.
Verify Windows operating systems are supported in Azure.
Verify Linux distributions supported in Azure.
Review URL and port access

Review which URLs and ports are accessed during migration.
Scenario Details URLs Ports
VMware Uses the Azure Migrate Review the public cloud Review the port
vSphere appliance for migration. and government URLs requirements for agentless
agentless Nothing is installed on needed for discovery, migration.
migration VMware vSphere VMs. assessment, and migration
with the appliance.
VMware Uses the replication Review the public cloud Review the ports used
vSphere appliance for migration. and Azure Government during agent-based
agent- The Mobility service URLs that the replication migration.
based agent is installed on appliance needs to access.
migration VMs.
Hyper-V Uses a Provider installed Review the public cloud The Replication Provider on
migration on Hyper-V hosts for and Azure Government the Hyper-V host uses
migration. Nothing is URLs that the Replication outbound connections on
installed on Hyper-V Provider running on the HTTPS port 443 to send VM
VMs. hosts needs to access. replication data.
Physical Uses the replication Review the public cloud Review the ports used
machines appliance for migration. and Azure Government during physical migration.
The Mobility service URLs that the replication
agent is installed on the appliance needs to access.
physical machines.
Verify required changes before migrating

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 VMware Windows on

vSphere vSphere Hyper-V
(agentless (agent-
migration) based)/physical
machines
Configure the SAN policy as Online All Set Set Set

automatically automatically in automatically
for machines most cases. for machines
running running
Windows Windows
Server 2008 Server 2008
R2 or later. R2 or later.
Configure
manually for
earlier
operating
systems.
Install Hyper-V Guest Integration Install Install manually Install

manually on on machines manually on
machines running machines
running Windows running
Windows Server 2003. Windows
Server 2003. Server 2003.
Enable Azure Serial Console Enable Enable Enable

manually manually manually
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.
Action VMware VMware Windows on
vSphere vSphere Hyper-V
(agentless (agent-
migration) based)/physical
machines
Install the Windows Azure Guest Agent Set Set Set

automatically automatically automatically
The Virtual Machine Agent (VM Agent) is a for machines for machines for machines
secure, lightweight process that manages running running running
virtual machine (VM) interaction with the Azure Windows Windows Windows
Fabric Controller. The VM Agent has a primary Server 2008 Server 2008 R2 Server 2008
role in enabling and executing Azure virtual R2 or later. or later. R2 or later.
machine extensions that enable post- Configure
deployment configuration of VM, such as manually for
installing and configuring software. earlier
operating
systems.
Connect after migration Set up Set up Set up

manually. manually. manually.
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:
1. On the on-premises machine (not the host server), open an elevated command
prompt.
2. Enter diskpart.
3. Enter SAN. If the drive letter of the guest operating system isn't maintained,
Offline All or Offline Shared is returned.
4. 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.
5. 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 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)
Cent OS 8.x, 7.7, 7.6, 7.5, 7.4, 6.x (Azure Linux VM agent is also installed
automatically during migration)
SUSE Linux Enterprise Server 15 SP0, 15 SP1, 12, 11 SP4, 11 SP3
Ubuntu 20.04, 19.04, 19.10, 18.04LTS, 16.04LTS, 14.04LTS (Azure Linux VM agent is
also installed automatically during migration)
Debian 10, 9, 8, 7
Oracle Linux 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 Rebuild the Linux init image so it contains the Most new versions of Linux
Hyper-V necessary Hyper-V drivers. Rebuilding the init distributions have this included
Linux image ensures that the VM will boot in Azure. by default.
Integration
Services If not included, install manually
for all versions except those
called out above.
Enable Enabling console logging helps you

Azure troubleshoot. You don't need to reboot the VM.
Serial The Azure VM will boot by using the disk
Console image. The disk image boot is equivalent to a
logging reboot for the new VM.
Follow these instructions to enable.

Action Details Linux version
Update Update the device map file with the device Install manually for all versions
device name-to-volume associations, so you use except those called out above.
map file persistent device identifiers. (Only applicable in agent-based
VMware scenario)
Update Update entries to use persistent volume Update manually for all versions
fstab identifiers. except those called out above.
entries
Remove Remove any udev rules that reserves interface Remove manually for all versions
udev rule names based on mac address etc. except those called out above.
Update Update network interfaces to receive IP address Update manually for all versions
network based on DHCP.nst except those called out above.
interfaces
Enable ssh Ensure ssh is enabled and the sshd service is set Enable manually for all versions
to start automatically on reboot. except those called out above.
Ensure that incoming ssh connection requests

are not blocked by the OS firewall or scriptable
rules.
Install the The Microsoft Azure Linux Agent (waagent) is a Enable manually for all versions
Linux secure, lightweight process that manages Linux except those called out above.
Azure & FreeBSD provisioning, and VM interaction Follow instructions to install the
Guest with the Azure Fabric Controller. Linux Agent manually for other
Agent 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 Agentless VMware Agentless

VMware vSphere vSphere Migration Hyper-V
Migration Migration
Update kernel image with Yes Yes Yes

Hyper-V Linux Integration
Services.
(The LIS drivers should be
present on the kernel.)
Action Agent-Based Agentless VMware Agentless
VMware vSphere vSphere Migration Hyper-V
Migration Migration
Enable Azure Serial Console Yes Yes Yes

logging
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/7.x/6.x, CentOS 8.x/7.x/6.x, Ubuntu
14.04/16.04/18.04/19.04/19.10/20.04, SUSE 15 SP0/15 SP1/12/11 SP4/11 SP3, Debian
9/8/7, 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.
Before migrating, review the Azure VMs requirements for VMware, Hyper-V, and
physical server migration.
Prepare to connect after migration

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:
1. Configure Windows settings. Settings include removing any static persistent routes
or WinHTTP proxy.
2. Make sure required services are running.
3. Enable remote desktop (RDP) to allow remote connections to the on-premises
machine. Learn how to use PowerShell to enable RDP.
4. 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.
5. 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.
6. 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:
1. Check that the Secure Shell service is set to start automatically on system boot.
2. 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:
1. 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.
2. Check that network security group (NSG) rules on the VM allow incoming
connections to the RDP or SSH port.
3. Check boot diagnostics to view the VM.
Next steps
Decide which method you want to use to migrate VMware vSphere VMs to Azure, or
begin migrating Hyper-V VMs or physical servers or virtualized or cloud VMs.
See what's supported

For VMware vSphere VMs, Migration and modernization supports agentless or agent-
based migration.
VMware vSphere VMs: Verify migration requirements and support for VMware
vSphere VMs.
Hyper-V VMs: Verify migration requirements and support for Hyper-V VMs.
Physical machines: Verify migration requirements and support for on-premises
physical machines and other virtualized servers.
Learn more
Prepare for VMware vSphere agentless migration with Azure Migrate.
Prepare Windows Server 2003 machines
for migration
This article describes how to prepare machines running Windows Server 2003 for
migration to Azure.
７ Note
Windows Server 2003 extended support ended on July 14, 2015. The Azure
support team continues to help in troubleshooting issues that concern running
Windows Server 2003 on Azure. However, this support is limited to issues that don't
require OS-level troubleshooting or patches. Migrating your applications to Azure
instances running a newer version of Windows Server is the recommended
approach to ensure that you are effectively leveraging the flexibility and reliability
of the Azure cloud. However, if you still choose to migrate your Windows Server
2003 to Azure, you can use the Migration and modernization tool if your Windows
Server is a VM running on VMware or Hyper-V.
You can use agentless migration to migrate Hyper-V VMs and VMware VMs to
Azure.
In order to connect to Azure VMs after migration, Hyper-V Integration Services
must be installed on the Azure VM. Windows Server 2003 machines don't have this
installed by default.
There's no direct download link to install Hyper-V Integration Services, so you
need to do the following:
For Hyper-V VMs that don't have it installed, you extract installation files for
Integration Services on a machine running Windows Server 2012 R2/Windows
Server 2012 with the Hyper-V role, and then copy the installer to the Windows
Server 2003 machine. The installation files aren't available on machines running
Windows Server 2016.
For VMware VMs, you create a startup task that installs Integration Services
when the Azure VM starts after migration.
Install on Hyper-V VMs

Before migration, check whether Hyper-V Integration Services is installed, and then
install if needed.
1. Follow these instructions to check whether it's installed.
2. If it isn't installed, sign into a machine running Windows Server 2012 R2/Windows
Server 2012 with the Hyper-V role.
3. Navigate to the installation file at C:\Windows\System32\vmguest.iso, and mount
the file.
4. Copy the installation folder to the Windows Server 2003 machine, and install
Integration Services.
5. After installation, you can leave the default settings in Integration Services.
Install on VMware VMs

1. Sign into a machine running Windows Server 2012 R2/Windows Server 2012 with
the Hyper-V role.
2. Navigate to the installation file at C:\Windows\System32\vmguest.iso, and mount
the file.
3. Copy the installation folder to the VMware VM.
4. From the command line on the VM, run gpedit.msc .
5. Open Computer Configuration > Windows Settings > Scripts
(Startup/Shutdown).
6. In Startup > Add > Script Name, type the setup.exe address.
7. After migration to Azure, the script runs the first time the Azure VM starts.
8. Manually restart the Azure VM. There's a pop-up in boot diagnostics to indicate
that a restart is needed.
9. After the script runs and Hyper-V Integration Services is installed on the Azure VM,
you can remove the script from startup.
10. After installation, you can leave the default settings in Integration Services.
Next steps
Review migration requirements for VMware and Hyper-V VMs.
Migrate VMware and Hyper-V VMs.
Migrate VMware VMs to Azure VMs enabled with
server-side encryption and customer-managed
keys
This article describes how to migrate VMware VMs to Azure virtual machines with disks encrypted using
server-side encryption(SSE) with customer-managed keys(CMK), using Migration and modernization
(agentless replication).
The Migration and modernization portal experience lets you migrate VMware VMs to Azure with agentless
replication. The portal experience currently doesn't offer the ability to turn on SSE with CMK for your
replicated disks in Azure. The ability to turn on SSE with CMK for the replicated disks is currently available
only through REST API. In this article, you'll see how to create and deploy an Azure Resource Manager
template to replicate a VMware VM and configure the replicated disks in Azure to use SSE with CMK.
The examples in this article use Azure PowerShell to perform the tasks needed to create and deploy the
Resource Manager template.
Learn more about server-side encryption (SSE) with customer managed keys(CMK) for managed disks.
Prerequisites
Review the tutorial on migration of VMware VMs to Azure with agentless replication to understand tool
requirements.
Follow these instructions to create an Azure Migrate project and add the Migration and
modernization tool to the project.
Follow these instructions to set up the Azure Migrate appliance for VMware in your on-premises
environment and complete discovery.
Prepare for replication

Once VM discovery is complete, the Discovered Servers line on the Migration and modernization tile will
show a count of VMware VMs discovered by the appliance.
Before you can start replicating VMs, the replication infrastructure needs to be prepared.
1. Create a Service Bus instance in the target region. The Service Bus is used by the on-premises Azure
Migrate appliance to communicate with the Migration and modernization service to coordinate
replication and migration.
2. Create a storage account for transfer of operation logs from replication.
3. Create a storage account that the Azure Migrate appliance uploads replication data to.
4. Create a Key Vault and configure the Key Vault to manage shared access signature tokens for blob
access on the storage accounts created in step 3 and 4.
5. Generate a shared access signature token for the service bus created in step 1 and create a secret for
the token in the Key Vault created in the previous step.
6. Create a Key Vault access policy to give the on-premises Azure Migrate appliance (using the appliance
AAD app) and the Migration and modernization Service access to the Key Vault.
7. Create a replication policy and configure the Migration and modernization service with details of the
replication infrastructure created in the previous step.
The replication infrastructure must be created in the target Azure region for the migration and in the target
Azure subscription that the VMs are being migrated to.
The Migration and modernization portal experience simplifies preparation of the replication infrastructure by
automatically doing this for you when you replicate a VM for the first time in a project. In this article, we'll
assume that you've already replicated one or more VMs using the portal experience and that the replication
infrastructure is already created. We'll look at how to discover details of the existing replication infrastructure
and how to use these details as inputs to the Resource Manager template that will be used to set up
replication with CMK.
Identifying replication infrastructure components

1. On the Azure portal, go the resource groups page and select the resource group in which the Azure
Migrate project was created.
2. Select Deployments from the left menu and search for a deployment name beginning with the string
"Microsoft.MigrateV2.VMwareV2EnableMigrate". You'll see a list of Resource Manager templates created
by the portal experience to set up replication for VMs in this project. We'll download one such
template and use that as the base to prepare the template for replication with CMK.
3. To download the template, select any deployment matching the string pattern in the previous step >
select Template from the left menu > Click Download from the top menu. Save the template.json file
locally. You'll edit this template file in the last step.
Create a Disk Encryption Set

A disk encryption set object maps Managed Disks to a Key Vault that contains the CMK to use for SSE. To
replicate VMs with CMK, you'll create a disk encryption set and pass it as an input to the replication
operation.
Follow the example here to create a disk encryption set using Azure PowerShell. Ensure that the disk
encryption set is created in the target subscription that VMs are being migrated to, and in the target Azure
region for the migration.
The disk encryption set can be configured to encrypt managed disks with a customer-managed key, or for
double encryption with both a customer-managed key and a platform key. To use the double encryption at
rest option configure the disk encryption set as described here.
In the example shown below the disk encryption set is configured to use a customer-managed key.
Azure PowerShell
$Location = "southcentralus" #Target Azure region for migration

$TargetResourceGroupName = "ContosoMigrationTarget"
$KeyVaultName = "ContosoCMKKV"
$KeyName = "ContosoCMKKey"
$KeyDestination = "Software"
$DiskEncryptionSetName = "ContosoCMKDES"
$KeyVault = New-AzKeyVault -Name $KeyVaultName -ResourceGroupName $TargetResourceGroupName -

Location $Location -EnableSoftDelete -EnablePurgeProtection
$Key = Add-AzKeyVaultKey -VaultName $KeyVaultName -Name $KeyName -Destination $KeyDestination
$desConfig = New-AzDiskEncryptionSetConfig -Location $Location -SourceVaultId

$KeyVault.ResourceId -KeyUrl $Key.Key.Kid -IdentityType SystemAssigned
$des = New-AzDiskEncryptionSet -Name $DiskEncryptionSetName -ResourceGroupName

$TargetResourceGroupName -InputObject $desConfig
Set-AzKeyVaultAccessPolicy -VaultName $KeyVaultName -ObjectId $des.Identity.PrincipalId -

PermissionsToKeys wrapkey,unwrapkey,get
New-AzRoleAssignment -ResourceName $KeyVaultName -ResourceGroupName $TargetResourceGroupName -

ResourceType "Microsoft.KeyVault/vaults" -ObjectId $des.Identity.PrincipalId -
RoleDefinitionName "Reader"
Get details of the VMware VM to migrate

In this step, you'll use Azure PowerShell to get the details of the VM that needs to be migrated. These details
will be used to construct the Resource Manager template for replication. Specifically, the two properties of
interest are:
The machine Resource ID for the discovered VMs.

The list of disks for the VM and their disk identifiers.
Azure PowerShell
$ProjectResourceGroup = "ContosoVMwareCMK" #Resource group that the Azure Migrate Project is

created in
$ProjectName = "ContosoVMwareCMK" #Name of the Azure Migrate Project
$solution = Get-AzResource -ResourceGroupName $ProjectResourceGroup -ResourceType

Microsoft.Migrate/MigrateProjects/solutions -ExpandProperties -ResourceName $ProjectName |
where Name -eq "Servers-Discovery-ServerDis
covery"
# Displays one entry for each appliance in the project mapping the appliance to the VMware
sites discovered through the appliance.
$solution.Properties.details.extendedDetails.applianceNameToSiteIdMapV2 | ConvertFrom-Json |
select ApplianceName, SiteId
Output
ApplianceName SiteId
------------- ------
VMwareApplianc /subscriptions/509099b2-9d2c-4636-b43e-
bd5cafb6be69/resourceGroups/ContosoVMwareCMK/providers/Microsoft.OffAzure/VMwareSites/VMwareAp
plianca8basite
Copy the value of the SiteId string corresponding to the Azure Migrate appliance that the VM is discovered
through. In the example shown above, the SiteId is "/subscriptions/509099b2-9d2c-4636-b43e-
bd5cafb6be69/resourceGroups/ContosoVMwareCMK/providers/Microsoft.OffAzure/VMwareSites/VMwareAppli
anca8basite"
Azure PowerShell
#Replace value with SiteId from the previous step
$SiteId = "/subscriptions/509099b2-9d2c-4636-b43e-
plianca8basite"
$SiteName = Get-AzResource -ResourceId $SiteId -ExpandProperties | Select-Object -
ExpandProperty Name
$DiscoveredMachines = Get-AzResource -ResourceGroupName $ProjectResourceGroup -ResourceType
Microsoft.OffAzure/VMwareSites/machines -ExpandProperties -ResourceName $SiteName
#Get machine details

PS /home/bharathram> $MachineName = "FPL-W19-09" #Replace string with VMware VM name of
the machine to migrate
PS /home/bharathram> $machine = $Discoveredmachines | where {$_.Properties.displayName -eq
$MachineName}
PS /home/bharathram> $machine.count #Validate that only 1 VM was found matching this name.
Copy the ResourceId, name and disk uuid values for the machine to be migrated.
Output
PS > $machine.Name
10-150-8-52-b090bef3-b733-5e34-bc8f-eb6f2701432a_50098f99-f949-22ca-642b-724ec6595210
PS > $machine.ResourceId
/subscriptions/509099b2-9d2c-4636-b43e-
plianca8basite/machines/10-150-8-52-b090bef3-b733-5e34-bc8f-eb6f2701432a_50098f99-f949-22ca-
642b-724ec6595210
PS > $machine.Properties.disks | select uuid, label, name, maxSizeInBytes
uuid label name maxSizeInBytes

---- ----- ---- --------------
6000C291-5106-2aac-7a74-4f33c3ddb78c Hard disk 1 scsi0:0 42949672960
6000C293-39a1-bd70-7b24-735f0eeb79c4 Hard disk 2 scsi0:1 53687091200
6000C29e-cbee-4d79-39c7-d00dd0208aa9 Hard disk 3 scsi0:2 53687091200
Create Resource Manager template for replication

Open the Resource Manager template file that you downloaded in the Identifying replication
infrastructure components step in an editor of your choice.
Remove all resource definitions from the template except for resources that are of type
"Microsoft.RecoveryServices/vaults/replicationFabrics/replicationProtectionContainers/replicationMigrationItems"
If there are multiple resource definitions of the above type, remove all but one. Remove any
dependsOn property definitions from the resource definition.
At the end of this step, you should have a file that looks like the example below and has the same set
of properties.
{
"$schema": "http://schema.management.azure.com/schemas/2015-01-
"resources": [
{
"type":
"Microsoft.RecoveryServices/vaults/replicationFabrics/replicationProtectionContainers/replicat
ionMigrationItems",
"apiVersion": "2018-01-10",
"name":
"ContosoMigration7371rsvault/VMware104e4replicationfabric/VMware104e4replicationcontainer/10-
150-8-52-b090bef3-b733-5e34-bc8f-eb6f2701432a_500937f3-805e-9414-11b1-f22923456e08",
"properties": {
"policyId": "/Subscriptions/6785ea1f-ac40-4244-a9ce-
94b12fd832ca/resourceGroups/ContosoMigration/providers/Microsoft.RecoveryServices/vaults/Conto
soMigration7371rsvault/replicationPolicies/migrateVMware104e4sitepolicy",
"providerSpecificDetails": {
"instanceType": "VMwareCbt",
"vmwareMachineId": "/subscriptions/6785ea1f-ac40-4244-a9ce-
94b12fd832ca/resourceGroups/ContosoMigration/providers/Microsoft.OffAzure/VMwareSites/VMware10
4e4site/machines/10-150-8-52-b090bef3-b733-5e34-bc8f-eb6f2701432a_500937f3-805e-9414-11b1-
f22923456e08",
"targetResourceGroupId": "/subscriptions/6785ea1f-ac40-4244-a9ce-
94b12fd832ca/resourceGroups/PayrollRG",
"targetNetworkId": "/subscriptions/6785ea1f-ac40-4244-a9ce-
94b12fd832ca/resourceGroups/PayrollRG/providers/Microsoft.Network/virtualNetworks/PayrollNW",
"targetSubnetName": "PayrollSubnet",
"licenseType": "NoLicenseType",
"disksToInclude": [
{
"diskId": "6000C295-dafe-a0eb-906e-d47cb5b05a1d",
"isOSDisk": "true",
"logStorageAccountId": "/subscriptions/6785ea1f-ac40-4244-a9ce-
94b12fd832ca/resourceGroups/ContosoMigration/providers/Microsoft.Storage/storageAccounts/migra
telsa1432469187",
"logStorageAccountSasSecretName": "migratelsa1432469187-cacheSas",
"diskType": "Standard_LRS"
}
],
"dataMoverRunAsAccountId": "/subscriptions/6785ea1f-ac40-4244-a9ce-
4e4site/runasaccounts/b090bef3-b733-5e34-bc8f-eb6f2701432a",
"snapshotRunAsAccountId": "/subscriptions/6785ea1f-ac40-4244-a9ce-
4e4site/runasaccounts/b090bef3-b733-5e34-bc8f-eb6f2701432a",
"targetBootDiagnosticsStorageAccountId": "/subscriptions/6785ea1f-ac40-
4244-a9ce-
94b12fd832ca/resourceGroups/ContosoMigration/providers/Microsoft.Storage/storageAccounts/migra
telsa1432469187",
"targetVmName": "PayrollWeb04"
}
}
}
]
}
Edit the name property in the resource definition. Replace the string that follows the last "/" in the
name property with the value of $machine.Name( from the previous step).
Change the value of the properties.providerSpecificDetails.vmwareMachineId property with value of
$machine.ResourceId( from the previous step).
Set the values for targetResourceGroupId, targetNetworkId, targetSubnetName to the target
resource group ID, target virtual network resource ID, and target subnet name respectively.
Set the value of licenseType to "WindowsServer" to apply Azure Hybrid Benefit for this VM. If this VM
is not eligible for Azure Hybrid Benefit, set the value of licenseType to NoLicenseType.
Change the value of the targetVmName property to the desired Azure virtual machine name for the
migrated VM.
Optionally add a property named targetVmSize below the targetVmName property. Set the value of
the targetVmSize property to the desired Azure virtual machine size for the migrated VM.
The disksToInclude property is a list of disk inputs for replication with each list item representing one
on-premises disk. Create as many list items as the number of disks on the on-premises VM. Replace the
diskId property in the list item to the uuid of the disks identified in the previous step. Set the isOSDisk
value to "true" for the OS disk of the VM and "false" for all other disks. Leave the logStorageAccountId
and the logStorageAccountSasSecretName properties unchanged. Set the diskType value to the Azure
Managed Disk type (Standard_LRS, Premium_LRS, StandardSSD_LRS) to use for the disk. For the disks
that need to be encrypted with CMK, add a property named diskEncryptionSetId and set the value to
the resource ID of the disk encryption set created($des.Id) in the Create a Disk Encryption Set step
Save the edited template file. For the example above, the edited template file looks as follows:
{
"$schema": "http://schema.management.azure.com/schemas/2015-01-
"resources": [
{
"type":
"Microsoft.RecoveryServices/vaults/replicationFabrics/replicationProtectionContainers/replicat
ionMigrationItems",
"apiVersion": "2018-01-10",
"name":
"ContosoVMwareCMK00ddrsvault/VMwareApplianca8bareplicationfabric/VMwareApplianca8bareplication
container/10-150-8-52-b090bef3-b733-5e34-bc8f-eb6f2701432a_50098f99-f949-22ca-642b-
724ec6595210",
"properties": {
"policyId": "/subscriptions/509099b2-9d2c-4636-b43e-
bd5cafb6be69/resourceGroups/ContosoVMwareCMK/providers/Microsoft.RecoveryServices/vaults/Conto
soVMwareCMK00ddrsvault/replicationPolicies/migrateVMwareApplianca8basitepolicy",
"providerSpecificDetails": {
"instanceType": "VMwareCbt",
"vmwareMachineId": "/subscriptions/509099b2-9d2c-4636-b43e-
plianca8basite/machines/10-150-8-52-b090bef3-b733-5e34-bc8f-eb6f2701432a_50098f99-f949-22ca-
642b-724ec6595210",
"targetResourceGroupId": "/subscriptions/509099b2-9d2c-4636-b43e-
bd5cafb6be69/resourceGroups/ContosoMigrationTarget",
"targetNetworkId": "/subscriptions/509099b2-9d2c-4636-b43e-
bd5cafb6be69/resourceGroups/cmkRTest/providers/Microsoft.Network/virtualNetworks/cmkvm1_vnet",
"targetSubnetName": "cmkvm1_subnet",
"licenseType": "NoLicenseType",
"disksToInclude": [
{
"diskId": "6000C291-5106-2aac-7a74-4f33c3ddb78c",
"isOSDisk": "true",
"logStorageAccountId": "/subscriptions/509099b2-9d2c-4636-b43e-
bd5cafb6be69/resourceGroups/ContosoVMwareCMK/providers/Microsoft.Storage/storageAccounts/migra
telsa1671875959",
"diskEncryptionSetId": "/subscriptions/509099b2-9d2c-4636-b43e-
bd5cafb6be69/resourceGroups/CONTOSOMIGRATIONTARGET/providers/Microsoft.Compute/diskEncryptionS
ets/ContosoCMKDES",
},
{
"diskId": "6000C293-39a1-bd70-7b24-735f0eeb79c4",
"isOSDisk": "false",
telsa1671875959",
ets/ContosoCMKDES",
},
{
"diskId": "6000C29e-cbee-4d79-39c7-d00dd0208aa9",
"isOSDisk": "false",
telsa1671875959",
ets/ContosoCMKDES",
}
],
"dataMoverRunAsAccountId": "/subscriptions/509099b2-9d2c-4636-b43e-
plianca8basite/runasaccounts/b090bef3-b733-5e34-bc8f-eb6f2701432a",
"snapshotRunAsAccountId": "/subscriptions/509099b2-9d2c-4636-b43e-
plianca8basite/runasaccounts/b090bef3-b733-5e34-bc8f-eb6f2701432a",
"targetBootDiagnosticsStorageAccountId": "/subscriptions/509099b2-9d2c-
4636-b43e-
telsa1671875959",
"performAutoResync": "true",
"targetVmName": "FPL-W19-09"
}
}
}
]
}
Set up replication
You can now deploy the edited Resource Manager template to the project resource group to set up
replication for the VM. Learn how to deploy resource with Azure Resource Manager templates and Azure
PowerShell
Azure PowerShell
New-AzResourceGroupDeployment -ResourceGroupName $ProjectResourceGroup -TemplateFile

"C:\Users\Administrator\Downloads\template.json"
Output
DeploymentName : template
ResourceGroupName : ContosoVMwareCMK
ProvisioningState : Succeeded
Timestamp : 3/11/2020 8:52:00 PM
Mode : Incremental
TemplateLink :
Parameters :
Outputs :
DeploymentDebugLogLevel :
Next steps
Monitor replication status through the portal experience and perform Test migrations and migration.
Test migrate replicating virtual
machines
This article helps you understand how to test replicating virtual machines. Test migration
provides a way to test and validate migrations prior to the actual migration.
Prerequisites
Before you get started, perform the following steps:
Create an Azure Migrate project.

Deploy the appliance for your scenario and complete the discovery of virtual
machines.
Configure replication for one or more virtual machines that are to be migrated.
） Important
You'll need at least one replicating virtual machine in the project before you can
test the migration.
Review the following tutorials based on your environment:
Migrating VMware VMs with agentless migration.

Migrating Hyper-V VMs to Azure.
Migrating machines as physical servers to Azure
Setting up your test environment

The requirements for a test environment can vary according to your needs. Azure
Migrate provides customers complete flexibility to create their own test environment. An
option to select the VNet is provided during test migration. You can customize the
setting of this VNet to create a test environment according to your requirement.
Furthermore, you can create 1:1 mapping between subnets of the VNet and Network
Interface Cards (NICs) on VM, which gives more flexibility in creating the test
environment.
７ Note
Currently, the subnet selection feature is available only for agentless VMware
migration scenario.
The following logic is used for subnet selection for other scenarios (Migration from
Hyper-V environment and physical server migration).
If a target subnet (other than default) was specified as an input while enabling
replication. Azure Migrate prioritizes using a subnet with the same name in the
Virtual Network selected for the test migration.
If the subnet with the same name ins't found, then Azure Migrate selects the first
subnet available alphabetically that isn't a Gateway/Application
Gateway/Firewall/Bastion subnet. For example,
Suppose the target VNet is VNet-alpha and target subnet is Subnet-alpha for a
replicating VM. VNet-beta is selected during test migration for this VM, then -
If VNet-beta has a subnet named Subnet-alpha, that subnet would be chosen
for test migration.
If VNet-beta doesn't have a Subnet-alpha, then the next alphabetically available
subnet, suppose Subnet-beta, would be chosen if it isn't Gateway / Application
Gateway / Firewall / Bastion subnet.
Precautions to take while selecting the test

migration virtual network
The test environment boundaries would depend on the network setting of the VNet you
selected. The tested VM would behave exactly like it's supposed to run after migration.
Performing a test migration to a production virtual network is not recommended. If the
VNet selected for test migration has connections open to the on-premises VNet, it may
cause issues like duplication of VM or DNS entry changes.
Selecting test migration VNet while enabling

replication (Agentless VMware migration)
Select the VNet and subnet for test migration from the Target settings tab. These
settings can be overridden later in the Compute and Network tab of the replicating VM
or while starting test migration of the replicating VM.
Changing test migration virtual network and
subnet of a replicating machine (Agentless
VMware migration)
You can change the VNet and subnet of a replicating machine by following the steps
below.
1. Select the virtual machine from the list of currently replicating virtual machines
2. Select Compute and Network option under General.
3. Select the virtual network from the Test migration column. It's important to select
the VNet in this drop down for test migration to be able to select subnet for each
Network Interface Card (NIC) in the following steps.
4. Select the NIC's name to check its settings. You can select the subnet for each of
the NICs of the VM.
5. To change the settings, select edit. Change the setting for the NIC in the new form.
Select OK.
6. Select Save. Changes aren't saved until you can see the colored square next to the
NIC's name.
Scale agentless migration of VMware
virtual machines to Azure
This article helps you understand how to use a scale-out appliance to migrate a large
number of VMware virtual machines (VMs) to Azure using the Migration and
modernization tool's agentless method for migration of VMware VMs.
Using the agentless migration method for VMware virtual machines you can:
Replicate up to 300 VMs from a single vCenter server concurrently using one Azure
Migrate appliance.
Replicate up to 500 VMs from a single vCenter server concurrently by deploying a
second scale-out appliance for migration.
In this article, you will learn how to:
Add a scale-out appliance for agentless migration of VMware virtual machines

Migrate up to 500 VMs concurrently using the scale-out appliance.
Prerequisites
Before you get started, you need to perform the following steps:
Create the Azure Migrate project.

Deploy the Azure Migrate appliance (primary appliance) and complete discovery of
VMware virtual machines managed by your vCenter server.
Configure replication for one or more virtual machines that are to be migrated.
） Important
You'll need to have at least one replicating virtual machine in the project before you
can add a scale-out appliance for migration.
To learn how to perform the above, review the tutorial on migrating VMware virtual
machines to Azure with the agentless migration method.
Deploy a scale-out appliance

To add a scale-out appliance, follow the steps mentioned below:
1. Click on Discover > Are your machines virtualized?
2. Select Yes, with VMware vSphere Hypervisor.
3. Select agentless replication in the next step.
4. Select Scale-out an existing primary appliance in the select the type of appliance
menu.
5. Select the primary appliance (the appliance using which discovery was performed)
that you wish to scale out.
1. Generate the Azure Migrate project key

1. In Generate Azure Migrate project key, provide a suffix name for the scale-out
appliance. The suffix can contain only alphanumeric characters and has a length
limit of 14 characters.
2. Click Generate key to start the creation of the required Azure resources. Do not
close the Discover page during the creation of resources.
3. Copy the generated key. You will need the key later to complete the registration of
the scale-out appliance.
2. Download the installer for the scale-out appliance

In Download Azure Migrate appliance, click Download. You need to download the
PowerShell installer script to deploy the scale-out appliance on an existing server
running Windows Server 2016 and with the required hardware configuration (32-GB
RAM, 8 vCPUs, around 80 GB of disk storage and internet access, either directly or
through a proxy).
 Tip
You can validate the checksum of the downloaded zip file using these steps:
1. On the server to which you downloaded the file, open an administrator

command window.
2. Run the following command to generate the hash for the zipped file: -
C:\>CertUtil -HashFile <file_location> [Hashing Algorithm] - Example
usage: C:\>CertUtil -HashFile

3. Download the latest version of the scale-out appliance installer from the
portal if the computed hash value doesn't match this string:
CE63463B3CE07D7500F0A34F9CAFF0AB939368E5DB320F9F05EE45A386A49C
DC


command:
5. Select from the scenario, cloud, configuration and connectivity options to deploy
the desired appliance. For instance, the selection shown below sets up a scale-out
appliance to initiate concurrent replications on servers running in your VMware
connectivity on Azure public cloud.
Installs gateway agent and appliance configuration manager to perform more

concurrent server replications.
PowerShell ISE.
Migrate.
７ Note

Before you begin, ensure that the these Azure endpoints are accessible from the scale-
out appliance.
Open a browser on any machine that can connect to the scale-out appliance
server, and open the URL of the appliance configuration manager: https://scale-
out appliance name or IP address: 44368.
Alternately, you can open the configuration manager from the scale-out appliance
server's desktop using the shortcut to the configuration manager.
Accept the license terms, and read the third-party information.

steps:
uses a proxy:

７ Note

that's shown.
to see the prompt.
７ Note

Import appliance configuration from primary appliance

To complete the registration of the scale-out appliance, click import to get the
necessary configuration files from the primary appliance.
i. Clicking import opens a pop-up window with instructions on how to import

the necessary configuration files from the primary appliance.
ii. Login (remote desktop) to the primary appliance and execute the following
PowerShell commands:
PS cd 'C:\Program Files\Microsoft Azure Appliance Configuration

Manager\Scripts\PowerShell'
PS .\ExportConfigFiles.ps1
iii. Copy the zip file created by running the above commands to the scale-out
appliance. The zip file contains configuration files needed to register the
scale-out appliance.
iv. In the pop-up window opened in the previous step, select the location of the
copied configuration zip file and click Save.
Once the files have been successfully imported, the registration of the scale-out
appliance will complete and it will show you the timestamp of the last successful
import. You can also see the registration details by clicking View details.
4. Install the VDDK: The appliance checks that VMware vSphere Virtual Disk
Development Kit (VDDK) is installed. If the VDDK isn't installed, download VDDK
6.7 from VMware. Extract the downloaded zip file contents to the specified location
on the appliance, as indicated in the Installation instructions.
The Migration and modernization tool uses the VDDK to replicate servers during
migration to Azure.
At this point, you should revalidate that the scale-out appliance is able to connect to
your vCenter server. Click revalidate to validate vCenter Server connectivity from scale-
out appliance.
） Important
If you edit the vCenter Server credentials on the primary appliance, ensure that you
import the configuration files again to the scale-out appliance to get the latest
configuration and continue any ongoing replications.
If you do not need the scale-out appliance any longer, make sure that you disable
the scale-out appliance. Learn more on how to disable the scale-out appliance
when not needed.
Replicate
1. After the scale-out appliance is registered, on the Migration and modernization
tile, select Replicate.
2. Follow the steps on the screen to start replicating more virtual machines.
With the scale-out appliance in place, you can now replicate 500 VMs concurrently. You
can also migrate VMs in batches of 200 through the Azure portal.
The Migration and modernization tool will take care of distributing the virtual machines
between the primary and scale-out appliance for replication. Once the replication is
done, you can migrate the virtual machines.
 Tip
We recommend migrating virtual machines in batches of 200 for optimal

performance if you want to migrate a large number of virtual machines.
Next steps
In this article, you learned:
How to configure a scale-out appliance

How to replicate VMs using a scale-out appliance
Learn more about migrating servers to Azure using the Migration and modernization
tool.
Scale migration of VMs
This article helps you understand how to use scripts to migrate large number of virtual
machines (VMs). To scale migration, you use Azure Site Recovery.
Site Recovery scripts are available for your download at Azure PowerShell Samples
repo on GitHub. The scripts can be used to migrate VMware, AWS, GCP VMs, and
physical servers to managed disks in Azure. You can also use these scripts to migrate
Hyper-V VMs if you migrate the VMs as physical servers. The scripts that leverage Azure
Site Recovery PowerShell are documented here.
Current limitations
Supports specifying the static IP address only for the primary NIC of the target VM.
The scripts do not take Azure Hybrid Benefit related inputs; you need to manually
update the properties of the replicated VM in the portal.
How does it work?
Prerequisites
Before you get started, you need to do the following steps:
Ensure that the Site Recovery vault is created in your Azure subscription.
Ensure that the Configuration Server and Process Server are installed in the source
environment and the vault can discover the environment.
Ensure that a Replication Policy is created and associated with the Configuration
Server.
Ensure that you have added the VM admin account to the config server (that will
be used to replicate the on premises VMs).
Ensure that the following target artifacts in Azure are created:
Target Resource Group
Target Storage Account (and its Resource Group) - Create a premium storage
account if you plan to migrate to premium-managed disks
Cache Storage Account (and its Resource Group) - Create a standard storage
account in the same region as the vault
Target Virtual Network for failover (and its Resource Group)
Target Subnet
Target Virtual Network for Test failover (and its Resource Group)
Availability Set (if needed)
Target Network Security Group and its Resource Group
Ensure that you have decided on the following properties of the target VM
Target VM name
Target VM size in Azure (can be decided using Azure Migrate assessment)
Private IP Address of the primary NIC in the VM
Download the scripts from Azure PowerShell Samples repo on GitHub
CSV Input file

Once you have completed all the pre-requisites, you need to create a CSV file, which has
data for each source machine that you want to migrate. The input CSV must have a
header line with the input details and a row with details for each machine that needs to
be migrated. All the scripts are designed to work on the same CSV file. A sample CSV
template is available in the scripts folder for your reference.
Script execution
Once the CSV is ready, you can execute the following steps to perform migration of the
on-premises VMs:
Step Script Name Description

#
1 asr_startmigration.ps1 Enable replication for all the VMs listed in the csv, the
script creates a CSV output with the job details for each
VM
2 asr_replicationstatus.ps1 Check the status of replication, the script creates a csv with
the status for each VM
3 asr_updateproperties.ps1 Once the VMs are replicated/protected, use this script to

update the target properties of the VM (Compute and
Network properties)
4 asr_propertiescheck.ps1 Verify if the properties are appropriately updated
5 asr_testmigration.ps1 Start the test failover of the VMs listed in the csv, the script
creates a CSV output with the job details for each VM
6 asr_cleanuptestmigration.ps1 Once you manually validate the VMs that were test failed-
over, you can use this script to clean up the test failover
VMs
#
7 asr_migration.ps1 Perform an unplanned failover for the VMs listed in the csv,
the script creates a CSV output with the job details for
each VM. The script does not shut down the on premises
VMs before triggering the failover, for application
consistency, it is recommended that you manually shut
down the VMs before executing the script.
8 asr_completemigration.ps1 Perform the commit operation on the VMs and delete the
Azure Site Recovery entities
9 asr_postmigration.ps1 If you plan to assign network security groups to the NICs

post-failover, you can use this script to do that. It assigns
an NSG to any one NIC in the target VM.
How to migrate to managed disks?

The script, by default, migrates the VMs to managed disks in Azure. If the target storage
account provided is a premium storage account, premium-managed disks are created
post migration. The cache storage account can still be a standard account. If the target
storage account is a standard storage account, standard disks are created post
migration.
Next steps
Learn more about migrating servers to Azure using Azure Site Recovery
 Documentation

Migrate

Replicate data over ExpressRoute for Azure Migrate projects with public endpoint
connectivity - Azure Migrate
Use Azure ExpressRoute for replication with the Migration and modernization tool.


Show 5 more
Scale migration of VMware VMs
Article • 05/11/2023
This article helps you understand how to use scripts to migrate large number of VMware
virtual machines (VMs) using the agentless method. To scale migrations, you use Azure
Migrate PowerShell module.
The Azure Migrate VMware migration automation scripts are available for download in
the Azure PowerShell Samples repo on GitHub. The scripts can be used to migrate
VMware VMs to Azure using the agentless migration method. The Azure Migrate
PowerShell commands used in these scripts are documented here.
Current limitations
These scripts support migration of VMware VMs with all its disks. You can update
the scripts if you want to selectively replicate the disks attached to a VMware VM.
The scripts support use of assessment recommendations. If assessment
recommendations aren't used, all disks attached to the VMware VM are migrated
to the same managed disk type (Standard or Premium). You can update the scripts
if you want to use multiple types of managed disks with the same VM.
Prerequisites
Complete the discovery tutorial to prepare Azure and VMware for migration.
We recommend that you complete the second tutorial to assess VMware VMs
before migrating them to Azure.
You must have the Azure PowerShell Az module. If you need to install or upgrade
Azure PowerShell, follow this guide to install and configure Azure PowerShell.
Install Azure Migrate PowerShell module

The Azure Migrate PowerShell module is available in preview. You'll need to install the
PowerShell module using the following command.
Azure PowerShell
Install-Module -Name Az.Migrate

CSV input file
Once you have completed all the pre-requisites, you need to create a CSV file that has
data of each source VM that you want to migrate. All the scripts are designed to work
on the same CSV file. A sample CSV template is available in the scripts folder for your
reference. The csv file is configurable so that you can use assessment recommendations
and even specify if certain operations are not to be triggered for a particular VM.
７ Note
The same csv file can be used to migrate VMs in multiple Azure Migrate projects.
CSV file schema
Column Header Description
AZMIGRATEPROJECT_SUBSCRIPTION_ID Provide Azure Migrate project subscription ID.
AZMIGRATEPROJECT_RESOURCE_GROUP_NAME Provide Azure Migrate resource group name.
AZMIGRATEPROJECT_NAME Provide the name of the Azure Migrate project

in that you want to migrate servers.
SOURCE_MACHINE_NAME Provide a friendly name (display name) for the

discovered VM in the Azure Migrate project.
AZMIGRATEASSESSMENT_NAME Provide the name of the assessment that

needs to be leveraged for migration.
AZMIGRATEGROUP_NAME Provide the name of the group that was used

for the Azure Migrate assessment.
TARGET_RESOURCE_GROUP_NAME Provide the name of the Azure resource group

to which the VM needs to be migrated to.
TARGET_VNET_NAME Provide the name of the Azure Virtual Network

that the migrated VM should use.
TARGET_SUBNET_NAME Provide the name of the subnet in the target

virtual network that the migrated VM should
use. If left blank, “default” subnet will be used.
TARGET_MACHINE_NAME Provide the name that the migrated VM

should use in Azure. If left blank, the source
machine name will be used.
TARGET_MACHINE_SIZE Provide the Stock Keeping Unit (SKU) that the

VM should use in Azure. To migrate a VM to
D2_v2 VM in Azure, specify the value in this
field as "Standard_D2_v2". If you use an
assessment, this value will be derived based on
the assessment recommendation.
LICENSE_TYPE Specify if you want to use Azure Hybrid Benefit

for Windows Server VMs. Use value
"WindowsServer" to take advantage of Azure
Hybrid Benefit. Otherwise, leave it blank or use
"NoLicenseType".
OS_DISK_ID Provide the OS disk ID for the VM to be

migrated. The disk ID to be used is the unique
identifier (UUID) property for the disk retrieved
using the Get-AzMigrateServer cmdlet. The
script will use the first disk of the VM as the OS
disk in case no value is provided.
TARGET_DISKTYPE Provide the disk type to be used for all disks of

the VM in Azure. Use 'Premium_LRS' for
premium-managed disks, 'StandardSSD_LRS'
for standard SSD disks and 'Standard_LRS' to
use standard HDD disks. If you choose to use
an assessment, the script will prioritize using
recommended disk types for each disk of the
VM. If you don't use assessment or specify any
value, the script will use standard HDD disks by
default.
AVAILABILITYZONE_NUMBER Specify the availability zone number to be

used for the migrated VM. You can leave this
blank if you don't want to use availability
zones.
AVAILABILITYSET_NAME Specify the name of the availability set to be

used for the migrated VM. You can leave this
blank if you don't want to use availability set.
TURNOFF_SOURCESERVER Specify 'Y' if you want to turn off the source

VM at the time of migration. Use 'N' otherwise.
If left blank, the script assumes the value as 'N'.
TESTMIGRATE_VNET_NAME Specify the name of the virtual network to be

used for test migration.
UPDATED_TARGET_RESOURCE_GROUP_NAME If you want to update the resource group to be

used by the migrated VM in Azure, specify the
name of the Azure resource group, else leave it
blank.
UPDATED_TARGET_VNET_NAME If you want to update the Virtual Network to

be used by the migrated VM in Azure, specify
the name of the Azure Virtual Network, else
leave it blank.
UPDATED_TARGET_MACHINE_NAME If you want to update the name to be used by

the migrated VM in Azure, specify the new
name to be used, else leave it blank.
UPDATED_TARGET_MACHINE_SIZE If you want to update the SKU to be used by

the migrated VM in Azure, specify the new SKU
to be used, else leave it blank.
UPDATED_AVAILABILITYZONE_NUMBER If you want to update the availability zone to

be used by the migrated VM in Azure, specify
the new availability zone to be used, else leave
it blank.
UPDATED_AVAILABILITYSET_NAME If you want to update the availability set to be

used by the migrated VM in Azure, specify the
new availability set to be used, else leave it
blank.
UPDATE_NIC1_ID Specify the ID of the NIC to be updated. If left

blank, the script assumes the value to be the
first NIC of the discovered VM. If you don't
want to update the NIC of the VM, leave all the
fields containing NIC name blank.
UPDATED_TARGET_NIC1_SELECTIONTYPE Specify the value to be used for this NIC. Use

"Primary","Secondary", or "DoNotCreate" to
specify if this NIC should be the primary,
secondary, or should not be created on the
migrated VM. Only one NIC can be specified as
the primary NIC for the VM. Leave blank if you
don't want to update.
UPDATED_TARGET_NIC1_SUBNET_NAME Specify the name of the subnet to use for the

NIC on the migrated VM. Leave blank if you
UPDATED_TARGET_NIC1_IP Specify the IPv4 address to be used by the NIC

on the migrated VM if you want to use static
IP. Use "auto" if you want to automatically
assign the IP. Leave blank if you don't want to
update.
UPDATE_NIC2_ID Specify the ID of the NIC to be updated. If left

blank, then the script assumes the value to be
the second NIC of the discovered VM. If you
don't want to update the NIC of the VM, then
leave all the fields containing NIC name blank.
UPDATED_TARGET_NIC2_SELECTIONTYPE Specify the value to be used for this NIC. Use

"Primary","Secondary" or "DoNotCreate" to
specify if this NIC should be the primary,
secondary, or should not be created on the
migrated VM. Only one NIC can be specified as
the primary NIC for the VM. Leave blank if you
UPDATED_TARGET_NIC2_SUBNET_NAME Specify the name of the subnet to use for the

NIC on the migrated VM. Leave blank if you
UPDATED_TARGET_NIC2_IP Specify the IPv4 address to be used by the NIC

on the migrated VM if you want to use static
IP. Use "auto" if you want to automatically
assign the IP. Leave blank if you don't want to
update.
OK_TO_UPDATE Use 'Y' to indicate whether the VM properties

need to be updated when you run the
AzMigrate_UpdateMachineProperties script.
Use 'N' or leave blank otherwise.
OK_TO_MIGRATE Use 'Y' to indicate whether the VM should be

migrated when you run the
AzMigrate_StartMigration script. Use 'N' or
leave blank if you don't want to migrate the
VM.
OK_TO_USE_ASSESSMENT Use 'Y' to indicate whether the VM should start

replication using assessment
recommendations when you run the
AzMigrate_StartReplication script. This will
override the TARGET_MACHINE_SIZE and
TARGET_DISKTYPE values in the csv file. Use 'N'
or leave blank if you don't want to use
assessment recommendations.
OK_TO_TESTMIGRATE Use 'Y' to indicate whether the VM should be

test migrated when you run the
AzMigrate_StartTestMigration script. Use 'N' or
leave blank if you don't want to test migrate
the VM.
OK_TO_RETRIEVE_REPLICATIONSTATUS Use 'Y' to indicate whether the replication

status of the VM should be updated when you
run the AzMigrate_ReplicationStatus script. Use
'N' or leave blank if you don't want to update
the replication status.
OK_TO_CLEANUP Use 'Y' to indicate whether the replication for

the VM should be cleaned up when you run
the AzMigrate_StopReplication script. Use 'N'
or leave blank otherwise.
OK_TO_TESTMIGRATE_CLEANUP Use 'Y' to indicate whether the test migration

for the VM should be cleaned up when you
run the AzMigrate_CleanUpTestMigration
script. Use 'N' or leave blank otherwise.
Script execution
Once the CSV is ready, you can execute the following steps to migrate your on-premises
VMware VMs.

#
1 AzMigrate_StartReplication.ps1 Enable replication for all the VMs listed in the

csv, the script creates a CSV output and a log
file for troubleshooting.
2 AzMigrate_ReplicationStatus.ps1 Check the status of replication, the script

creates a csv output with the status for each
VM and a log file for troubleshooting.
#
3 AzMigrate_UpdateMachineProperties.ps1 Once the VMs have completed initial

replication, use this script to update the target
properties of the VM (Compute and Network
properties). The script creates a CSV output
with the job details for each VM.
4 AzMigrate_StartTestMigration.ps1 Start the test failover for all VMs listed in the
csv that are configured for test migration. The
script creates a CSV output with the job details
for each VM.
5 AzMigrate_CleanUpTestMigration.ps1 Once you manually validate the VMs that were

test failed-over, use this script to clean up the
test failover VMs for all VMs listed in the csv
that are configured for test migration cleanup.
The script creates a CSV output with the job
details for each VM.
6 AzMigrate_StartMigration.ps1 Start the migration for all VMs listed in the csv
that are configured for migration. The script
creates a CSV output with the job details for
each VM.
7 AzMigrate_StopReplication.ps1 Stops the replication for the VM after it has

been successfully migrated or if you want to
cancel the replication due to other reasons.
The script creates a CSV output with the job
details for each VM.
The following scripts are invoked by other scripts for all Azure Migrate operations like
enabling replication, starting test migration, updating VM properties and so on. Ensure
that all the scripts are present in the same folder/path.

#
1 AzMigrate_Shared.ps1 Common script containing functions for retrieving

assessment properties (through API), discovered VMs, and
replicating VMs.
2 AzMigrate_CSV_Processor.ps1 Common script containing functions used for csv file

operations including loading, reading, and printing for
logs.
#
3 AzMigrate_Logger.ps1 Common script invoked for generating the log file for
Azure Migrate automation operations. The log file will be
of the format log.Scriptname.Datetime.txt.
In addition to the above, the folder also contains AzMigrate_Template.ps1 that contains
the skeleton framework for building custom scripts for different Azure Migrate
operations.
Script execution syntax

Once you have downloaded the scripts, the scripts can be executed as follows.
If you want to execute the script to start replication for VMs using the Input.csv file, use
the following syntax.
Azure PowerShell
".\AzMigrate_StartReplication.ps1" .\Input.csv
To learn more about using Azure PowerShell for migrating VMware VMs with Azure
Migrate, follow the tutorial.
Delete an Azure Migrate project
This article describes how to delete an Azure Migrate project.
Before you start

Before you delete a project:
When you delete a project, the project, and discovered machine metadata are
deleted.
If you've attached a Log Analytics workspace to the Server Assessment tool for
dependency analysis, decide whether you want to delete the workspace.
The workspace isn't automatically deleted. Delete it manually.
Verify what a workspace is used for before you delete it. The same Log Analytics
workspace can be used for multiple scenarios.
Before you delete the project, you can find a link to the workspace in Azure
Migrate - Servers > Azure Migrate - Server Assessment, under OMS
Workspace.
To delete a workspace after deleting a project, find the workspace in the
relevant resource group, and follow these instructions.
Delete a project
1. In the Azure portal, open the resource group in which the project was created.
2. In the resource group page, select Show hidden types.
3. Select the project and the associated resources that you want to delete.
The resource type for Azure Migrate projects is

Microsoft.Migrate/migrateprojects.
In the next section, review the resources created for discovery, assessment,
and migration in an Azure Migrate project.
If the resource group only contains the Azure Migrate project, you can delete
the entire resource group.
If you want to delete a project from the previous version of Azure Migrate,
the steps are the same. The resource type for these projects is Migration
project.
Created resources
These tables summarize the resources created for discovery, assessment, and migration
in an Azure Migrate project.
７ Note
Delete the key vault with caution because it might contain security keys.
Projects with public endpoint connectivity
VMware/physical server
Resource Type
"Appliancename"kv Key vault
"Appliancename"site Microsoft.OffAzure/VMwareSites
"ProjectName" Microsoft.Migrate/migrateprojects
"ProjectName"project Microsoft.Migrate/assessmentProjects
"ProjectName"rsvault Recovery Services vault
"ProjectName"-MigrateVault-* Recovery Services vault
migrateappligwsa* Storage account
migrateapplilsa* Storage account
migrateapplicsa* Storage account
migrateapplikv* Key vault
migrateapplisbns* Service Bus Namespace
Hyper-V VM
Resource Type
"ProjectName" Microsoft.Migrate/migrateprojects
"ProjectName"project Microsoft.Migrate/assessmentProjects
HyperV*kv Key vault
HyperV*Site Microsoft.OffAzure/HyperVSites
Resource Type
"ProjectName"-MigrateVault-* Recovery Services vault
The following tables summarize the resources created by Azure Migrate to discover,
assess, and migrate servers over a private network using [Azure private link](./how-to-
use-azure-migrate-with-private-endpoints.md).
Projects with private endpoint connectivity
VMware VMs - agentless migrations
Type Resource Private endpoint
Microsoft.Migrate/migrateprojects "ProjectName" "ProjectName"*pe
Discovery site (master site) "ProjectName"*mastersite "ProjectName"*mastersite*pe
Microsoft.Migrate/assessmentProjects "ApplianceName"*project "ApplianceName"*project*pe
Key vault "ProjectName"*kv "ProjectName"*kv*pe
Microsoft.OffAzure/VMwareSites "ApplianceName"*site NA
Recovery Services vault "ApplianceName"*vault NA
Storage account "ApplianceName"*usa "ApplianceName"*usa*pe
Recovery Services vault "ProjectName"- NA

MigrateVault-*
Storage account migrateappligwsa* NA
Storage account migrateapplilsa* NA
Key vault migrateapplikv* NA
Service Bus Namespace migrateapplisbns* NA
Hyper-V VMs

Microsoft.OffAzure/HyperVSites "ApplianceName"*site NA
Recovery Services vault "ProjectName"- "ProjectName"-MigrateVault-

MigrateVault-* *pe
Physical servers / AWS VMs / GCP VMs
Microsoft.OffAzure/serversites "ApplianceName"*site NA
Recovery Services vault "ProjectName"- "ProjectName"-MigrateVault-

MigrateVault-* *pe
Next steps
Learn how to add additional assessment and migration tools.
Work with the previous version of Azure
Migrate
This article provides information about working with the previous version of Azure
Migrate.
There are two versions of the Azure Migrate service:
Current version: Use this version to create Azure Migrate projects, discover on-
premises machines, and orchestrate assessments and migrations. Learn more
about what's new in this version.
Previous version: If you're using the previous version of Azure Migrate (only
assessment of on-premises VMware VMs was supported), you should now use the
current version. The previous version projects are referred to as Classic projects in
this article. Classic Azure Migrate is retiring in Feb 2024. After Feb 2024, the classic
version of Azure Migrate will no longer be supported and the inventory metadata
in classic projects will be deleted. If you still need to use classic Azure Migrate
projects, this is what you can and can't do:
You can no longer create migration projects.
We recommend that you don't perform new discoveries.
You can still access existing projects.
You can still run assessments.
Upgrade between versions

You can't upgrade projects or components in the previous version to the new version.
You need to create a new Azure Migrate project, and add assessment and migration
tools to it. Use the tutorials to understand how to use the assessment and migration
tools available. If you had a Log Analytics workspace attached to a Classic project, you
can attach it to a project of current version after you delete the Classic project.
Find projects from previous version

Find projects from the previous version as follows:
1. In the Azure portal > All services, search for and select Azure Migrate.
2. On the Azure Migrate dashboard, there's a notification and a link to access old
Azure Migrate projects.
3. Click the link to open Classic projects.
Delete projects from previous version

Find and delete projects from the previous version as follows:
1. In the Azure portal > All services, search for and select Azure Migrate.
2. On the Azure Migrate dashboard, there's a notification and a link to access old
Azure Migrate projects.
3. Click the link to open Classic projects.
4. Select the project you would like to delete and delete it.
Create an assessment
After VMs are discovered in the portal, you group them and create assessments.
You can create on-premises assessments immediately after VMs are discovered in
the portal.
For performance-based assessments, we recommend you wait at least a day before
creating a performance-based assessment, to get reliable size recommendations.
Create an assessment as follows:
1. In the project Overview page, click +Create assessment.

2. Click View all to review the assessment properties.
3. Create the group, and specify a group name.
4. Select the machines that you want to add to the group.
5. Click Create Assessment, to create the group and the assessment.
6. After the assessment is created, view it in Overview > Dashboard.
7. Click Export assessment, to download it as an Excel file.
If you would like to update an existing assessment with the latest performance data, you
can use the Recalculate command on the assessment to update it.
An assessment has three stages:
An assessment starts with a suitability analysis to figure out whether machines are
compatible in Azure.
Sizing estimations.
Monthly cost estimation.
A machine only moves along to a later stage if it passes the previous one. For example,
if a machine fails the suitability check, it’s marked as unsuitable for Azure, and sizing and
costing isn't done.
Review Azure readiness

The Azure readiness view in the assessment shows the readiness status of each VM.
Readiness State Details
Ready for No compatibility issues. The machine can be migrated For VMs that are ready,
Azure as-is to Azure, and it will boot in Azure with full Azure Azure Migrate
support. recommends a VM size
in Azure.
Conditionally The machine might boot in Azure, but might not have Azure Migrate explains
ready for full Azure support. For example, a machine with an the readiness issues,
Azure older version of Windows Server that isn't supported in and provides
Azure. remediation steps.
Not ready The VM won't boot in Azure. For example, if a VM has Azure Migrate explains
for Azure a disk that's more than 4 TB, it can't be hosted on the readiness issues and
Azure. provides remediation
steps.
Readiness Azure Migrate can't identify Azure readiness, usually

unknown because data isn't available.
Azure VM properties
Readiness takes into account a number of VM properties, to identify whether the VM

can run in Azure.
Property Details Readiness
Boot type BIOS supported. UEFI not supported. Conditionally

ready if boot type
is UEFI.
Property Details Readiness
Cores Machines core <= the maximum number of cores (128) Ready if less than
supported for an Azure VM. or equal to limits.
If performance history is available, Azure Migrate considers the

utilized cores.
If a comfort factor is specified in the assessment settings, the
number of utilized cores is multiplied by the comfort factor.
If there's no performance history, Azure Migrate uses the

allocated cores, without applying the comfort factor.
Memory The machine memory size <= the maximum memory (3892 GB Ready if within
on Azure M series Standard_M128m 2) for an Azure VM. Learn limits.
more.
If performance history is available, Azure Migrate considers the

utilized memory.
If a comfort factor is specified, the utilized memory is

multiplied by the comfort factor.
If there's no history, the allocated memory is used, without

applying the comfort factor.
Storage Allocated size of a disk must be 4 TB (4096 GB) or less. Ready if within
disk limits.
The number of disks attached to the machine must be 65 or
less, including the OS disk.
Networking A machine must have 32 or less NICs attached to it. Ready if within
limits.
Guest operating system

Along with VM properties, Azure Migrate also looks at the guest OS of the on-premises
VM to identify if the VM can run in Azure.
Azure Migrate considers the OS specified in the vCenter Server.

Since the discovery done by Azure Migrate is appliance-based, it does not have a
way to verify if the OS running inside the VM is same as the one specified in
vCenter Server.
The following logic is used.

Operating Details Readiness
System
Windows Azure provides full support. Ready for Azure

Server 2016
and all SPs

Server 2012
R2 and all
SPs

Server 2012
and all SPs

Server 2008
R2 and all
SPs

Server 2008
(32-bit and
64-bit)
Windows Out-of-support and need a Custom Support Conditionally ready for Azure.
Server 2003, Agreement (CSA) for support in Azure. Consider upgrading the OS
2003 R2 before migrating to Azure.
Windows Out-of-support. The machine might boot in Conditionally ready for Azure. It
2000, 98, 95, Azure, but no OS support is provided by Azure. is recommended to upgrade
NT, 3.1, MS- the OS before migrating to
DOS Azure.
Windows Azure provides support with Visual Studio Conditionally ready for Azure.
Client 7, 8 subscription only.
and 10
Windows 10 Azure provides support with Multitenant Conditionally ready for Azure.
Pro Desktop Hosting Rights.
Windows Out-of-support. The machine might boot in Conditionally ready for Azure. It
Vista, XP Azure, but no OS support is provided by Azure. is recommended to upgrade
Professional the OS before migrating to
Azure.
Operating Details Readiness
System
Linux Azure endorses these Linux operating systems. Ready for Azure if the version is
Other Linux operating systems might boot in endorsed.
Azure, but we recommend upgrading the OS
to an endorsed version, before migrating to Conditionally ready if the
Azure. version is not endorsed.
Other Azure doesn't endorse these operating Conditionally ready for Azure. It
operating systems. The machine may boot in Azure, but is recommended to install a
systems no OS support is provided by Azure. supported OS before migrating
to Azure.
For example,
Oracle
Solaris, Apple
macOS etc.,
FreeBSD, etc.
OS specified Azure Migrate cannot identify the OS in this Unknown readiness. Ensure that
as Other in case. the OS running inside the VM is
vCenter supported in Azure.
Server
32-bit The machine may boot in Azure, but Azure may Conditionally ready for Azure,
operating not provide full support. consider upgrading the OS of
systems the machine from 32-bit OS to
64-bit OS before migrating to
Azure.
Review sizing
The Azure Migrate size recommendation depends on the sizing criterion specified in the
assessment properties.
If sizing is performance-based, the size recommendation considers the

performance history of the VMs (CPU and memory) and disks (IOPS and
throughput).
If the sizing criterion is 'as on-premises', the size recommendation in Azure is
based on the size of the VM on-premises. Disk sizing is based on the Storage type
specified in the assessment properties (default is premium disks). Azure Migrate
doesn't consider the performance data for the VM and disks.

Cost estimates show the total compute and storage cost of running the VMs in Azure,
along with the details for each machine.
Cost estimates are calculated using the size recommendation for a VM machine,
and its disks, and the assessment properties.
Estimated monthly costs for compute and storage are aggregated for all VMs in
the group.
The cost estimation is for running the on-premises VM as Azure Infrastructure as a
service (IaaS) VMs. Azure Migrate doesn't consider costs for Platform as a service
(PaaS) or Software as a service (SaaS).
Review confidence rating (performance-based

assessment)
Each performance-based assessment is associated with a confidence rating.
A confidence rating ranges from one-star to five-star (one-star being the lowest
and five-star the highest).
The confidence rating is assigned to an assessment, based on the availability of
data points needed to compute the assessment.
The confidence rating of an assessment helps you estimate the reliability of the
size recommendations provided by Azure Migrate.
Confidence rating isn't available for "as-is" on-premises assessments.
For performance-based sizing, Azure Migrate needs the following:
Utilization data for CPU.

VM memory data.
For every disk attached to the VM, it needs the disk IOPS and throughput data.
For each network adapter attached to a VM, Azure Migrate needs the network
input/output.
If any of the above aren't available, size recommendations (and thus confidence
ratings) might not be reliable.
Depending on the percentage of data points available, the possible confidence ratings
are summarized in the table.
0%-20% 1 Star
21%-40% 2 Star
41%-60% 3 Star
61%-80% 4 Star
81%-100% 5 Star
Assessment issues affecting confidence ratings

An assessment might not have all the data points available due to a number of reasons:
You didn't profile your environment for the duration of the assessment. For
example, if you create the assessment with performance duration set to one day,
you must wait for at least a day after you start the discovery, or all the data points
to be collected.
Some VMs were shut down during the period for which the assessment was
calculated. If any VMs were powered off for part of the duration, Azure Migrate
can't collect performance data for that period.
Some VMs were created in between during the assessment calculation period. For
example, if you create an assessment using the last month's performance history
but create a number of VMs in the environment a week ago, the performance
history of the new VMs won't be for the entire duration.
７ Note
If the confidence rating of any assessment is below five-stars, wait for at least a day
for the appliance to profile the environment, and then recalculate the assessment. If
you don't performance-based sizing might not be reliable. If you don't want to
recalculate, we recommended switching to as on-premises sizing, by changing the
assessment properties.
Create groups using dependency visualization

In addition to creating groups manually, you can create groups using dependency
visualization.
You typically use this method when you want to assess groups with higher levels of
confidence by cross-checking machine dependencies, before you run an
assessment.
Dependency visualization can help you effectively plan your migration to Azure. It
helps you ensure that nothing is left behind, and that surprise outages do not
occur when you are migrating to Azure.
You can discover all interdependent systems that need to migrate together and
identify whether a running system is still serving users or is a candidate for
decommissioning instead of migration.
Azure Migrate uses the Service Map solution in Azure Monitor to enable
７ Note
Dependency visualization is not available in Azure Government.
To set up dependency visualization, you associate a Log Analytics workspace with an

Azure Migrate project, install agents on machines for which you want to visualize
dependencies, and then create groups using dependency information.
Associate a Log Analytics workspace

To use dependency visualization, you associate a Log Analytics workspace with a
migration project. You can only create or attach a workspace in the same subscription
where the migration project is created.
1. To attach a Log Analytics workspace to a project, in Overview > Essentials, click

Requires configuration.
2. You can create a new workspace, or attach an existing one:
To create a new workspace, specify a name. The workspace is created in a

region in the same Azure geography as the migration project.
When you attach an existing workspace, you can pick from all the available
workspaces in the same subscription as the migration project. Only those
workspaces are listed which were created in a supported Service Map region.
To attach a workspace, ensure that you have 'Reader' access to the
workspace.
７ Note
You can't change the workspace associated with a migration project.
Download and install VM agents

After you configure a workspace, you download and install agents on each on-premises
machine that you want to evaluate. In addition, if you have machines with no internet
connectivity, you need to download and install Log Analytics gateway on them.
1. In Overview, click Manage > Machines, and select the required machine.
2. In the Dependencies column, click Install agents.
3. On the Dependencies page, download and install the Microsoft Monitoring Agent
(MMA), and the Dependency agent on each VM you want to assess.
4. Copy the workspace ID and key. You need these when you install the MMA on the
on-premises machine.
７ Note
To automate the installation of agents you can use a deployment tool such as
Configuration Manager or a partner tool such as Intigua, that provides an agent
deployment solution for Azure Migrate.
Install the MMA agent on a Windows machine

To install the agent on a Windows machine:
1. Double-click the downloaded agent.

2. On the Welcome page, click Next. On the License Terms page, click I Agree to
accept the license.
3. In Destination Folder, keep or modify the default installation folder > Next.
4. In Agent Setup Options, select Azure Log Analytics > Next.
5. Click Add to add a new Log Analytics workspace. Paste in the workspace ID and
key that you copied from the portal. Click Next.
You can install the agent from the command line or using an automated method such as
Configuration Manager. Learn more about using these methods to install the MMA
agent.
Install the MMA agent on a Linux machine

To install the agent on a Linux machine:
1. Transfer the appropriate bundle (x86 or x64) to your Linux computer using
scp/sftp.
2. Install the bundle by using the --install argument.
sudo sh ./omsagent-<version>.universal.x64.sh --install -w <workspace id> -s
<workspace key>
Learn more about the list of Linux operating systems support by MMA.
Install the MMA agent on a machine monitored by

Operations Manager
For machines monitored by System Center Operations Manager 2012 R2 or later, there
is no need to install the MMA agent. Service Map integrates with the Operations
Manager MMA to gather the necessary dependency data. Learn more. The Dependency
agent needs to be installed.
Install the Dependency agent

1. To install the Dependency agent on a Windows machine, double-click the setup file
and follow the wizard.
2. To install the Dependency agent on a Linux machine, install as root using the
following command:
sh InstallDependencyAgent-Linux64.bin
Learn more about the Dependency agent support for the Windows and Linux
operating systems.
Learn more about how you can use scripts to install the Dependency agent.
７ Note
The Azure Monitor for VMs article referenced to provide an overview of the system
prerequisites and methods to deploy the Dependency agent are also applicable to
the Service Map solution.
Create a group with dependency mapping

1. After you install the agents, go to the portal, and click Manage > Machines.
2. Search for the machine where you installed the agents.
3. The Dependencies column for the machine should now show as View
Dependencies. Click the column to view the dependencies of the machine.
4. The dependency map for the machine shows the following details:
Inbound (Clients) and outbound (Servers) TCP connections to/from the
machine
The dependent machines that do not have the MMA and dependency
agent installed are grouped by port numbers.
The dependent machines that have the MMA and the dependency agent
installed are shown as separate boxes.
Processes running inside the machine, you can expand each machine box to
view the processes
Machine properties, including the FQDN, operating System, MAC address are
shown. You can click on each machine box to view the details.
5. You can view dependencies for different time durations by clicking on the time
duration in the time range label. By default the range is an hour. You can modify
the time range, or specify start and end dates, and the duration.
７ Note
A time range of up to an hour is supported. Use Azure Monitor logs to query

dependency data over a longer duration.
6. After you've identified dependent machines that you want to group together, use
Ctrl+Click to select multiple machines on the map, and click Group machines.
7. Specify a group name. Verify that the dependent machines are discovered by
Azure Migrate.
７ Note
If a dependent machine is not discovered by Azure Migrate, you can't add it

to the group. To add such machines to the group, you need to run the
discovery process again with the right scope in vCenter Server and ensure that
the machine is discovered by Azure Migrate.
8. If you want to create an assessment for this group, select the checkbox to create a
new assessment for the group.
9. Click OK to save the group.
Once the group is created, it is recommended to install agents on all the machines of
the group and refine the group by visualizing the dependency of the entire group.
Query dependency data from Azure Monitor
logs
Dependency data captured by Service Map is available for querying in the Log Analytics
workspace associated with your Azure Migrate project. Learn more about the Service
Map data tables to query in Azure Monitor logs.
To run the Kusto queries:
1. After you install the agents, go to the portal and click Overview.
2. In Overview, go to Essentials section of the project and click on workspace name
provided next to OMS Workspace.
3. On the Log Analytics workspace page, click General > Logs.
4. Write your query to gather dependency data using Azure Monitor logs. Find
sample queries in the next section.
5. Run your query by clicking on Run.
Learn more about how to write Kusto queries.
Sample Azure Monitor logs queries

Following are sample queries you can use to extract dependency data. You can modify
the queries to extract your preferred data points. An exhaustive list of the fields in
dependency data records is available here. Find more sample queries here.
Summarize inbound connections on a set of machines

The records in the table for connection metrics, VMConnection, do not represent
individual physical network connections. Multiple physical network connections are
grouped into a logical connection. Learn more about how physical network connection
data is aggregated into a single logical record in VMConnection.
// the machines of interest

VMConnection
| summarize sum(LinksEstablished) by Computer, Direction, SourceIp,
DestinationIp, DestinationPort
Summarize volume of data sent and received on inbound

connections between a set of machines
// the machines of interest

VMConnection
| summarize sum(BytesSent), sum(BytesReceived) by Computer, Direction,
SourceIp, DestinationIp, DestinationPort
Next steps
Learn about the latest version of Azure Migrate.
 Documentation


Migrate



Show 5 more
 Training
Learning path
Certification
Onboard on-premises servers in VMware
virtual environment to Azure Arc
This article describes how to onboard on-premises VMware VMs to Azure Arc for Azure
Management using the Azure Migrate: Discovery and assessment tool.
Azure Arc allows you to manage your hybrid IT estate with a single pane of glass by extending the
Azure management experience to your on-premises servers that are not ideal candidates for
migration. Learn more about Azure Arc.
Before you get started

Review the requirements to discover servers running in VMware environment with Azure
Prepare VMware vCenter for usage and review the VMware requirements to perform software
inventory. Software inventory must be complete to start onboarding discovered servers to
Azure Arc.
Review application discovery requirements before initiating software inventory on servers.
Verify the prerequisites to allow remote connections to the inventory of discovered servers for
onboarding them to Azure Arc.
1. Allow inbound remote connections to the discovered servers

For Windows: Inbound connection on WinRM port 5985 (HTTP). On all the target
Windows servers, run “winrm qc” command to enable the WS-Management protocol
on the local computer.
For Linux: On all target Linux servers, allow inbound connections on port 22 (SSH).
You can also add the IP addresses of the remote machines (discovered servers) to the
WinRM TrustedHosts list on the appliance.
2. The Azure Migrate appliance should have a network line of sight to the target servers.
Be sure to verify the prerequisites for Azure Arc and review the following considerations:
Onboarding to Azure Arc can only be initiated after the vCenter Server discovery and
software inventory is completed. It may take up to 6 hours for software inventory to
complete after it is turned on.
The Azure Arc Hybrid Connected Machine agent will be installed on the discovered servers
during the Arc onboarding process. Make sure you provide credentials with administrator
permissions on the servers to install and configure the agent. On Linux, provide the root
account, and on Windows, provide an account that is a member of the Local Administrators
group.
Verify that the servers are running a supported operating system.
Ensure that the Azure account is granted assignment to the required Azure roles.
Make sure the required URLs are not blocked if the discovered servers connect through a
firewall or proxy server to communicate over the Internet.
Review the regions supported for Azure Arc.
Azure Arc-enabled servers support up to 5,000 machine instances in a resource group.
Set up the Azure Migrate project

1. Before you start, prepare the Azure user Account and verify you have the required roles in the
subscription to create resources required by Azure Migrate.
2. Use this article to set up a new Azure Migrate project with the Azure Migrate: Discovery and
７ Note
You can also use an existing Migrate project and onboard the discovered servers inventory
to Azure Arc. To do so, launch the appliance configuration manager from your appliance
server and make sure the services are updated to their latest versions. Learn more
Next, follow these instructions to onboard your servers.
Deploy and register the Azure Migrate appliance

Azure Migrate: Discovery and assessment use a lightweight Azure Migrate appliance. The appliance
performs server discovery and sends server configuration and performance metadata to Azure
Migrate.
Before you set up the appliance,
1. Review the requirements for deploying the Azure Migrate appliance.

2. Review the Azure URLs that the appliance will need to access in the public and government
clouds.
3. Note the port access requirements for the appliance.
Next,
Follow this article to set up the Azure Migrate appliance to start vCenter Server discovery. To
deploy the appliance, you can download and import an OVA template into VMware to create a
server running in your vCenter Server.
After deploying the appliance, you need to register it with the project before you initiate the
discovery. Follow these instructions to register the appliance.
Configure the appliance and start discovery

Use this article to configure the Azure Migrate appliance and kick off the vCenter Server discovery.
As you configure the appliance for discovery, you need to specify the details in the appliance
The details of the vCenter Server to which you want to connect.

vCenter Server credentials scoped to discover the servers in your VMware environment.
Server credentials with Administrator permissions. Onboarding to Azure Arc requires
credentials with Administrator permissions on the server to install and configure the Azure Arc
Hybrid Connect Machine agent. Learn more about how to provide credentials and how we
handle them.
After the discovery has been successfully completed, it takes around 15 minutes for discovered
servers to appear in the portal.
Onboard to Azure Arc
） Important
Software inventory must be completed before onboarding your discovered servers to Azure
Arc.
Once the vCenter Server discovery has been completed, software inventory (discovery of installed
applications) will be automatically initiated. During software inventory, the server credentials
provided will be iterated and validated against the discovered servers. You can start onboarding
after the software inventory has been completed and the credentials have been mapped. It may take
up to 6 hours for software inventory to complete after it is turned on.
1. Navigate to the Onboard to Azure Arc panel.

2. Provide the subscription and resource group where you want the servers to be managed
within Azure.
3. In the Region drop-down list, select the Azure region to store the servers' metadata.
4. Provide the Azure Active Directory service principal details for onboarding at scale. Review
this article to create a service principal using the Azure portal or Azure PowerShell.
The following inputs are required:
Directory (tenant) ID - The unique identifier (GUID) that represents your dedicated
instance of Azure AD.
Application (client) ID - The unique identifier (GUID) that represents the application ID of
the service principal.
Service principal secret (application secret) - The client secret for password-based
authentication.
5. Optional: Provide the proxy server IP address or the name and port number if your discovered
servers require a proxy server to connect to the Internet. Enter the value in the format
http://<proxyURL>:<proxyport> . This proxy server used by the discovered servers can be
different from the proxy server required by the appliance server to connect to the Internet
(provided in the prerequisites section in the appliance configuration manager).
７ Note
Setting proxy authentication us not supported.

6. Select Start Onboarding to initiate the Azure Arc onboarding process. The onboarding process
will take some time. Once the onboarding has been completed, you will be presented with the
completion status and a detailed onboarding status report.
７ Note
If your login expires, select Login again. This will open a modal with the device code.
Select Copy code & Login to copy the device code and open an Azure Login prompt in a
new browser tab. If it doesn't appear, make sure you've disabled the pop-up blocker in the
browser.
7. Once the onboarding has completed, navigate to the Azure Arc home page to view and
manage your onboarded servers.
8. View the detailed onboarding report to understand the onboarding status of your servers and
take appropriate actions.
７ Note
The Azure Migrate appliance will initiate WinRM sessions to execute the Azure Arc onboarding
script. Ensure that there are no settings restricting access to the WinRM service on the target
servers.
Next steps
For more information and error details, review the detailed onboarding report. Resolve errors, if
any, to successfully onboard the servers.
You can select Start Onboarding to rerun the Azure Arc onboarding process. The onboarding
will be attempted for any newly discovered servers and servers that could not be onboarded
successfully in the previous run.
Troubleshooting Azure Arc onboarding errors

If you receive an error when onboarding to Azure Arc using the Azure Migrate appliance, the
following section can help identify the probable cause and suggested steps to resolve your problem.
If you don't see the error code listed below or if the error code starts with AZCM, refer to this guide
for troubleshooting Azure Arc.
Error 60001 - UnableToConnectToPhysicalServer
Possible causes
Either the prerequisites to connect to the server have not been met or there are network issues in
connecting to the server, for instance some proxy settings.
Recommended actions
Ensure that the server meets the prerequisites and port access requirements.
Add the IP addresses of the remote machines (discovered servers) to the WinRM TrustedHosts
list on the Azure Migrate appliance, and retry the operation. This is to allow remote inbound
connections on servers - Windows: WinRM port 5985 (HTTP) and Linux: SSH port 22 (TCP).
Ensure that you have chosen the correct authentication method on the appliance to connect to
the server.
７ Note
Azure Migrate supports both password-based and SSH key based authentication for Linux
servers.
If the issue persists, submit a Microsoft support case, providing the appliance machine ID
(available in the footer of the appliance configuration manager).
Error 60002 - InvalidServerCredentials

Possible causes
Unable to connect to server. Either you have provided incorrect credentials on the appliance or the
credentials previously provided have expired.
Recommended actions
Ensure that you have provided the correct credentials for the server on the appliance. You can
check that by trying to connect to the server using those credentials.
If the credentials added are incorrect or have expired, edit the credentials on the appliance and
revalidate the added servers. If the validation succeeds, the issue is resolved.
If the issue persists, submit a Microsoft support case, providing the appliance machine ID
Error 60005 - SSHOperationTimeout

Possible causes
The operation took longer than expected either due to network latency issues or due to the
lack of latest updates on the server.
Recommended actions
Ensure that the impacted server has the latest kernel and OS updates installed.
Ensure that there is no network latency between the appliance and the server. It is
recommended to have the appliance and source server on the same domain to avoid latency
issues.
Connect to the impacted server from the appliance and run the commands documented here
to check if they return null or empty data.
If the issue persists, submit a Microsoft support case providing the appliance machine ID
Error 60108 - SoftwareInventoryCredentialNotAssociated

Possible causes
No credentials were found to be associated with the server.
Recommended actions
Software inventory must be complete to start onboarding discovered servers to Azure Arc.
Learn more
Ensure that the credentials provided on the appliance configuration manager are valid and the
server is accessible using the credentials.
Go back to the appliance configuration manager to either provide another set of credentials or
edit an existing one.
Error 60109 - ArcOsNotSupported

Possible causes
The server hosts an unsupported operating system for Azure Arc onboarding.
Recommended actions
Review the supported operating systems for Azure Arc.
Error 10002 - ScriptExecutionTimedOutOnVm

Possible causes
The onboarding task did not complete in time. Then execution took longer than expected.
Recommended actions
The issue should automatically resolve in some time. If the issue persists, contact Microsoft
Support.
Error 50000 - AccessDenied

Possible causes
The operation could not be completed due to forbidden access on the server. The user account
provided on the appliance to access the server does not have the required permissions or the
credentials are incorrect. WinRM error code: 0x80070005
Recommended actions
Validate the possible causes and retry the operation. If the issue persists, contact support.
Error 960/951/60009/60078 -
NullResult/UnhandledException/ServerUnknownError/UnhandledError
Possible causes
The operation failed due to an internal error.
Recommended actions
Retry the operation after some time. If the issue persists, contact support and provide the
appliance machine ID (available in the footer of the appliance configuration manager).
Manage Azure Migrate projects at scale
with Azure Lighthouse
This topic provides an overview of how Azure Lighthouse can help you use Azure
Migrate in a scalable way across multiple Azure Active Directory (Azure AD) tenants.
Azure Lighthouse allows service providers to perform operations at scale across several
tenants at once, making management tasks more efficient.
Azure Migrate provides a centralized hub to assess and migrate to Azure on-premises
servers, infrastructure, applications, and data.
Azure Lighthouse integration with Azure Migrate lets service providers discover, assess,
and migrate workloads for different customers at scale, rather than accessing each
customer subscription individually. Service providers can have a single view of all of the
Azure Migrate projects they manage across multiple customer tenants. Their customers
will have full visibility into service provider access, and they maintain control of their
own environments.
 Tip
Though we refer to service providers and customers in this topic, this guidance also
applies to enterprises using Azure Lighthouse to manage multiple tenants.
Depending on your scenario, you may wish to create the Azure Migrate in the customer
tenant or in your managing tenant. Review the considerations below and determine
which model best fits your customer's migration needs.
７ Note
Via Azure Lighthouse, partners can perform discovery, assessment and migration
for on-premises VMware VMs, Hyper-V VMs, physical servers and AWS/GCP
instances. There are two options for VMware VM migration. Currently, only the
agent-based method of migration can be used when working on a migration
project in a delegated customer subscription; migration using agentless replication
is not currently supported through delegated access to the customer's scope.
Create an Azure Migrate project in the
customer tenant
One option when using Azure Lighthouse is to create the Azure Migrate project in the
customer tenant. Users in the managing tenant can then select the customer
subscription when creating a migration project. From the managing tenant, the service
provider can perform the necessary migration operations. This may include deploying
the Azure Migrate appliance to discover the workloads, assessing workloads by
grouping VMs and calculating cloud-related costs, reviewing VM readiness, and
performing the migration.
In this scenario, no resources will be created and stored in the managing tenant, even
though the discovery and assessment steps can be initiated and executed from that
tenant. All of the resources, such as migration projects, assessment reports for on-
premises workloads, and migrated resources at the target destination, will be deployed
in the customer subscription. However, the service provider can access all customer
projects from their own tenant and portal experience.
This approach minimizes context switching for service providers working across multiple
customers, while letting customers keep all of their resources in their own tenants.
The workflow for this model will be similar to the following:
1. The customer is onboarded to Azure Lighthouse. The Contributor built-in role is

required for the identity that will be used with Azure Migrate. See the delegated-
resource-management-azmigrate sample template for an example using this
role.
2. The designated user signs into the managing tenant in the Azure portal, then goes
to Azure Migrate. This user creates an Azure Migrate project, selecting the
appropriate delegated customer subscription.
3. The user then performs steps for discovery and assessment.
For VMware VMs, before you configure the appliance, you can limit discovery to
vCenter Server datacenters, clusters, a folder of clusters, hosts, a folder of hosts, or
individual VMs. To set the scope, assign permissions on the account that the
appliance uses to access the vCenter Server. This is useful if multiple customers'
VMs are hosted on the hypervisor. You can't limit the discovery scope of Hyper-V.
７ Note
You can discover and assess VMware virtual machines for migration using
Azure Migrate through the delegated access provided by Azure Lighthouse.
For migration of VMware virtual machines, only the agent-based method is
currently supported when working on a migration project in a delegated
customer subscription.
4. When the target customer subscription is ready, proceed with the migration
through the access granted by Azure Lighthouse. The migration project containing
assessment results and migrated resources will be created in the customer tenant
under the target subscription.
 Tip
Prior to migration, a landing zone must be deployed to provision the foundation

infrastructure resources and prepare the subscription to which virtual machines will
be migrated. To access or create some resources in this landing zone, the Owner
built-in role may be required, which is not currently supported in Azure Lighthouse.
With these scenarios, the customer may need to provide guest access or delegate
admin access via the Cloud Solution Provider (CSP) subscription model. For an
approach to creating multi-tenant landing zones, see the Multi-tenant-Landing-
Zones demo solution on GitHub.
Create an Azure Migrate project in the

managing tenant
In this scenario, migration-related operations such as discovery and assessment are still
performed by users in the managing tenant. However, the migration project and all of
the relevant resources will reside in the partner tenant, and the customer will not have
direct visibility into the project (though assessments can be shared with customers if
desired). The migration destination for each customer will be the customer's
subscription.
This approach enables services providers to start migration discovery and assessment
projects quickly, abstracting those initial steps from customer subscriptions and tenants.
The workflow for this model will be similar to the following:
1. The customer is onboarded to Azure Lighthouse. The Contributor built-in role is

required for the identity that will be used with Azure Migrate. See the delegated-
resource-management-azmigrate sample template for an example using this
role. Be sure to modify the parameter file to reflect your environment before
deploying the template.
2. The designated user signs into the managing tenant in the Azure portal, then goes
to Azure Migrate. This user creates an Azure Migrate project in a subscription
belonging to the managing tenant.
3. The user then performs steps for discovery and assessment. The on-premises VMs
will be discovered and assessed within the migration project created in the
managing tenant, then migrated from there.
If you are managing multiple customers in the same Hyper-V host, you can
discover all workloads at once. Customer-specific VMs can be selected in the same
group, then an assessment can be created, and migration can be performed by
selecting the appropriate customer's subscription as the target destination. There
is no need to limit the discovery scope, and you can maintain a full overview of all
customer workloads in one migration project.
4. When ready, proceed with the migration by selecting the delegated customer
subscription as the target destination for replicating and migrating the workloads.
The newly created resources will exist in the customer subscription, while the
assessment data and resources pertaining to the migration project will remain in
the managing tenant.
Partner recognition for customer migrations

As a member of the Microsoft Cloud Partner Program , you can link your partner ID
with the credentials used to manage delegated customer resources. This allows
Microsoft to attribute influence and Azure consumed revenue to your organization
based on the tasks you perform for customers, including migration projects.
For more information, see Link your partner ID to track your impact on delegated
resources.
Next steps
Learn more about Azure Migrate.
Learn about other cross-tenant management experiences supported by Azure
Lighthouse.
 Documentation
Review a business case with Azure Migrate - Azure Migrate

Describes how to review a business case with Azure Migrate



Migrate

Assess VMware servers for migration to Azure VMware Solution (AVS) with Azure
Migrate - Azure Migrate
Learn how to assess servers in VMware environment for migration to AVS with Azure Migrate.
Scale a migration to Azure - Cloud Adoption Framework

Use the Cloud Adoption Framework for Azure to learn how to plan for and perform a migration at
scale to Azure.
Show 5 more
 Training
Learning path
Troubleshoot Azure Migrate
Azure Migrate provides a hub of tools for assessment and migration, as well as third-
party independent software vendor (ISV) offerings. This article helps you troubleshoot
issues with Azure Migrate, Azure Migrate Server Assessment, and Migration and
modernization.
How do I create or find a project?

Review the Azure Migrate project troubleshooting guide.
I can't get the appliance working

Review answers to common issues with appliance deployment.
Machines aren't discovered

Review common discovery issues.
App-discovery isn't working

Discovery of apps, roles, and features running on on-premises machines is currently only
supported for VMware VMs. Review common errors for app-discovery.
Assessment isn't working

Review common assessment issues and errors.
 Documentation





Set up an Azure Migrate appliance with a script - Azure Migrate

Learn how to set up an Azure Migrate appliance with a script

Show 5 more
Troubleshoot Azure Migrate projects
This article helps you troubleshoot issues when creating and managing Azure Migrate
projects.
How to add new project?

You can have multiple Azure Migrate projects in a subscription. Learn how to create a
project for the first time, or add additional projects.
What Azure permissions are needed?

You need Contributor or Owner permissions in the subscription to create an Azure
Migrate project.
Can't find a project

Finding an existing Azure Migrate project depends upon whether you're using the
current or old version of Azure Migrate. Follow.
Can't find a geography

You can create an Azure Migrate project in supported geographies for public and
government clouds.
What are VM limits?

You can assess up to 35,000 VMware VMs or up to 35,000 Hyper-V VMs in a single
project. A project can include both VMware VMs and Hyper-V VMs, up to the
assessment limits.
Can I upgrade old project?

Projects from the previous version of Azure Migrate can't be updated. You need to
create a new project, and add tools to it.
Can't create a project
If you try to create a project and encounter a deployment error:
Try to create the project again in case it's a transient error. In Deployments, click
on Re-deploy to try again.
Check you have Contributor or Owner permissions in the subscription.
If you're deploying in a newly added geography, wait a short time and try again.
If you receive the error, "Requests must contain user identity headers", this might
indicate that you don't have access to the Azure Active Directory (Azure AD) tenant
of the organization. In this case:
When you're added to an Azure AD tenant for the first time, you receive an
email invitation to join the tenant.
Accept the invitation to be added to the tenant.
If you can't see the email, contact a user with access to the tenant, and ask them
to resend the invitation to you.
After receiving the invitation email, open it and select the link to accept the
invitation. Then, sign out of the Azure portal and sign in again. (refreshing the
browser won't work.) You can then start creating the migration project.
How do I delete a project

Follow these instructions to delete a project. Note that when you delete a project, both
the project and the metadata about discovered machines in the project are deleted.
Added tools don't show

Make sure you have the right project selected. In the Azure Migrate hub > Servers or in
Databases, click on Change next to Migrate project (Change) in the top-right corner of
the screen. Choose the correct subscription and project name > OK. The page should
refresh with the added tools of the selected project.
Next steps
Add assessment or migration tools to Azure Migrate projects.
Troubleshoot the Azure Migrate
appliance
This article helps you troubleshoot issues when you deploy the Azure Migrate appliance
and use the appliance to discover on-premises servers.
What's supported?
Review the appliance support requirements.
"Invalid OVF manifest entry" error occurs

during appliance setup
You get the error "The provided manifest file is invalid: Invalid OVF manifest entry" when
you set up an appliance by using the OVA template.
Remediation
1. Verify that the Azure Migrate appliance OVA file is downloaded correctly by
checking its hash value. Learn more. If the hash value doesn't match, download the
OVA file again and retry the deployment.
2. If deployment still fails and you're using the VMware vSphere client to deploy the
OVF file, try deploying it through the vSphere web client. If deployment still fails,
try using a different web browser.
3. If you're using the vSphere web client and trying to deploy it on vCenter Server 6.5
or 6.7, try to deploy the OVA directly on the ESXi host:
Connect to the ESXi host directly (instead of vCenter Server) with the web
client (https://<host IP Address>/ui).
In Home > Inventory, select File > Deploy OVF template. Browse to the OVA
and complete the deployment.
4. If the deployment still fails, contact Azure Migrate support.
Connectivity check fails during the

prerequisites setup
You get an error in the connectivity check on the appliance.
Remediation
1. Ensure that you can connect to the required URLs from the appliance.
2. Check if there's a proxy or firewall blocking access to these URLs. If you're required
to create an allowlist, make sure that you include all of the URLs.
3. If there's a proxy server configured on-premises, enter the proxy details correctly
by selecting Setup proxy in the same step. Enter the authorization credentials if
the proxy needs them.
4. Ensure that the server hasn't been previously used to set up the replication
appliance or that you have the mobility service agent installed on the server.
Connectivity check fails for the aka.ms URL

during the prerequisites setup
You get an error in the connectivity check on the appliance for the aka.ms URL.
Remediation
1. Ensure that you have connectivity to the internet and have added the URL-
aka.ms/* to the allowlist to download the latest versions of the services.
2. Check if there's a proxy or firewall blocking access to this URL. Ensure that you've
provided the proxy details correctly in the prerequisites step of the configuration
manager.
3. Go back to the appliance configuration manager and rerun prerequisites to initiate
auto-update.
4. If retry doesn't help, download the latestcomponents.json file from this website to
check the latest versions of the services that are failing. Manually update them
from the download links in the file.
If you've enabled the appliance for private endpoint connectivity and don't want to
allow access to this URL over the internet, disable auto-update because the aka.ms link
is required for this service.
７ Note
If you disable the auto-update service, the services running on the appliance won't
get the latest updates automatically. To get around this situation, update the
appliance services manually.
Auto-update check fails during the
prerequisites setup
You get an error in the auto-update check on the appliance.
Remediation
1. Make sure that you created an allowlist for the required URLs and that no proxy or
firewall setting is blocking them.
2. If the update of any appliance component is failing, either rerun the prerequisites
or manually update the appliance services.
Time sync check fails during the prerequisites

setup
An error about time synchronization indicates that the server clock might be out of
synchronization with the current time by more than five minutes.
Remediation
Ensure that the appliance server time is synchronized with the internet time by
checking the date and time settings from Control Panel.
You can also change the clock time on the appliance server to match the current
time by following these steps:
1. Open an admin command prompt on the server.

2. To check the time zone, run w32tm /tz.
3. To synchronize the time, run w32tm /resync.
VDDK check fails during the prerequisites setup

on the VMware appliance
The Virtual Disk Development Kit (VDDK) check failed because the appliance couldn't
find the required VDDK installed on the appliance. This issue can result in failures with
ongoing replication.
Remediation
1. Ensure that you've downloaded VDDK 6.7 and have copied its files to- C:\Program
Files\VMware\VMware Virtual Disk Development Kit on the appliance server.
2. Ensure that no other software or application is using another version of the VDDK
on the appliance.
Project key-related error occurs during

appliance registration
You're having issues when you try to register the appliance by using the Azure Migrate
project key copied from the project.
Remediation
1. Ensure that you've copied the correct key from the project. On the Azure Migrate:
Discovery and Assessment card in your project, select Discover. Then select
Manage Existing appliance in step 1. Select the appliance name for which you
previously generated a key from the dropdown menu. Copy the corresponding
key.
2. Ensure that you're pasting the key to the appliance of the right cloud type
(Public/US Gov) and appliance type (VMware/Hyper-V/Physical or other). Check at
the top of the appliance configuration manager to confirm the cloud and scenario
type.
"Failed to connect to the Azure Migrate

project" error occurs during appliance
registration
After a successful sign-in with an Azure user account, the appliance registration step
fails with the message, "Failed to connect to the Azure Migrate project. Check the error
detail and follow the remediation steps by clicking Retry."
This issue happens when the Azure user account that was used to sign in from the
appliance configuration manager is different from the user account that was used to
generate the Azure Migrate project key on the portal.
Remediation
You have two options:
To complete the registration of the appliance, use the same Azure user account
that generated the Azure Migrate project key on the portal.
You can also assign the required roles and permissions to the other Azure user
account being used for appliance registration.
"Azure Active Directory (AAD) operation failed

with status Forbidden" error occurs during
appliance registration
You're unable to complete registration because of insufficient Azure Active Directory
privileges and get the error "Azure Active Directory (AAD) operation failed with status
Forbidden."
Remediation
Ensure that you have the required permissions to create and manage Azure Active
Directory applications in Azure. You should have the Application Developer role or the
user role with User can register applications allowed at the tenant level.
"Forbidden to access Key Vault" error occurs

during appliance registration
The Azure Key Vault create or update operation failed for "{KeyVaultName}" because of
the error "{KeyVaultErrorMessage}."
This issue usually happens when the Azure user account used to register the appliance is
different from the account used to generate the Azure Migrate project key on the portal
(that is, when the key vault was created).
Remediation
1. Ensure that the currently signed-in user account on the appliance has the required
permissions on the key vault mentioned in the error message. The user account
needs permissions as mentioned at this website.
2. Go to the key vault and ensure that your user account has an access policy with all
the Key, Secret, and Certificate permissions assigned under Key Vault Access
Policy. Learn more.
3. If you enabled the appliance for private endpoint connectivity, ensure that the
appliance is either hosted in the same virtual network where the key vault was
created or it's connected to the Azure virtual network where the key vault was
created over a private link. Make sure that the key vault private link is resolvable
from the appliance. Go to Azure Migrate: Discovery and assessment > Properties
to find the details of private endpoints for resources like the key vault created
during the Azure Migrate key creation. Learn more.
4. If you have the required permissions and connectivity, retry the registration on the
appliance after some time.
Unable to connect to vCenter Server during

validation
If you get this connection error, you might be unable to connect to vCenter Server
Servername.com:9443. The error details indicate there's no endpoint listening at
https://\*servername*.com:9443/sdk that can accept the message.
Remediation
Check whether you're running the latest version of the appliance. If you're not,
upgrade the appliance to the latest version.
If the issue still occurs in the latest version, the appliance might be unable to
resolve the specified vCenter Server name, or the specified port might be wrong.
By default, if the port isn't specified, the collector tries to connect to port number
443.
1. Ping Servername.com from the appliance.

2. If step 1 fails, try to connect to the vCenter server by using the IP address.
3. Identify the correct port number to connect to the vCenter server.
4. Verify that the vCenter server is up and running.
Server credentials (domain) fails validation on

the VMware appliance
You get "Validation failed" for domain credentials added on the VMware appliance to
perform software inventory and agentless dependency analysis.
Remediation
1. Check that you've provided the correct domain name and credentials.
2. Ensure that the domain is reachable from the appliance to validate the credentials.
The appliance might be having line-of-sight issues, or the domain name might not
be resolvable from the appliance server.
3. Select Edit to update the domain name or credentials. Select Revalidate
credentials to validate the credentials again after some time.
"Access is denied" error occurs when you

connect to Hyper-V hosts or clusters during
validation
You're unable to validate the added Hyper-V host or cluster because of the error "Access
is denied."
Remediation
1. Ensure that you've met all the prerequisites for the Hyper-V hosts.
2. Check the steps on this website on how to prepare the Hyper-V hosts manually or
by using a provisioning PowerShell script.
"The server does not support WS-Management

Identify operations" error occurs during
validation
You're unable to validate Hyper-V clusters on the appliance because of the error "The
server does not support WS-Management Identify operations. Skip the TestConnection
part of the request and try again."
Remediation
This error usually occurs when you've provided a proxy configuration on the appliance.
The appliance connects to the clusters by using the short name for the cluster nodes,
even if you've provided the FQDN of the node. Add the short name for the cluster
nodes to the bypass proxy list on the appliance, the issue gets resolved, and validation
of the Hyper-V cluster succeeds.
"Can't connect to host or cluster" error occurs

during validation on a Hyper-V appliance
The error "Can't connect to a host or cluster because the server name can't be resolved.
WinRM error code: 0x803381B9" might occur if the Azure DNS service for the appliance
can't resolve the cluster or host name you provided.
This issue usually happens when you've added the IP address of a host that can't be
resolved by DNS. You might also see this error for hosts in a cluster. It indicates that the
appliance can connect to the cluster, but the cluster returns host names that aren't
FQDNs.
Remediation
To resolve this error, update the hosts file on the appliance by adding a mapping of the
IP address and host names.
1. Open Notepad as an admin.

2. Open the C:\Windows\System32\Drivers\etc\hosts file.
3. Add the IP address and host name in a row. Repeat for each host or cluster where
you see this error.
4. Save and close the hosts file.
5. Check whether the appliance can connect to the hosts by using the appliance
management app. After 30 minutes, you should see the latest information for
these hosts in the Azure portal.
"Unable to connect to server" error occurs

during validation of physical servers
Remediation
Ensure there's connectivity from the appliance to the target server.
If it's a Linux server, ensure password-based authentication is enabled by following
these steps:
1. Sign in to the Linux server, and open the ssh configuration file by using the
command vi /etc/ssh/sshd_config.
2. Set the PasswordAuthentication option to yes. Save the file.
3. Restart the ssh service by running service sshd restart.
If it's a Windows server, ensure the port 5985 is open to allow for remote WMI
calls.
If you're discovering a GCP Linux server and using a root user, use the following
commands to change the default setting for the root login:
1. Sign in to the Linux server, and open the ssh configuration file by using the
command vi /etc/ssh/sshd_config.
2. Set the PermitRootLogin option to yes.
"Failed to fetch BIOS GUID" error occurs for the

server during validation
The validation of a physical server fails on the appliance with the error message "Failed
to fetch BIOS GUID."
Remediation
Linux servers:
Connect to the target server that's failing validation. Run the following commands to see
if it returns the BIOS GUID of the server:
cat /sys/class/dmi/id/product_uuid
dmidecode | grep -i uuid | awk '{print $2}'
You can also run the commands from the command prompt on the appliance server by
making an SSH connection with the target Linux server by using the following
command:
ssh <username>@<servername>
Windows servers:
Run the following code in PowerShell from the appliance server for the target server
that's failing validation to see if it returns the BIOS GUID of the server:
[CmdletBinding()]
Param(
[Parameter(Mandatory=$True,Position=1)]
[string]$Hostname
)
$HostNS = "root\cimv2"
$error.Clear()
$Cred = Get-Credential
$Session = New-CimSession -Credential $Cred -ComputerName $Hostname
if ($Session -eq $null -or $Session.TestConnection() -eq $false)

{
Write-Host "Connection failed with $Hostname due to $error"
exit -1
}
Write-Host "Connection established with $Hostname"

#Get-WmiObject -Query "select uuid from Win32_ComputerSystemProduct"
$HostIntance = $Session.QueryInstances($HostNS, "WQL", "Select UUID from

Win32_ComputerSystemProduct")
$HostIntance | fl *
When you run the preceding code, you need to provide the hostname of the target
server. It can be IP address/FQDN/hostname. After that, you're prompted to provide the
credentials to connect to the server.
"No suitable authentication method found"

error occurs for the server during validation
You get the error "No suitable authentication method found" when you try to validate a
Linux server through the physical appliance.
Remediation
Ensure password-based authentication is enabled on the Linux server by following these
steps:
1. Sign in to the Linux server. Open the ssh configuration file by using the command
vi /etc/ssh/sshd_config.
2. Set the PasswordAuthentication option to yes. Save the file.
"Access is denied" error occurs when you

connect to physical servers during validation
You get the error "WS-Management service cannot process the request. The WMI
service returned an access denied error" when you try to validate a Windows server
through the physical appliance.
Remediation
If you get this error, make sure that the user account provided (domain/local) on
the appliance configuration manager was added to these groups: Remote
Management Users, Performance Monitor Users, and Performance Log Users.
If the Remote Management Users group isn't present, add the user account to the
group WinRMRemoteWMIUsers_.
You can also check if the WS-Management protocol is enabled on the server by
running the following command in the command prompt of the target server:
winrm qc
If you're still facing the issue, make sure that the user account has access
permissions to CIMV2 Namespace and sub-namespaces in the WMI Control Panel.
You can set the access by following these steps:
1. Go to the server that's failing validation on the appliance.

2. Search and select Run from the Start menu. In the Run dialog, enter
wmimgmt.msc in the Open text box and select Enter.
3. The wmimgmt console opens where you can find WMI Control (Local) in the
left pane. Right-click it, and select Properties from the menu.
4. In the WMI Control (Local) Properties dialog, select the Securities tab.
5. On the Securities tab, expand the Root folder in the namespace tree and
select the cimv2 namespace.
6. Select Security to open the Security for ROOT\cimv2 dialog.
7. Under the Group or users names section, select Add to open the Select
Users, Computers, Service Accounts or Groups dialog.
8. Search for the user account, select it, and select OK to return to the Security
for ROOT\cimv2 dialog.
9. In the Group or users names section, select the user account just added.
Check if the following permissions are allowed:
Enable account
Remote enable
10. Select Apply to enable the permissions set on the user account.
The same steps are also applicable on a local user account for non-
domain/workgroup servers. In some cases, UAC filtering might block some WMI
properties as the commands run as a standard user, so you can either use a local
administrator account or disable UAC so that the local user account isn't filtered
and instead becomes a full administrator.
Disabling Remote UAC by changing the registry entry that controls Remote UAC
isn't recommended but might be necessary in a workgroup. The registry entry is
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\s
ystem\LocalAccountTokenFilterPolicy. When the value of this entry is zero (0),
Remote UAC access token filtering is enabled. When the value is 1, remote UAC is
disabled.
Appliance is disconnected
You get an "Appliance is disconnected" error message when you try to enable
replication on a few VMware servers from the portal.
This error can occur if the appliance is in a shut-down state or the DRA service on the
appliance can't communicate with Azure.
Remediation
1. Go to the appliance configuration manager, and rerun prerequisites to see the
status of the DRA service under View appliance services.
2. If the service isn't running, stop and restart the service from the command prompt
by using the following commands:
net stop dra

net start dra
Next steps
Set up an appliance for VMware, Hyper-V, or physical servers.
Diagnose and solve issues with Azure
Migrate appliance
The Diagnose and solve capability on Azure Migrate appliance helps users identify and
self-assess any issues with the appliance configuration that might be blocking the
initiation of discovery or issues with an ongoing Migrate operation like discovery,
assessment and/or replication (in case of VMware appliance) from the appliance.
You can run Diagnose and solve at any time from the appliance configuration manager
to generate a diagnostics report. The report provides information about the checks
performed, their status, the issues identified and recommendation steps to solve the
issues.
） Important
Diagnose and solve capability is currently in preview for Azure Migrate appliance.
This preview is covered by customer support and can be used for production
workloads. For more information, see Supplemental Terms of Use for Microsoft
Azure Previews .
Diagnostic checks
Diagnose and solve runs some pre-validations to see if the required configuration files
are not missing or blocked by an anti-virus software on the appliance and then performs
the following checks:
Category Diagnostics Description

check
Prerequisite Connectivity Checks if the appliance has connectivity to Azure either directly or
checks checks via proxy.
Time sync Checks if the appliance server time is in sync with network time.
check
Auto update Checks if auto-update is enabled and if all agents running on the
check appliance are up to date.
VDDK check Checks if the required VDDK files have been downloaded and
copied at the required location on the appliance server.
Category Diagnostics Description
check
Service Operational Checks if the agents on the appliance are in running state.
health status If not, appliance will auto-resolve by restarting the agents.
checks
Service Checks if the agents can communicate to their respective services

endpoint on Azure either directly or via proxy.
connectivity
Azure- AAD App Checks if the AAD App created during the appliance registration
specific availability* is available and is accessible from the appliance.
checks
Migrate Checks if the Migrate project to which the appliance has been
project registered still exists and is accessible from the appliance.
availability*
Essential Checks if the Migrate resources created during appliance

resources registration still exist and are accessible from the appliance.
availability*
Appliance- Key Vault Checks if the certificate downloaded from Key Vault during
specific certificate appliance registration is still available on the appliance server.
checks availability* If not, appliance will auto-resolve by downloading the certificate
again, provided the Key Vault is available and accessible.
Credential Checks if the Credential store resources on the appliance server

store have not been moved/deleted/edited.
availability
Replication Checks if the same server has also been used to install any
appliance/ASR ASR/replication appliance components. It is currently not
components supported to install both Azure Migrate and replication appliance
(for agent-based migration) on the same server.
OS license Checks if the evaluation license on the appliance server created

availability from OVA/VHD is still valid. The Windows Server 2016 evaluation
license is valid for 180 days.
CPU & Checks the CPU and memory utilized by the Migrate agents on
memory the appliance server.
utilization
*checked and reported only if the appliance has already been registered. These checks are
run in the context of the current Azure user logged in the appliance.
Running diagnostic checks

If you are getting any issues with the appliance during its configuration or seeing issues
with the ongoing Migrate operations like discovery, assessment and/or replication (in
case of VMware appliance) on the portal, you can go to the appliance configuration
manager and run diagnostics.
７ Note
Currently Diagnose and solve can perform checks related to appliance connectivity
to Azure, availability of required resources on appliance server and/or Azure. The
connectivity or discovery issues with the source environment like vCenter
Server/ESXi hosts/Hyper-V hosts/VMs/physical servers are currently not covered
under Diagnose and solve.
1. Select Diagnose and solve from the ribbon at the top of the configuration
manager.
After selecting Diagnose and solve, the appliance automatically starts running the
diagnostic checks. This may take around 5 minutes to complete. You would see the
timestamp of the last diagnostics report, if you ran the checks before.
2. Once diagnostic checks have completed, you can either view the report in another
tab where you can choose it save it in a PDF format or you can go to this location-
C:\Users\Public\Desktop\DiagnosticsReport on the appliance server where the
report gets auto-saved in an HTML format.
3. The report provides information about the checks performed, their status, the
issues identified, and recommendation steps to solve the issues.
4. You can follow the remediation steps on the report to solve an issue. If you are
unable to resolve the issue, it is recommended that you attach the diagnostics
report while creating a Microsoft support case so that it helps expedite the
resolution.
Next steps
If you are getting issues not covered under Diagnose and solve, you can go to
troubleshoot the Azure Migrate appliance to find the remediation steps.
Troubleshoot ongoing server discovery,
software inventory, and SQL and web
apps discovery
Article • 04/20/2023
This article helps you troubleshoot issues with ongoing server discovery, software
inventory, and discovery of SQL Server instances and databases.
Discovered servers not showing in the portal

You get this error when you don't yet see the servers in the portal, and the discovery
state is Discovery in progress.
Remediation
If the servers don't appear in the portal, wait for a few minutes because it takes around
15 minutes for discovery of servers running on a vCenter server. It takes 2 minutes for
each Hyper-V host added on the appliance for discovery of servers running on the host
and 1 minute for discovery of each server added on the physical appliance.
If the state still doesn't change:
Select Refresh on the Servers tab to see the count of the discovered servers in
Azure Migrate: Discovery and assessment and Migration and modernization.
If the preceding step doesn't work and you're discovering VMware servers:
1. Verify that the vCenter account you specified has the permissions set correctly with
access to at least one server.
2. Check on VMware if the vCenter account has access granted at the vCenter VM
folder level. Azure Migrate can't discover servers on VMware. Learn more about
scoping discovery.
Server data not updating in the portal

You get this error if the discovered servers don't appear in the portal or if the server data
is outdated.
Remediation
Wait for a few minutes because it takes up to 30 minutes for changes in discovered
server configuration data to appear in the portal and a few hours for changes in
software inventory data to appear. If there's no data after this time, refresh and follow
these steps:
1. In Windows, Linux, and SQL Servers > Azure Migrate: Discovery and assessment,
select Overview.
2. Under Manage, select Appliances.
3. Select Refresh services. Wait for the refresh operation to finish. You should now
see up-to-date information.
Deleted servers appear in the portal

You get this error when the deleted servers continue to appear in the portal.
Remediation
If the data continues to appear, wait for 30 minutes and follow these steps:
select Overview.
You imported a CSV but see "Discovery is in

progress"
This status appears if your CSV upload failed because of a validation failure.
Remediation
Import the CSV again. Download the previous upload error report, and follow the file's
remediation guidance to fix the errors. Download the error report from the Import
Details section on the Discover servers page.
You don't see software inventory details after
you update guest credentials
You get this error when inventory details don't appear even after you update guest
credentials.
Remediation
The software inventory discovery runs once every 24 hours. This process might take a
few minutes depending on the number of servers discovered. If you want to see the
details immediately, refresh as follows:
select Overview.
Unable to export software inventory data

You get this error when you don't have Contributor privileges.
Remediation
Ensure the user downloading the inventory from the portal has Contributor privileges on
the subscription.
Export the software inventory errors

You can export all the errors and remediations for software inventory from portal by
selecting Export notifications. The exported CSV file also contains additional
information like the timestamp at which the error was encountered.
Common software inventory errors
Azure Migrate supports software inventory by using Azure Migrate: Discovery and
assessment. Learn more about how software inventory is performed.
For VMware VMs, software inventory is performed by connecting to the servers via the
vCenter Server using the VMware APIs. For Hyper-V VMs and physical servers, software
inventory is performed by directly connecting to Windows servers using PowerShell
remoting on port 5985 (HTTP) and to Linux servers using SSH connectivity on port 22
(TCP).
The table below summarizes all errors encountered when gathering software inventory
data through VMware APIs or by directly connecting to servers:
７ Note
The same errors can also be encountered with agentless dependency analysis
because it follows the same methodology as software inventory to collect the
required data.
Error Cause Action

Error Cause Action
60001:UnableToConnectToPhysicalServer Either the prerequisites to - Ensure that the

connect to the server have not server meets the
been met or there are network prerequisites and
issues in connecting to the port access
server, for instance some proxy requirements.
settings. - Add the IP
addresses of the
remote machines
(discovered servers)
to the WinRM
TrustedHosts list on
the Azure Migrate
appliance, and retry
the operation. This is
to allow remote
inbound connections
on servers -
Windows: WinRM
port 5985 (HTTP)
and Linux: SSH port
22 (TCP).
- Ensure that you
have chosen the
correct
authentication
method on the
appliance to connect
to the server.
- If the issue persists,
submit a Microsoft
support case,
providing the
appliance machine
ID (available in the
footer of the
appliance
configuration
manager).
Error Cause Action
60002:InvalidServerCredentials Unable to connect to server. - Ensure that you

Either you have provided have provided the
incorrect credentials on the correct credentials
appliance or the credentials for the server on the
previously provided have appliance. You can
expired. check that by trying
to connect to the
server using those
credentials.
- If the credentials
added are incorrect
or have expired, edit
the credentials on
the appliance and
revalidate the added
servers. If the
validation succeeds,
the issue is resolved.
submit a Microsoft
support case,
providing the
appliance machine
footer of the
appliance
configuration
manager).
Error Cause Action
60005:SSHOperationTimeout The operation took longer - Ensure that the

than expected either due to impacted server has
network latency issues or due the latest kernel and
to the lack of latest updates on OS updates installed.
the server. - Ensure that there is
no network latency
between the
appliance and the
server. It is
recommended to
have the appliance
and source server on
the same domain to
avoid latency issues.
- Connect to the
impacted server
from the appliance
and run the
commands
documented here to
check if they return
null or empty data.
submit a Microsoft
support case
providing the
appliance machine
footer of the
appliance
configuration
manager).
9000: VMware tools status on the server VMware tools might not be Ensure that VMware
can't be detected. installed on the server, or the tools later than
installed version is corrupted. version 10.2.1 are
installed and running
on the server.
9001: VMware tools aren't installed on VMware tools might not be Ensure that VMware
the server. installed on the server, or the tools later than
on the server.
Error Cause Action
9002: VMware tools aren't running on VMware tools might not be Ensure that VMware
the server. installed on the server, or the tools later than
on the server.
9003: Operating system type running on The operating system running Only Windows and
the server isn't supported. on the server isn't Windows or Linux OS types are
Linux. supported. If the
server is running
Windows or Linux
OS, check the
operating system
type specified in
vCenter Server.
9004: Server isn't in a running state. The server is in a powered-off Ensure that the
state. server is in a running
state.
9005: Operating system type running on The operating system running Only Windows and
the server isn't supported. on the server isn't Windows or Linux OS types are
Linux. supported. The
<FetchedParameter>
operating system
isn't supported
currently.
9006: The URL needed to download the This issue could be transient The issue should
discovery metadata file from the server because the discovery agent automatically resolve
is empty. on the appliance isn't working in the next cycle
as expected. within 24 hours. If
the issue persists,
submit a Microsoft
support case.
9007: The process that runs the script to This issue could be transient The issue should
collect the metadata isn't found in the because the discovery agent automatically resolve
server. on the appliance isn't working in the next cycle
the issue persists,
submit a Microsoft
support case.
Error Cause Action
9008: The status of the process running This issue could be transient The issue should
on the server to collect the metadata because of an internal error. automatically resolve
can't be retrieved. in the next cycle
within 24 hours. If
the issue persists,
submit a Microsoft
support case.
9009: Windows User Account Control Windows UAC settings are On the affected
(UAC) is preventing the execution of restricting the discovery of server, lower the
discovery operations on the server. installed applications from the level of the User
server. Account Control
settings in Control
Panel.
9010: The server is powered off. The server is in a powered-off Ensure that the
state. server is in a
powered-on state.
9011: The file containing the discovered This issue could be transient The issue should
metadata can't be found on the server. because of an internal error. automatically resolve
in the next cycle
within 24 hours. If
the issue persists,
submit a Microsoft
support case.
metadata on the server is empty. because of an internal error. automatically resolve
in the next cycle
within 24 hours. If
the issue persists,
submit a Microsoft
support case.
9013: A new temporary user profile is A new temporary user profile Submit a Microsoft
created on logging in to the server each is created on logging in to the support case to help
time. server each time. troubleshoot this
issue.
9014: Unable to retrieve the file Encountered an error on the Ensure that port 443
containing the discovered metadata ESXi host <HostName>. Error is open on the ESXi
because of an error encountered on the code: %ErrorCode; Details: host on which the
ESXi host. Error code: %ErrorCode; %ErrorMessage server is running.
Details: %ErrorMessage
Learn more on how
to remediate the
issue.
Error Cause Action
9015: The vCenter Server user account The required privileges of Ensure that the
provided for server discovery doesn't guest operations haven't been vCenter Server user
have guest operations privileges enabled on the vCenter Server account has
enabled. user account. privileges enabled
for Virtual Machines
> Guest Operations:
to interact with the
server and pull the
required data.
Learn more on how

to set up the vCenter
Server account with
required privileges.
9016: Unable to discover the metadata Either the VMware tools aren't Ensure that the
because the guest operations agent on installed on the server or the VMware tools are
the server is outdated. installed version isn't up to installed and running
date. up to date on the
server. The VMware
Tools version must
be version 10.2.1 or
later.
9017: The file containing the discovered This issue could be transient Submit a Microsoft
metadata can't be found on the server. because of an internal error. support case to help
troubleshoot this
issue.
9018: PowerShell isn't installed on the PowerShell can't be found on Ensure that
server. the server. PowerShell version
2.0 or later is
installed on the
server.
Learn more on how

to remediate the
issue.
Error Cause Action
9019: Unable to discover the metadata VMware guest operations Ensure that the
because of guest operation failures on failed on the server. The issue server credentials
the server. was encountered when you provided on the
tried the following credentials appliance are valid
on the server: and the username
<FriendlyNameOfCredentials>. provided in the
credentials is in the
user principal name
(UPN) format. (Find
the friendly name of
the credentials tried
by Azure Migrate in
the possible causes.)
9020: Unable to create the file required The role associated to the 1. Check if the
to contain the discovered metadata on credentials provided on the credentials provided
the server. appliance or a group policy on the appliance
on-premises is restricting the have created file
creation of a file in the permission on the
required folder. The issue was folder <folder
encountered when you tried path/folder name>
the following credentials on in the server.
the server: 2. If the credentials
<FriendlyNameOfCredentials>. provided on the
appliance don't have
the required
permissions, either
provide another set
of credentials or edit
an existing one.
(Find the friendly
name of the
credentials tried by
Azure Migrate in the
possible causes.)
9021: Unable to create the file required VMware tools are reporting an Ensure that VMware
to contain the discovered metadata at incorrect file path to create the tools later than
the right path on the server. file. version 10.2.0 are
on the server.
Error Cause Action
9022: The access is denied to run the The role associated to the 1. Check if the
Get-WmiObject cmdlet on the server. credentials provided on the credentials provided
appliance or a group policy on the appliance
on-premises is restricting have created file
access to the WMI object. The administrator
issue was encountered when privileges and have
you tried the following WMI enabled.
credentials on the server: 2. If the credentials
<FriendlyNameOfCredentials>. on the appliance
don't have the
required
permissions, either
provide another set
an existing one.
(Find the friendly
name of the
possible causes.)
Learn more on how

to remediate the
issue.
9023: Unable to run PowerShell because The value of the 1. Check if the
the %SystemRoot% environment %SystemRoot% environment environment variable
variable value is empty. variable is empty for the is returning an
server. empty value by
running the echo
%systemroot%
command on the
affected server.
2. If the issue
persists, submit a
Microsoft support
case.
Error Cause Action
9024: Unable to perform discovery The value of the %TEMP% 1. Check if the
because the %TEMP% environment environment variable is empty environment variable
variable value is empty. for the server. is returning an
empty value by
running the echo
%temp% command
on the affected
server.
2. If the issue
persists, submit a
Microsoft support
case.
9025: Unable to perform discovery PowerShell is corrupted on the Reinstall PowerShell

because PowerShell is corrupted on the server. and verify that it's
server. running on the
affected server.
9026: Unable to run guest operations on The current state of the server 1. Ensure that the
the server. isn't allowing the guest affected server is up
operations to run. and running.
2. If the issue
persists, submit a
Microsoft support
case.
9027: Unable to discover the metadata Unable to contact the guest Ensure that VMware
because the guest operations agent isn't operations agent on the tools later than
running on the server. server. version 10.2.0 are
on the server.
9028: Unable to create the file required There's a lack of sufficient Ensure that enough
to contain the discovered metadata storage space on the server space is available on
because of insufficient storage on the disk. the disk storage of
server. the affected server.
Error Cause Action
9029: The credentials provided on the The credentials provided on 1. Ensure that the
appliance don't have access permissions the appliance don't have credentials on the
to run PowerShell. access permissions to run appliance can access
PowerShell. The issue was PowerShell on the
encountered when you tried server.
the following credentials on 2. If the credentials
the server: on the appliance
<FriendlyNameOfCredentials>. don't have the
required access,
either provide
another set of
credentials or edit an
existing one. (Find
by Azure Migrate in
9030: Unable to gather the discovered The ESXi host on which the Ensure that the ESXi
metadata because the ESXi host where server is residing is in a host running the
the server is hosted is in a disconnected disconnected state. server is in a
state. connected state.
metadata because the ESXi host where server is residing is in an host running the
the server is hosted isn't responding. invalid state. server is in a running
and connected state.
9032: Unable to discover because of an The issue encountered is Follow the steps on
internal error. because of an internal error. this website to
remediate the issue.
If the issue persists,
open a Microsoft
support case.
Error Cause Action
9033: Unable to discover because the The credentials provided on Ensure that the
username of the credentials provided on the appliance contain invalid credentials provided
the appliance for the server has invalid characters in the username. on the appliance
characters. The issue was encountered don't have any
when you tried the following invalid characters in
credentials on the server: the username. Go
<FriendlyNameOfCredentials>. back to the
appliance
configuration
manager to edit the
credentials. (Find the
friendly name of the
possible causes.)
9034: Unable to discover because the The credentials on the Ensure that the
username of the credentials provided on appliance don't have the credentials on the
the appliance for the server isn't in the username in the UPN format. appliance have their
UPN format. The issue was encountered username in the
when you tried the following UPN format. Go back
credentials on the server: to the appliance
<FriendlyNameOfCredentials>. configuration
manager to edit the
possible causes.)
9035: Unable to discover because the PowerShell language mode Ensure that the
PowerShell language mode isn't set isn't set to Full language. PowerShell language
correctly. mode is set to Full
language.
Error Cause Action
when you tried the following UPN format. Go back
credentials on the server: to the appliance
<FriendlyNameOfCredentials>. configuration
manager to edit the
possible causes.)
9037: The metadata collection is The server is taking too long The issue should
temporarily paused because of a high to respond. automatically resolve
response time from the server. in the next cycle
within 24 hours. If
the issue persists,
submit a Microsoft
support case.
10000: The operation system type The operating system running Only Windows and
running on the server isn't supported. on the server isn't Windows or Linux OS types are
<GuestOSName>
operating system
isn't supported
currently.
10001: The script required to gather The script required to perform Submit a Microsoft
discovery metadata isn't found on the discovery might have been support case to help
server. deleted or removed from the troubleshoot this
expected location. issue.
10002: The discovery operations timed This issue could be transient The issue should
out on the server. because the discovery agent automatically resolve
on the appliance isn't working in the next cycle
as expected. within 24 hours. If it
isn't resolved, follow
the steps on this
website to remediate
the issue. If the issue
persists, open a
Microsoft support
case.
Error Cause Action
10003: The process executing the The process executing the The issue should
discovery operations exited with an discovery operations exited automatically resolve
error. abruptly because of an error. in the next cycle
within 24 hours. If
the issue persists,
submit a Microsoft
support case.
10004: Credentials aren't provided on The credentials for the server 1. Ensure that you
the appliance for the server OS type. OS type weren't added on the add the credentials
appliance. for the OS type of
the affected server
on the appliance.
2. You can now add
multiple server
credentials on the
appliance.
10005: Credentials provided on the The credentials provided on 1. Ensure that the
appliance for the server are invalid. the appliance aren't valid. The credentials provided
issue was encountered when on the appliance are
you tried the following valid and the server
credentials on the server: \ is accessible by using
<FriendlyNameOfCredentials>. the credentials.
2. You can now add
multiple server
credentials on the
appliance.
3. Go back to the
appliance
configuration
manager to either
provide another set
an existing one.
(Find the friendly
name of the
possible causes.)
Learn more on how

to remediate the
issue.
Error Cause Action
<GuestOSName>
operating system
isn't supported
currently.
10007: Unable to process the discovered An error occurred when Submit a Microsoft
metadata from the server. parsing the contents of the file support case to help
containing the discovered troubleshoot this
metadata. issue.
creation of a file in the permissions on the
encountered when you tried path/folder name>
the following credentials on in the server.
the server: 2. If the credentials
the required
permissions, either
provide another set
an existing one.
(Find the friendly
name of the
possible causes.)
Error Cause Action
10009: Unable to write the discovered The role associated to the 1. Check if the
metadata in the file on the server. credentials provided on the credentials provided
on-premises is restricting have write file
writing in the file on the server. permissions on the
The issue was encountered folder <folder
when you tried the following path/folder name>
credentials on the server: in the server.
<FriendlyNameOfCredentials>. 2. If the credentials
provided on the
the required
permissions, either
provide another set
an existing one.
(Find the friendly
name of the
possible causes.)
10010: Unable to discover because the The package containing the Ensure that the
command- %CommandName; required command %CommandName; package containing
to collect some metadata is missing on isn't installed on the server. the command
the server. %CommandName; is
installed on the
server.
10011: The credentials provided on the The interactive login and log- Use the resolution
appliance were used to log in and log off forces the registry keys to methods
off for an interactive session. be unloaded in the profile of documented on this
the account being used. This website.
condition makes the keys
unavailable for future use.
Error Cause Action
10012: Credentials haven't been Either no credentials were 1. Ensure that the
provided on the appliance for the provided for the server or you credentials are
server. provided domain credentials provided on the
with an incorrect domain appliance for the
name on the appliance. Learn server and the server
more about the cause of this is accessible by using
error. the credentials.
2. You can now add
multiple credentials
on the appliance for
servers. Go back to
the appliance
configuration
manager to provide
credentials for the
server.
Error 9014:
HTTPGetRequestToRetrieveFileFailed
Cause
The issue happens when the VMware discovery agent in the appliance tries to download
the output file containing dependency data from the server file system through the ESXi
host on which the server is hosted.
Remediation
You can test TCP connectivity to the ESXi host (name provided in the error message)
on port 443 (required to be open on ESXi hosts to pull dependency data) from the
appliance by opening PowerShell on the appliance server and running the
following command:
Test -NetConnection -ComputeName <Ip address of the ESXi host> -Port

443
If the command returns successful connectivity, go to the Azure Migrate project >
Discovery and assessment > Overview > Manage > Appliances, select the
appliance name, and select Refresh services.
Error 9018: PowerShellNotFound
Cause
The error usually appears for servers running Windows Server 2008 or lower.
Remediation
Install the required PowerShell version (2.0 or later) at this location on the server:
($SYSTEMROOT)\System32\WindowsPowershell\v1.0\powershell.exe. Learn more about
how to install PowerShell in Windows Server.
After you install the required PowerShell version, verify if the error was resolved by
following the steps on this website.
Error 9022: GetWMIObjectAccessDenied
Remediation
Make sure that the user account provided in the appliance has access to WMI
namespace and subnamespaces. To set the access:
1. Go to the server that's reporting this error.

wmimgmt.msc in the Open text box and select Enter.
3. The wmimgmt console opens where you can find WMI Control (Local) in the left
pane. Right-click it, and select Properties from the menu.
5. Select Security to open the Security for ROOT dialog.
6. Select Advanced to open the Advanced Security Settings for Root dialog.
7. Select Add to open the Permission Entry for Root dialog.
8. Click Select a principal to open the Select Users, Computers, Service Accounts or
Groups dialog.
9. Select the usernames or groups you want to grant access to the WMI, and select
OK.
10. Ensure you grant execute permissions, and select This namespace and
subnamespaces in the Applies to dropdown list.
11. Select Apply to save the settings and close all dialogs.
After you get the required access, verify if the error was resolved by following the steps
on this website.
Error 9032: InvalidRequest
Cause
There can be multiple reasons for this issue. One reason is when the username provided
(server credentials) on the appliance configuration manager has invalid XML characters.
Invalid characters cause an error in parsing the SOAP request.
Remediation
Make sure the username of the server credentials doesn't have invalid XML
characters and is in the username@domain.com format. This format is popularly
known as the UPN format.
After you edit the credentials on the appliance, verify if the error was resolved by
Error 10002: ScriptExecutionTimedOutOnVm
Cause
This error occurs when the server is slow or unresponsive and the script executed
to pull the dependency data starts timing out.
After the discovery agent encounters this error on the server, the appliance doesn't
attempt agentless dependency analysis on the server thereafter to avoid
overloading the unresponsive server.
You'll continue to see the error until you check the issue with the server and restart
the discovery service.
Remediation
1. Sign in to the server encountering this error.
2. Run the following commands on PowerShell:

Get-WMIObject win32_operatingsystem;
Get-WindowsFeature | Where-Object {$_.InstallState -eq 'Installed' -or
($_.InstallState -eq $null -and $_.Installed -eq 'True')};
Get-WmiObject Win32_Process;
netstat -ano -p tcp | select -Skip 4;
3. If the commands output the result in a few seconds, go to the Azure Migrate
project > Discovery and assessment > Overview > Manage > Appliances, select
the appliance name, and select Refresh services to restart the discovery service.
4. If the commands are timing out without giving any output, you need to:
Figure out which process is consuming high CPU or memory on the server.
Try to provide more cores or memory to that server and run the commands
again.
Error 10005: GuestCredentialNotValid
Remediation
Ensure the validity of credentials (friendly name provided in the error) by selecting
Revalidate credentials on the appliance configuration manager.
Ensure that you can sign in to the affected server by using the same credential
provided in the appliance.
You can try by using another user account (for the same domain, in case the server
is domain joined) for that server instead of an administrator account.
The issue can happen when Global Catalog <-> Domain Controller communication
is broken. Check for this problem by creating a new user account in the domain
controller and providing the same in the appliance. You might also need to restart
the domain controller.
After you take the remediation steps, verify if the error was resolved by following
the steps on this website.
Error 10012: CredentialNotProvided
Cause
This error occurs when you've provided a domain credential with the wrong domain
name on the appliance configuration manager. For example, if you provided a domain
credential with the username user@abc.com but provided the domain name as def.com,
those credentials won't be attempted if the server is connected to def.com and you'll
get this error message.
Remediation
Go to the appliance configuration manager to add a server credential or edit an
existing one as explained in the cause.
Mitigation verification
After you use the mitigation steps for the preceding errors, verify if the mitigation
worked by running a few PowerCLI commands from the appliance server. If the
commands succeed, it means that the issue is resolved. Otherwise, check and follow the
remediation steps again.
For VMware VMs (using VMware pipe)

1. Run the following commands to set up PowerCLI on the appliance server:
Install-Module -Name VMware.PowerCLI -AllowClobber

Set-PowerCLIConfiguration -InvalidCertificateAction Ignore
2. Connect to vCenter Server from the appliance by providing the vCenter Server IP
address in the command and credentials in the prompt:
Connect-VIServer -Server <IPAddress of vCenter Server>
3. Connect to the target server from the appliance by providing the server name and
server credentials (as provided on the appliance):
$vm = get-VM <VMName>

$credential = Get-Credential
4. For software inventory, run the following commands to see if you get a successful
output:
Invoke-VMScript -VM $vm -ScriptText "powershell.exe 'Get-

WMIObject win32_operatingsystem'" -GuestCredential $credential
Invoke-VMScript -VM $vm -ScriptText "powershell.exe Get-

WindowsFeature" -GuestCredential $credential
For Linux servers:
Invoke-VMScript -VM $vm -ScriptText "ls" -GuestCredential

$credential
For Hyper-V VMs and physical servers (using direct

connect pipe)
1. Connect to Windows server by running the command:
$Server = New-PSSession –ComputerName <IPAddress of Server> -Credential

<user_name>
and input the server credentials in the prompt.
2. Run the following commands to validate for software inventory to see if you get a
successful output:
Invoke-Command -Session $Server -ScriptBlock {Get-WMIObject

win32_operatingsystem}
Invoke-Command -Session $Server -ScriptBlock {Get-WindowsFeature}
For Linux servers:

1. Install the OpenSSH client
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0
2. Install the OpenSSH server
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
3. Start and configure OpenSSH Server
Start-Service sshd
Set-Service -Name sshd -StartupType 'Automatic'
4. Connect to OpenSSH Server
ssh username@servername
5. Run the following commands to validate for software inventory to see if you get a
successful output:
ls
After you verify that the mitigation worked, go to the Azure Migrate project >
Discovery and assessment > Overview > Manage > Appliances, select the appliance
name, and select Refresh services to start a fresh discovery cycle.
Discovered SQL Server instances and databases

not in the portal
After you've initiated discovery on the appliance, it might take up to 24 hours to start
showing the inventory data in the portal.
If you haven't provided Windows authentication or SQL Server authentication

credentials on the appliance configuration manager, add the credentials so that the
appliance can use them to connect to the respective SQL Server instances.
After the appliance is connected, it gathers configuration and performance data of SQL
Server instances and databases. The SQL Server configuration data is updated once
every 24 hours, and the performance data is captured every 30 seconds. Any change to
the properties of the SQL Server instance and databases, such as database status and
compatibility level, can take up to 24 hours to update on the portal.
SQL Server instance is showing up in a "Not

connected" state on the portal
To view the issues encountered during discovery of SQL Server instances and databases,
select the Not connected status in the connection status column on the Discovered
servers page in your project.
Creating assessment on top of servers containing SQL instances that weren't discovered
completely or are in a not-connected state might lead to readiness being marked as
Unknown.
Common SQL Server instances and database

discovery errors
Azure Migrate supports discovery of SQL Server instances and databases running on on-
premises machines by using Azure Migrate: Discovery and assessment. See the
Discovery tutorial to get started.
Typical SQL discovery errors are summarized in the following table.
Error Cause Action Guide
30000: Either manually associated credentials Add credentials for SQL -

Credentials are invalid or auto-associated Server on the appliance and
associated credentials can no longer access the wait until the next SQL
with this SQL SQL server. discovery cycle or force
server didn't refresh.
work.
30001: Unable 1. The appliance doesn't have a 1. Make SQL Server -

to connect to network line of sight to SQL Server. reachable from the
SQL Server 2. The firewall is blocking the appliance.
from the connection between SQL Server and 2. Allow incoming
appliance. the appliance. connections from the
appliance to SQL Server.
30003: A trusted certificate isn't installed on Set up a trusted certificate View

Certificate isn't the computer running SQL Server. on the server. Learn more.
trusted.
30004: This error could occur because of the Grant the sysadmin role to View
Insufficient lack of permissions required to scan the credentials/ account
permissions. SQL Server instances. provided on the appliance
for discovering SQL Server
instances and databases.
Learn more.
30005: SQL Either the database itself is invalid or Use ALTER LOGIN to set the View
Server login the login lacks CONNECT permission default database to master
failed to on the database. database.
connect Grant the sysadmin role to
because of a the credentials/ account
problem with provided on the appliance
its default for discovering SQL Server
master instances and databases.
database. Learn more.
30006: SQL 1. The login might be a SQL Server If you try to connect by View
Server login login, but the server only accepts using SQL Server
can't be used Windows authentication. authentication, verify that
with Windows 2. You're trying to connect by using SQL Server is configured in
authentication. SQL Server authentication, but the Mixed authentication mode
login used doesn't exist on SQL Server. and that the SQL Server
3. The login might use Windows login exists.
authentication, but the login is an If you try to connect by
unrecognized Windows principal. An using Windows
unrecognized Windows principal authentication, verify that
means that the login can't be verified you're properly logged in to
by Windows. This issue could occur the correct domain. Learn
because the Windows login is from an more.
untrusted domain.
30007: The password of the account has The SQL Server login View
Password expired. password might have
expired. expired. Reset the password
or extend the password
expiration date. Learn more.
30008: The password of the account must be Change the password of the View
Password changed. credential provided for SQL
must be Server discovery. Learn
changed. more.
30009: An An internal error occurred while Contact Microsoft support if -

internal error discovering SQL Server instances and the issue persists.
occurred. databases.
30010: No Unable to find any databases from the Grant the sysadmin role to -
databases selected server instance. the credentials/ account
found. provided on the appliance
for discovering SQL
databases.

internal error performing assessment. the issue persists.
occurred while
assessing a
SQL instance
or database.
30012: SQL 1. The firewall on the server has Use this interactive user View
connection refused the connection. guide to troubleshoot the
failed. 2. The SQL Server Browser service connectivity issue. Wait for
(sqlbrowser) isn't started. 24 hours after following the
3. SQL Server didn't respond to the guide for the data to update
client request because the server in the service. If the issue
probably isn't started. persists, contact Microsoft
4. The SQL Server client can't connect support.
to the server. This error could occur
because the server isn't configured to
accept remote connections.
5. The SQL Server client can't connect
to the server. This error could occur
because either the client can't resolve
the name of the server or the name of
the server is incorrect.
6. The TCP or named pipe protocols
aren't enabled.
7. The specified SQL Server instance
name isn't valid.
30013: An 1. The SQL Server name can't be If you can ping SQL Server View
error occurred resolved from the appliance. from the appliance, wait 24
while 2. SQL Server doesn't allow remote hours to check if this issue
establishing a connections. autoresolves. If it doesn't,
connection to contact Microsoft support.
the SQL Server Learn more.
instance.
30014: This error could occur because of an Provide a credential with a View
Username or authentication failure that involves a valid username and
password is bad password or username. password. Learn more.
invalid.

internal error discovering the SQL Server instance. the issue persists.
occurred while
discovering
the SQL Server
instance.
30016: This problem could occur if the firewall Verify whether the firewall View
Connection to on the server refuses the connection. on the SQL server is
instance configured to accept
'%instance;' connections. If the error
failed because persists, contact Microsoft
of a timeout. support. Learn more.
30017: Internal Unhandled exception. Contact Microsoft support if -

error occurred. the issue persists.
30018: Internal An internal error occurred while Wait for 24 hours and -
error occurred. collecting data such as the Temp DB contact Microsoft support if
size and the file size of the SQL the issue persists.
instance.
30019: Internal An internal error occurred while Wait for 24 hours and -
error occurred. collecting performance metrics such as contact Microsoft support if
memory utilization of a database or an the issue persists.
instance.
Common web apps discovery errors

Azure Migrate supports discovery of web apps running on on-premises machines by
using Azure Migrate: Discovery and assessment. See the Discovery tutorial to get
started.
Typical web apps discovery errors are summarized in the following table.
Error Cause Action

Error Cause Action
40001: IIS IIS web app discovery uses the Ensure that the Web Server (IIS) role
Management management API that's included including the IIS Management Console
console with the local version of IIS to read feature (part of Management Tools) is
feature isn't the IIS configuration. This API is enabled and that the server OS is
enabled. available when the IIS Management Windows Server 2008 R2 or later version.
Console feature of IIS is enabled.
Either this feature isn't enabled or
the OS isn't a supported version for
IIS web app discovery.
40002: Unable Connection to the server failed Ensure that the login credentials
to connect to because of invalid login credentials provided for the server are correct and
the server or an unavailable machine. that the server is online and accepting
from the WS-Management PowerShell remote
appliance. connections.
40003: Unable Connection to the server failed Ensure that the login credentials
to connect to because of invalid login credentials. provided for the server are correct and
the server that WS-Management PowerShell
because of remoting is enabled.
invalid
credentials.
40004: No permissions or insufficient Confirm that the user credentials

Unable to permissions. provided for the server are
access the IIS administrator-level credentials and that
configuration. the user has permission to access files
under the IIS directory
(%windir%\System32\inetsrv) and IIS
server configuration directory
(%windir%\System32\inetsrv\config).
40005: Unable Failed to complete discovery on the Confirm that the user credentials
to complete VM. This issue might occur because provided for the server are
IIS discovery. of issues with accessing administrator-level credentials and that
configuration on the server. The the user has permission to access files
error was '%detailedMessage;'. under the IIS directory
(%windir%\System32\inetsrv) and IIS
server configuration directory
(%windir%\System32\inetsrv\config).
Then contact Microsoft support with the
error details.
40006: New error scenario. Contact Microsoft support with error

Uncategorized details and logs. Logs can be found on
exception. the appliance server under the path
C:\ProgramData\Microsoft Azure\Logs.
Error Cause Action
40007: No The web server doesn't have any Check the web server configuration.
web apps hosted applications.
found for the
web server.
Next steps
Set up an appliance for VMware, Hyper-V, or physical servers.
Troubleshoot dependency visualization
This article helps you troubleshoot issues with agent-based and agentless dependency
analysis, which is only available for VMware servers. Learn more about the types of
dependency visualization supported in Azure Migrate.
Visualize dependencies for >1 hour with

With agentless dependency analysis, you can visualize dependencies or export them in a
map for a duration of up to 30 days.
Visualize dependencies for >10 servers with

Azure Migrate offers a Power BI template that you can use to visualize network
connections of many servers at once, and filter by process and server. Learn more about
how to visualize the dependencies for many servers together.
Dependencies export CSV shows "Unknown

process" with agentless dependency analysis
In agentless dependency analysis, the process names are captured on a best-effort
basis. In certain scenarios, although the source and destination server names and the
destination port are captured, it isn't feasible to determine the process names at both
ends of the dependency. In such cases, the process is marked as "Unknown process."
Unable to export dependency data in a CSV

due to the error "403: This request is not
authorized to perform this operation"
If your Azure Migrate project has private endpoint connectivity, the request to export
dependency data should be initiated from a client connected to the Azure virtual
network over a private network. To resolve this error, open the Azure portal in your on-
premises network or on your appliance server and try exporting again.
Export the dependency analysis errors
You can export all the errors and remediations for agentless dependency analysis from
the portal by selecting Export notifications. The exported CSV file also contains
additional information like the timestamp at which the error was encountered and if it
was an error in validation or discovery of dependency data.
Common agentless dependency analysis errors

Azure Migrate supports agentless dependency analysis by using Azure Migrate:
Discovery and assessment. Learn more about how to perform agentless dependency
analysis.
For VMware VMs, agentless dependency analysis is performed by connecting to the

servers via the vCenter Server using the VMware APIs. For Hyper-V VMs and physical
servers, agentless dependency analysis is performed by directly connecting to Windows
servers using PowerShell remoting on port 5985 (HTTP) and to Linux servers using SSH
connectivity on port 22 (TCP).
The table below summarizes all errors encountered when gathering dependency data
through VMware APIs or by directly connecting to servers:
７ Note
The same errors can also be encountered with software inventory because it follows
the same methodology as agentless dependency analysis to collect the required
data.
Error Cause Action

Error Cause Action
60001:UnableToConnectToPhysicalServer Either the prerequisites to - Ensure that the

connect to the server have not server meets the
been met or there are network prerequisites and
issues in connecting to the port access
server, for instance some proxy requirements.
settings. - Add the IP
addresses of the
remote machines
(discovered servers)
to the WinRM
TrustedHosts list on
the Azure Migrate
appliance, and retry
the operation. This is
to allow remote
inbound connections
on servers -
Windows: WinRM
port 5985 (HTTP)
and Linux: SSH port
22 (TCP).
- Ensure that you
have chosen the
correct
authentication
method on the
appliance to connect
to the server.
submit a Microsoft
support case,
providing the
appliance machine
footer of the
appliance
configuration
manager).
Error Cause Action
60002:InvalidServerCredentials Unable to connect to server. - Ensure that you

Either you have provided have provided the
incorrect credentials on the correct credentials
appliance or the credentials for the server on the
previously provided have appliance. You can
expired. check that by trying
to connect to the
server using those
credentials.
- If the credentials
added are incorrect
or have expired, edit
the credentials on
the appliance and
revalidate the added
servers. If the
validation succeeds,
the issue is resolved.
submit a Microsoft
support case,
providing the
appliance machine
footer of the
appliance
configuration
manager).
Error Cause Action
60005:SSHOperationTimeout The operation took longer - Ensure that the

than expected either due to impacted server has
network latency issues or due the latest kernel and
to the lack of latest updates on OS updates installed.
the server. - Ensure that there is
no network latency
between the
appliance and the
server. It is
recommended to
have the appliance
and source server on
the same domain to
avoid latency issues.
- Connect to the
impacted server
from the appliance
and run the
commands
documented here to
check if they return
null or empty data.
submit a Microsoft
support case
providing the
appliance machine
footer of the
appliance
configuration
manager).
9000: VMware tools status on the server VMware tools might not be Ensure that VMware
can't be detected. installed on the server or the tools later than
on the server.
9001: VMware tools aren't installed on VMware tools might not be Ensure that VMware
the server. installed on the server or the tools later than
on the server.
Error Cause Action
9002: VMware tools aren't running on VMware tools might not be Ensure that VMware
the server. installed on the server or the tools later than
on the server.
9003: Operation system type running on Operating system running on Only Windows and
the server isn't supported. the server isn't Windows or Linux OS types are
Linux. supported. If the
server is indeed
running Windows or
Linux OS, check the
operating system
type specified in
vCenter Server.
9004: Server isn't in a running state. Server is in a powered-off Ensure that the
state. server is in a running
state.
9005: Operation system type running on Operating system running on Only Windows and
the server isn't supported. the server isn't Windows or Linux OS types are
<FetchedParameter>
operating system
isn't supported
currently.
9006: The URL needed to download the This issue could be transient The issue should
discovery metadata file from the server because of the discovery agent automatically resolve
is empty. on the appliance not working in the next cycle
the issue persists,
submit a Microsoft
support case.
9007: The process that runs the script to This issue could be transient The issue should
collect the metadata isn't found in the because of the discovery agent automatically resolve
server. on the appliance not working in the next cycle
the issue persists,
submit a Microsoft
support case.
Error Cause Action
9008: The status of the process running This issue could be transient The issue should
on the server to collect the metadata because of an internal error. automatically resolve
can't be retrieved. in the next cycle
within 24 hours. If
the issue persists,
submit a Microsoft
support case.
9009: Windows User Account Control Windows UAC settings restrict On the affected
(UAC) prevents the execution of the discovery of installed server, lower the
discovery operations on the server. applications from the server. level of the User
Account Control
settings on the
Control Panel.
9010: The server is powered off. The server is in a powered-off Ensure that the
state. server is in a
powered-on state.
metadata can't be found on the server. because of an internal error. automatically resolve
in the next cycle
within 24 hours. If
the issue persists,
submit a Microsoft
support case.
metadata on the server is empty. because of an internal error. automatically resolve
in the next cycle
within 24 hours. If
the issue persists,
submit a Microsoft
support case.
9013: A new temporary user profile is A new temporary user profile Submit a Microsoft
created on logging in to the server each is created on logging in to the support case to help
time. server each time. troubleshoot this
issue.
9014: Unable to retrieve the file Encountered an error on the Ensure that port 443
containing the discovered metadata ESXi host <HostName>. Error is open on the ESXi
because of an error encountered on the code: %ErrorCode; Details: host on which the
ESXi host. Error code: %ErrorCode; %ErrorMessage. server is running.
Details: %ErrorMessage
Learn more on how
to remediate the
issue.
Error Cause Action
9015: The vCenter Server user account The required privileges of Ensure that the
provided for server discovery doesn't guest operations haven't been vCenter Server user
have guest operations privileges enabled on the vCenter Server account has
enabled. user account. privileges enabled
for Virtual Machines
> Guest Operations
to interact with the
server and pull the
required data.
Learn more on how

to set up the vCenter
Server account with
required privileges.
9016: Unable to discover the metadata Either the VMware tools aren't Ensure that the
because the guest operations agent on installed on the server or the VMware tools are
the server is outdated. installed version isn't up to installed and running
date. and up to date on
the server. The
VMware Tools
version must be
version 10.2.1 or
later.
9017: The file containing the discovered This could be a transient issue Submit a Microsoft
metadata can't be found on the server. because of an internal error. support case to help
troubleshoot this
issue.
9018: PowerShell isn't installed on the PowerShell can't be found on Ensure that
server. the server. PowerShell version
2.0 or later is
installed on the
server.
Learn more about

how to remediate
the issue.
Error Cause Action
9019: Unable to discover the metadata VMware guest operations Ensure that the
because of guest operation failures on failed on the server. The issue server credentials on
the server. was encountered when trying the appliance are
the following credentials on valid and the
the server: username in the
<FriendlyNameOfCredentials>. credentials is in the
user principal name
(UPN) format. (Find
by Azure Migrate in
creation of the file in the permission on the
encountered when trying the path/folder name>
following credentials on the in the server.
server: 2. If the credentials
the required
permissions, either
provide another set
an existing one.
(Find the friendly
name of the
possible causes.)
9021: Unable to create the file required VMware tools are reporting an Ensure that VMware
to contain the discovered metadata at incorrect file path to create the tools later than
the right path on the server. file. version 10.2.0 are
on the server.
Error Cause Action
9022: The access is denied to run the The role associated to the 1. Check if the
Get-WmiObject cmdlet on the server. credentials provided on the credentials provided
on-premises is restricting have created file
access to the WMI object. The administrator
issue was encountered when privileges and have
trying the following credentials WMI enabled.
on the server: 2. If the credentials
the required
permissions, either
provide another set
an existing one.
(Find the friendly
name of the
possible causes.)
Learn more on how

to remediate the
issue.
9023: Unable to run PowerShell because The value of the 1. Check if the
the %SystemRoot% environment %SystemRoot% environment environment variable
variable value is empty. variable is empty for the is returning an
server. empty value by
running echo
%systemroot%
command on the
affected server.
2. If issue persists,
submit a Microsoft
support case.
Error Cause Action
9024: Unable to perform discovery as The value of %TEMP% 1. Check if the

the %TEMP% environment variable environment variable is empty environment variable
value is empty. for the server. is returning an
empty value by
running the echo
%temp% command
on the affected
server.
2. If the issue
persists, submit a
Microsoft support
case.
9025: Unable to perform discovery PowerShell is corrupted on the Reinstall PowerShell

because PowerShell is corrupted on the server. and verify that it's
server. running on the
affected server.
9026: Unable to run guest operations on The current state of the server 1. Ensure that the
the server. doesn't allow the guest affected server is up
operations to run. and running.
2. If the issue
persists, submit a
Microsoft support
case.
9027: Unable to discover the metadata Unable to contact the guest Ensure that VMware
because the guest operations agent isn't operations agent on the tools later than
running on the server. server. version 10.2.0 are
on the server.
9028: Unable to create the file required There's a lack of sufficient Ensure that enough
to contain the discovered metadata storage space on the server space is available on
because of insufficient storage on the disk. the disk storage of
server. the affected server.
Error Cause Action
9029: The credentials provided on the The credentials on the 1. Ensure that the
appliance don't have access permissions appliance don't have access credentials on the
to run PowerShell. permissions to run PowerShell. appliance can access
The issue was encountered PowerShell on the
when trying the following server.
credentials on the server: 2. If the credentials
<FriendlyNameOfCredentials>. on the appliance
don't have the
required access,
either provide
another set of
credentials or edit an
existing one. (Find
by Azure Migrate in
metadata because the ESXi host where server is residing is in a host running the
the server is hosted is in a disconnected disconnected state. server is in a
state. connected state.
metadata because the ESXi host where server is residing is in an host running the
the server is hosted isn't responding. invalid state. server is in a running
and connected state.
9032: Unable to discover because of an The issue encountered is Follow the steps on
internal error. because of an internal error. this website to
remediate the issue.
If the issue persists,
open a Microsoft
support case.
Error Cause Action
username of the credentials provided on appliance contain invalid credentials on the
the appliance for the server has invalid characters in the username. appliance don't have
characters. The issue was encountered any invalid
when trying the following characters in the
credentials on the server: username. You can
<FriendlyNameOfCredentials>. go back to the
appliance
configuration
manager to edit the
possible causes.)
when trying the following UPN format. You can
credentials on the server: go back to the
<FriendlyNameOfCredentials>. appliance
configuration
manager to edit the
possible causes.)
9035: Unable to discover because the The PowerShell language Ensure that the
PowerShell language mode isn't set mode isn't set to Full PowerShell language
correctly. language. mode is set to Full
language.
Error Cause Action
when trying the following UPN format. You can
credentials on the server: go back to the
<FriendlyNameOfCredentials>. appliance
configuration
manager to edit the
possible causes.)
9037: The metadata collection is The server is taking too long The issue should
temporarily paused because of high to respond. automatically resolve
response time from the server. in the next cycle
within 24 hours. If
the issue persists,
submit a Microsoft
support case.
Linux. supported.
<GuestOSName>
operating system
isn't supported
currently.
10001: The script required to gather The script required to perform Submit a Microsoft
discovery metadata isn't found on the discovery might have been support case to help
server. deleted or removed from the troubleshoot this
expected location. issue.
10002: The discovery operations timed This issue could be transient The issue should
out on the server. because the discovery agent automatically resolve
on the appliance isn't working in the next cycle
as expected. within 24 hours. If it
isn't resolved, follow
the steps on this
website to remediate
the issue. If the issue
persists, open a
Microsoft support
case.
Error Cause Action
10003: The process executing the The process executing the The issue should
discovery operations exited with an discovery operations exited automatically resolve
error. abruptly because of an error. in the next cycle
within 24 hours. If
the issue persists,
submit a Microsoft
support case.
10004: Credentials aren't provided on The credentials for the server 1. Ensure that you
the appliance for the server OS type. OS type weren't added on the add the credentials
appliance. for the OS type of
the affected server
on the appliance.
2. You can now add
multiple server
credentials on the
appliance.
10005: Credentials provided on the The credentials provided on 1. Ensure that the
appliance for the server are invalid. the appliance aren't valid. The credentials provided
issue was encountered when on the appliance are
trying the following credentials valid and the server
on the server: is accessible by using
<FriendlyNameOfCredentials>. the credentials.
2. You can now add
multiple server
credentials on the
appliance.
3. Go back to the
appliance
configuration
manager to either
provide another set
an existing one.
(Find the friendly
name of the
possible causes.)
Learn more about

how to remediate
the issue.
Error Cause Action
Linux. supported.
<GuestOSName>
operating system
isn't supported
currently.
10007: Unable to process the discovered An error occurred when Submit a Microsoft
metadata from the server. parsing the contents of the file support case to help
containing the discovered troubleshoot this
metadata. issue.
creation of file in the required permission on the
folder. The issue was folder <folder
encountered when trying the path/folder name>
following credentials on the in the server.
server: 2. If the credentials
the required
permissions, either
provide another set
an existing one.
(Find the friendly
name of the
possible causes.)
Error Cause Action
10009: Unable to write the discovered The role associated to the 1. Check if the
metadata in the file on the server. credentials provided on the credentials provided
on-premises is restricting have write file
writing in the file on the server. permission on the
The issue was encountered folder <folder
when trying the following path/folder name>
credentials on the server: in the server.
<FriendlyNameOfCredentials>. 2. If the credentials
provided on the
the required
permissions, either
provide another set
an existing one.
(Find the friendly
name of the
possible causes.)
10010: Unable to discover because the The package containing the Ensure that the
command- %CommandName; required command %CommandName; package that
to collect some metadata is missing on isn't installed on the server. contains the
the server. command
%CommandName; is
installed on the
server.
10011: The credentials provided on the The interactive login and Use the resolution
appliance were used to log in and log logout forces the registry keys methods
out for an interactive session. to be unloaded in the profile documented on this
of the account being used. website.
This condition makes the keys
unavailable for future use.
Error Cause Action
10012: Credentials haven't been Either no credentials have 1. Ensure that the
provided on the appliance for the been provided for the server credentials are
server. or you've provided domain provided on the
credentials with an incorrect appliance for the
domain name on the server and the server
appliance. Learn more about is accessible by using
the cause of this error. the credentials.
2. You can now add
multiple credentials
on the appliance for
servers. Go back to
the appliance
configuration
manager to provide
credentials for the
server.
Error 970:
DependencyMapInsufficientPrivilegesException
Cause
The error usually appears for Linux servers when you haven't provided credentials with
the required privileges on the appliance.
Remediation
You have two options:
Ensure that you've provided a root user account.

Ensure that an account has these permissions on /bin/netstat and /bin/ls files:
CAP_DAC_READ_SEARCH
CAP_SYS_PTRACE
To check if the user account provided on the appliance has the required privileges:
1. Log in to the server where you encountered this error with the same user account
as mentioned in the error message.
2. Run the following commands in Azure Shell. You'll get errors if you don't have the
required privileges for agentless dependency analysis.
ps -o pid,cmd | grep -v ]$
netstat -atnp | awk '{print $4,$5,$7}'
3. Set the required permissions on /bin/netstat and /bin/ls files by running the
following commands:

4. You can validate if the preceding commands assigned the required permissions to
the user account or not.
getcap /usr/bin/ls
getcap /usr/bin/netstat
5. Rerun the commands provided in step 2 to get a successful output.
Error 9014:
HTTPGetRequestToRetrieveFileFailed
Cause
The issue happens when the VMware discovery agent in appliance tries to download the
output file containing dependency data from the server file system through the ESXi
host on which the server is hosted.
Remediation
You can test TCP connectivity to the ESXi host (name provided in the error message)
on port 443 (required to be open on ESXi hosts to pull dependency data) from the
appliance. Open PowerShell on the appliance server and run the following
command:
Test -NetConnection -ComputeName <Ip address of the ESXi host> -Port
443
If the command returns successful connectivity, go to the Azure Migrate project >
Discovery and assessment > Overview > Manage > Appliances, select the
appliance name, and select Refresh services.
Error 9018: PowerShellNotFound
Cause
The error usually appears for servers running Windows Server 2008 or lower.
Remediation
Install the required PowerShell version (2.0 or later) at this location on the server:
($SYSTEMROOT)\System32\WindowsPowershell\v1.0\powershell.exe. Learn more about
how to install PowerShell in Windows Server.
After you install the required PowerShell version, verify if the error was resolved by
Error 9022: GetWMIObjectAccessDenied
Remediation
Make sure that the user account provided in the appliance has access to the WMI
namespace and subnamespaces. To set the access:
1. Go to the server that's reporting this error.

wmimgmt.msc in the Open text box, and select Enter.
3. The wmimgmt console opens where you can find WMI Control (Local) in the left
pane. Right-click it, and select Properties from the menu.
5. On the Securities tab, select Security to open the Security for ROOT dialog.
6. Select Advanced to open the Advanced Security Settings for Root dialog.
7. Select Add to open the Permission Entry for Root dialog.
8. Click Select a principal to open the Select Users, Computers, Service Accounts, or
Groups dialog.
9. Select the usernames or groups you want to grant access to the WMI, and select
OK.
10. Ensure you grant execute permissions, and select This namespace and
subnamespaces in the Applies to dropdown list.
11. Select Apply to save the settings and close all dialogs.
After you get the required access, verify if the error was resolved by following the steps
on this website.
Error 9032: InvalidRequest
Cause
There can be multiple reasons for this issue. One reason is when the username provided
(server credentials) on the appliance configuration manager has invalid XML characters.
Invalid characters cause an error in parsing the SOAP request.
Remediation
Make sure the username of the server credentials doesn't have invalid XML
characters and is in the username@domain.com format. This format is popularly
known as the UPN format.
After you edit the credentials on the appliance, verify if the error was resolved by
Error 10002: ScriptExecutionTimedOutOnVm
Cause
This error occurs when the server is slow or unresponsive and the script executed
to pull the dependency data starts timing out.
After the discovery agent encounters this error on the server, the appliance doesn't
attempt agentless dependency analysis on the server thereafter to avoid
overloading the unresponsive server.
You'll continue to see the error until you check the issue with the server and restart
the discovery service.
Remediation
1. Log in to the server that's encountering this error.
2. Run the following commands on PowerShell:
Get-WMIObject win32_operatingsystem;
Get-WindowsFeature | Where-Object {$_.InstallState -eq 'Installed' -or
($_.InstallState -eq $null -and $_.Installed -eq 'True')};
Get-WmiObject Win32_Process;
netstat -ano -p tcp | select -Skip 4;
3. If commands output the result in a few seconds, go to the Azure Migrate project
> Discovery and assessment > Overview > Manage > Appliances, select the
appliance name, and select Refresh services to restart the discovery service.
4. If the commands are timing out without giving any output, you need to:
Figure out which processes are consuming high CPU or memory on the
server.
Try to provide more cores or memory to that server and run the commands
again.
Error 10005: GuestCredentialNotValid
Remediation
Ensure the validity of credentials (friendly name provided in the error) by selecting
Revalidate credentials on the appliance configuration manager.
Ensure that you can log in to the affected server by using the same credential
provided in the appliance.
You can try using another user account (for the same domain, in case the server is
domain joined) for that server instead of the administrator account.
The issue can happen when Global Catalog <-> Domain Controller communication
is broken. Check for this problem by creating a new user account in the domain
controller and providing the same in the appliance. You might also need to restart
the domain controller.
Error 10012: CredentialNotProvided
Cause
This error occurs when you've provided a domain credential with the wrong domain
name on the appliance configuration manager. For example, if you've provided domain
credentials with the username user@abc.com but provided the domain name as
def.com, those credentials won't be attempted if the server is connected to def.com and
you'll get this error message.
Remediation
Go to the appliance configuration manager to add a server credential or edit an
existing one as explained in the cause.
Mitigation verification
After you use the mitigation steps for the preceding errors, verify if the mitigation
worked by running a few PowerCLI commands from the appliance server. If the
commands succeed, it means that the issue is resolved. Otherwise, check and follow the
remediation steps again.
For VMware VMs (using VMware pipe)

1. Run the following commands to set up PowerCLI on the appliance server:
Install-Module -Name VMware.PowerCLI -AllowClobber

Set-PowerCLIConfiguration -InvalidCertificateAction Ignore
2. Connect to the vCenter server from the appliance by providing the vCenter server
IP address in the command and credentials in the prompt:
Connect-VIServer -Server <IPAddress of vCenter Server>

3. Connect to the target server from the appliance by providing the server name and
server credentials, as provided on the appliance:
$vm = get-VM <VMName>

$credential = Get-Credential
4. For agentless dependency analysis, run the following commands to see if you get a
successful output.
Invoke-VMScript -VM $vm -ScriptText "powershell.exe 'Get-WmiObject

Win32_Process'" -GuestCredential $credential
Invoke-VMScript -VM $vm -ScriptText "powershell.exe 'netstat -ano

-p tcp'" -GuestCredential $credential
For Linux servers:
Invoke-VMScript -VM $vm -ScriptText "ps -o pid,cmd | grep -v ]$" -

GuestCredential $credential
Invoke-VMScript -VM $vm -ScriptText "netstat -atnp | awk '{print

$4,$5,$7}'" -GuestCredential $credential
For Hyper-V VMs and physical servers (using direct

connect pipe)
1. Connect to Windows server by running the command:
$Server = New-PSSession –ComputerName <IPAddress of Server> -Credential

<user_name>
and input the server credentials in the prompt.

2. Run the following commands to validate for agentless dependency analysis to see
if you get a successful output:
Invoke-Command -Session $Server -ScriptBlock {Get-WmiObject

Win32_Process}
Invoke-Command -Session $Server -ScriptBlock {netstat -ano -p tcp}
For Linux servers:
1. Install the OpenSSH client
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0
2. Install the OpenSSH server
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
3. Start and configure OpenSSH Server
Start-Service sshd
Set-Service -Name sshd -StartupType 'Automatic'
4. Connect to OpenSSH Server
ssh username@servername
5. Run the following commands to validate for agentless dependency analysis to see
if you get a successful output:
ps -o pid,cmd | grep -v ]$
netstat -atnp | awk '{print $4,$5,$7}'
After you verify that the mitigation worked, go to the Azure Migrate project >
Discovery and assessment > Overview > Manage > Appliances, select the appliance
name, and select Refresh services to start a fresh discovery cycle.
My Log Analytics workspace isn't listed when
you try to configure the workspace in Azure
Migrate for agent-based dependency analysis
Azure Migrate currently supports creation of OMS workspace in East US, Southeast Asia,
and West Europe regions. If the workspace is created outside of Azure Migrate in any
other region, it currently can't be associated with a project.
Agent-based dependency visualization in Azure

Government
Agent-based dependency analysis isn't supported in Azure Government. Use agentless
dependency analysis, which is only available for VMware servers.
Agent-based dependencies don't show after

agent installation
After you've installed the dependency visualization agents on on-premises VMs, Azure
Migrate typically takes 15 to 30 minutes to display the dependencies in the portal. If
you've waited for more than 30 minutes, make sure that the Microsoft Monitoring Agent
(MMA) can connect to the Log Analytics workspace.
For Windows VMs:
1. In the Control Panel, start MMA.
2. In Microsoft Monitoring Agent properties > Azure Log Analytics (OMS), make
sure that the Status for the workspace is green.
3. If the status isn't green, try removing the workspace and adding it again to MMA.
For Linux VMs, make sure that the installation commands for MMA and the dependency
agent succeeded. Refer to more troubleshooting guidance on this website.
Supported operating systems for agent-based

dependency analysis
MMS agent: The supported Windows and Linux operating systems.
Dependency agent: The supported Windows and Linux operating systems.
Visualize dependencies for >1 hour with agent-

based dependency analysis
With agent-based dependency analysis, although Azure Migrate allows you to go back
to a particular date in the last month, the maximum duration for which you can visualize
the dependencies is one hour. For example, you can use the time duration functionality
in the dependency map to view dependencies for yesterday, but you can view them for
a one-hour period only. You can use Azure Monitor logs to query the dependency data
over a longer duration.
Visualize dependencies for >10 servers with
agent-based dependency analysis
In Azure Migrate, with agent-based dependency analysis, you can visualize
dependencies for groups with up to 10 VMs. For larger groups, split the VMs into
smaller groups to visualize dependencies.
Servers show "Install agent" for agent-based

dependency analysis
After you migrate servers with dependency visualization enabled to Azure, servers might
show the Install agent action instead of View dependencies because of the following
behavior:
After migration to Azure, on-premises servers are turned off and equivalent VMs
are spun up in Azure. These servers acquire a different MAC address.
Servers might also have a different IP address, based on whether you've retained
the on-premises IP address or not.
If both MAC and IP addresses are different from on-premises, Azure Migrate
doesn't associate the on-premises servers with any Service Map dependency data.
In this case, it shows the option to install the agent rather than to view
dependencies.
After a test migration to Azure, on-premises servers remain turned on as expected.
Equivalent servers spun up in Azure acquire different MAC addresses and might
acquire different IP addresses. Unless you block outgoing Azure Monitor log traffic
from these servers, Azure Migrate won't associate the on-premises servers with
any Service Map dependency data. In this case, it shows the option to install
agents rather than to view dependencies.
Capture network traffic

To collect network traffic logs:
1. Sign in to the Azure portal .

2. Select F12 to start Developer Tools. If needed, clear the Clear entries on navigation
setting.
3. Select the Network tab, and start capturing network traffic:
In Chrome, select Preserve log. The recording should start automatically. A

red circle indicates that traffic is being captured. If the red circle doesn't
appear, select the black circle to start.
In Microsoft Edge and Internet Explorer, the recording should start
automatically. If it doesn't, select the green play button.
4. Try to reproduce the error.

5. After you encounter the error while recording, stop recording, and save a copy of
the recorded activity:
In Chrome, right-click and select Save as HAR with content. This action
compresses and exports the logs as an HTTP Archive (har) file.
In Microsoft Edge or Internet Explorer, select the Export captured traffic
option. This action compresses and exports the log.
6. Select the Console tab to check for any warnings or errors. To save the console log:
In Chrome, right-click anywhere in the console log. Select Save as to export,

and zip the log.
In Microsoft Edge or Internet Explorer, right-click the errors and select Copy
all.
7. Close Developer Tools.
Next steps
Create or customize an assessment.
 Documentation
Migrate


assessment

common errors.
Set up a scale-out process server during disaster recovery of VMware VMs and
physical servers with Azure Site Recovery - Azure Site Recovery
This article describes how to set up scale-out process server during disaster recovery of VMware VMs
and physical servers.
Troubleshoot slow replication or stuck migration in agentless VMware migration -

Azure Migrate
Learn how to troubleshoot issues with slow replication or stuck migration for VMware.

Show 5 more
Troubleshoot assessment
Article • 05/09/2023
This article helps you troubleshoot issues with assessment and dependency visualization
with Azure Migrate: Discovery and assessment.
Azure VM assessment readiness issues

This table lists help for fixing the following assessment readiness issues.
Issue Fix
Unsupported boot Azure does not support UEFI boot type for VMs with the Windows Server
type 2003/Windows Server 2003 R2/Windows Server 2008/Windows Server
2008 R2 operating systems. Check the list of operating systems that
support UEFI-based machines here.
Conditionally The operating system has passed its end-of-support date and needs a
supported Windows Custom Support Agreement for support in Azure. Consider upgrading
operating system before you migrate to Azure. Review information about preparing servers
running Windows Server 2003 for migration to Azure.
Unsupported Azure supports only selected Windows OS versions. Consider upgrading

Windows operating the server before you migrate to Azure.
system
Conditionally Azure endorses only selected Linux OS versions. Consider upgrading the
endorsed Linux OS server before you migrate to Azure. Learn more.
Unendorsed Linux The server might start in Azure, but Azure provides no operating system
OS support. Consider upgrading to an endorsed Linux version before you
migrate to Azure.
Unknown operating The operating system of the VM was specified as Other in vCenter Server
system or could not be identified as a known OS in Azure Migrate. This behavior
blocks Azure Migrate from verifying the Azure readiness of the VM.
Ensure that the operating system is supported by Azure before you
migrate the server.
Unsupported bit VMs with a 32-bit operating system might boot in Azure, but we
version recommend that you upgrade to 64-bit before you migrate to Azure.
Requires a Microsoft The server is running a Windows client operating system, which is
Visual Studio supported only through a Visual Studio subscription.
subscription
Issue Fix
VM not found for The storage performance (input/output operations per second (IOPS) and
the required storage throughput) required for the server exceeds Azure VM support. Reduce
performance storage requirements for the server before migration.
VM not found for The network performance (in/out) required for the server exceeds Azure
the required network VM support. Reduce the networking requirements for the server.
performance
VM not found in the Use a different target location before migration.

specified location
One or more One or more disks attached to the VM don't meet Azure requirements.
unsuitable disks
Azure Migrate: Discovery and assessment assesses the disks based on the
disk limits for Ultra disks (64 TB).
For each disk attached to the VM, make sure that the size of the disk is <
64 TB (supported by Ultra SSD disks).
If it isn't, reduce the disk size before you migrate to Azure, or use multiple
disks in Azure and stripe them together to get higher storage limits. Make
sure that the performance (IOPS and throughput) needed by each disk is
supported by Azure managed virtual machine disks.
One or more Remove unused network adapters from the server before migration.
unsuitable network
adapters
Disk count exceeds Remove unused disks from the server before migration.
limit
Disk size exceeds Azure Migrate: Discovery and assessment supports disks with up to 64 TB
limit size (Ultra disks). Shrink disks to less than 64 TB before migration, or use
multiple disks in Azure and stripe them together to get higher storage
limits.
Disk unavailable in Make sure the disk is in your target location before you migrate.
the specified
location
Disk unavailable for The disk should use the redundancy storage type defined in the
the specified assessment settings (LRS by default).
redundancy
Couldn't determine Try creating a new assessment for the group.

disk suitability
because of an
internal error
Issue Fix
VM with required Azure couldn't find a suitable VM type. Reduce the memory and number
cores and memory of cores of the on-premises server before you migrate.
not found

VM suitability
because of an
internal error

suitability for one or
more disks because
of an internal error

suitability for one or
more network
adapters because of
an internal error
No VM size found Server marked not suitable because the VM size wasn't found for the
for offer currency selected combination of RI, offer, and currency. Edit the assessment
Reserved Instance properties to choose the valid combinations and recalculate the
(RI) assessment.
Azure VMware Solution (AVS) assessment

readiness issues
This table lists help for fixing the following assessment readiness issues.
Issue Fix
Unsupported Only applicable to Azure VMware Solution assessments. Azure VMware Solution
IPv6 doesn't support IPv6 internet addresses. Contact the Azure VMware Solution team
for remediation guidance if your server is detected with IPv6.
Unsupported Support for certain Operating System versions has been deprecated by VMware
OS and the assessment recommends you to upgrade the operating system before
migrating to Azure VMware Solution. Learn more .
Suggested migration tool in an import-based

Azure VMware Solution assessment is unknown
For servers imported via a CSV file, the default migration tool in an Azure VMware
Solution assessment is unknown. For servers in a VMware environment, use the VMware
Hybrid Cloud Extension (HCX) solution. Learn more.
Linux VMs are "conditionally ready" in an Azure

VM assessment
In the case of VMware and Hyper-V VMs, an Azure VM assessment marks Linux VMs as
conditionally ready because of a known gap.
The gap prevents it from detecting the minor version of the Linux OS installed on
the on-premises VMs.
For example, for RHEL 6.10, currently an Azure VM assessment detects only RHEL 6
as the OS version. This behavior occurs because the vCenter Server and the Hyper-
V host don't provide the kernel version for Linux VM operating systems.
Since Azure endorses only specific versions of Linux, the Linux VMs are currently
marked as conditionally ready in an Azure VM assessment.
You can determine whether the Linux OS running on the on-premises VM is
endorsed in Azure by reviewing Azure Linux support.
After you've verified the endorsed distribution, you can ignore this warning.
This gap can be addressed by enabling application discovery on the VMware VMs. An
Azure VM assessment uses the operating system detected from the VM by using the
guest credentials provided. This Operating System data identifies the right OS
information in the case of both Windows and Linux VMs.
Operating system version not available

For physical servers, the operating system minor version information should be
available. If it isn't available, contact Microsoft Support. For servers in a VMware
environment, Azure Migrate uses the operating system information specified for the VM
in the vCenter Server. But vCenter Server doesn't provide the minor version for
operating systems. To discover the minor version, set up application discovery. For
Hyper-V VMs, operating system minor version discovery isn't supported.
Azure SKUs bigger than on-premises in an

Azure VM assessment
An Azure VM assessment might recommend Azure VM SKUs with more cores and
memory than the current on-premises allocation based on the type of assessment:
The VM SKU recommendation depends on the assessment properties.

The recommendation is affected by the type of assessment you perform in an
Azure VM assessment. The two types are Performance-based or As on-premises.
For performance-based assessments, the Azure VM assessment considers the
utilization data of the on-premises VMs (CPU, memory, disk, and network
utilization) to determine the right target VM SKU for your on-premises VMs. It also
adds a comfort factor when determining effective utilization.
For on-premises sizing, performance data isn't considered, and the target SKU is
recommended based on on-premises allocation.
Let's look at an example recommendation:
We have an on-premises VM with 4 cores and 8 GB of memory, with 50% CPU utilization
and 50% memory utilization, and a specified comfort factor of 1.3.
If the assessment is As on-premises, an Azure VM SKU with 4 cores and 8 GB of

memory is recommended.
If the assessment is Performance-based, based on effective CPU and memory
utilization (50% of 4 cores * 1.3 = 2.6 cores and 50% of 8 GB memory * 1.3 = 5.2
GB memory), the cheapest VM SKU of 4 cores (nearest supported core count) and
8 GB of memory (nearest supported memory size) is recommended.
Learn more about assessment sizing.
Why is the recommended Azure disk SKU

bigger than on-premises in an Azure VM
assessment?
Azure VM assessment might recommend a bigger disk based on the type of assessment:
Disk sizing depends on two assessment properties: sizing criteria and storage type.
If the sizing criteria is Performance-based and the storage type is set to
Automatic, the IOPS and throughput values of the disk are considered when
identifying the target disk type (Standard HDD, Standard SSD, Premium, or Ultra
disk). A disk SKU from the disk type is then recommended, and the
recommendation considers the size requirements of the on-premises disk.
If the sizing criteria is Performance-based and the storage type is Premium, a
premium disk SKU in Azure is recommended based on the IOPS, throughput, and
size requirements of the on-premises disk. The same logic is used to perform disk
sizing when the sizing criteria is As on-premises and the storage type is Standard
HDD, Standard SSD, Premium, or Ultra disk.
For example, say you have an on-premises disk with 32 GB of memory, but the
aggregated read and write IOPS for the disk is 800 IOPS. The Azure VM assessment
recommends a premium disk because of the higher IOPS requirements. It also
recommends a disk SKU that can support the required IOPS and size. The nearest match
in this example would be P15 (256 GB, 1100 IOPS). Even though the size required by the
on-premises disk was 32 GB, the Azure VM assessment recommended a larger disk
because of the high IOPS requirement of the on-premises disk.
Why is performance data missing for some or

all VMs in my assessment report?
For Performance-based assessment, the assessment report export says
'PercentageOfCoresUtilizedMissing' or 'PercentageOfMemoryUtilizedMissing' when the
Azure Migrate appliance can't collect performance data for the on-premises VMs. Make
sure to check:
If the VMs are powered on for the duration for which you're creating the
assessment.
If only memory counters are missing and you're trying to assess Hyper-V VMs,
check if you have dynamic memory enabled on these VMs. Because of a known
issue, currently the Azure Migrate appliance can't collect memory utilization for
such VMs.
If all of the performance counters are missing, ensure the port access requirements
for assessment are met. Learn more about the port access requirements for
VMware, Hyper-V, and physical assessments. If any of the performance counters
are missing, Azure Migrate: Discovery and assessment falls back to the allocated
cores/memory on-premises and recommends a VM size accordingly.

all servers in my Azure VM or Azure VMware
Solution assessment report?
For Performance-based assessment, the assessment report export says
PercentageOfCoresUtilizedMissing or PercentageOfMemoryUtilizedMissing when the
Azure Migrate appliance can't collect performance data for the on-premises servers.
Make sure to check:
If the servers are powered on for the duration for which you're creating the
assessment.
If only memory counters are missing and you're trying to assess servers in a Hyper-
V environment. In this scenario, enable dynamic memory on the servers and
recalculate the assessment to reflect the latest changes. The appliance can collect
memory utilization values for servers in a Hyper-V environment only when the
server has dynamic memory enabled.
７ Note
If any of the performance counters are missing, Azure Migrate: Discovery and
assessment falls back to the allocated cores/memory on-premises and
recommends a VM size accordingly.

all SQL instances or databases in my Azure SQL
assessment?
To ensure performance data is collected, make sure to check:
If the SQL servers are powered on for the duration for which you're creating the
assessment.
If the connection status of the SQL agent in Azure Migrate is Connected, and also
check the last heartbeat.
If the Azure Migrate connection status for all SQL instances is Connected in the
discovered SQL instance pane.
on port 443 (HTTPS) are allowed.
If any of the performance counters are missing, the Azure SQL assessment recommends
the smallest Azure SQL configuration for that instance or database.
Why is the confidence rating of my assessment

low?
The confidence rating is calculated for Performance-based assessments based on the
percentage of available data points needed to compute the assessment. An assessment
could get a low confidence rating for the following reasons:
assessment. For example, if you're creating an assessment with performance
discovery for all the data points to get collected. If you can't wait for the duration,
change the performance duration to a shorter period and recalculate the
assessment.
The assessment isn't able to collect the performance data for some or all the
servers in the assessment period. For a high confidence rating, ensure that:
Servers are powered on for the duration of the assessment.
Outbound connections on ports 443 are allowed.
For Hyper-V Servers, dynamic memory is enabled.
The connection status of agents in Azure Migrate is Connected. Also check the
last heartbeat.
instances is Connected in the discovered SQL instance pane.
For Azure VM and Azure VMware Solution assessments, few servers were created
after discovery had started. For example, say you're creating an assessment for the
performance history of the past month, but a few servers were created in the
environment only a week ago. In this case, the performance data for the new
servers won't be available for the entire duration and the confidence rating would
be low. Learn more.
discovery had started. For example, say you're creating an assessment for the
performance history of the past month, but a few SQL instances or databases were
the new servers won't be available for the entire duration and the confidence
rating would be low. Learn more.
Why is my RAM utilization greater than 100%?

By design, in Hyper-V if maximum memory provisioned is less than what is required by
the VM, the assessment will show memory utilization to be more than 100%.
Is the operating system license included in an
Azure VM assessment?
An Azure VM assessment currently considers the operating system license cost only for
Windows servers. License costs for Linux servers aren't currently considered.
How does performance-based sizing work in an

Azure VM assessment?
An Azure VM assessment continuously collects performance data of on-premises servers
and uses it to recommend the VM SKU and disk SKU in Azure. Learn more about how
performance-based data is collected.
Can I migrate my disks to an Ultra disk by using

Azure Migrate?
No. Currently, both Azure Migrate and Azure Site Recovery don't support migration to
Ultra disks. Learn more about deploying an Ultra disk.
Why are the provisioned IOPS and throughput

in my Ultra disk more than my on-premises
IOPS and throughput?
As per the official pricing page , Ultra disk is billed based on the provisioned size,
provisioned IOPS, and provisioned throughput. For example, if you provisioned a 200-
GiB Ultra disk with 20,000 IOPS and 1,000 MB/second and deleted it after 20 hours, it
will map to the disk size offer of 256 GiB. You'll be billed for 256 GiB, 20,000 IOPS, and
1,000 MB/second for 20 hours.
IOPS to be provisioned = (Throughput discovered) * 1024/256
Does the Ultra disk recommendation consider

latency?
No, currently only disk size, total throughput, and total IOPS are used for sizing and
costing.
I can see M series supports Ultra disk, but in
my assessment where Ultra disk was
recommended, it says "No VM found for this
location"
This result is possible because not all VM sizes that support Ultra disks are present in all
Ultra disk supported regions. Change the target assessment region to get the VM size
for this server.
Why is my assessment showing a warning that

it was created with an invalid offer?
Your assessment was created with an offer that is no longer valid and hence, the Edit
and Recalculate buttons are disabled. You can create a new assessment with any of the
valid offers - Pay as you go, Pay as you go Dev/Test, and Enterprise Agreement. You can
also use the Discount(%) field to specify any custom discount on top of the Azure offer.
Learn more.

it was created with a target Azure location that
has been deprecated?
Your assessment was created with an Azure region that has been deprecated and hence
the Edit and Recalculate buttons are disabled. You can create a new assessment with
any of the valid target locations. Learn more.

it was created with an invalid combination of
Reserved Instances, VM uptime, and Discount
(%)?
When you select Reserved Instances, the Discount (%) and VM uptime properties aren't
applicable. As your assessment was created with an invalid combination of these
properties, the Edit and Recalculate buttons are disabled. Create a new assessment.
Learn more.
Why are some of my assessments marked as
"to be upgraded to latest assessment version"?
Recalculate your assessment to view the upgraded Azure SQL assessment experience to
identify the ideal migration target for your SQL deployments across Azure SQL Managed
Instances, SQL Server on Azure VM, and Azure SQL DB:
We recommended migrating instances to SQL Server on Azure VM as per the Azure

best practices.
Right sized Lift and Shift - Server to SQL Server on Azure VM. We recommend this
when SQL Server credentials are not available.
Enhanced user-experience that covers readiness and cost estimates for multiple
migration targets for SQL deployments in one assessment.
We recommend that you export your existing assessment before recalculating.
I don't see performance data for some network

adapters on my physical servers
This issue can happen if the physical server has Hyper-V virtualization enabled. On these
servers, because of a product gap, Azure Migrate currently discovers both the physical
and virtual network adapters. The network throughput is captured only on the virtual
network adapters discovered.
The recommended Azure VM SKU for my

physical server is oversized
servers, Azure Migrate currently discovers both the physical and virtual network
adapters. As a result, the number of network adapters discovered is higher than the
actual number. The Azure VM assessment picks an Azure VM that can support the
required number of network adapters, which can potentially result in an oversized VM.
Learn more about the impact of the number of network adapters on sizing. This product
gap will be addressed going forward.
The readiness category is marked "Not ready"

for my physical server
The readiness category might be incorrectly marked as Not ready in the case of a
physical server that has Hyper-V virtualization enabled. On these servers, because of a
product gap, Azure Migrate currently discovers both the physical and virtual adapters.
As a result, the number of network adapters discovered is higher than the actual
number. In both As on-premises and Performance-based assessments, the Azure VM
assessment picks an Azure VM that can support the required number of network
adapters. If the number of network adapters is discovered to be higher than 32, the
maximum number of NICs supported on Azure VMs, the server will be marked Not
ready. Learn more about the impact of number of NICs on sizing.
The number of discovered NICs is higher than

actual for physical servers
servers, Azure Migrate currently discovers both the physical and virtual adapters. As a
result, the number of NICs discovered is higher than the actual number.
Capture network traffic

To collect network traffic logs:
1. Sign in to the Azure portal .

2. Select F12 to start Developer Tools. If needed, clear the Clear entries on navigation
setting.
3. Select the Network tab, and start capturing network traffic:
In Chrome, select Preserve log. The recording should start automatically. A

red circle indicates that traffic is being captured. If the red circle doesn't
appear, select the black circle to start.
In Microsoft Edge and Internet Explorer, recording should start automatically.
If it doesn't, select the green play button.
4. Try to reproduce the error.

5. After you've encountered the error while recording, stop recording and save a
copy of the recorded activity:
In Chrome, right-click and select Save as HAR with content. This action
compresses and exports the logs as a .har file.
In Microsoft Edge or Internet Explorer, select the Export captured traffic
option. This action compresses and exports the log.
6. Select the Console tab to check for any warnings or errors. To save the console log:
In Chrome, right-click anywhere in the console log. Select Save as to export,

and zip the log.
In Microsoft Edge or Internet Explorer, right-click the errors and select Copy
all.
7. Close Developer Tools.
Where is the Operating System data in my

assessment discovered from?
For VMware VMs, by default, it's the operating system data provided by the
vCenter Server.
For VMware Linux VMs, if application discovery is enabled, the OS details are
fetched from the guest VM. To check which OS details are in the assessment, go
to the Discovered servers view, and hover over the value in the Operating
system column. In the text that pops up, you'd be able to see whether the OS
data you see is gathered from the vCenter Server or from the guest VM by
using the VM credentials.
For Windows VMs, the operating system details are always fetched from the
vCenter Server.
For Hyper-V VMs, the operating system data is gathered from the Hyper-V host.
For physical servers, it is fetched from the server.
Common web apps discovery errors

Azure Migrate provides options to assess discovered ASP.NET web apps for migration to
Azure App Service by using the Azure Migrate: Discovery and assessment tool. Refer to
the assessment tutorial to get started.
Typical App Service assessment errors are summarized in the table.
Error Cause Recommended action
Application The IIS site is using Azure App Service doesn't support more than one
pool check the following application pool configuration per App Service
application pools: {0}. application. Move the workloads to a single application
pool and remove other application pools.
Application The site's application App Service doesn't support using the LocalSystem or
pool identity pool is running as an SpecificUser application pool identity types. Set the
check unsupported user application pool to run as ApplicationPoolIdentity.
identity type: {0}.
Authorization The following App Service supported authentication types and

check unsupported configuration are different from on-premises IIS.
authentication types Disable the unsupported authentication types on the
were found: {0}. site. After the migration is complete, it will be possible
to configure the site by using one of the App Service
supported authentication types.
Authorization Unable to determine Unable to determine authentication types. Fix all

check enabled configuration errors and confirm that all site content
unknown authentication types locations are accessible to the administrators group.
for all of the site
configuration.
Configuration The following Migration readiness can't be determined without

error check configuration errors reading all applicable configuration. Fix all
were found: {0}. configuration errors. Make sure configuration is valid
and accessible.
Content size The site content For successful migration, site content should be less
check appears to be greater than 2 GB. Evaluate if the site could switch to using
than the maximum non-file-system-based storage options for static
allowed of 2 GB for content, such as Azure Storage.
successful migration.
Content size File content size Content must be accessible to migrate the site. Confirm
check couldn't be that the site isn't using UNC shares for content and that
unknown determined, which all site content locations are accessible to the
usually indicates an administrators group.
access issue.
Global The following App Service supports limited global modules. Remove
module check unsupported global the unsupported modules from the GlobalModules
modules were section, along with all associated configuration.
detected: {0}.
ISAPI filter The following Automatic configuration of custom ISAPI filters isn't
check unsupported ISAPI supported. Remove the unsupported ISAPI filters.
filters were detected:
{0}.
ISAPI filter Unable to determine Automatic configuration of custom ISAPI filters isn't
check ISAPI filters present supported. Fix all configuration errors and confirm that
unknown for all of the site all site content locations are accessible to the
configuration. administrators group.
Location tag The following location The migration method doesn't support moving location
check paths were found in path configuration in applicationHost.config. Move the
the location path configuration to either the site's root
applicationHost.config web.config file or to a web.config file associated with
file: {0}. the specific application to which it applies.
Protocol Bindings were found App Service only supports the HTTP and HTTPS
check by using the following protocols. Remove the bindings with protocols that
unsupported aren't HTTP or HTTPS.
protocols: {0}.
Virtual The following virtual Migration doesn't support migrating site content
directory directories are hosted hosted on UNC shares. Move content to a local file path
check on UNC shares: {0}. or consider changing to a non-file-system-based
storage option, such as Azure Storage. If you use shared
configuration, disable shared configuration for the
server before you modify the content paths.
HTTPS The application uses More manual steps are required for HTTPS
binding check HTTPS. configuration in App Service. Other post-migration
steps are required to associate certificates with the App
Service site.
TCP port Bindings were found App Service supports only ports 80 and 443. Clients
check on the following making requests to the site should update the port in
unsupported ports: their requests to use 80 or 443.
{0}.
Framework The following Migration doesn't validate the framework for non-.NET
check non-.NET frameworks sites. App Service supports multiple frameworks, but
or unsupported .NET these have different migration options. Confirm that the
framework versions non-.NET frameworks aren't being used by the site, or
were detected as consider using an alternate migration option.
possibly in use by this
site: {0}.
Next steps
Create or customize an assessment.
Troubleshooting replication issues in
agentless VMware VM migration
Article • 04/24/2023
This article describes some common issues and specific errors that you might encounter
when you replicate on-premises VMware VMs using the Migration and modernization
agentless method.
When you replicate a VMware virtual machine using the agentless replication method,
data from the virtual machine's disks (vmdks) are replicated to replica managed disks in
your Azure subscription. When replication starts for a VM, an initial replication cycle
occurs, in which full copies of the disks are replicated. After the initial replication
completes, incremental replication cycles are scheduled periodically to transfer any
changes that have occurred since the previous replication cycle.
You may occasionally see replication cycles failing for a VM. These failures can happen
due to reasons ranging from issues in on-premises network configuration to issues at
the Azure Migrate Cloud Service backend. In this article, we will:
Show you how you can monitor replication status and resolve errors.
List some of the commonly occurring replication errors and suggest steps to
remediate them.
Monitor replication status using the Azure

portal
Use the following steps to monitor the replication status for your virtual machines:
1. Go to the Servers, databases and web apps page in Azure Migrate on the Azure
portal.
2. In the Migration and modernization tile, under Replications, select the number
next to Azure VM .
3. You'll see a list of replicating servers along with additional information such as
status, health, last sync time, etc. The Replication health column indicates the
current replication health of the VM. A Critical or Warning value typically indicates
that the previous replication cycle for the VM failed. To get more details, right-click
on the VM, and select Health error Details. The Error Details page contains
information on the error and additional details on how to troubleshoot.
4. Select Recent Events to see the previous replication cycle failures for the VM. In
the events page, look for the most recent event of type Replication cycle failed or
Replication cycle failed for disk" for the VM.
5. Select the event to understand the possible causes of the error and recommended
remediation steps. Use the information provided to troubleshoot and remediate
the error.
Common Replication Errors

This section describes some of the common errors, and how you can troubleshoot them.
Key Vault operation failed error when trying to

replicate VMs
Error: “Key Vault operation failed. Operation: Configure managed storage account, Key
Vault: Key-vault-name, Storage Account: storage account name failed with the error:”
Error: “Key Vault operation failed. Operation: Generate shared access signature
definition, Key Vault: Key-vault-name, Storage Account: storage account name failed
with the error:”
This error typically occurs because the User Access Policy for the Key Vault doesn't give
the currently logged in user the necessary permissions to configure storage accounts to
be Key Vault managed. To check for user access policy on the key vault, go to the Key
vault page on the portal for the Key vault and select Access policies.
When the portal creates the key vault, it also adds a user access policy granting the
currently logged in user permissions to configure storage accounts to be Key Vault
managed. This can fail for two reasons:
The logged in user is a remote principal on the customer's Azure tenant (CSP
subscription - and the logged in user is the partner admin). The work-around in
this case is to delete the key vault, sign out from the portal, and then sign in with a
user account from the customer's tenant (not a remote principal) and retry the
operation. The CSP partner will typically have a user account in the customers
Azure Active Directory tenant that they can use. If not, they can create a new user
account for themselves in the customers Azure Active Directory tenant, sign in to
the portal as the new user, and then retry the replicate operation. The account
used must have either Owner or Contributor+User Access Administrator
permissions granted to the account on the resource group (Migrate project
resource group).
The other case where this may happen is when one user (user1) attempted to set
up replication initially and encountered a failure, but the key vault has already
been created (and user access policy appropriately assigned to this user). Now at a
later point a different user (user2) tries to set up replication, but the Configure
Managed Storage Account or Generate SAS definition operation fails as there's no
user access policy corresponding to user2 in the key vault.
Resolution: To work around this issue, create a user access policy for user2 in the key
vault granting user2 permission to configure managed storage account and generate
SAS definitions. User2 can do this from Azure PowerShell using the below cmdlets:
$userPrincipalId = $(Get-AzureRmADUser -UserPrincipalName

"user2_email_address").Id
Set-AzureRmKeyVaultAccessPolicy -VaultName "keyvaultname" -ObjectId

$userPrincipalId -PermissionsToStorage get, list, delete, set, update,
regeneratekey, getsas, listsas, deletesas, setsas, recover, back up,
restore, purge
DisposeArtefactsTimedOut
Error ID: 181008
Error Message: VM: VMName. Error: Encountered timeout event

'DisposeArtefactsTimeout' in the state
&'['Gateway.Service.StateMachine.SnapshotReplication.SnapshotReplicationEngine+Wait
ingForArtefactsDisposalPreCycle' ('WaitingForArtefactsDisposalPreCycle')]'.
Possible Causes:
The component trying to replicate data to Azure is either down or not responding. The
possible causes include:
The gateway service running in the Azure Migrate appliance is down.

The gateway service is experiencing connectivity issues to Service Bus/Event
hubs/Appliance Storage account.
Identifying the exact cause for DisposeArtefactsTimedOut and the corresponding

resolution:
1. Ensure that the Azure Migrate appliance is up and running.
2. Check if the gateway service is running on the appliance:
a. Sign in to the Azure Migrate appliance using remote desktop.
b. Open the Microsoft services MMC snap-in (run > services.msc), and check if the
Microsoft Azure Gateway Service is running. If the service is stopped or not
running, start the service. Alternatively, you can open command prompt or
PowerShell and enter 'Net Start asrgwy'.
3. Check for connectivity issues between Azure Migrate appliance and Appliance
Storage Account:
Run the following command after downloading azcopy in the Azure Migrate
appliance:
_azcopy bench https://[account].blob.core.windows.net/[container]?SAS_

Steps to run the performance benchmark test:
a. Download azcopy.
b. Look for the appliance Storage Account in the Resource Group. The Storage
Account has a name that resembles migrategwsa**********. This is the value of
parameter [account] in the above command.
c. Search for your storage account in the Azure portal. Ensure that the subscription
you use to search is the same subscription (target subscription) in which the
storage account is created. Go to Containers in the Blob Service section. Select
+Container and create a Container. Retain Public Access Level to the default
selected value.
d. Go to Settings > Shared Access Signature and select Container in Allowed

Resource Type.
e. Select Generate SAS and connection string and copy the SAS token. If you're
using PowerShell, ensure you enclose the URL with single quotation marks (' ').
f. Execute the above command in Command Prompt by replacing account,

container, SAS with the values obtained in steps b, c, and e respectively.
Alternatively, download the Azure Storage Explore on to the appliance and try to
upload 10 blobs of ~64 MB into the storage accounts. If there's no issue, the
upload should be successful.
Resolution: If this test fails, there's a networking issue. Engage your local
networking team to check connectivity issues. Typically, there can be some firewall
settings that are causing the failures.
4. Check for connectivity issues between Azure Migrate appliance and Service Bus:
７ Note
This is applicable only for the projects that are set up with public endpoint.
A Service bus refers to the ServiceBusNamespace type resource in the
resource group for a Migrate project. The name of the Service Bus is of the
format migratelsa(keyvaultsuffix). The Migrate key vault suffix is available in
the gateway.json file on the appliance.
For example, if the gateway.json contains:
"AzureKeyVaultArmId":
"/subscriptions//resourceGroups//providers/Microsoft.KeyVault/vaults/migratekv
1329610309",
the service bus namespace resource will be migratelsa1329610309.
This test checks if the Azure Migrate appliance can communicate to the Azure
Migrate Cloud Service backend. The appliance communicates to the service
backend through Service Bus and Event Hubs message queues. To validate
connectivity from the appliance to the Service Bus, download the Service Bus
Explorer, try to connect to the appliance Service Bus and perform the send
message/receive message operations. If there's no issue, this should be successful.
Steps to run the test:

a. Copy the connection string from the Service Bus that got created in the Migrate
Project.
b. Open the Service Bus Explorer.
c. Go to File then Connect.
d. Paste the connection string and select Connect.
e. This will open Service Bus Name Space.
f. Select Snapshot Manager. Right-click on Snapshot Manager, select Receive
Messages > peek, and select OK.
g. If the connection is successful, you'll see "[x] messages received" on the console
output. If the connection isn't successful, you'll see a message stating that the
connection failed.
5. Connectivity issues between Azure Migrate appliance and Azure Key Vault:
This test checks for connectivity issues between the Azure Migrate appliance and
the Azure Key Vault. The Key Vault is used to manage Storage Account access used
for replication.
Steps to check connectivity:
a. Fetch the Key Vault URI from the list of resources in the Resource Group
corresponding to Azure Migrate Project.
b. Open PowerShell in the Azure Migrate appliance and run the following
command:
_test-netconnection Key Vault URI -P 443_

This command will attempt a TCP connection and will return an output.
In the output, check the field "TcpTestSucceeded". If the value is "True", there's
no connectivity issue between the Azure Migrate Appliance and the Azure
Key Vault. If the value is "False", there's a connectivity issue.
Resolution: If this test fails, there's a connectivity issue between the Azure Migrate
appliance and the Azure Key Vault. Engage your local networking team to check
connectivity issues. Typically, there can be some firewall settings that are causing
the failures.
DiskUploadTimedOut
Error ID: 1011
Error Message: The upload of data for disk DiskPath, DiskId of virtual machine VMName;
VMId didn't complete within the expected time.
This error typically indicates either that the Azure Migrate appliance performing the
replication is unable to connect to the Azure Cloud Services, or that replication is
progressing slowly causing the replication cycle to time out.
The possible causes include:
The Azure Migrate appliance is down.

The replication gateway service on the appliance isn't running.
The replication gateway service is experiencing connectivity issues to one of the
following Azure service components that are used for replication: Service
Bus/Event Hubs/Azure cache Storage Account/Azure Key Vault.
The gateway service is being throttled at the vCenter level while trying to read the
disk.
Identifying the root cause and resolving the issue:
1. Ensure that the Azure Migrate appliance is up and running.
2. Check if the gateway service is running on the appliance:
a. Sign in to the Azure Migrate appliance using remote desktop and do the
following.
b. Open the Microsoft services MMC snap-in (run > services.msc), and check if the
"Microsoft Azure Gateway Service" is running. If the service is stopped or not
running, start the service. Alternatively, you can open command prompt or
PowerShell and enter 'Net Start asrgwy'.
3. Check for connectivity issues between Azure Migrate appliance and cache
Storage Account:
Run the following command after downloading azcopy in the Azure Migrate
appliance:
_azcopy bench https://[account].blob.core.windows.net/[container]?SAS_
Steps to run the performance benchmark test:
a. Download azcopy
b. Look for the Appliance Storage Account in the Resource Group. The Storage
Account has a name that resembles migratelsa**********. This is the value of
parameter [account] in the above command.
c. Search for your storage account in the Azure portal. Ensure that the subscription
you use to search is the same subscription (target subscription) in which the
storage account is created. Go to Containers in the Blob Service section. Select
+Container and create a Container. Leave Public Access Level to default
selected value.
d. Go to Settings > Shared Access Signature. Select Container in Allowed

Resource Type. Select Generate SAS and connection string. Copy the SAS value.
e. Execute the above command in Command Prompt by replacing account,

container, SAS with the values obtained in steps 2, 3, and 4 respectively.
Alternatively, download the Azure Storage Explore on to the appliance and try to
upload 10 blobs of ~64 MB into the storage accounts. If there's no issue, the
upload should be successful.
4. Connectivity issues between Azure Migrate appliance and Azure Service Bus:
This test will check whether the Azure Migrate appliance can communicate to the
Azure Migrate Cloud Service backend. The appliance communicates to the service
backend through Service Bus and Event Hubs message queues. To validate
connectivity from the appliance to the Service Bus, download the Service Bus
Explorer, try to connect to the appliance Service Bus and perform the send
message/receive message operations. If there's no issue, this should be successful.
Steps to run the test:
a. Copy the connection string from the Service Bus that got created in the
Resource Group corresponding to Azure Migrate Project.
b. Open Service Bus Explorer.
c. Go to File > Connect.
d. Paste the connection string you copied in step 1, and select Connect.
e. This will open Service Bus namespace.
f. Select Snapshot Manager in namespace. Right-click on Snapshot Manager,

select Receive Messages > peek, and select OK.
If the connection is successful, you'll see "[x] messages received" on the console
output. If the connection isn't successful, you'll see a message stating that the
connection failed.
appliance and Service Bus. Engage your local networking team to check these
the failures.
5. Connectivity issues between Azure Migrate appliance and Azure Key Vault:
This test checks for connectivity issues between the Azure Migrate appliance and
the Azure Key Vault. The Key Vault is used to manage Storage Account access used
for replication.
Steps to check connectivity:
a. Fetch the Key Vault URI from the list of resources in the Resource Group
corresponding to Azure Migrate Project.
b. Open PowerShell in the Azure Migrate appliance and run the following
command:
_test-netconnection Key Vault URI -P 443_
This command will attempt a TCP connection and will return an output.
a. In the output, check the field "TcpTestSucceeded". If the value is "True", there's no
connectivity issue between the Azure Migrate Appliance and the Azure Key
Vault. If the value is "False", there's a connectivity issue.
appliance and the Azure Key Vault. Engage your local networking team to check
the failures.
Encountered an error while trying to fetch

changed blocks
Error Message: 'Encountered an error while trying to fetch change blocks'
The agentless replication method uses VMware's changed block tracking technology
(CBT) to replicate data to Azure. CBT lets the Migration and modernization tool track
and replicate only the blocks that have changed since the last replication cycle. This
error occurs if changed block tracking for a replicating virtual machine is reset or if the
changed block tracking file is corrupt.
This error can be resolved in the following two ways:
If you had opted for Automatically repair replication by selecting "Yes" when you
triggered replication of VM, the tool will try to repair it for you. Right-click on the
VM, and select Repair Replication.
If you didn't opt for Automatically repair replication or the above step didn't work
for you, then stop replication for the virtual machine, reset changed block
tracking on the virtual machine, and then reconfigure replication.
One such known issue that may cause a CBT reset of virtual machine on VMware
vSphere 5.5 is described in VMware KB 1020128: Changed Block Tracking is reset after
a storage vMotion operation in vSphere 5.x. If you are on VMware vSphere 5.5, ensure
that you apply the updates described in this KB.
Alternatively, you can reset VMware changed block tracking on a virtual machine using
VMware PowerCLI.
An internal error occurred
Sometimes you may hit an error that occurs due to issues in the VMware
environment/API. We've identified the following set of errors as VMware environment-
related errors. These errors have a fixed format.
Error Message: An internal error occurred. [Error message]
For example: Error Message: An internal error occurred. [An Invalid snapshot
configuration was detected].
The following section lists some of the commonly seen VMware errors and how you can
mitigate them.
Error Message: An internal error occurred. [Server

Refused Connection]
The issue is a known VMware issue and occurs in VDDK 6.7. You need to stop the
gateway service running in the Azure Migrate appliance, download an update from
VMware KB , and restart the gateway service.
Steps to stop gateway service:
1. Press Windows + R and open services.msc. Select Microsoft Azure Gateway

Service, and stop it.
2. Alternatively, you can open command prompt or PowerShell and enter 'Net Stop
asrgwy'. Ensure you wait until you get the message that service is no longer
running.
Steps to start gateway service:
1. Press Windows + R, open services.msc. Right-click on Microsoft Azure Gateway

Service, and start it.
2. Alternatively, you can open command prompt or PowerShell and enter 'Net Start
asrgwy'.
Error Message: An internal error occurred. ['An Invalid

snapshot configuration was detected.']
If you have a virtual machine with multiple disks, you may encounter this error if you
remove a disk from the virtual machine. To remediate this problem, refer to the steps in
this VMware article .
Error Message: An internal error occurred. [Generate
Snapshot Hung]
This issue occurs when snapshot generation stops responding. When this issue occurs,
you can see create snapshot task stops at 95% or 99%. Refer to this VMware KB to
overcome this issue.
Error Message: An internal error occurred. [Failed to

consolidate the disks on VM [Reasons]]
When we consolidate disks at the end of replication cycle, the operation fails. Follow the
instructions in the VMware KB by selecting the appropriate Reason to resolve the
issue.
The following errors occur when VMware snapshot-related operations – create, delete,
or consolidate disks fail. Follow the guidance in the next section to remediate the errors:
Error Message: An internal error occurred. [Another task

is already in progress]
This issue occurs when there are conflicting virtual machine tasks running in the
background, or when a task within the vCenter Server times out. Follow the resolution
provided in the following VMware KB .
Error Message: An internal error occurred. [Operation not

allowed in current state]
This issue occurs when vCenter Server management agents stop working. To resolve this
issue, refer to the resolution in the following VMware KB .
Error Message: An internal error occurred. [Snapshot Disk

size invalid]
This is a known VMware issue in which the disk size indicated by snapshot becomes
zero. Follow the resolution given in the VMware KB .
Error Message: An internal error occurred. [Memory

allocation failed. Out of memory.]
This happens when the NFC host buffer is out of memory. To resolve this issue, you
need to move the VM (compute vMotion) to a different host, which has free resources.
Error Message: An internal error occurred. [File is larger

than maximum file size supported (1012384)]
This happens when the file size is larger than the maximum supported file size while
creating the snapshot. Follow the resolution given in the VMware KB
Error Message: An internal error occurred. [Cannot

connect to the host (1004109)]
This happens when ESXi hosts can't connect to the network. Follow the resolution given
in the VMware KB .
Error message: An error occurred while saving the

snapshot: Invalid change tracker error code
This error occurs when there's a problem with the underlying datastore on which the
snapshot is being stored. Follow the resolution given in the VMware KB .
Error message: An error occurred while taking a snapshot:

Unable to open the snapshot file.
This error occurs when the size of the snapshot file created is larger than the available
free space in the datastore where the VM is located. Follow the resolution given in this
document .
Replication cycle failed

Error ID: 181008
Error Message: VM: 'VMName'. Error: No disksnapshots were found for the snapshot
replication with snapshot ID: 'SnapshotID'.
Possible Causes:
One or more included disks is no longer attached to the VM.
Recommendation:
Restore the included disks to the original path using storage vMotion and try
replication again.
Host Connection Refused

Error ID: 1022
Error Message: The Azure Migrate appliance is unable to connect to the vSphere host
'%HostName;'
Possible Causes:
This may happen if:
1. The Azure Migrate appliance is unable to resolve the hostname of the vSphere
host.
2. The Azure Migrate appliance is unable to connect to the vSphere host on port 902
(default port used by VMware vSphere Virtual Disk Development Kit), because TCP
port 902 is being blocked on the vSphere host or by a network firewall.
Recommendations:
Ensure that the hostname of the vSphere host is resolvable from the Azure Migrate
appliance.
Sign in to the Azure Migrate appliance and open PowerShell.

Perform an nslookup on the hostname and verify if the address is being resolved:
nslookup '%HostName;' .
If the host name isn't getting resolved, ensure that the DNS resolution of the
vSphere hostnames can be performed from the Azure Migrate appliance.
Alternatively, add a static host entry for each vSphere host to the hosts
file(C:\Windows\System32\drivers\etc\hosts) on the appliance.
Ensure the vSphere host is accepting connections on port 902 and that the endpoint
is reachable from the appliance.
Sign in to the Azure Migrate appliance and open PowerShell.

Use the Test-NetConnection cmdlet to validate connectivity: Test-NetConnection
'%HostName;' -Port 902 .
If the tcp test doesn't succeed, the connection is being blocked by a firewall or isn't
being accepted by the vSphere host. Resolve the network issues to allow
replication to proceed.
Next Steps
Continue VM replication, and perform test migration.
Troubleshoot slow replication or stuck
migration issues in agentless VMware
migration
This article helps you troubleshoot slow replication or stuck migration issues that you
may encounter when you replicate on-premises VMware VMs using the Azure Migrate:
Server Migration agentless method.
Replication is slow or stuck for VM

While performing replications, you might observe that replication for a particular VM
isn't progressing at the expected pace. Generally, the underlying reason for this issue is
an unavailability or scarcity of some resources required for replication. The resources
might be consumed by other VMs that are replicating or some other process running on
the appliance in the datacenter.
Following are some reasons that generally cause this issue and remediations.
NFC buffer size low

The Azure Migrate appliance operates under the constraint of using 32 MB of NFC
buffer to concurrently replicate 8 disks on the ESXi host. An NFC buffer size of less than
32 MB might cause slow replication. You may also get the following exception:
Exception: GatewayErrorHandling.GatewayServiceException: The operation failed with

the error 'Memory allocation failed. Out of memory.'
Remediation
You can increase the NFC buffer size beyond 32 MB to increase concurrency. The setting
needs to be done on both the ESXi host and on the appliance. If not, the replication may
perform even worse.
Ｕ Caution
Increasing the size to more than 32 MB might cause resource constraints in the
environment. Before proceeding, consult with the System Administrator to
understand the implications.
Changes in ESXi host
1. SSH to the ESXi host as root.
2. Use the vi editor to open “/etc/vmware/hostd/config.xml”.
3. Find the section that looks like the one below:
<nfcsvc>
<enabled>true</enabled>
<maxMemory>134217728</maxMemory>
<maxStreamMemory>10485760</maxStreamMemory>
<path>libnfcsvc.so</path>
</nfcsvc>
4. Edit the value of maxMemory to the value (in Bytes) that you’d like to configure for
the NFC buffer. In this example, it's set to 128 MB (128 * 1024 * 1024).
5. Save and exit.
6. Restart the management agents from the shell using the following commands:
/etc/init.d/hostd restart
/etc/init.d/vpxa restart
Changes in Appliance
1. Sign in to the Azure Migrate appliance as an administrator using the Remote

Desktop.
2. Open the GatewayDataWorker.json file in the "%programdata%\Microsoft
Azure\Config" folder.
3. Create an empty json file if it doesn’t exist and paste the following text in the new
file created.
{
"HostBufferSizeInMB": "32",
}
4. Change the value of HostBufferSizeInMB to the value that you set in the ESXi host.
5. Save and exit.
6. Restart the Azure Migrate gateway service that is running on the appliance. Open
PowerShell and execute the following:
net stop asrgwy (wait for the service to stop)

net start asrgwy
ESXi host available RAM low

When the ESXi host on which the replicating VM is present is too busy, the replication
process will slow down due to unavailability of RAM.
Remediation
Use VMotion to move the VM with slow replication to an ESXi host, which isn't too busy.
Network bandwidth
Replications might be slow because of low network bandwidth available to the Azure
Migrate appliance. Low bandwidth might be due to other applications using up the
bandwidth or presence of bandwidth throttling applications or a proxy setting
restricting the bandwidth use of replication appliance.
Remediation
In case of low bandwidth, you can first reduce the number of applications using network
bandwidth. Check with your network administrator if any throttling application or proxy
setting is present.
Disk I/O
Replications can be slow because the server that is being replicated has too much load
on it and this is causing high I/O operations on disks attached to it. It's advised to
reduce the load on the server to increase the replication speed. You may also encounter
the following error:
The last replication cycle for the virtual machine ‘VM Name’ failed. Encountered timeout
event.
If no action is taken, the replication will proceed and be completed with a delay.
Disk write rates

Replications can be slower than expected if the data upload speed is higher than the
write speed of the disk that you selected while enabling replication. To get better speeds
at same upload speeds, you would need to restart the replication and select Premium
while selecting the disk type for replication.
Ｕ Caution
The disk type recommended during Assessment might not be Premium for a
particular VM. In this case, switching to Premium disk to improve replication speeds
isn't advisable since it might not be required post migration to have a Premium
disk attached to this VM.
Migration operation on VM is stuck

While triggering migration for a particular VM, you might observe that the migration is
stuck at some stage (queued or delta sync) longer than expected. Generally, the
underlying reason for this issue is an unavailability or scarcity of some resources
required for migration. The resources might be consumed by other VMs that are
replicating or some other process running on appliance on in the datacenter. Following
are some reasons that generally cause this issue and the remedies.
NFC buffer size low

If an IR cycle for a server with large disks is ongoing while migration is triggered for
second VM, the second VM’s migration job can get stuck. Even though migration jobs
are given high priority, the NFC buffer might not be available for migration. In this case,
it's recommended to stop or pause the initial replication of servers with large disks and
complete the migration of the second VM.
Ongoing delta sync cycle isn't complete

If migration is triggered during an ongoing delta replication cycle, it would be queued.
The delta replication cycle on the VM will be completed first after which migration will
start. The time required to trigger migration depends on the time taken to complete
one delta sync cycle.
Shutdown of on-premises VM taking longer than usual

Try to migrate without shutting down the VM or turn off the VM manually and then
migrate it.
Next steps
Learn more about migrating VMware VMs.
Troubleshooting web apps migration
issues
This article describes some common issues and specific errors you might encounter when
trying to migrate web apps using Azure Migrate.
Web Apps migration issues

This table lists the steps for fixing the following migration issues:
Error code Error message Troubleshooting steps
AccessDenied Access denied. Check error details. This may be due to a change
since last web app discovery. Confirm that the
web app discovery is still successful and/or
troubleshoot web app discovery access issues
first.
AddConflict The role This may be due to AKS 1.23+ version. If you're
assignment using AKS 1.23+, edit the script as mentioned in
already exists. Build container image before building the
docker image.
AppContentAlreadyExists Application Retry the migration using a new storage

content account. Contact support if this occurs
appContent.zip persistently.
already present
on storage
before content
copy.
AppZipUploadFailed Error Retry if it's a transient issue and confirm

uploading connectivity between the appliance and the
application Azure storage account specified for the
content to migration.
storage
account.
CopyAppContentToApplianceFailure Error occurred Check error details for more information.

copying Confirm connectivity between appliance and
content from web server such as by looking for recently
IIS web server successful web app discovery.
to appliance.
IISWebAppExceededMaxContentSize Content size The deployment method used only supports

exceeded max content up to 2 GB in size. If uncompressed
content size (2 content is larger than 2 GB, migration won't be
GB) for attempted with this error. This should be
migration flagged in the web app assessment and may
using this tool. indicate file content size changes since the last
web app discovery was completed.
IISWebAppFailureCompressingSiteContent Exception Check error details for more information. This

occurred could be related to physical file permissions,
compressing including, if access has been blocked for the
site content. Administrator account used for the web app
discovery and migration of the site content.
IISWebAppMigrationError Error occurred Check the error message for additional details.
during app
content copy
operation.
IISWebAppNotFoundOnServer Web This may be due to changes on the web server

application since the last web app discovery was completed,
matching site such as site delete or rename operations.
name not Confirm that web app discovery was completed
found on web recently and that the site still exists on the web
server. server.
IISWebAppUNCContentDirectory Web app Currently, migration isn't supported for content

contains only on UNC shares. This error will occur if all site
UNC directory content is on UNC shares, if there are non-UNC
content. UNC share content directories those will be migrated.
directories are
not currently
supported for
migration.
IISWebServerAccessFailedError Unable to This can be caused by insufficient access to IIS

access the IIS configuration and management API locations.
configuration. Web app migration uses the same identity and
connection mechanism as web app discovery.
Check if settings have changed since the last
successful web app discovery and if that
discovery is still successful for this web server.
IISWebServerIISNotFoundError IIS This error indicates that the IIS Management

Management Console feature isn't enabled on the web server,
Console and is likely a change to the web server since
feature is not the last successful web app discovery was
enabled. completed. Ensure that the Web Server (IIS) role
including the IIS Management Console feature
(part of Management Tools) is enabled and that
web app discovery can discover web apps for
the target web server.
IISWebServerInvalidSiteConfig Invalid IIS This indicates an invalid site configuration for

configuration one or more sites on the IIS server. Add a root
encountered, "/" application for all web sites on the IIS server
the site has no or remove the associated (non-functional) sites.
root
application
defined.
IISWebServerPowerShellError Error occurred Check the error message for more details.
during Remote PowerShell is used to package the site
PowerShell content from the web server without requiring
operation. the installation of any products or machine
changes on the web server.
IISWebServerPowerShellVersionLessThan4 PowerShell Migration is only supported for IIS web servers

version on IIS with PowerShell V4 or later versions. Update the
web server was web server with PowerShell v4 to enable this
less than migration.
minimum
required
PowerShell
version 4.
IISWebServerUnableToConnect Unable to Check error details. This may be due to a change

connect to the since last successful web app discovery. Confirm
server. that web app discovery is still successful and/or
troubleshoot web app discovery access issues
first.
IISWebServerZeroWebAppsFound No web apps This may indicate that the web server was
were found on modified after the last web app discovery was
the target IIS completed. Confirm that web app discovery was
server. recently completed and that web apps weren't
removed from the web server.
NullResult PowerShell Remote PowerShell is used for packaging the

script returned site content from the web server without
no results. requiring install of any products or persistent
files on the server. This error may indicate that
the MaxMemoryPerShell value on the IIS server
is too low, or has been changed since web app
discovery was completed. Try increasing the
MaxMemoryPerShell value on the IIS server
using a command like: Set-Item
WSMan:\localhost\Shell\MaxMemoryPerShellMB
4096
ResultFileContentJSONParseError Results in Contact support if you're seeing this error.

unexpected
format.
ScriptExecutionTimedOutOnVm Operation This error may indicate a change on the server

timed out. since last web app discovery. Check if web app
discovery is still running and successful.
StorageAuthenticationFailed Failed to Check the error details for more information.

authenticate
with Azure
Storage
container.
StorageBlobAlreadyExists App content Retry the migration using a new storage

blob already account.
present before
upload of app
content.
StorageGenericError Azure Storage The Azure Resource Manager deployment step

related error. will complete only when the content
(appContent.zip) or an error file (error.json)
appear in the site’s storage container – if the
NuGet is unable to upload the error.json file in
error cases, the Azure Resource Manager
deployment will continue until it times out,
waiting for the content. This may indicate an
issue with connectivity between the appliance
and the specified storage account being used by
migration.
UnableToConnectToPhysicalServer Connecting to Check error details. This may be due to a change

the remote since last web app discovery. Check for web app
server failed. discovery errors and troubleshoot web app
discovery connection issues first.
UnableToConnectToServer Connecting to Check error details. This may be due to a change

the remote since last web app discovery. Check for web app
server failed. discovery errors and troubleshoot web app
discovery connection issues first.
Next steps
Continue to perform at-scale agentless migration of ASP.NET web apps to Azure App
Service.
Once you have successfully completed migration, you may explore the following steps
based on web app specific requirement(s):
Securely connect to Azure resources.
az offazure
Reference
７ Note
This reference is part of the offazure extension for the Azure CLI (version 2.15.0 or
higher). The extension will automatically install the first time you run an az offazure
command. Learn more about extensions.
Manage on-premise resources for migrate.
Commands
az offazure hyperv Manage Hyper-V on-premise resources.
az offazure hyperv cluster Manage Hyper-V cluster.
az offazure hyperv cluster list Get all clusters on the on-premise site.
az offazure hyperv cluster Get the details of a Hyper-V cluster.

show
az offazure hyperv host Manage Hyper-V host.
az offazure hyperv host list Get all hosts on the on-premise site.
az offazure hyperv host show Get the details of a Hyper-V host.
az offazure hyperv machine Manage Hyper-V machine.
az offazure hyperv machine List all machines on the on-premise site.

list
az offazure hyperv machine Get the details of a machine.

show
az offazure hyperv run-as- Manage Hyper-V run-as-account.

account
az offazure hyperv run-as- List all run-as-accounts on the on-premise site.

account list
az offazure hyperv run-as- Get the details of a run-as-account.

account show
az offazure hyperv site Manage Hyper-V site.

az offazure hyperv site create Create a Hyper-V site.
az offazure hyperv site delete Delete a Hyper-V site.
az offazure hyperv site show Get the details of a site.
az offazure vmware Manage VMware on-premise resources.
az offazure vmware machine Manage VMware machine.
az offazure vmware machine List all machines on the on-premise site.

list
az offazure vmware machine Get the details of a machine.

show
az offazure vmware run-as- Manage VMware run-as-account.

account
az offazure vmware run-as- List all run-as-accounts on the on-premise site.

account list
az offazure vmware run-as- Get the details of a run-as-account.

account show
az offazure vmware site Manage VMware site.
az offazure vmware site create Create a site for VMware resources.
az offazure vmware site delete Delete a VMware site.
az offazure vmware site show Get the details of a VMware site.
az offazure vmware vcenter Manage VMware vCenter.
az offazure vmware vcenter List all vCenters on the on-premise site.

list
az offazure vmware vcenter Get the details of a vCenter.

show
Az.Migrate
Reference
Microsoft Azure PowerShell: Migrate cmdlets
Migrate
Get-AzMigrateDiscoveredServer Get All discovered servers in a migrate
project.
Get-AzMigrateJob Retrieves the status of an Azure Migrate job.
Get-AzMigrateProject Method to get a migrate project.
Get-AzMigrateReplicationFabric Gets the details of an Azure Site Recovery

fabric.
Get-AzMigrateReplicationPolicy Gets the details of a replication policy.
Get-AzMigrateReplicationProtectionContainer Gets the details of a protection container.
Get- Gets the details of a protection container

AzMigrateReplicationProtectionContainerMapping mapping.
Get- Gets the details of registered recovery

AzMigrateReplicationRecoveryServicesProvider services provider.
Get-AzMigrateRunAsAccount Method to get run as account.
Get-AzMigrateServerReplication Retrieves the details of the replicating server.
Get-AzMigrateSite Method to get a site.
Get-AzMigrateSolution Gets a solution in the migrate project.
Initialize-AzMigrateReplicationInfrastructure Initialises the infrastructure for the migrate

project.
New-AzMigrateDiskMapping Creates a new disk mapping
New-AzMigrateNicMapping Creates an object to update NIC properties

of a replicating server.
New-AzMigrateProject Creates a new Migrate project.
New-AzMigrateReplicationPolicy The operation to create a replication policy.
New- The operation to create a protection

AzMigrateReplicationProtectionContainerMapping container mapping.
New-AzMigrateServerReplication Starts replication for the specified server.
New-AzMigrateTestNicMapping Creates an object to update NIC properties

of a test migrating server.
Register-AzMigrateProjectTool Registers a tool with the migrate project.
Remove-AzMigrateProject Delete the migrate project. Deleting non-

existent project is a no-operation.
Remove-AzMigrateServerReplication Stops replication for the migrated server.
Restart-AzMigrateServerReplication Restarts the replication for specified server.
Resume-AzMigrateServerReplication Starts the replication that has been

suspended.
Set-AzMigrateDiskMapping Updates disk mapping
Set-AzMigrateServerReplication Updates the target properties for the

replicating server.
Start-AzMigrateServerMigration Starts the migration for the replicating

server.
Start-AzMigrateTestMigration Starts the test migration for the replicating

server.
Start-AzMigrateTestMigrationCleanup Cleans up the test migration for the

replicating server.
Suspend-AzMigrateServerReplication Suspends the ongoing replication.

Azure Policy built-in definitions for
Azure Migrate
This page is an index of Azure Policy built-in policy definitions for Azure Migrate. For
additional Azure Policy built-ins for other services, see Azure Policy built-in definitions.
The name of each built-in policy definition links to the policy definition in the Azure
portal. Use the link in the Version column to view the source on the Azure Policy GitHub
repo .
Azure Migrate
Name Description Effect(s) Version
(Azure portal) (GitHub)
Configure Use private DNS zones to override the DNS DeployIfNotExists, 1.0.0
Azure resolution for a private endpoint. A private DNS Disabled
Migrate zone links to your virtual network to resolve to
resources to your Azure Migrate project. Learn more at:
use private https://aka.ms/privatednszone .
DNS zones
Next steps
See the built-ins on the Azure Policy GitHub repo .
Review the Azure Policy definition structure.
Review Understanding policy effects.
 Training

Introduction to Azure Policy - Training
This module introduces you to Azure Policy and describes how to use it to apply compliance to your
environment.
Learning certificate
Cloud migration in the Cloud Adoption
Framework
Any enterprise-scale cloud adoption plan includes workloads that don't deserve
significant investments in the creation of new business logic. Those workloads could be
moved to the cloud through any number of approaches: lift and shift, lift and optimize,
or modernize. Each approach is considered a migration.
Watch the following video to get a quick overview of the lift and shift approach.
https://www.microsoft.com/en-us/videoplayer/embed/RWDup6?postJsllMsg=true
The following exercises help establish the iterative processes to assess, migrate,
optimize, secure, and manage those workloads.
To prepare you for this phase of the cloud adoption lifecycle, we recommend the
following steps:
Migrate your first workload: Use the Azure migration guide to become familiar with the
Azure native tools and approach to migration.
Migration scenarios: Use other migration tools and approaches to act on other migration
scenarios.
Best practices: Address common migration needs through the application of consistent
best practices.
Process improvements: Migration is a process heavy activity. As migration efforts scale,

use these process improvements to evaluate and mature various aspects of migration.
The Migrate methodology and the steps above build on the following assumptions:
The methodology that migration sprints fit within migration waves or releases. You
define migration waves or releases by using the Plan, Ready, and Adopt
methodologies. Within each migration sprint, a batch of workloads is migrated to
the cloud.
Before migrating workloads, you've identified, configured, and deployed at least
one landing zone to meet the needs of the near-term cloud adoption plan.
Migration is commonly associated with the terms lift and shift or rehost. This
methodology and the steps above are built on the belief that no datacenter and
few workloads should be migrated using a pure rehost approach. While you can
rehost many workloads, customers more often choose to modernize specific assets
within each workload. During this iterative process, the balance between speed
and modernization is a common discussion point.
Migration effort
The actions required to migrate workloads generally falls into three efforts, or phases,
for each workload: assess workloads, deploy workloads, and release workloads. This
section of the Cloud Adoption Framework teaches readers how to maximize the return
from each phase required to migrate a workload to production.
In a standard two-week iteration, an experienced migration team can complete this

process for 2-5 workloads of low-medium complexity. More complex workloads, such as
SAP, may take several two-week iterations to complete all three phases of migration
effort for a single workload. Experience and complexity both have a significant impact
on timelines and migration velocity.
The following bullets provide an overview of the phases of this process (pictured above):
Assess workloads: Assess workloads to evaluate cost, modernization, and

deployment tooling. This process focuses on validating or challenging
assumptions. You make these assumptions during discovery and assessments by
looking more closely at rationalization options. This process is also when user
patterns and dependencies are studied more closely to ensure workloads will
achieve technical success after migration.
Watch this video to get a quick overview about completing a comprehensive

assessment.
https://www.microsoft.com/en-us/videoplayer/embed/RWDpel?
postJsllMsg=true
Deploy workloads: After you assess workloads, the existing workload functionality
is replicated or improved in the cloud. This replication could involve a lift and shift
or rehost to the cloud. But, more commonly during this phase, many of the assets
supporting these workloads will be modernized to capitalize on the benefits of the
cloud.
Release workloads: Once functionality is replicated to the cloud, workloads can be

tested, optimized, documented, and released for ongoing operations. The effort to
review the migrated workloads and hand them off is critical during this process.
The effort is critical to governance, operations management, and security teams for
ongoing workload support.
７ Note
In some early iterations of the migration effort, it's common to limit scope to a
single workload. This approach maximizes skills retention and provides the team
with more time to experiment and learn.
７ Note
When building a migration factory, some teams may choose to disperse each of the
above phases across multiple teams and multiple sprints. This approach can
improve repeatability and accelerate migration efforts.
Migration waves and iterative change

management
Migration iterations deliver technical value by migrating assets and workloads. A
migration wave is the smallest collection of workloads that deliver measurable business
value. Each iteration should result in a report that outlines the technical efforts
completed. However, business change and strategic planning typically happen at a
slightly higher level. As the cloud adoption team delivers on the migration effort, the
cloud strategy team focuses on planning the next 1-2 migration waves. The cloud
strategy team also tracks technical progress as a learning metric to better understand
the timelines for realizing business value. Migration waves are the iterative change
management approach to tracking business outcomes, people, and timelines.
In the previous section, the graphic describes the processes within the Plan
methodology, the Ready methodology, and to some extent the Strategy methodology
of the Cloud Adoption Framework. These methodologies provide guidance on planning
and managing the migration waves. The management of those waves defines the
migration effort to be delivered by the technical teams.
Next steps
The steps outlined above and further methodology guidance can help you improve
processes within each migration sprint. The Azure migration guide includes articles that
outline the most common tools and approaches needed during your first migration
wave.
Azure migration guide

Overview of application migration
examples for Azure
This section of the Cloud Adoption Framework provides examples of several common
migration scenarios and demonstrates how you can migrate on-premises infrastructure
to Microsoft Azure .
Introduction
Azure provides access to a comprehensive set of cloud services. As developers and IT
professionals, you can use these services to build, deploy, and manage applications on a
range of tools and frameworks through a global network of datacenters. As your
business faces challenges associated with the digital shift, the Azure platform helps you
to determine how to:
Optimize resources and operations.

Engage with your customers and employees.
Transform your products.
The cloud provides advantages for speed and flexibility, minimized costs, performance,
and reliability. However, many organizations might need to continue to run on-premises
datacenters. In response to cloud adoption barriers, Azure provides a hybrid cloud
strategy that builds bridges between your on-premises datacenters and the Azure public
cloud. An example is using Azure cloud resources like Azure Backup to protect on-
premises resources or Azure analytics to gain insights into on-premises workloads.
As part of the hybrid cloud strategy, Azure provides growing solutions for migrating on-
premises applications and workloads to the cloud. With simple steps, you can
comprehensively assess your on-premises resources to determine how they'll run in the
Azure platform. With a deep assessment in hand, you can confidently migrate resources
to Azure. When resources are up and running in Azure, you can optimize them to retain
and improve access, flexibility, security, and reliability.
Migration patterns
Strategies for migration to the cloud fall into four broad patterns: rehost, refactor,
rearchitect, or rebuild. The strategy you adopt depends on your business drivers and
migration goals. You might adopt multiple patterns. For example, you could choose to
rehost noncritical applications while rearchitecting applications that are more complex
and business-critical. Let's look at these patterns.
Pattern Definition When to use
Rehost Often referred to as a lift-and-shift migration, this - When you need to move
option doesn't require code changes. You can use applications quickly to the
it to migrate your existing applications to Azure cloud
quickly. Each application is migrated as is to reap - When you want to move an
the benefits of the cloud without the risk and cost application without modifying
associated with code changes. it
- When your applications are
designed to take advantage of
Azure infrastructure as a
service (IaaS) scalability after
migration.
- When applications are
important to your business, but
you don't need to immediately
change application capabilities.
Refactor Often referred to as a "repackaging," refactoring - If your application can easily

requires minimal changes to applications so that be repackaged to work in
they can connect to Azure platform as a service Azure
(PaaS) and use cloud offerings. - If you want to apply
innovative DevOps practices
For example, you could migrate existing provided by Azure, or if you're
applications to Azure App Service or Azure thinking about DevOps using a
Kubernetes Service (AKS). Or, you could refactor container strategy for
relational and nonrelational databases into workloads
options such as Azure SQL Managed Instance, - For refactoring, you need to
Azure Database for MySQL, Azure Database for think about the portability of
PostgreSQL, and Azure Cosmos DB. your existing code base and
available development skills.
Rearchitect Rearchitecting for migration focuses on - When your applications need

modifying and extending application functionality major revisions to incorporate
and the code base to optimize the application new capabilities or to work
architecture for cloud scalability. effectively on a cloud platform
- When you want to use
For example, you could break down a monolithic existing application
application into a group of microservices that investments, meet scalability
work together and scale easily. You could also requirements, apply innovative
rearchitect relational and nonrelational databases DevOps practices, and
to a fully managed database solution, such as minimize use of virtual
SQL Managed Instance, Azure Database for machines
MySQL, Azure Database for PostgreSQL, and
Azure Cosmos DB.
Pattern Definition When to use
Rebuild Rebuild takes things a step further by rebuilding - When you want rapid
an application from scratch using Azure cloud development, and existing
technologies. applications have limited
functionality and lifespan
For example, you could build greenfield - When you're ready to
applications with cloud-native technologies like expedite business innovation
Azure Functions, AI, SQL Managed Instance, and (including DevOps practices
Azure Cosmos DB. provided by Azure), build new
applications using cloud-native
technologies, and take
advantage of advancements in
AI, blockchain, and IoT.
Migration example articles

This section provides examples of several common migration scenarios. Each example
includes background information and detailed deployment scenarios. These scenarios
illustrate how to set up a migration infrastructure and assess the suitability of on-
premises resources for migration. More articles will be added to this section over time.
This series focuses on each migration scenario, which is driven by slightly different
business goals to determine the migration strategy. For each deployment scenario, we
provide information about:
Business drivers and goals.

A proposed architecture.
Steps to perform the migration.
Recommendations for cleanup and next steps after migration is finished.
Assessment
Article Details
Assess on- This article in the Plan methodology discusses how to run an assessment of an
premises on-premises application running on VMware. In the article, an example
resources for organization assesses application VMs by using Azure Migrate and the application
migration to SQL Server database by using Data Migration Assistant.
Azure
Infrastructure
Article Details
Deploy This article shows how an organization can prepare its on-premises infrastructure
Azure and its Azure infrastructure for migration. The infrastructure example established
infrastructure in this article is referenced in the other samples provided in this section.
Windows Server workloads
Article Details
Rehost an application This article provides an example of migrating on-premises application

on Azure VMs VMs to Azure VMs using Azure Migrate.
SQL Server workloads
Article Details
Migrate SQL Server This article demonstrates how the fictional company Contoso assessed,
databases to Azure planned, and migrated its various on-premises SQL Server databases to
Azure.
Rehost an This article provides an example of a lift-and-shift migration to Azure for an

application on an on-premises application. This process involves migrating the application
Azure VM and SQL front-end VM by using Azure Migrate and the application database to SQL
Managed Instance Managed Instance by using Azure Database Migration Service.
Article Details
Rehost an This example shows how to migrate an application and data by using
application on Azure-hosted SQL Server VMs. It uses Azure Migrate to migrate the
Azure VMs using application VMs and Database Migration Service to migrate the application
SQL Server Always database to a SQL Server cluster that's protected by an Always On
On availability availability group.
groups
Linux and open-source databases
Article Details
Migrate open-source This article demonstrates how the fictional company Contoso assessed,
databases to Azure planned, and migrated its various on-premises open-source databases
to Azure.
Migrate MySQL to This article demonstrates how the fictional company Contoso planned
Azure and migrated its on-premises MySQL open-source database platform to
Azure.
Migrate PostgreSQL to This article demonstrates how the fictional company Contoso planned
Azure and migrated its on-premises PostgreSQL open-source database
platform to Azure.
Migrate MariaDB to This article demonstrates how the fictional company Contoso planned
Azure and migrated its on-premises MariaDB open-source database platform
to Azure.
Rehost a Linux This article provides an example of migrating a Linux-hosted application

application on Azure to Azure VMs by using Azure Migrate. The application database is
VMs and Azure migrated to Azure Database for MySQL by using Database Migration
Database for MySQL Service.
Rehost a Linux This example shows how to complete a lift-and-shift migration of a

application on Azure Linux-based application to Azure VMs by using Azure Migrate.
VMs
Dev/test workloads
Article Details
Migrate dev/test This article demonstrates how Contoso rehosts its dev/test environment
environments to for two applications running on VMware VMs by migrating to Azure VMs.
Azure IaaS
Article Details
Migrate to Azure This article discusses how Contoso moves its dev/test workloads to Azure
DevTest Labs by using DevTest Labs.
ASP.NET and PHP web apps
Article Details
Refactor a Windows This example shows how to migrate an on-premises Windows-

application by using App based application to an Azure web app. It also shows how to
Service and SQL Database migrate the application database to an Azure SQL Database server
instance by using Database Migration Service.
Refactor a Windows This example shows how to migrate an on-premises Windows-

application by using App based application to an Azure web app. It also shows how to
Service and SQL Managed migrate the application database to SQL Managed Instance by
Instance using Database Migration Service.
Refactor a Linux application This example shows how to migrate an on-premises Linux-based
to multiple regions by using application to an Azure web app on multiple Azure regions by
App Service, Azure Traffic using Traffic Manager to integrate with GitHub for continuous
Manager, and Azure delivery. The application database is migrated to an Azure
Database for MySQL Database for MySQL instance.
Rebuild an application in This article provides an example of rebuilding an on-premises

Azure application by using a range of Azure capabilities and managed
services. These capabilities and services include App Service, AKS,
Azure Functions, Azure Cognitive Services, and Azure Cosmos DB.
Refactor Team Foundation This article shows an example migration of an on-premises Team
Server to Azure DevOps Foundation Server deployment to Azure DevOps Services in Azure.
Services
SAP
Article Details
SAP migration guide Get practical guidance to move your on-premises SAP
workloads to the cloud.
Migrate SAP applications to White paper and roadmap for your SAP journey to the
Azure cloud.
Migration methodologies for SAP Overview of various migration options to move SAP
on Azure applications to Azure.
Specialized workloads
Article Details
Move on-premises VMware This article provides an example of moving on-premises VMware
infrastructure to Azure VMs to Azure by using Azure VMware Solution.
Azure NetApp Files Enterprise file storage powered by NetApp. Run Linux and
Windows file workloads in Azure.
Oracle on Azure Run your Oracle databases and enterprise applications in Azure
and Oracle Cloud Infrastructure.
Cray in Azure High-performance computing with Cray in Azure. A dedicated

supercomputer on your virtual network.
VDI
Article Details
Move on-premises Remote Desktop This article shows how to migrate on-premises Remote
Services to Azure Virtual Desktop Desktop Services to Azure Virtual Desktop.
Migration scaling
Article Details
Scale a migration to This article shows how an example organization prepares to scale to a full
Azure migration to Azure.
Demo applications
The example articles provided in this section use two demo applications: SmartHotel360
and osTicket.
SmartHotel360: This test application was developed by Microsoft to use when you work
with Azure. It's provided under an open-source license, and you can download it from
GitHub . It's an ASP.NET application connected to a SQL Server database. In the
scenarios discussed in these articles, the current version of this application is deployed
to two VMware VMs running Windows Server 2008 R2 and SQL Server 2008 R2. These
application VMs are hosted on-premises and managed by vCenter Server.
osTicket: This open-source service desk ticketing application runs on Linux. You can
download it from GitHub . In the scenarios discussed in these articles, the current
version of this application is deployed on-premises to two VMware VMs running Ubuntu
16.04 LTS using Apache 2, PHP 7.0, and MySQL 5.7.
Azure Migrate REST API
migration, as well as third-party independent software vendor (ISV) offerings. To learn
more about Azure Migrate, see the Azure Migrate documentation.
Microsoft.Migrate resource types
This article lists the available versions for each resource type.
For a list of changes in each API version, see change log
Resource types and versions

Types Versions
assessmentProjects 2019-10-01
assessmentProjects/assessmentOptions 2019-10-01
assessmentProjects/groups 2019-10-01
assessmentProjects/groups/assessments 2019-10-01
assessmentProjects/groups/assessments/assessedMachines 2019-10-01
assessmentProjects/hypervcollectors 2019-10-01
assessmentProjects/importcollectors 2019-10-01
assessmentProjects/machines 2019-10-01
assessmentProjects/privateEndpointConnections 2019-10-01
assessmentProjects/privateLinkResources 2019-10-01
assessmentProjects/servercollectors 2019-10-01
assessmentProjects/vmwarecollectors 2019-10-01
migrateProjects 2020-05-01
migrateProjects/privateEndpointConnections 2020-05-01
projects 2018-02-02
projects/groups 2018-02-02
projects/groups/assessments 2018-02-02
projects/groups/assessments/assessedMachines 2018-02-02
projects/machines 2018-02-02

Azure Migrate

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Azure Migrate

Uploaded by

Copyright:

Available Formats

Tell us about your PDF experience.

Azure Migrate documentation

About Azure Migrate

What is Azure Migrate?

What's new in Azure Migrate?

Assess VMware VMs with Server Assessment

Assess Hyper-V VMs with Server Assessment

Assess physical servers with Server Assessment

Assess servers using imported data

Assess SQL instances for migration to Azure SQL

Migrate VMware VMs with Migration and modernization

Migrate Hyper-V VMs with Migration and modernization

Migrate physical servers/VMs with Migration and modernization

Modernize ASP.NET web apps to Azure Kubernetes Service (AKS)

Review best practices for Server Assessment

Learn about Azure Migrate appliance deployment

Review the Azure Migrate support matrix

Review the VMware support matrix

Review the Hyper-V support matrix

Review the physical server support matrix

Add assessment tools

Discover application inventory

Add migration tools

Scale VMware assessment

Automate and scale migration

Troubleshoot assessment and migration

Learn about VMware/physical agent-based migration

Learn about Hyper-V migration

Learn about assessments

Learn about dependency visualization

Request a service feature

Ask a forum question

Azure Tech Community

This article provides a quick overview of the Azure Migrate service.

Azure Migrate provides a simplified migration, modernization, and optimization service

Tool Assess and migrate Details

Data Assess SQL Server Data Migration Assistant is a stand-alone tool to

Azure Migrate on-premises Learn more about Database Migration Service.

Movere Assess servers Learn more about Movere.

Use Migration Assistant to migrate .NET and PHP

Carbonite Migrate servers.

Cloudamize Assess servers.

CloudSphere Assess servers.

Corent Technology Assess and migrate servers.

Device42 Assess servers.

Lakeside Assess VDI.

RackWare Migrate servers.

Turbonomic Assess servers.

UnifyCloud Assess servers and databases.

Zerto Migrate servers.

Azure Migrate: Discovery and assessment tool

Here's what the tool does:

On-premises Migrate VMs to Azure using agentless or agent-based migration.

For agent-based migration, the Migration and modernization tool uses a

On-premises Migrate VMs to Azure.

Selecting assessment and migration tools

Discovery of virtual and physical servers.

Azure Migrate versions

Update (May 2023)

Update (April 2023)

Update (March 2023)

Update (February 2023)

Update (January 2023)

Update (December 2022)