Azure Migration Plan
Azure Migration Plan
The Azure Migrate service assesses on-premises workloads for migration to Azure. The service assesses the
migration suitability of on-premises machines, performs performance-based sizing, and provides cost
estimations for running on-premises machines in Azure. If you're contemplating lift-and-shift migrations, or are
in the early assessment stages of migration, this service is for you. After the assessment, you can use services
such as Azure Site Recovery and Azure Database Migration Service, to migrate the machines to Azure.
Current limitations
You can only assess on-premises VMware virtual machines (VMs) for migration to Azure VMs. The
VMware VMs must be managed by vCenter Server (version 5.5, 6.0, 6.5 or 6.7).
Support for Hyper-V is currently in preview with production support, if you are interested in trying it out,
please sign up here.
For assessment of physical servers, you can leverage our partner tools.
You can discover up to 1500 VMs in a single discovery and in a single project. We have a preview release
available that allows discovery of up to 10,000 VMware VMs in a single project using a single appliance, if
you are interested in trying it out, please sign up here.
If you want to discover a larger environment, you can split the discovery and create multiple projects.
Learn more. Azure Migrate supports up to 20 projects per subscription.
Azure Migrate only supports managed disks for migration assessment.
You can only create an Azure Migrate project in the following geographies. However, this does not restrict
your ability to create assessments for other target Azure locations.
What's in an assessment?
Assessment settings can be customized based on your needs. Assessment properties are summarized in the
following table.
PROPERTY DETAILS
Storage type The type of managed disks you want to allocate for all VMs
that are part of the assessment. If the sizing criterion is as
on-premises sizing you can specify the target disk type either
as premium disks (the default), standard SSD disks or
standard HDD disks. For performance-based sizing, along
with the above options, you also have the option to select
Automatic which will ensure that the disk sizing
recommendation is automatically done based on the
performance data of the VMs. For example, 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 which
will ensure that all disks in the assessment will be
recommended as Premium managed disks. Note that Azure
Migrate only supports managed disks for migration
assessment.
VM series The VM series used for size estimations. 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. Sizing is based on the selected series
only.
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 will be done accordingly. The default
value is 31 days per month and 24 hours per day.
Azure offer The Azure offer you're enrolled to. Azure Migrate estimates
the cost accordingly.
Azure Hybrid Benefit Whether you have software assurance and are eligible for
Azure Hybrid Benefit with discounted costs.
Next steps
Follow the tutorial to create an assessment for an on-premises VMware VM.
Review frequently asked questions about Azure Migrate.
Discover and assess on-premises VMware VMs for
migration to Azure
6/10/2019 • 13 minutes to read • Edit Online
The Azure Migrate services assesses on-premises workloads for migration to Azure.
In this tutorial, you learn how to:
Create an account that Azure Migrate uses to discover on-premises VMs
Create an Azure Migrate project.
Set up an on-premises collector virtual machine (VM ), to discover on-premises VMware VMs for assessment.
Group VMs and create an assessment.
If you don't have an Azure subscription, create a free account before you begin.
Prerequisites
VMware: The VMs that you plan to migrate must be managed by vCenter Server running version 5.5, 6.0, 6.5,
or 6.7. Additionally, you need one ESXi host running version 5.5 or higher to deploy the collector VM.
vCenter Server account: You need a read-only account to access the vCenter Server. Azure Migrate uses this
account to discover the on-premises VMs.
Permissions: On the vCenter Server, you need permissions to create a VM by importing a file in .OVA format.
Create a project
1. In the Azure portal, click Create a resource.
2. Search for Azure Migrate, and select the service Azure Migrate in the search results. Then click Create.
3. Specify a project name, and the Azure subscription for the project.
4. Create a new resource group.
5. Specify the geography in which you want to create the project, then click Create. You can only create an Azure
Migrate project in the following geographies. However, you can still plan your migration for any target Azure
location. The geography specified for the project is only used to store the metadata gathered from on-premises
VMs.
GEOGRAPHY STORAGE LOCATION
NOTE
The one-time discovery appliance is now deprecated as this method relied on vCenter Server's statistics settings for
performance data point availability and collected average performance counters which resulted in under-sizing of
VMs for migration to Azure.
Quick assessments: With the continuous discovery appliance, once the discovery is complete (takes
couple of hours depending on the number of VMs), you can immediately create assessments. Since the
performance data collection starts when you kick off discovery, if you are looking for quick assessments,
you should select the sizing criterion in the assessment as as on-premises. For performance-based
assessments, it is advised to wait for at least a day after kicking off discovery to get reliable size
recommendations.
The appliance only collects performance data continuously, it does not detect any configuration change in
the on-premises environment (that is, VM addition, deletion, disk addition etc.). If there is a configuration
change in the on-premises environment, you can do the following to reflect the changes in the portal:
Addition of items (VMs, disks, cores etc.): To reflect these changes in the Azure portal, you can stop
the discovery from the appliance and then start it again. This will ensure that the changes are
updated in the Azure Migrate project.
Deletion of VMs: Due to the way the appliance is designed, deletion of VMs is not reflected even if
you stop and start the discovery. This is because data from subsequent discoveries are appended to
older discoveries and not overridden. In this case, you can simply ignore the VM in the portal, by
removing it from your group and recalculating the assessment.
3. In Copy project credentials, copy the project ID and key. You need these when you configure the
collector.
MD5 dfa1838b1e64f7cde51915927220cf48
SHA1 24bdbd9c37c7366567ff252db3a37a13dda9de42
SHA256 e9f8f16ceb970c27dd068f5a5f7a4b2fd336f2820e9d6247d51
0ba6824e3f06c
MD5 5f6b199d8272428ccfa23543b0b5f600
SHA1 daa530de6e8674a66a728885a7feb3b0a2e8ccb0
SHA256 85da50a21a7a6ca684418a87ccc1dd4f8aab30152c438a17b2
16ec401ebb3a21
MD5 169f6449cc1955f1514059a4c30d138b
SHA1 f8d0a1d40c46bbbf78cd0caa594d979f1b587c8f
SHA256 d68fe7d94be3127eb35dd80fc5ebc60434c8571dcd0e114b87
587f24d6b4ee4d
MD5 2ca5b1b93ee0675ca794dd3fd216e13d
SHA1 8c46a52b18d36e91daeae62f412f5cb2a8198ee5
SHA256 3b3dec0f995b3dd3c6ba218d436be003a687710abab9fcd17d
4bdc90a11276be
MD5 e9ef16b0c837638c506b5fc0ef75ebfa
SHA1 37b4b1e92b3c6ac2782ff5258450df6686c89864
SHA256 8a86fc17f69b69968eb20a5c4c288c194cdcffb4ee6568d85ae
5ba96835559ba
MD5 6d8446c0eeba3de3ecc9bc3713f9c8bd
SHA1 e9f5bdfdd1a746c11910ed917511b5d91b9f939f
SHA256 7f7636d0959379502dfbda19b8e3f47f3a4744ee9453fc9ce54
8e6682a66f13c
MD5 d0363e5d1b377a8eb08843cf034ac28a
SHA1 df4a0ada64bfa59c37acf521d15dcabe7f3f716b
SHA256 f677b6c255e3d4d529315a31b5947edfe46f45e4eb4dbc8019
d68d1d1b337c2e
The collector checks that the collector service is running. The service is installed by default on the
collector VM.
Download and install VMware PowerCLI.
6. In Specify vCenter Server details, do the following:
Specify the name (FQDN ) or IP address of the vCenter server.
In User name and Password, specify the read-only account credentials that the collector will use to
discover VMs on the vCenter server.
In Collection scope, select a scope for VM discovery. The collector can only discover VMs within
the specified scope. Scope can be set to a specific folder, datacenter, or cluster. It shouldn't contain
more than 1500 VMs. Learn more about how you can discover a larger environment.
NOTE
Collection scope lists only folders of hosts and clusters. Folders of VMs cannot be directly selected as
collection scope. However, you can discover by using a vCenter account that has access to the individual
VMs. Learn more about how to scope to a folder of VMs.
7. In Specify migration project, specify the Azure Migrate project ID and key that you copied from the
portal. If didn't copy them, open the Azure portal from the collector VM. In the project Overview page,
click Discover Machines, and copy the values.
8. In View collection progress, monitor discovery status. Learn more about what data is collected by the
Azure Migrate collector.
NOTE
The collector only supports "English (United States)" as the operating system language and the collector interface language.
If you change the settings on a machine you want to assess, trigger discover again before you run the assessment. In the
collector, use the Start collection again option to do this. After the collection is done, select the Recalculate option for the
assessment in the portal, to get updated assessment results.
NOTE
It is strongly recommended to wait for at least a day, after starting discovery, before creating an assessment. 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.
Assessment details
An assessment includes information about whether the on-premises VMs are compatible for Azure, what would
be the right VM size for running the VM in Azure and the estimated monthly Azure costs.
Azure readiness
The Azure readiness view in the assessment shows the readiness status of each VM. Depending on the properties
of the VM, each VM can be marked as:
Ready for Azure
Conditionally ready for Azure
Not ready for Azure
Readiness unknown
For VMs that are ready, Azure Migrate recommends a VM size in Azure. The size recommendation done by Azure
Migrate depends on the sizing criterion specified in the assessment properties. If the sizing criterion is
performance-based sizing, the size recommendation is done by considering the performance history of the VMs
(CPU and memory) and disks (IOPS and throughput). If the sizing criterion is 'as on-premises', Azure Migrate
does not consider the performance data for the VM and disks. The recommendation for the VM size in Azure is
done by looking at the size of the VM on-premises and the disk sizing is done based on the Storage type specified
in the assessment properties (default is premium disks). Learn more about how sizing is done in Azure Migrate.
For VMs that aren't ready or conditionally ready for Azure, Azure Migrate explains the readiness issues, and
provides remediation steps.
The VMs for which Azure Migrate cannot identify Azure readiness (due to data unavailability) are marked as
readiness unknown.
In addition to Azure readiness and sizing, Azure Migrate also suggests tools that you can use for the migrating the
VM. This requires a deeper discovery of on the on-premises environment. Learn more about how you can do a
deeper discovery by installing agents on the on-premises machines. If the agents are not installed on the on-
premises machines, lift and shift migration is suggested using Azure Site Recovery. If the agents are installed on
the on-premises machine, Azure Migrate looks at the processes running inside the machine and identifies whether
the machine is a database machine or not. If the machine is a database machine, Azure Database Migration
Service is suggested, else Azure Site Recovery is suggested as the migration tool.
NOTE
The cost estimation provided by Azure Migrate is for running the on-premises VMs as Azure Infrastructure as a service
(IaaS) VMs. Azure Migrate does not consider any Platform as a service (PaaS) or Software as a service (SaaS) costs.
Estimated monthly costs for compute and storage are aggregated for all VMs in the group.
Confidence rating
Each performance-based assessment in Azure Migrate is associated with a confidence rating that ranges from 1
star to 5 star (1 star being the lowest and 5 star being 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 is not applicable to "as-is" on-premises assessments.
For performance-based sizing, Azure Migrate needs the utilization data for CPU, memory of the VM. Additionally,
for every disk attached to the VM, it needs the disk IOPS and throughput data. Similarly for each network adapter
attached to a VM, Azure Migrate needs the network in/out to do performance-based sizing. If any of the above
utilization numbers are not available in vCenter Server, the size recommendation done by Azure Migrate may not
be reliable. Depending on the percentage of data points available, the confidence rating for the assessment is
provided as below:
0%-20% 1 Star
21%-40% 2 Star
41%-60% 3 Star
61%-80% 4 Star
81%-100% 5 Star
An assessment may not have all the data points available due to one of the following reasons:
You did not profile your environment for the duration for which you are creating the assessment. For
example, if you are creating the assessment with performance duration set to 1 day, you need to wait for at
least a day after you start the discovery for all the data points to get collected.
Few VMs were shut down during the period for which the assessment is calculated. If any VMs were
powered off for some duration, we will not be able to collect the performance data for that period.
Few VMs were created in between the period for which the assessment is calculated. For example, if you
are creating an assessment for the performance history of last one month, but few VMs were created in the
environment only a week ago. In such cases, the performance history of the new VMs will not be there for
the entire duration.
NOTE
If the confidence rating of any assessment is below 5 Stars, wait for at least a day for the appliance to profile the
environment and then Recalculate the assessment. If the preceding cannot be done , performance-based sizing may not be
reliable and it is recommended to switch to as on-premises sizing by changing the assessment properties.
Next steps
Learn how to customize an assessment based on your requirements.
Learn how to create high-confidence assessment groups using machine dependency mapping
Learn more about how assessments are calculated.
Learn how to discover and assess a large VMware environment.
Learn more about the FAQs on Azure Migrate
About the Collector appliance
5/31/2019 • 13 minutes to read • Edit Online
Discovery method
Previously, there were two options for the collector appliance, one-time discovery, and continuous discovery. The
one-time discovery model is now deprecated as it relied on vCenter Server statistics settings for performance data
collection (required statistics settings to be set to level 3) and also collected average counters (instead of peak)
which resulted in under-sizing. The continuous discovery model ensures granular data collection and results in
accurate sizing due to collection of peak counters. Below is how it works:
The collector appliance is continuously connected to the Azure Migrate project and continuously collects
performance data of VMs.
The collector continuously profiles the on-premises environment to gather real-time utilization data every 20
seconds.
The appliance rolls up the 20-second samples, and creates a single data point every 15 minutes.
To create the data point the appliance selects the peak value from the 20-second samples, and sends it to Azure.
This model doesn't depend on the vCenter Server statistics settings to collect performance data.
You can stop continuous profiling at anytime from the Collector.
Quick assessments: With the continuous discovery appliance, once the discovery is complete (it takes couple of
hours depending on the number of VMs), you can immediately create assessments. Since the performance data
collection starts when you kick off discovery, if you are looking for quick assessments, you should select the sizing
criterion in the assessment as as on-premises. For performance-based assessments, it is advised to wait for at least
a day after kicking off discovery to get reliable size recommendations.
The appliance only collects performance data continuously, it does not detect any configuration change in the on-
premises environment (i.e. VM addition, deletion, disk addition etc.). If there is a configuration change in the on-
premises environment, you can do the following to reflect the changes in the portal:
Addition of items (VMs, disks, cores etc.): To reflect these changes in the Azure portal, you can stop the
discovery from the appliance and then start it again. This will ensure that the changes are updated in the
Azure Migrate project.
Deletion of VMs: Due to the way the appliance is designed, deletion of VMs is not reflected even if you stop
and start the discovery. This is because data from subsequent discoveries are appended to older discoveries
and not overridden. In this case, you can simply ignore the VM in the portal, by removing it from your
group and recalculating the assessment.
NOTE
The one-time discovery appliance is now deprecated as this method relied on vCenter Server's statistics settings for
performance data point availability and collected average performance counters which resulted in under-sizing of VMs for
migration to Azure.
Deploying the Collector
You deploy the Collector appliance using an OVF template:
You download the OVF template from an Azure Migrate project in the Azure portal. You import the
downloaded file to vCenter Server, to set up the Collector appliance VM.
From the OVF, VMware sets up a VM with 8 cores, 16 GB RAM, and one disk of 80 GB. The operating
system is Windows Server 2016 (64 bit).
When you run the Collector, a number of prerequisite checks run to make sure that the Collector can
connect to Azure Migrate.
Learn more about creating the Collector.
Collector prerequisites
The Collector must pass a few prerequisite checks to ensure it can connect to the Azure Migrate service over the
internet, and upload discovered data.
Verify Azure cloud: The Collector needs to know the Azure cloud to which you are planning to migrate.
Select Azure Government if you are planning to migrate to Azure Government cloud.
Select Azure Global if you are planning to migrate to commercial Azure cloud.
Based on the cloud specified here, the appliance will send discovered metadata to the respective end
points.
Check internet connection: The Collector can connect to the internet directly, or via a proxy.
The prerequisite check verifies connectivity to required and optional URLs.
If you have a direct connection to the internet, no specific action is required, other than making sure that
the Collector can reach the required URLs.
If you're connecting via a proxy, note the requirements below.
Verify time synchronization: The Collector should synchronized with the internet time server to ensure the
requests to the service are authenticated.
The portal.azure.com url should be reachable from the Collector so that the time can be validated.
If the machine isn't synchronized, you need to change the clock time on the Collector VM to match the
current time. To do this open an admin prompt on the VM, run w32tm /tz to check the time zone. Run
w32tm /resync to synchronize the time.
Check collector service running: The Azure Migrate Collector service should be running on the Collector
VM.
This service is started automatically when the machine boots.
If the service isn't running, start it from the Control Panel.
The Collector service connects to vCenter Server, collects the VM metadata and performance data, and
sends it to the Azure Migrate service.
Check VMware PowerCLI 6.5 installed: The VMware PowerCLI 6.5 PowerShell module must be installed on
the Collector VM, so that it can communicate with vCenter Server.
If the Collector can access the URLs required to install the module, it's install automatically during
Collector deployment.
If the Collector can't install the module during deployment, you must install it manually.
Check connection to vCenter Server: The Collector must be able to vCenter Server and query for VMs, their
metadata, and performance counters. Verify prerequisites for connecting.
Connect to the internet via a proxy
If the proxy server requires authentication, you can specify the username and password when you set up the
Collector.
The IP address/FQDN of the Proxy server should specified as http://IPaddress or http://FQDN.
Only HTTP proxy is supported. HTTPS -based proxy servers aren't supported by the Collector.
If the proxy server is an intercepting proxy, you must import the proxy certificate to the Collector VM.
1. In the collector VM, go to Start Menu > Manage computer certificates.
2. In the Certificates tool, under Certificates - Local Computer, find Trusted Publishers >
Certificates.
3. Copy the proxy certificate to the collector VM. You might need to obtain it from your network admin.
4. Double-click to open the certificate, and click Install Certificate.
5. In the Certificate Import Wizard > Store Location, choose Local Machine.
6. Select Place all certificates in the following store > Browse > Trusted Publishers. Click Finish
to import the certificate.
7. Check that the certificate is imported as expected, and check that the internet connectivity
prerequisite check works as expected.
URLs for connectivity
The connectivity check is validated by connecting to a list of URLs.
*.powershellgallery.com:443
*.msecnd.net:443
*.visualstudio.com:443
*.visualstudio.microsoft.com
ACCOUNT PERMISSIONS
At least a read-only user account Data Center object –> Propagate to Child Object, role=Read-
only
Collector communications
The collector communicates as summarized in the following diagram and table.
COLLECTOR COMMUNICATES WITH PORT DETAILS
Collected metadata
NOTE
Metadata discovered by the Azure Migrate collector appliance is used to help you right-size your applications as you migrate
them to Azure, perform Azure suitability analysis, application dependency analysis, and cost planning. Microsoft does not use
this data in relation to any license compliance audit.
The collector appliance discovers the following configuration metadata for each VM. The configuration data for the
VMs is available an hour after you start discovery.
VM display name (on vCenter Server)
VM’s inventory path (the host/folder on vCenter Server)
IP address
MAC address
Operating system
Number of cores, disks, NICs
Memory size, Disk sizes
Performance counters of the VM, disk and network.
Performance counters
The collector appliance collects the following performance counters for each VM from the ESXi host at an interval
of 20 seconds. These counters are vCenter counters and although the terminology says average, the 20-second
samples are real time counters. The performance data for the VMs starts becoming available in the portal two
hours after you have kicked off the discovery. It is strongly recommended to wait for at least a day before creating
performance-based assessments to get accurate right-sizing recommendations. If you are looking for instant
gratification, you can create assessments with sizing criterion as as on-premises which will not consider the
performance data for right-sizing.
The complete list of VMware counters collected by Azure Migrate is available below:
Disk Details (per disk) Disk name This value is generated using
disk.UnitNumber, disk.Key and
disk.ControllerKey.Value
Disk Details (per disk) Number of read operations per second virtualDisk.numberReadAveraged.avera
ge
Disk Details (per disk) Number of write operations per second virtualDisk.numberWriteAveraged.avera
ge
Network Adapter Details (per NIC) Megabytes per second of read net.received.average
throughput
CATEGORY METADATA VCENTER DATAPOINT
Network Adapter Details (per NIC) Megabytes per second of write net.transmitted.average
throughput
Inventory Path Details Complete inventory path container.Name with complete path
Inventory Path Details Datacenter details for each Host Folder ((Datacenter)container).HostFolder
Discovery process
After the appliance is set up, you can run discovery. Here's how that works:
You run a discovery by scope. All VMs in the specified vCenter inventory path will be discovered.
You set one scope at a time.
The scope can include 1500 VMs or less.
The scope can be a datacenter, folder, or ESXi host.
After connecting to vCenter Server, you connect by specifying a migration project for the collection.
VMs are discovered, and their metadata and performance data is sent to Azure. These actions are part of a
collection job.
The Collector appliance is given a specific Collector ID that's persistent for a given machine across
discoveries.
A running collection job is given a specific session ID. The ID changes for each collection job, and can be
used for troubleshooting.
Next steps
Set up an assessment for on-premises VMware VMs
Collector appliance updates
3/29/2019 • 2 minutes to read • Edit Online
This article summarizes upgrade information for the Collector appliance in Azure Migrate.
The Azure Migrate Collector is a lightweight appliance that's used to discover an on-premises vCenter
environment, for the purposes of assessment before migration to Azure. Learn more.
MD5 846b1eb29ef2806bcf388d10519d78e6
SHA1 6243239fa49c6b3f5305f77e9fd4426a392d33a0
SHA256 fb058205c945a83cc4a31842b9377428ff79b08247f3fb8bb4ff
30c125aa47ad
MD5 27704154082344c058238000dff9ae44
SHA1 41e9e2fb71a8dac14d64f91f0fd780e0d606785e
SHA256 c6e7504fcda46908b636bfe25b8c73f067e3465b748f77e5002
7e66f2727c2a9
NOTE
The one-time discovery appliance is now deprecated as this method relied on vCenter Server's statistics settings for
performance data point availability and collected average performance counters which resulted in under-sizing of VMs for
migration to Azure.
MD5 d2c53f683b0ec7aaf5ba3d532a7382e1
SHA1 e5f922a725d81026fa113b0c27da185911942a01
SHA256 a159063ff508e86b4b3b7b9a42d724262ec0f2315bdba8418b
ce95d973f80cfc
Version 1.0.9.14
Hash values for upgrade package 1.0.9.14
MD5 c5bf029e9fac682c6b85078a61c5c79c
SHA1 af66656951105e42680dfcc3ec3abd3f4da8fdec
SHA256 58b685b2707f273aa76f2e1d45f97b0543a8c4d017cd27f0bd
b220e6984cc90e
Version 1.0.9.13
Hash values for upgrade package 1.0.9.13
MD5 739f588fe7fb95ce2a9b6b4d0bf9917e
SHA1 9b3365acad038eb1c62ca2b2de1467cb8eed37f6
SHA256 7a49fb8286595f39a29085534f29a623ec2edb12a3d76f90c96
54b2f69eef87e
Next steps
Learn more about the Collector appliance.
Run an assessment for VMware VMs.
Assessment calculations
3/15/2019 • 11 minutes to read • Edit Online
Azure Migrate assesses on-premises workloads for migration to Azure. This article provides information about
how assessments are calculated.
Overview
An Azure Migrate 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.
Boot type Azure supports VMs with boot type as Conditionally ready if boot type is UEFI.
BIOS, and not UEFI.
PROPERTY DETAILS AZURE READINESS STATUS
Cores The number of cores in the machines Ready if less than or equal to limits.
must be equal to or less than the
maximum number of cores (128 cores)
supported for an Azure VM.
NOTE
Azure Migrate considers the OS specified in vCenter Server to do the following analysis. 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 by Azure Migrate to identify the Azure readiness of the VM based on the operating
system.
OPERATING SYSTEM DETAILS AZURE READINESS STATUS
Windows Server 2016 & all SPs Azure provides full support. Ready for Azure
Windows Server 2012 R2 & all SPs Azure provides full support. Ready for Azure
Windows Server 2012 & all SPs Azure provides full support. Ready for Azure
Windows Server 2008 R2 with all SPs Azure provides full support. Ready for Azure
Windows Server 2008 (32-bit and 64- Azure provides full support. Ready for Azure
bit)
Windows Server 2003, 2003 R2 These operating systems have passed Conditionally ready for Azure, consider
their end of support date and need a upgrading the OS before migrating to
Custom Support Agreement (CSA) for Azure.
support in Azure.
Windows 2000, 98, 95, NT, 3.1, MS- These operating systems have passed Conditionally ready for Azure, it is
DOS their end of support date, the machine recommended to upgrade the OS
may boot in Azure, but no OS support before migrating to Azure.
is provided by Azure.
Windows Client 7, 8 and 10 Azure provides support with Visual Conditionally ready for Azure
Studio subscription only.
Windows 10 Pro Desktop Azure provides support with Conditionally ready for Azure
Multitenant Hosting Rights.
Windows Vista, XP Professional These operating systems have passed Conditionally ready for Azure, it is
their end of support date, the machine recommended to upgrade the OS
may boot in Azure, but no OS support before migrating to Azure.
is provided by Azure.
Linux Azure endorses these Linux operating Ready for Azure if the version is
systems. Other Linux operating endorsed.
systems may boot in Azure, but it is
recommended to upgrade the OS to an Conditionally ready if the version is not
endorsed version before migrating to endorsed.
Azure.
Other operating systems Azure does not endorse these Conditionally ready for Azure, it is
operating systems. The machine may recommended to install a supported
e.g., Oracle Solaris, Apple Mac OS etc., boot in Azure, but no OS support is OS before migrating to Azure.
FreeBSD, etc. provided by Azure.
OS specified as Other in vCenter Server Azure Migrate cannot identify the OS in Unknown readiness. Ensure that the OS
this case. running inside the VM is supported in
Azure.
32-bit operating systems The machine may boot in Azure, but Conditionally ready for Azure, consider
Azure may not provide full support. upgrading the OS of the machine from
32-bit OS to 64-bit OS before
migrating to Azure.
Sizing
After a machine is marked as ready for Azure, Azure Migrate sizes the VM and its disks for Azure. If the sizing
criterion specified in the assessment properties is to do performance-based sizing, Azure Migrate considers the
performance history of the machine to identify the VM size and disk type in Azure. This method is helpful in
scenarios where you have over-allocated the on-premises VM but the utilization is low and you would like to
right-size the VMs in Azure to save cost.
If you do not want to consider the performance history for VM -sizing and want to take the VM as-is to Azure, you
can specify the sizing criterion as as on-premises and Azure Migrate will then size the VMs based on the on-
premises configuration without considering the utilization data. Disk sizing, in this case, will be done based on the
Storage type you specify in the assessment properties (Standard disk or Premium disk)
Performance -based sizing
For performance-based sizing, Azure Migrate starts with the disks attached to the VM, followed by network
adapters and then maps an Azure VM based on the compute requirements of the on-premises VM.
Storage: Azure Migrate tries to map every disk attached to the machine to a disk in Azure.
NOTE
Azure Migrate supports only managed disks for assessment.
To get the effective disk I/O per second (IOPS ) and throughput (MBps), Azure Migrate multiplies the
disk IOPS and the throughput with the comfort factor. Based on the effective IOPS and throughput
values, Azure Migrate identifies if the disk should be mapped to a standard or premium disk in Azure.
If Azure Migrate can't find a disk with the required IOPS & throughput, it marks the machine as
unsuitable for Azure. Learn more about Azure limits per disk and VM.
If it finds a set of suitable disks, Azure Migrate selects the ones that support the storage redundancy
method, and the location specified in the assessment settings.
If there are multiple eligible disks, it selects the one with the lowest cost.
If performance data for disks in unavailable, all the disks are mapped to standard disks in Azure.
Network: Azure Migrate tries to find an Azure VM that can support the number of network adapters
attached to the on-premises machine and the performance required by these network adapters.
To get the effective network performance of the on-premises VM, Azure Migrate aggregates the data
transmitted per second (MBps) out of the machine (network out), across all network adapters, and
applies the comfort factor. This number is used to find an Azure VM that can support the required
network performance.
Along with network performance, it also considers if the Azure VM can support the required the
number of network adapters.
If no network performance data is available, only the network adapters count is considered for VM
sizing.
Compute: After storage and network requirements are calculated, Azure Migrate considers CPU and
memory requirements to find a suitable VM size in Azure.
Azure Migrate looks at the utilized cores and memory, and applies the comfort factor to get the
effective cores and memory. Based on that number, it tries to find a suitable VM size in Azure.
If no suitable size is found, the machine 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.
As on-premises sizing
If the sizing criterion is as on-premises sizing, Azure Migrate does not consider the performance history of the
VMs and disks and allocates a VM SKU in Azure based on the size allocated on-premises. Similarly for disk sizing,
it looks at the Storage type specified in assessment properties (Standard/Premium) and recommends the disk
type accordingly. Default storage type is Premium disks.
Confidence rating
Each performance-based assessment in Azure Migrate is associated with a confidence rating that ranges from 1
star to 5 star (1 star being the lowest and 5 star being 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 is not applicable to as on-premises assessments.
For performance-based sizing, Azure Migrate needs the utilization data for CPU, memory of the VM. Additionally,
for every disk attached to the VM, it needs the disk IOPS and throughput data. Similarly for each network adapter
attached to a VM, Azure Migrate needs the network in/out to do performance-based sizing. If any of the above
utilization numbers are not available in vCenter Server, the size recommendation done by Azure Migrate may not
be reliable. Depending on the percentage of data points available, the confidence rating for the assessment is
provided as below:
0%-20% 1 Star
21%-40% 2 Star
41%-60% 3 Star
61%-80% 4 Star
81%-100% 5 Star
Below are the reasons regarding why an assessment could get a low confidence rating:
You did not profile your environment for the duration for which you are creating the assessment. For
example, if you are creating the assessment with performance duration set to 1 day, you need to wait for at
least a day after you start the discovery for all the data points to get collected.
Few VMs were shut down during the period for which the assessment is calculated. If any VMs were
powered off for some duration, we will not be able to collect the performance data for that period.
Few VMs were created in between the period for which the assessment is calculated. For example, if you
are creating an assessment for the performance history of last one month, but few VMs were created in the
environment only a week ago. In such cases, the performance history of the new VMs will not be there for
the entire duration.
NOTE
If the confidence rating of any assessment is below 5 Stars, we recommend you to wait for at least a day for the
appliance to profile the environment and then Recalculate the assessment. If the preceding cannot be done ,
performance-based sizing may not be reliable and it is recommended to switch to as on-premises sizing by
changing the assessment properties.
Next steps
Create an assessment for on-premises VMware VMs
Dependency visualization
3/14/2019 • 3 minutes to read • Edit Online
The Azure Migrate services assesses groups of on-premises machines for migration to Azure. You can use the
dependency visualization functionality in Azure Migrate to create groups. This article provides information about
this feature.
NOTE
The dependency visualization functionality is not available in Azure Government.
Overview
Dependency visualization in Azure Migrate allows you to create high-confidence groups for migration
assessments. Using dependency visualization you can view network dependencies of machines and identify related
machines that needed to be migrated together to Azure. This functionality is useful in scenarios where you are not
completely aware of the machines that constitute your application and need to be migrated together to Azure.
While associating a workspace, you will get the option to create a new workspace or attach an existing one:
When you create a new workspace, you need to specify a name for the workspace. The workspace is then
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. Note that only those workspaces are listed which were created in a
region where Service Map is supported. To be able to attach a workspace, ensure that you have 'Reader'
access to the workspace.
NOTE
Once you have attached a workspace to a project, you cannot change it later.
The associated workspace is tagged with the key Migration Project, and value Project name, which you
can use to search in the Azure portal.
To navigate to the workspace associated with the project, you can go to Essentials section of the project
Overview page and access the workspace
To use dependency visualization, you need to download and install agents on each on-premises machine that you
want to analyze.
Microsoft Monitoring agent(MMA) needs to be installed on each machine.
The Dependency agent needs to be installed on each machine.
In addition, if you have machines with no internet connectivity, you need to download and install Log Analytics
gateway on them.
You don't need these agents on machines you want to assess unless you're using dependency visualization.
NOTE
The dependency visualization feature uses Service Map via a Log Analytics workspace. Since 28 February 2018, with the
announcement of Azure Migrate general availability, the feature is now available at no extra charge. You will need to create a
new project to make use of the free usage workspace. Existing workspaces before general availability are still chargeable,
hence we recommend you to move to a new project.
Next steps
Group machines using machine dependencies
Learn more about the FAQs on dependency visualization.
Contoso migration series
6/5/2019 • 3 minutes to read • Edit Online
We have a series of articles that demonstrates how the fictitious organization Contoso migrates on-premises
infrastructure to the Microsoft Azure cloud.
The series includes information and scenarios that illustrate how to set up a migration of infrastructure, and run
different types of migrations. Scenarios grow in complexity as they progress. The articles show how the Contoso
company completes its migration mission, but pointers for general reading and specific instructions are provided
throughout.
Migration articles
The articles in the series are summarized in the table below.
Each migration scenario is driven by slightly different business goals that determine the migration strategy.
For each deployment scenario, we provide information about business drivers and goals, a proposed
architecture, steps to perform the migration, and recommendation for cleanup and next steps after migration is
complete.
ARTICLE DETAILS
Article 2: Deploy Azure infrastructure Contoso prepares its on-premises infrastructure and its Azure
infrastructure for migration. The same infrastructure is used
for all migration articles in the series.
Article 3: Assess on-premises resources for migration to Azure Contoso runs an assessment of its on-premises
SmartHotel360 app running on VMware. Contoso assesses
app VMs using the Azure Migrate service, and the app SQL
Server database using Data Migration Assistant.
Article 4: Rehost an app on an Azure VM and SQL Database Contoso runs a lift-and-shift migration to Azure for its on-
Managed Instance premises SmartHotel360 app. Contoso migrates the app
front-end VM using Azure Site Recovery. Contoso migrates
the app database to an Azure SQL Database Managed
Instance using the Azure Database Migration Service.
Article 5: Rehost an app on Azure VMs Contoso migrates its SmartHotel360 app VMs to Azure VMs
by using the Site Recovery service.
Article 6: Rehost an app on Azure VMs and in a SQL Server Contoso migrates the SmartHotel360 app. Contoso uses Site
AlwaysOn availability group Recovery to migrate the app VMs. It uses the Database
Migration Service to migrate the app database to a SQL Server
cluster that's protected by an AlwaysOn availability group.
Article 7: Rehost a Linux app on Azure VMs Contoso completes a lift-and-shift migration of its Linux
osTicket app to Azure VMs, using the Site Recovery service.
ARTICLE DETAILS
Article 8: Rehost a Linux app on Azure VMs and Azure Contoso migrates its Linux osTicket app to Azure VMs by
Database for MySQL using Site Recovery. It migrates the app database to Azure
Database for MySQL by using MySQL Workbench.
Article 9: Refactor an app in an Azure web app and Azure SQL Contoso migrates its SmartHotel360 app to an Azure web app
Database and migrates the app database to an Azure SQL Server
instance with the Database Migration Assistant.
Article 10: Refactor a Linux app in an Azure web app and Contoso migrates its Linux osTicket app to an Azure web app
Azure Database for MySQL on multiple Azure regions using Azure Traffic Manager,
integrated with GitHub for continuous delivery. Contoso
migrates the app database to an Azure Database for MySQL
instance.
Article 11: Refactor Team Foundation Server on Azure DevOps Contoso migrates its on-premises Team Foundation Server
Services deployment to Azure DevOps Services in Azure.
Article 12: Rearchitect an app in Azure containers and Azure Contoso migrates its SmartHotel app to Azure. Then, it
SQL Database rearchitects the app web tier as a Windows container running
in Azure Service Fabric, and the database with Azure SQL
Database.
Article 13: Rebuild an app in Azure Contoso rebuilds its SmartHotel app by using a range of Azure
capabilities and services, including Azure App Service, Azure
Kubernetes Service (AKS), Azure Functions, Azure Cognitive
Services, and Azure Cosmos DB.
Article 14: Scale a migration to Azure After trying out migration combinations, Contoso prepares to
scale to a full migration to Azure.
Next steps
Learn about cloud migration.
Discover and assess a large VMware environment
5/10/2019 • 14 minutes to read • Edit Online
Azure Migrate has a limit of 1500 machines per project, this article describes how to assess large numbers of on-
premises virtual machines (VMs) by using Azure Migrate.
NOTE
We have a preview release available that allows discovery of up to 10,000 VMware VMs in a single project using a single
appliance, if you are interested in trying it out, please sign up here.
Prerequisites
VMware: The VMs that you plan to migrate must be managed by vCenter Server version 5.5, 6.0, 6.5 or 6.7.
Additionally, you need one ESXi host running version 5.5 or later to deploy the collector VM.
vCenter account: You need a read-only account to access vCenter Server. Azure Migrate uses this account to
discover the on-premises VMs.
Permissions: In vCenter Server, you need permissions to create a VM by importing a file in OVA format.
Statistics settings: This requirement is only applicable to the one-time discovery model which is deprecated
now. For one-time discovery model, the statistics settings for vCenter Server should be set to level 3 before
you start deployment. The statistics level is to be set to 3 for each of the day, week, and month collection
intervals. If the level is lower than 3 for any of the three collection intervals, the assessment will work, but the
performance data for storage and network won't be collected. The size recommendations will then be based on
performance data for CPU and memory, and configuration data for disk and network adapters.
NOTE
The one-time discovery appliance is now deprecated as this method relied on vCenter Server's statistics settings for
performance data point availability and collected average performance counters which resulted in under-sizing of VMs for
migration to Azure.
Set up permissions
Azure Migrate needs access to VMware servers to automatically discover VMs for assessment. The VMware
account needs the following permissions:
User type: At least a read-only user
Permissions: Data Center object –> Propagate to Child Object, role=Read-only
Details: 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).
If you are deploying in a multi-tenant environment and would like to scope by folder of VMs for a single tenant,
you cannot directly select the VM folder when scoping collection in Azure Migrate. Following are instructions on
how to scope discovery by folder of VMs:
1. Create a user per tenant and assign read-only permissions to all the VMs belonging to a particular tenant.
2. Grant this user read-only access to all the parent objects where the VMs are hosted. All parent objects - host,
folder of hosts, cluster, folder of clusters - in the hierarchy up to the data center are to be included. You do not
need to propagate the permissions to all child objects.
3. Use the credentials for discovery selecting datacenter as Collection Scope. The RBAC set up ensures that the
corresponding vCenter user will have access to only tenant-specific VMs.
NOTE
The one-time discovery appliance is now deprecated as this method relied on vCenter Server's statistics settings for
performance data point availability and collected average performance counters which resulted in under-sizing of VMs for
migration to Azure. It is recommended to move to the continuous discovery appliance.
Project 1,500
Discovery 1,500
Assessment 1,500
NOTE
The one-time discovery appliance is now deprecated as this method relied on vCenter Server's statistics settings for
performance data point availability and collected average performance counters which resulted in under-sizing of
VMs for migration to Azure.
Instant gratification: With the continuous discovery appliance, once the discovery is complete (takes
couple of hours depending on the number of VMs), you can immediately create assessments. Since the
performance data collection starts when you kick off discovery, if you are looking for instant gratification,
you should select the sizing criterion in the assessment as as on-premises. For performance-based
assessments, it is advised to wait for at least a day after kicking off discovery to get reliable size
recommendations.
Note that the appliance only collects performance data continuously, it does not detect any configuration
change in the on-premises environment (i.e. VM addition, deletion, disk addition etc.). If there is a
configuration change in the on-premises environment, you can do the following to reflect the changes in
the portal:
Addition of items (VMs, disks, cores etc.): To reflect these changes in the Azure portal, you can stop
the discovery from the appliance and then start it again. This will ensure that the changes are
updated in the Azure Migrate project.
Deletion of VMs: Due to the way the appliance is designed, deletion of VMs is not reflected even if
you stop and start the discovery. This is because data from subsequent discoveries are appended to
older discoveries and not overridden. In this case, you can simply ignore the VM in the portal, by
removing it from your group and recalculating the assessment.
3. In Copy project credentials, copy the ID and key for the project. You need these when you configure the
collector.
Verify the collector appliance
Check that the OVA 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 command to generate the hash for the OVA:
C:\>CertUtil -HashFile <file_location> [Hashing Algorithm]
3. Make sure that the generated hash matches the following settings.
Continuous discovery
For OVA version 1.0.10.4
ALGORITHM HASH VALUE
MD5 2ca5b1b93ee0675ca794dd3fd216e13d
SHA1 8c46a52b18d36e91daeae62f412f5cb2a8198ee5
SHA256 3b3dec0f995b3dd3c6ba218d436be003a687710abab9fcd17d
4bdc90a11276be
MD5 e9ef16b0c837638c506b5fc0ef75ebfa
SHA1 37b4b1e92b3c6ac2782ff5258450df6686c89864
SHA256 8a86fc17f69b69968eb20a5c4c288c194cdcffb4ee6568d85ae
5ba96835559ba
MD5 6d8446c0eeba3de3ecc9bc3713f9c8bd
SHA1 e9f5bdfdd1a746c11910ed917511b5d91b9f939f
SHA256 7f7636d0959379502dfbda19b8e3f47f3a4744ee9453fc9ce54
8e6682a66f13c
MD5 d0363e5d1b377a8eb08843cf034ac28a
SHA1 df4a0ada64bfa59c37acf521d15dcabe7f3f716b
SHA256 f677b6c255e3d4d529315a31b5947edfe46f45e4eb4dbc8019
d68d1d1b337c2e
MD5 b5d9f0caf15ca357ac0563468c2e6251
SHA1 d6179b5bfe84e123fabd37f8a1e4930839eeb0e5
SHA256 09c68b168719cb93bd439ea6a5fe21a3b01beec0e15b84204
857061ca5b116ff
For OVA version 1.0.9.7
MD5 d5b6a03701203ff556fa78694d6d7c35
SHA1 f039feaa10dccd811c3d22d9a59fb83d0b01151e
SHA256 e5e997c003e29036f62bf3fdce96acd4a271799211a84b34b3
5dfd290e9bea9c
2. In the Deploy OVF Template Wizard > Source, specify the location of the OVA file.
3. In Name and Location, specify a friendly name for the collector VM, and the inventory object in which the
VM will be hosted.
4. In Host/Cluster, specify the host or cluster on which the collector VM will run.
5. In storage, specify the storage destination for the collector VM.
6. In Disk Format, specify the disk type and size.
7. In Network Mapping, specify the network to which the collector VM will connect. The network needs
internet connectivity to send metadata to Azure.
8. Review and confirm the settings, and then select Finish.
Identify the ID and key for each project
If you have multiple projects, be sure to identify the ID and key for each one. You need the key when you run the
collector to discover the VMs.
1. In the project, select Getting Started > Discover & Assess > Discover Machines.
2. In Copy project credentials, copy the ID and key for the project.
WARNING
The one-time discovery method that relied on vCenter Server's statistic settings for performance data collection is now
deprecated.
Next steps
Learn how to create a group for assessment.
Learn more about how assessments are calculated.
Group machines for assessment
12/11/2018 • 2 minutes to read • Edit Online
This article describes how to create a group of machines for assessment by Azure Migrate. Azure Migrate assesses
machines in the group to check whether they're suitable for migration to Azure, and provides sizing and cost
estimations for running the machine in Azure. If you know the machines that need be migrated together, you can
manually create the group in Azure Migrate using the following method. If you are not very sure about the
machines that need to be grouped together, you can use the dependency visualization functionality in Azure
Migrate to create groups. Learn more.
NOTE
The dependency visualization functionality is not available in Azure Government.
Create a group
1. In the Overview of the Azure Migrate project, under Manage, clickGroups>+Group, and specify a group
name.
2. Add one or more machines to the group, and clickCreate.
3. You can optionally select to run a new assessment for the group.
After the group is created, you can modify it by selecting the group on the Groups page, and then adding or
removing machines.
Next steps
Learn how to use machine dependency mapping to create high confidence groups.
Learn more about how assessments are calculated.
Group machines using machine dependency
mapping
4/9/2019 • 7 minutes to read • Edit Online
This article describes how to create a group of machines for Azure Migrate assessment by visualizing
dependencies of machines. You typically use this method when you want to assess groups of VMs 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 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.
NOTE
The dependency visualization functionality is not available in Azure Government.
While associating a workspace, you will get the option to create a new workspace or attach an existing one:
When you create a new workspace, you need to specify a name for the workspace. The workspace is
then 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. Note that only those workspaces are listed which were created in
a region where Service Map is supported. To be able to attach a workspace, ensure that you have
'Reader' access to the workspace.
NOTE
You cannot change the workspace associated to a migration project.
NOTE
To automate the installation of agents you can use any deployment tool like System Center Configuration Manager or use
our partner tool, Intigua, that has an agent deployment solution for Azure Migrate.
Learn more about the list of Linux operating systems support by MMA.
Install the agent on a machine monitored by SCOM
For machines monitored by System Center Operations Manager 2012 R2 or later, there is no need to install the
MMA agent. Service Map has an integration with SCOM that leverages the SCOM MMA to gather the necessary
dependency data. You can enable the integration using the guidance here. Note, however, that the dependency
agent will need to installed on these machines.
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.
Create a group
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
Properties like Fully Qualified Domain Name, Operating System, MAC Address etc. of each
machine, you can click on each machine box to view these details
5. 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.
NOTE
Currently, the dependency visualization UI does not support selection of a time range longer than an hour. Use
Azure Monitor logs to query the 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 cannot 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.
Summarize volume of data sent and received on inbound connections between a set of machines
Next steps
Learn more about the FAQs on dependency visualization.
Learn how to refine the group by visualizing group dependencies.
Learn more about how assessments are calculated.
Refine a group using group dependency mapping
4/9/2019 • 7 minutes to read • Edit Online
This article describes how to refine a group by visualizing dependencies of all machines in the group. You typically
use this method when you want to refine membership for an existing group, by cross-checking group
dependencies, before you run an assessment. Refining a group using dependency visualization can help you
effectively plan your migration to Azure. You can discover all interdependent systems that need to migrate
together. It helps you ensure that nothing is left behind and surprise outages do not occur when you are migrating
to Azure.
NOTE
Groups for which you want to visualize dependencies shouldn't contain more than 10 machines. If you have more than 10
machines in the group, we recommend you to split it into smaller groups to leverage the dependency visualization
functionality.
NOTE
This article was recently updated to use the term Azure Monitor logs instead of Log Analytics. Log data is still stored in a Log
Analytics workspace and is still collected and analyzed by the same Log Analytics service. We are updating the terminology to
better reflect the role of logs in Azure Monitor. See Azure Monitor terminology changes for details.
NOTE
The dependency visualization functionality is not available in Azure Government.
NOTE
You cannot change the workspace associated to a migration project.
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.
4. To view more granular dependencies, click the time range to modify it. By default, the range is an hour. You
can modify the time range, or specify start and end dates, and duration.
NOTE
Currently, the dependency visualization UI does not support selection of a time range longer than an hour. Use Azure
Monitor logs to query the dependency data over a longer duration.
5. Verify the dependent machines, the process running inside each machine and identify the machines that
should be added or removed from the group.
6. Use Ctrl+Click to select machines on the map to add or remove them from the group.
You can only add machines that have been discovered.
Adding and removing machines from a group invalidates past assessments for it.
You can optionally create a new assessment when you modify the group.
7. Click OK to save the group.
If you want to check the dependencies of a specific machine that appears in the group dependency map, set up
machine dependency mapping.
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
Summarize volume of data sent and received on inbound connections between a set of machines
Next steps
Learn more about the FAQs on dependency visualization.
Learn more about how assessments are calculated.
Customize an assessment
1/10/2019 • 5 minutes to read • Edit Online
Azure Migrate creates assessments with default properties. After creating an assessment, you can modify the
default properties using the instructions in this article.
Target location The Azure location to which you want West US 2 is the default location.
to migrate.
Storage type You can use this property to specify The default value is Premium-
the type of disks you want to move managed disks (with Sizing criterion
to in Azure. For as-on premises as as on-premises sizing).
sizing, you can specify the target disk
type either as Premium-managed
disks or Standard-managed disks. For
performance-based sizing, you can
specify the target disk type either as
Automatic, Premium-managed disks
or Standard-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). For example, 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. Note that Azure Migrate only
supports managed disks for
migration assessment.
SETTING DETAILS DEFAULT
Reserved Instances You can also specify if you have The default value for this property is
reserved instances in Azure and 3-years reserved instances.
Azure Migrate will estimate the cost
accordingly. Reserved instances are
currently only supported for Pay-As-
You-Go offer in Azure Migrate.
VM series You can specify the VM series that By default, all VM series are selected.
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.
Offer Azure Offer that you are enrolled to. Pay-as-you-go is the default.
VM uptime If your VMs are not going to be The default value is 31 days per
running 24x7 in Azure, you can month and 24 hours per day.
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.
Azure Migrate assesses on-premises machines to check whether they're suitable for migration to Azure, and
provides sizing and cost estimations for running the machine in Azure. Currently, Azure Migrate only assesses
machines for migration. The migration itself is currently performed using other Azure services.
This article describes how to get suggestions for a migration tool after you've run a migration assessment.
NOTE
The migration tool suggestion is not available in Azure Government.
3. In Suggested Tool, review the suggestions for tools you can use for migration.
Next steps
Learn more about how assessments are calculated.
Scale migration of VMs using Azure Site Recovery
4/1/2019 • 3 minutes to read • Edit Online
This article helps you understand the process of using scripts to migrate large number of VMs using Azure Site
Recovery. These 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 Azure and support migration to
managed disks. You can also use these scripts to migrate Hyper-V VMs if you migrate the VMs as physical servers.
The scripts leverage Azure Site Recovery PowerShell documented here.
Current Limitations:
Support 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
Deletion of VMs: Due to the way the appliance is designed, deletion of VMs is not reflected even if you stop
and start the discovery. This is because data from subsequent discoveries are appended to older discoveries
and not overridden. In this case, you can simply ignore the VM in the portal, by removing it from your group
and recalculating the assessment.
Deletion of Azure Migrate projects and associated Log Analytics workspace
When you delete an Azure Migrate project, it deletes the migration project along with all the groups and
assessments. However, if you have attached a Log Analytics workspace to the project, it does not automatically
delete the Log Analytics workspace. This is because the same Log Analytics workspace might be used for multiple
use cases. If you would like to delete the Log Analytics workspace as well, you need to do it manually.
1. Browse to the Log Analytics workspace attached to the project. a. If you have not deleted the migration
project yet, you can find the link to the workspace from the project overview page in the Essentials section.
b. If you already deleted the migration project, click Resource Groups in the left pane in Azure portal and
go to the Resource Group in which the workspace was created and then browse to it.
2. Follow the instructions in this article to delete the workspace.
Migration project creation failed with error Requests must contain user identity headers
This issue can happen for users who do not have access to the Azure Active Directory (Azure AD ) tenant of the
organization. When a user is added to an Azure AD tenant for the first time, he/she receives an email invite to join
the tenant. Users need to go to the email and accept the invitation to get successfully added to the tenant. If you are
unable to see the email, reach out to a user who already has access to the tenant and ask them to resend the
invitation to you using the steps specified here.
Once the invitation email is received, you need to open the email and click the link in the email to accept the
invitation. Once this is done, you need to sign out of Azure portal and sign-in again, refreshing the browser will not
work. You can then try creating the migration project.
I am unable to export the assessment report
If you are unable to export the assessment report from the portal, try using the below REST API to get a download
URL for the assessment report.
1. Install armclient on your computer (if you don’t have it already installed):
a. In an administrator Command Prompt window, run the following command:
@powershell -NoProfile -ExecutionPolicy Bypass -Command "iex ((New-Object
System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))" && SET
"PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin"
b. In an administrator Windows PowerShell window, run the following command: choco install armclient
2. Get the download URL for the assessment report using Azure Migrate REST API
a. In an administrator Windows PowerShell window, run the following command: armclient login
This opens the Azure login pop-up where you need to sign in to Azure.
b. In the same PowerShell window, run the following command to get the download URL for the
assessment report (replace the URI parameters with the appropriate values, sample API request below )
```armclient POST
https://management.azure.com/subscriptions/{subscriptionID}/resourceGroups/{resourceGroupName}/providers
/Microsoft.Migrate/projects/{projectName}/groups/{groupName}/assessments/{assessmentName}/downloadUrl?
api-version=2018-02-02```
3. Copy the URL from the response and open it in a browser to download the assessment report.
4. Once the report is downloaded, use Excel to browse to the downloaded folder and open the file in Excel to
view it.
Performance data for CPU, memory and disks is showing up as zeroes
Azure Migrate continuously profiles the on-premises environment to collect performance data of the on-premises
VMs. If you have just started the discovery of your environment, you need to wait for at least a day for the
performance data collection to be done. If an assessment is created without waiting for one day, the performance
metrics will show up as zeroes. After waiting for a day, you can either create a new assessment or update the
existing assessment by using the 'Recalculate' option in the assessment report.
I specified an Azure geography, while creating a migration project, how do I find out the exact Azure region
where the discovered metadata would be stored?
You can go to the Essentials section in the Overview page of the project to identify the exact location where the
metadata is stored. The location is selected randomly within the geography by Azure Migrate and you cannot
modify it. If you want to create a project in a specific region only, you can use the REST APIs to create the
migration project and pass the desired region.
Collector issues
Deployment of Azure Migrate Collector failed with the error: The provided manifest file is invalid: Invalid OVF
manifest entry.
1. Verify if Azure Migrate Collector OVA file is downloaded correctly by checking its hash value. Refer to the article
to verify the hash value. If the hash value is not matching, download the OVA file again and retry the
deployment.
2. If it still fails and if you are using VMware vSphere Client to deploy the OVF, try deploying it through vSphere
Web Client. If it still fails, try using different web browser.
3. If you are using vSphere web client and trying to deploy it on vCenter Server 6.5 or 6.7, try to deploy the OVA
directly on ESXi host by following the below steps:
Connect to the ESXi host directly (instead of vCenter Server) using the web client (https://<host IP
Address>/ui)
Go to Home > Inventory
Click File > Deploy OVF template > Browse to the OVA and complete the deployment
4. If the deployment still fails, contact Azure Migrate support.
Unable to select the Azure cloud in the appliance, fails with error "Azure cloud selection failed"
This is a known issue and a fix is available for the issue. Please download the latest upgrade bits for the appliance
and update the appliance to apply the fix.
Collector is not able to connect to the internet
This can happen when the machine you are using is behind a proxy. Make sure you provide the authorization
credentials if the proxy needs one. If you are using any URL -based firewall proxy to control outbound connectivity,
be sure to whitelist these required URLs:
URL PURPOSE
The collector can't connect to the internet because of a certificate validation failure
This can happen if you are using an intercepting proxy to connect to the Internet, and if you have not imported the
proxy certificate on to the collector VM. You can import the proxy certificate using the steps detailed here.
The collector can't connect to the project using the project ID and key I copied from the portal.
Make sure you've copied and pasted the right information. To troubleshoot, install the Microsoft Monitoring Agent
(MMA) and verify if the MMA can connect to the project as follows:
1. On the collector VM, download the MMA.
2. To start the installation, double-click the downloaded file.
3. In setup, on the Welcome page, click Next. On the License Terms page, click I Agree to accept the license.
4. In Destination Folder, keep or modify the default installation folder > Next.
5. In Agent Setup Options, select Azure Log Analytics > Next.
6. Click Add to add a new Log Analytics workspace. Paste in project ID and key that you copied. Then click Next.
7. Verify that the agent can connect to the project. If it can't, verify the settings. If the agent can connect but the
collector can't, contact Support.
Error 802: Date and time synchronization error
The server clock might be out-of-synchronization with the current time by more than five minutes. Change the
clock time on the collector VM to match the current time, as follows:
1. Open an admin command prompt on the VM.
2. To check the time zone, run w32tm /tz.
3. To synchronize the time, run w32tm /resync.
VMware PowerCLI installation failed
Azure Migrate collector downloads PowerCLI and installs it on the appliance. Failure in PowerCLI installation could
be due to unreachable endpoints for the PowerCLI repository. To troubleshoot, try manually installing PowerCLI in
the collector VM using the following step:
1. Open Windows PowerShell in administrator mode
2. Go to the directory C:\ProgramFiles\ProfilerService\VMWare\Scripts\
3. Run the script InstallPowerCLI.ps1
Error UnhandledException Internal error occurred: System.IO.FileNotFoundException
This issue could occur due to an issue with VMware PowerCLI installation. Follow the below steps to resolve the
issue:
1. If you are not on the latest version of the collector appliance, upgrade your Collector to the latest version
and check if the issue is resolved.
2. If you already have the latest collector version, follow the below steps to do a clean installation of PowerCLI :
a. Close the web browser in the appliance.
b. Stop the 'Azure Migrate Collector' service by going to Windows Service Manager (Open 'Run' and type
services.msc to open Windows Service Manager). Right click on Azure Migrate Collector Service and click
Stop.
c. Delete all folders starting with 'VMware' from the following locations: C:\Program
Files\WindowsPowerShell\Modules
C:\Program Files (x86)\WindowsPowerShell\Modules
d. Restart the 'Azure Migrate Collector' service in Windows Service Manager (Open 'Run' and type
services.msc to open Windows Service Manager). Right click on Azure Migrate Collector Service and click
Start.
e. Double-click the desktop shortcut 'Run collector' to start the collector application. The collector
application should automatically download and install the required version of PowerCLI.
3. If the above does not resolve the issue, follow steps a to c above and then manually install PowerCLI in the
appliance using the following steps:
a. Clean up all incomplete PowerCLI installation files by following steps #a to #c in step #2 above.
b. Go to Start > Run > Open Windows PowerShell(x86) in administrator mode
c. Run the command: Install-Module "VMWare.VimAutomation.Core" -RequiredVersion "6.5.2.6234650"
(type 'A' when it asks for confirmation)
d. Restart the 'Azure Migrate Collector' service in Windows Service Manager (Open 'Run' and type
services.msc to open Windows Service Manager). Right click on Azure Migrate Collector Service and click
Start.
e. Double-click the desktop shortcut 'Run collector' to start the collector application. The collector
application should automatically download and install the required version of PowerCLI.
4. If you are unable to download the module in the appliance due to firewall issues, download and install the
module in a machine that has access to internet using the following steps:
a. Clean up all incomplete PowerCLI installation files by following steps #a to #c in step #2 above.
b. Go to Start > Run > Open Windows PowerShell(x86) in administrator mode
c. Run the command: Install-Module "VMWare.VimAutomation.Core" -RequiredVersion "6.5.2.6234650"
(type 'A' when it asks for confirmation)
d. Copy all modules starting with "VMware" from “C:\Program Files (x86)\WindowsPowerShell\Modules”
to the same location on the collector VM.
e. Restart the 'Azure Migrate Collector' service in Windows Service Manager (Open 'Run' and type
services.msc to open Windows Service Manager). Right click on Azure Migrate Collector Service and click
Start.
f. Double-click the desktop shortcut 'Run collector' to start the collector application. The collector application
should automatically download and install the required version of PowerCLI.
Error UnableToConnectToServer
Unable to connect to vCenter Server "Servername.com:9443" due to error: There was no endpoint listening at
https://Servername.com:9443/sdk that could accept the message.
Check if you are running the latest version of the collector appliance, if not, upgrade the appliance to the latest
version.
If the issue still happens in the latest version, it could be because the collector machine is unable to resolve the
vCenter Server name specified or the port specified is wrong. By default, if the port is not specified, collector will
try to connect to the port number 443.
1. Try to ping the Servername.com from the collector machine.
2. If step 1 fails, try to connect to the vCenter server over IP address.
3. Identify the correct port number to connect to the vCenter.
4. Finally check if the vCenter server is up and running.
Antivirus exclusions
To harden the Azure Migrate appliance, you need to exclude the following folders in the appliance from antivirus
scanning:
Folder that has the binaries for Azure Migrate Service. Exclude all sub-folders. %ProgramFiles%\ProfilerService
Azure Migrate Web Application. Exclude all sub-folders. %SystemDrive%\inetpub\wwwroot
Local Cache for Database and log files. Azure migrate service needs RW access to this folder.
%SystemDrive%\Profiler
Unsupported boot type Azure does not support VMs with EFI boot type. It is
recommended to convert the boot type to BIOS before you
run a migration.
Conditionally supported Windows OS The OS has passed its end of support date and needs a
Custom Support Agreement (CSA) for support in Azure,
consider upgrading the OS before migrating to Azure.
Conditionally endorsed Linux OS Azure endorses only selected Linux OS versions, consider
upgrading the OS of the machine before migrating to Azure.
Unknown operating system The operating system of the VM was specified as 'Other' in
vCenter Server, due to which Azure Migrate cannot identify
the Azure readiness of the VM. Ensure that the OS running
inside the machine is supported by Azure before you migrate
the machine.
Requires Visual Studio subscription. The machines has a Windows client OS running inside it which
is supported only in Visual Studio subscription.
VM not found for the required storage performance. The storage performance (IOPS/throughput) required for the
machine exceeds Azure VM support. Reduce storage
requirements for the machine before migration.
VM not found for the required network performance. The network performance (in/out) required for the machine
exceeds Azure VM support. Reduce the networking
requirements for the machine.
VM not found in the specified location. Use a different target location before migration.
One or more unsuitable disks. One or more disks attached to the VM do not meet the Azure
requirements. For each disk attached to the VM, ensure that
the size of the disk is < 4 TB, if not, shrink the disk size before
migrating to Azure. Ensure that the performance
(IOPS/throughput) needed by each disk is supported by Azure
managed virtual machine disks.
One or more unsuitable network adapters. Remove unused network adapters from the machine before
migration.
ISSUE FIX
Disk count exceeds limit Remove unused disks from the machine before migration.
Disk size exceeds limit Azure supports disks with up to size 4 TB. Shrink disks to less
than 4 TB before migration.
Disk unavailable in the specified location Make sure the disk is in your target location before you
migrate.
Disk unavailable for the specified redundancy The disk should use the redundancy storage type defined in
the assessment settings (LRS by default).
Could not determine disk suitability due to an internal error Try creating a new assessment for the group.
VM with required cores and memory not found Azure couldn't fine a suitable VM type. Reduce the memory
and number of cores of the on-premises machine before you
migrate.
Could not determine VM suitability due to an internal error. Try creating a new assessment for the group.
Could not determine suitability for one or more disks due to Try creating a new assessment for the group.
an internal error.
Could not determine suitability for one or more network Try creating a new assessment for the group.
adapters due to an internal error.
Collect logs
How do I collect logs on the collector VM?
Logging is enabled by default. Logs are located as follows:
C:\Profiler\ProfilerEngineDB.sqlite
C:\Profiler\Service.log
C:\Profiler\WebApp.log
To collect Event Tracing for Windows, do the following:
1. On the collector VM, open a PowerShell command window.
2. Run Get-EventLog -LogName Application | export-csv eventlog.csv.
How do I collect portal network traffic logs?
1. Open the browser and navigate and log in to the portal.
2. Press F12 to start the Developer Tools. If needed, clear the setting Clear entries on navigation.
3. Click 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 capture. If it doesn't appear, click the black circle to start
In Microsoft Edge/IE, recording should start automatically. If it doesn't, click 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 click Save as HAR with content. This zips and exports the logs as a .har file.
In Microsoft Edge/IE, click the Export captured traffic icon. This zips and exports the log.
6. Navigate to 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/IE, right-click on the errors and select Copy all.
7. Close Developer Tools.
751 UnableToConnectToSe Unable to connect to Check the error Resolve the issue and
rver vCenter Server message for more try again.
'%Name;' due to details.
error: %ErrorMessage;
752 InvalidvCenterEndpoi The server '%Name;' Provide vCenter Retry the operation
nt is not a vCenter Server details. with correct vCenter
Server. Server details.
753 InvalidLoginCredential Unable to connect to Connection to the Ensure that the login
s the vCenter Server vCenter Server failed credentials provided
'%Name;' due to due to invalid login are correct.
error: %ErrorMessage; credentials.
754 NoPerfDataAvailable Performance data not Check Statistics Level Change Statistics
available. in vCenter Server. It Level to 3 (for 5
should be set to 3 for minutes, 30 minutes,
performance data to and 2 hours duration)
be available. and try after waiting
at least for a day.
756 NullInstanceUUID Encountered a vCenter Server may Resolve the issue and
machine with null have an inappropriate try again.
InstanceUUID object.
757 VMNotFound Virtual machine is not Virtual machine may Ensure that the virtual
found be deleted: %VMID; machines selected
while scoping vCenter
inventory exists
during the discovery
802 TimeSyncError Time is not in sync Time is not in sync Ensure that the time
with the internet time with the internet time on the machine is
server. server. accurately set for the
machine's time zone
and retry the
operation.
702 OMSInvalidProjectKey Invalid project key Invalid project key Retry the operation
specified. specified. with correct project
key.
703 OMSHttpRequestExce Error while sending Check project ID and Retry the operation. If
ption request. Message key and ensure that the issue persists,
%Message; endpoint is reachable. contact Microsoft
Support.
704 OMSHttpRequestTim HTTP request timed Check project ID and Retry the operation. If
eoutException out. Message key and ensure that the issue persists,
%Message; endpoint is reachable. contact Microsoft
Support.
Azure Migrate - Frequently Asked Questions (FAQ)
4/15/2019 • 13 minutes to read • Edit Online
This article includes frequently asked questions about Azure Migrate. If you have any further queries after reading
this article, post them on the Azure Migrate forum.
General
Does Azure Migrate support assessment of only VMware workloads?
Yes, Azure Migrate currently only supports assessment of VMware workloads. Support for Hyper-V is in preview,
please sign up here to get access to the preview. Support for physical servers will be enabled in future.
Does Azure Migrate need vCenter Server to discover a VMware environment?
Yes, Azure Migrate requires vCenter Server to discover a VMware environment. It does not support discovery of
ESXi hosts that are not managed by a vCenter Server.
How is Azure Migrate different from Azure Site Recovery?
Azure Migrate is an assessment service that helps you discover your on-premises workloads and plan your
migration to Azure. Azure Site Recovery, along with being a disaster recovery solution, helps you migrate on-
premises workloads to IaaS VMs in Azure.
What's the difference between using Azure Migrate for assessments and the Map Toolkit?
Azure Migrate provides migration assessment specifically to assist with migration readiness and evaluation of on-
premises workloads into Azure. Microsoft Assessment and Planning (MAP ) Toolkit has other functionalities such
as migration planning for newer versions of Windows client and server operating systems and software usage
tracking. For those scenarios, continue to use the MAP Toolkit.
How is Azure Migrate different from Azure Site Recovery Deployment Planner?
Azure Migrate is a migration planning tool and Azure Site Recovery Deployment Planner is a disaster recovery
(DR ) planning tool.
Migration from VMware to Azure: If you intend to migrate your on-premises workloads to Azure, use Azure
Migrate for migration planning. Azure Migrate assesses on-premises workloads and provides guidance, insights,
and mechanisms to assist you in migrating to Azure. Once you are ready with your migration plan, you can use
services such as Azure Site Recovery and Azure Database Migration Service to migrate the machines to Azure.
Migration from Hyper-V to Azure: The Generally Available version of Azure Migrate currently supports
assessment of VMware virtual machines for migration to Azure. Support for Hyper-V is currently in preview with
production support. If you are interested in trying out the preview, please sign up here.
Disaster Recovery from VMware/Hyper-V to Azure: If you intend to do disaster recovery (DR ) on Azure using
Azure Site Recovery (Site Recovery), use Site Recovery Deployment Planner for DR planning. Site Recovery
Deployment Planner does a deep, ASR -specific assessment of your on-premises environment. It provides
recommendations that are required by Site Recovery for successful DR operations such as replication, failover of
your virtual machines.
Which Azure geographies are supported by Azure Migrate?
Azure Migrate currently supports Europe, United States, and Azure Government as the project geographies. Even
though you can only create migration projects in these geographies, you can still assess your machines for
multiple target locations. The project geography is only used to store the discovered metadata.
GEOGRAPHY METADATA STORAGE LOCATION
Discovery
What data is collected by Azure Migrate?
Azure Migrate supports two kinds of discovery, appliance-based discovery and agent-based discovery. The
appliance-based discovery collects metadata about the on-premises VMs, the complete list of metadata collected
by the appliance is listed below:
Configuration data of the VM
VM display name (on vCenter)
VM inventory path (host/cluster/folder in vCenter)
IP address
MAC address
Operating system
Number of cores, disks, NICs
Memory size, Disk sizes
Performance data of the VM
CPU usage
Memory usage
For each disk attached to the VM:
Disk read throughput
Disk writes throughput
Disk read operations per sec
Disk writes operations per sec
For each network adapter attached to the VM:
Network in
Network out
The agent-based discovery is an option available on top of the appliance-based discovery and helps customers
visualize dependencies of the on premises VMs. The dependency agents collect details like, FQDN, OS, IP address,
MAC address, processes running inside the VM and the incoming/outgoing TCP connections from the VM. The
agent-based discovery is optional and you can choose to not install the agents if you do not want to visualize the
dependencies of the VMs.
Would there be any performance impact on the analyzed ESXi host environment?
With continuous profiling of performance data, there is no need to change the vCenter Server statistics level to run
a performance-based assessment. The collector appliance will profile the on-premises machines to measure the
performance data of the virtual machines. This would have almost zero performance impact on the ESXi hosts as
well as on the vCenter Server.
Where is the collected data stored and for how long?
The data collected by the collector appliance is stored in the Azure location that you specify while creating the
migration project. The data is securely stored in a Microsoft subscription and is deleted when the user deletes the
Azure Migrate project.
For dependency visualization, if you install agents on the VMs, the data collected by the dependency agents is
stored in the US in a Log Analytics workspace created in user’s subscription. This data is deleted when you delete
the Log Analytics workspace in your subscription. Learn more.
What is the volume of data which is uploaded by Azure Migrate in the case of continuous profiling?
The volume of data which is sent to Azure Migrate would vary based on several parameters. To give an indicative
number, a project having ten machines (each having one disk and one NIC ), would send around 50 MB per day.
This is an approximate value and would change based on the number of data points for the NICs and disks (the
data sent would be non-linear if the number of machines, NICs or disks increase).
Is the data encrypted at rest and while in transit?
Yes, the collected data is encrypted both at rest and while in transit. The metadata collected by the appliance is
securely sent to the Azure Migrate service over internet via https. The collected metadata is stored in Cosmos DB
and in Azure blob storage in a Microsoft subscription and is encrypted at rest.
The data collected by the dependency agents is also encrypted in transit (secure https channel) and is stored in a
Log Analytics workspace in the user’s subscription. It is also encrypted at rest.
How does the collector communicate with the vCenter Server and the Azure Migrate service?
The collector appliance connects to the vCenter Server (port 443) using the credentials provided by the user in the
appliance. It queries the vCenter Server using VMware PowerCLI to collect metadata about the VMs managed by
vCenter Server. It collects both configuration data about VMs (cores, memory, disks, NIC etc.) as well as
performance history of each VM for the last one month from vCenter Server. The collected metadata is then sent
to the Azure Migrate service (over internet via https) for assessment. Learn more
Can I connect the same collector appliance to multiple vCenter servers?
Yes, a single collector appliance can be used to discover multiple vCenter Servers, but not concurrently. You need
to run the discovery one after another.
Is the OVA template used by Site Recovery integrated with the OVA used by Azure Migrate?
Currently there is no integration. The .OVA template in Site Recovery is used to set up a Site Recovery
configuration server for VMware VM/physical server replication. The .OVA used by Azure Migrate is used to
discover VMware VMs managed by a vCenter server, for the purposes of migration assessment.
I changed my machine size. Can I rerun the assessment?
If you change the settings on a VM you want to assess, trigger discover again using the collector appliance. In the
appliance, use the Start collection again option to do this. After the collection is done, select the Recalculate
option for the assessment in the portal, to get updated assessment results.
How can I discover a multi-tenant environment in Azure Migrate?
If you have an environment that is shared across tenants and you do not want to discover the VMs of one tenant
in another tenant's subscription, you can use the Scope field in the collector appliance to scope the discovery. If the
tenants are sharing hosts, create a credential that has read-only access to only the VMs belonging to the specific
tenant and then use this credential in the collector appliance and specify the Scope as the host to do the discovery.
Alternatively, you can also create folders in vCenter Server (let's say folder1 for tenant1 and folder2 for tenant2),
under the shared host, move the VMs for tenant1 into folder1 and for tenant2 into folder2 and then scope the
discoveries in the collector accordingly by specifying the appropriate folder.
How many virtual machines can be discovered in a single migration project?
You can discover 1500 virtual machines in a single migration project. If you have more machines in your on-
premises environment, learn more about how you can discover a large environment in Azure Migrate.
Assessment
Does Azure Migrate support Enterprise Agreement (EA ) based cost estimation?
Azure Migrate currently does not support cost estimation for Enterprise Agreement offer. The workaround is to
specify Pay-As-You-Go as the offer and manually specifying the discount percentage (applicable to the
subscription) in the 'Discount' field of the assessment properties.
What is the difference between as-on-premises sizing and performance -based sizing?
When you specify the sizing criterion to be as-on-premises sizing, Azure Migrate does not consider the
performance data of the VMs and sizes the VMs based on the on-premises configuration. If the sizing criterion is
performance-based, the sizing is done based on utilization data. For example, if there is an on-premises VM with 4
cores and 8 GB memory with 50% CPU utilization and 50% memory utilization. If the sizing criterion is as on-
premises sizing an Azure VM SKU with 4 cores and 8GB memory is recommended, however, if the sizing criterion
is performance-based as VM SKU of 2 cores and 4 GB would be recommended as the utilization percentage is
considered while recommending the size. Similarly, for disks, the disk sizing depends on two assessment
properties - sizing criterion and storage type. If the sizing criterion is performance-based and storage type is
automatic, the IOPS and throughput values of the disk are considered to identify the target disk type (Standard or
Premium). If the sizing criterion is performance-based and storage type is premium, a premium disk is
recommended, the premium disk SKU in Azure is selected based on the size of the on-premises disk. The same
logic is used to do disk sizing when the sizing criterion is as on-premises sizing and storage type is standard or
premium.
What impact does performance history and percentile utilization have on the size recommendations?
These properties are only applicable for performance-based sizing. Azure Migrate collects performance history of
on-premises machines and uses it to recommend the VM size and disk type in Azure. The collector appliance
continuously profiles the on-premises environment to gather real-time utilization data every 20 seconds. The
appliance rolls up the 20-second samples, and creates a single data point for every 15 minutes. To create the single
data point, the appliance selects the peak value from all the 20-second samples, and sends it to Azure. When you
create an assessment in Azure, based on the performance duration and performance history percentile value,
Azure Migrate calculates the effective utilization value and uses it for sizing. For example, if you have set the
performance duration to be 1 day and percentile value to 95 percentile, Azure Migrate uses the 15 min sample
points sent by collector for the last one day, sorts them in ascending order and picks the 95th percentile value as
the effective utilization. The 95th percentile value ensures that you are ignoring any outliers which may come if
you pick the 99th percentile. If you want to pick the peak usage for the period and do not want to miss any outliers,
you should select the 99th percentile.
Dependency visualization
NOTE
The dependency visualization functionality is not available in Azure Government.
Next steps
Read the Azure Migrate overview
Learn how you can discover and assess a VMware environment