67% found this document useful (3 votes)
843 views88 pages

Azure Migration Plan

Azure Migrate is a service that assesses on-premises workloads for migration to Azure. It analyzes VMware VMs to provide sizing recommendations, performance metrics, and cost estimates for running machines in Azure. Current limitations include support only for VMware VMs, a maximum of 1500 VMs per discovery, and storage of metadata according to the migration project's geography. Assessments can be customized based on target location, storage type, performance history period, and other settings to refine the analysis.

Uploaded by

saikumar Muktha
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
67% found this document useful (3 votes)
843 views88 pages

Azure Migration Plan

Azure Migrate is a service that assesses on-premises workloads for migration to Azure. It analyzes VMware VMs to provide sizing recommendations, performance metrics, and cost estimates for running machines in Azure. Current limitations include support only for VMware VMs, a maximum of 1500 VMs per discovery, and storage of metadata according to the migration project's geography. Assessments can be customized based on target location, storage type, performance history period, and other settings to refine the analysis.

Uploaded by

saikumar Muktha
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 88

Contents

Azure Migrate Documentation


Overview
About Azure Migrate
Tutorials
Discover and assess VMware VMs
Concepts
About the collector
Collector version upgrades
Assessment calculations
About dependency visualization
How-to guides
Migration examples-Contoso series
Discover and assess a large environment
Group machines
Group machines using machine dependencies
Refine a group using group dependencies
Customize an assessment
Migrate machines after assessment
Automate migration of large number of VMs
Troubleshoot Azure Migrate
Resources
FAQ
REST API
Resource Manager template
Pricing
UserVoice
Forum
Blog
Azure Migrate
Azure Roadmap
About Azure Migrate
4/5/2019 • 7 minutes to read • Edit Online

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.

Why use Azure Migrate?


Azure Migrate helps you to:
Assess Azure readiness: Assess whether your on-premises machines are suitable for running in Azure.
Get size recommendations: Get size recommendations for Azure VMs based on the performance history of
on-premises VMs.
Estimate monthly costs: Get estimated costs for running on-premises machines in Azure.
Migrate with high confidence: Visualize dependencies of on-premises machines to create groups of
machines that you will assess and migrate together.

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.

GEOGRAPHY STORAGE LOCATION

Azure Government US Gov Virginia

Asia Southeast Asia or East Asia

Europe North Europe or West Europe

United States East US or West Central US


The geography associated with the migration project is used to store the metadata discovered from the
on-premises environment. Metadata is stored in one of the regions based on the geography specified for
the migration project. If you use dependency visualization by creating a new Log Analytics workspace, the
workspace is created in the same region as the project.
The dependency visualization functionality is not available in Azure Government.

What do I need to pay for?


Learn more about Azure Migrate pricing.

What's in an assessment?
Assessment settings can be customized based on your needs. Assessment properties are summarized in the
following table.

PROPERTY DETAILS

Target location The Azure location to which you want to migrate.

Azure Migrate currently supports 33 regions as migration


target locations. Check regions. By default, the target region
is set to East US.

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.

Reserved Instances Whether you have reserved instances in Azure. Azure


Migrate estimates the cost accordingly.

Sizing criterion Sizing can be based on performance history of the on-


premises VMs (the default), or as on-premises, without
considering performance history.

Performance history By default, Azure Migrate evaluates the performance of on-


premises machines using performance history for the last
day, with a 95% percentile value.
PROPERTY DETAILS

Comfort factor Azure Migrate considers a buffer (comfort factor) during


assessment. This buffer is applied on top of machine
utilization data for VMs (CPU, memory, disk, and network).
The comfort factor accounts for issues such as seasonal
usage, short performance history, and likely increases in
future usage.

For example, a 10-core VM with 20% utilization normally


results in a 2-core VM. However, with a comfort factor of
2.0x, the result is a 4-core VM instead. The default comfort
setting is 1.3x.

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.

Currency Billing currency. Default is US dollars.

Discount (%) Any subscription-specific discount you receive on top of the


Azure offer. The default setting is 0%.

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.

How does Azure Migrate work?


1. You create an Azure Migrate project.
2. Azure Migrate uses an on-premises VM called the collector appliance, to discover information about your
on-premises machines. To create the appliance, you download a setup file in Open Virtualization Appliance
(.ova) format, and import it as a VM on your on-premises vCenter Server.
3. You connect to the VM from the vCenter Server, and specify a new password for it while connecting.
4. You run the collector on the VM to initiate discovery.
5. The collector collects VM metadata using the VMware PowerCLI cmdlets. Discovery is agentless, and
doesn't install anything on VMware hosts or VMs. The collected metadata includes VM information (cores,
memory, disks, disk sizes, and network adapters). It also collects performance data for VMs, including CPU
and memory usage, disk IOPS, disk throughput (MBps), and network output (MBps).
6. The metadata is pushed to the Azure Migrate project. You can view it in the Azure portal.
7. For the purposes of assessment, you gather the discovered VMs into groups. For example, you might
group VMs that run the same application. For more precise grouping, you can use dependency
visualization to view dependencies of a specific machine, or for all machines in a group and refine the
group.
8. After a group is defined, you create an assessment for it.
9. After the assessment finishes, you can view it in the portal, or download it in Excel format.

What are the port requirements?


The table summarizes the ports needed for Azure Migrate communications.

COMPONENT COMMUNICATES WITH DETAILS

Collector Azure Migrate service The collector connects to the service


over SSL port 443.

Collector vCenter Server By default the collector connects to the


vCenter Server on port 443. If the
server listens on a different port,
configure it as an outgoing port on the
collector VM.

On-premises VM Log Analytics Workspace The Microsoft Monitoring Agent


(MMA) uses TCP port 443 to connect
to Azure Monitor logs. You only need
this port if you're using dependency
visualization, that requires the MMA
agent.

What happens after assessment?


After you've assessed on-premises machines, you can use a couple of tools to perform the migration:
Azure Site Recovery: You can use Azure Site Recovery to migrate to Azure. To do this, you prepare the Azure
components you need, including a storage account and virtual network. On-premises, you prepare your
VMware environment. When everything's prepared, you set up and enable replication to Azure, and migrate
the VMs. Learn more.
Azure Database Migration: If on-premises machines are running a database such as SQL Server, MySQL,
or Oracle, you can use the Azure Database Migration Service to migrate them to Azure.
Want to learn more from community experts?
Visit the Azure Migrate MSDN forum or Stack Overflow

Need help? Contact us.


If you have questions or need help, create a support request. If your support request requires deep technical
guidance, please visit Azure Support Plans

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 an account for VM discovery


Azure Migrate needs access to VMware servers to automatically discover VMs for assessment. Create a VMware
account with the following properties. You specify this account during Azure Migrate setup.
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).

Sign in to the Azure portal


Sign in to the Azure portal.

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

Azure Government US Gov Virginia

Asia Southeast Asia

Europe North Europe or West Europe

Unites States East US or West Central US

Download the collector appliance


Azure Migrate creates an on-premises VM known as the collector appliance. This VM discovers on-premises
VMware VMs, and sends metadata about them to the Azure Migrate service. To set up the collector appliance, you
download an .OVA file, and import it to the on-premises vCenter server to create the VM.
1. In the Azure Migrate project, click Getting Started > Discover & Assess > Discover Machines.
2. In Discover machines, click Download to download the appliance.
The Azure Migrate appliance communicates with vCenter Server and continuously profiles the on-
premises environment to gather real-time utilization data for each VM. It collects peak counters for each
metric (CPU utilization, memory utilization etc.). This model does not depend on the statistics settings of
vCenter Server for performance data collection. You can stop the continuous profiling anytime from the
appliance.

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.

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]
Example usage: C:\>CertUtil -HashFile C:\AzureMigrate\AzureMigrate.ova SHA256
3. The generated hash should match these settings.
Continuous discovery
For OVA version 1.0.10.15

ALGORITHM HASH VALUE

MD5 dfa1838b1e64f7cde51915927220cf48

SHA1 24bdbd9c37c7366567ff252db3a37a13dda9de42

SHA256 e9f8f16ceb970c27dd068f5a5f7a4b2fd336f2820e9d6247d51
0ba6824e3f06c

For OVA version 1.0.10.11

ALGORITHM HASH VALUE

MD5 5f6b199d8272428ccfa23543b0b5f600

SHA1 daa530de6e8674a66a728885a7feb3b0a2e8ccb0

SHA256 85da50a21a7a6ca684418a87ccc1dd4f8aab30152c438a17b2
16ec401ebb3a21

For OVA version 1.0.10.9

ALGORITHM HASH VALUE

MD5 169f6449cc1955f1514059a4c30d138b

SHA1 f8d0a1d40c46bbbf78cd0caa594d979f1b587c8f

SHA256 d68fe7d94be3127eb35dd80fc5ebc60434c8571dcd0e114b87
587f24d6b4ee4d

For OVA version 1.0.10.4

ALGORITHM HASH VALUE

MD5 2ca5b1b93ee0675ca794dd3fd216e13d

SHA1 8c46a52b18d36e91daeae62f412f5cb2a8198ee5

SHA256 3b3dec0f995b3dd3c6ba218d436be003a687710abab9fcd17d
4bdc90a11276be

One-time discovery (deprecated now)


This model is now deprecated, support for existing appliances will be provided.
For OVA version 1.0.9.15

ALGORITHM HASH VALUE

MD5 e9ef16b0c837638c506b5fc0ef75ebfa

SHA1 37b4b1e92b3c6ac2782ff5258450df6686c89864

SHA256 8a86fc17f69b69968eb20a5c4c288c194cdcffb4ee6568d85ae
5ba96835559ba

For OVA version 1.0.9.14

ALGORITHM HASH VALUE

MD5 6d8446c0eeba3de3ecc9bc3713f9c8bd

SHA1 e9f5bdfdd1a746c11910ed917511b5d91b9f939f

SHA256 7f7636d0959379502dfbda19b8e3f47f3a4744ee9453fc9ce54
8e6682a66f13c

For OVA version 1.0.9.12

ALGORITHM HASH VALUE

MD5 d0363e5d1b377a8eb08843cf034ac28a

SHA1 df4a0ada64bfa59c37acf521d15dcabe7f3f716b

SHA256 f677b6c255e3d4d529315a31b5947edfe46f45e4eb4dbc8019
d68d1d1b337c2e

Create the collector VM


Import the downloaded file to the vCenter Server.
1. In the vSphere Client console, click File > Deploy OVF Template.
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, then click Finish.

Run the collector to discover VMs


1. In the vSphere Client console, right-click the VM > Open Console.
2. Provide the language, time zone, and password preferences for the appliance.
3. On the desktop, click the Run collector shortcut.
4. Click Check for updates in the top bar of the collector UI and verify that the collector is running on the
latest version. If not, you can choose to download the latest upgrade package from the link and update the
collector.
5. In the Azure Migrate Collector, open Set up prerequisites.
Select the Azure cloud to which you plan to migrate (Azure Global or Azure Government).
Accept the license terms, and read the third-party information.
The collector checks that the VM has internet access.
If the VM accesses the internet via a proxy, click Proxy settings, and specify the proxy address and
listening port. Specify credentials if the proxy needs authentication. Learn more about the internet
connectivity requirements and the list of URLs that the collector accesses.
NOTE
The proxy address needs to be entered in the form http://ProxyIPAddress or http://ProxyFQDN. Only HTTP
proxy is supported. If you have an intercepting proxy, the internet connection might initially fail if you have
not imported the proxy certificate; learn more on how you can fix this by importing the proxy certificate as a
trusted certificate on the collector VM.

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.

Verify VMs in the portal


The collector appliance will continuously profile the on-premises environment and will keep sending the
performance data at an hour interval. You can view the machines in the portal after an hour of kicking off the
discovery.
1. In the migration project, click Manage > Machines.
2. Check that the VMs you want to discover appear in the portal.

Create and view an assessment


After VMs are discovered in the portal, you group them and create assessments. You can immediately create as
on-premises assessments once the VMs are discovered in the portal. It is recommended to wait for at least a day
before creating any performance-based assessments to get reliable size recommendations.
1. In the project Overview page, click +Create assessment.
2. Click View all to review the assessment properties.
3. Create the group, and specify a group name.
4. Select the machines that you want to add to the group.
5. Click Create Assessment, to create the group and the assessment.
6. After the assessment is created, view it in Overview > Dashboard.
7. Click Export assessment, to download it as an Excel file.

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.

Monthly cost estimate


This view shows the total compute and storage cost of running the VMs in Azure along with the details for each
machine. Cost estimates are calculated considering the size recommendations done by Azure Migrate for a
machine, its disks, and the assessment properties.

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:

AVAILABILITY OF DATA POINTS CONFIDENCE RATING

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

This article provides information about Azure Migrate Collector.


The Azure Migrate Collector is a lightweight appliance that can be used to discover an on-premises vCenter
environment for the purposes of assessment with the Azure Migrate service, before migration to Azure.

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.

URL DETAILS PREREQUISITE CHECK

*.portal.azure.com Applicable to Azure Global. Checks Access to URL required.


connectivity with the Azure service, and
time synchronization. Prerequisites check fails if there's no
connectivity.

*.portal.azure.us Applicable only to Azure Government. Access to URL required.


Checks connectivity with the Azure
service, and time synchronization. Prerequisites check fails if there's no
connectivity.
URL DETAILS PREREQUISITE CHECK

*.oneget.org:443 Used to download the PowerShell Access to URLs is required.


vCenter PowerCLI module.
*.github.com/oneget/oneget Prerequisites check won't fail.

*.windows.net:443 Automatic module installation on the


Collector VM will fail. You'll need to
*.windowsazure.com:443 install the module manually in a
machine that has internet connectivity
*.azure.microsoft.com and then copy the modules to the
appliance. Learn more by going to
*.azure.microsoft.com/en-us Step#4 in this troubleshooting guide.

*.powershellgallery.com:443

*.msecnd.net:443

*.visualstudio.com:443

*.visualstudio.microsoft.com

Install VMware PowerCLI module manually


1. Install the module using these steps. These steps describe both online and offline installation.
2. If the Collector VM is offline and install on the module on a different machine with internet access, you need to
copy the VMware.* files from that machine to the Collector VM.
3. After installation, you can restart the prerequisites checks to confirm that PowerCLI is installed.
Connect to vCenter Server
The Collector connects to the vCenter Server and queries for VM metadata, and performance counters. Here's
what you need for the connection.
Only vCenter Server versions 5.5, 6.0, 6.5 and 6.7 are supported.
You need a read-only account with the permissions summarized below for discovery. Only datacenters
accessible with the account can be accessed for discovery.
By default you connect to vCenter Server with an FQDN or IP address. If vCenter Server listens on a different
port, you connect to it using the form IPAddress:Port_Number or FQDN:Port_Number.
The Collector should have a network line of sight to the vCenter server.
Account permissions

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

Azure Migrate service TCP 443 Collector communicates with Azure


Migrate service over SSL 443.

vCenter Server TCP 443 The Collector must be able to


communicate with the vCenter Server.

By default, it connects to vCenter on


443.

If vCenter Server listens on a different


port, that port should be available as
outgoing port on the Collector.

RDP TCP 3389

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.

COUNTER IMPACT ON ASSESSMENT

cpu.usage.average Recommended VM size and cost

mem.usage.average Recommended VM size and cost

virtualDisk.read.average Calculates disk size, storage cost, VM size

virtualDisk.write.average Calculates disk size, storage cost, VM size

virtualDisk.numberReadAveraged.average Calculates disk size, storage cost, VM size

virtualDisk.numberWriteAveraged.average Calculates disk size, storage cost, VM size

net.received.average Calculates VM size

net.transmitted.average Calculates VM size

The complete list of VMware counters collected by Azure Migrate is available below:

CATEGORY METADATA VCENTER DATAPOINT

Machine Details VM ID vm.Config.InstanceUuid

Machine Details VM name vm.Config.Name

Machine Details vCenter Server ID VMwareClient.InstanceUuid

Machine Details VM description vm.Summary.Config.Annotation

Machine Details License product name vm.Client.ServiceContent.About.License


ProductName

Machine Details Operating system type vm.Summary.Config.GuestFullName

Machine Details Operating system version vm.Summary.Config.GuestFullName

Machine Details Boot type vm.Config.Firmware


CATEGORY METADATA VCENTER DATAPOINT

Machine Details Number of cores vm.Config.Hardware.NumCPU

Machine Details Megabytes of memory vm.Config.Hardware.MemoryMB

Machine Details Number of disks vm.Config.Hardware.Device.ToList().Find


All(x => x is VirtualDisk).count

Machine Details Disk size list vm.Config.Hardware.Device.ToList().Find


All(x => x is VirtualDisk)

Machine Details Network adapters list vm.Config.Hardware.Device.ToList().Find


All(x => x is VirtualEthernetCard)

Machine Details CPU utilization cpu.usage.average

Machine Details Memory utilization mem.usage.average

Disk Details (per disk) Disk key value disk.Key

Disk Details (per disk) Disk unit number disk.UnitNumber

Disk Details (per disk) Disk controller key value disk.ControllerKey.Value

Disk Details (per disk) Gigabytes provisioned virtualDisk.DeviceInfo.Summary

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

Disk Details (per disk) Megabytes per second of read virtualDisk.read.average


throughput

Disk Details (per disk) Megabytes per second of write virtualDisk.write.average


throughput

Network Adapter Details (per NIC) Network adapter name nic.Key

Network Adapter Details (per NIC) MAC Address ((VirtualEthernetCard)nic).MacAddress

Network Adapter Details (per NIC) IPv4 Addresses vm.Guest.Net

Network Adapter Details (per NIC) IPv6 Addresses vm.Guest.Net

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 Name container.GetType().Name

Inventory Path Details Type of child object container.ChildType

Inventory Path Details Reference details container.MoRef

Inventory Path Details Complete inventory path container.Name with complete path

Inventory Path Details Parent details Container.Parent

Inventory Path Details Folder details for each VM ((Folder)container).ChildEntity.Type

Inventory Path Details Datacenter details for each VM Folder ((Datacenter)container).VmFolder

Inventory Path Details Datacenter details for each Host Folder ((Datacenter)container).HostFolder

Inventory Path Details Cluster details for each Host ((ClusterComputeResource)container).H


ost)

Inventory Path Details Host details for each VM ((HostSystem)container).Vm

Securing the Collector appliance


We recommend the following steps to secure the Collector appliance:
Don't share or misplace administrator passwords with unauthorized parties.
Shut down the appliance when not in use.
Place the appliance in a secured network.
After migration is finished, delete the appliance instance.
In addition, after migration, also delete the disk backup files (VMDKs), as the disks might have vCenter
credentials cached on them.

OS license in the collector VM


The collector comes with a Windows Server 2016 evaluation license which is valid for 180 days. If the evaluation
period is expiring for your collector VM, it is recommended to download a new OVA and create a new appliance.

Updating the OS of the Collector VM


Although the collector appliance has an evaluation license for 180 days, you need to continuously update the OS
on the appliance to avoid auto-shut down of the appliance.
If the Collector isn't updated for 60 days, it starts shutting down the machine automatically.
If a discovery is running, the machine won't be turned off, even if 60 days have passed. The machine will be
turned off after the discovery completes.
If you've used the Collector for more than 60 days, we recommend keeping the machine updated at all times by
running Windows update.
Upgrading the Collector appliance version
You can upgrade the Collector to the latest version without downloading the OVA again.
1. Download the latest listed upgrade package
2. To ensure that the downloaded hotfix is secure, open Administrator command window and run the
following command to generate the hash for the ZIP file. The generated hash should match with the hash
mentioned against the specific version:
C:\>CertUtil -HashFile <file_location> [Hashing Algorithm]

(example usage C:>CertUtil -HashFile C:\AzureMigrate\CollectorUpdate_release_1.0.9.14.zip SHA256)


3. Copy the zip file to the Azure Migrate collector virtual machine (collector appliance).
4. Right-click on the zip file and select Extract All.
5. Right-click on Setup.ps1 and select Run with PowerShell and follow the instructions on screen to install the
update.

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.

How to upgrade the appliance


You can upgrade the Collector to the latest version without downloading the OVA again.
1. Close all browser windows and any open files/folders in the appliance.
2. Download the latest upgrade package from the list of updates mentioned below in this article.
3. To ensure that the downloaded package is secure, open Administrator command window and run the
following command to generate the hash for the ZIP file. The generated hash should match with the hash
mentioned against the specific version:
C:\>CertUtil -HashFile <file_location> [Hashing Algorithm]

Example: C:>CertUtil -HashFile C:\AzureMigrate\CollectorUpdate_release_1.0.9.14.zip SHA256)


4. Copy the zip file to the Collector appliance VM.
5. Right-click on the zip file > Extract All.
6. Right-click on Setup.ps1 > Run with PowerShell, and follow the installation instructions.

Collector update release history


Continuous discovery: Upgrade versions
Version 1.0.10.14 (Released on 03/29/2019)
Contains few UI enhancements.
Hash values for upgrade package 1.0.10.14

ALGORITHM HASH VALUE

MD5 846b1eb29ef2806bcf388d10519d78e6

SHA1 6243239fa49c6b3f5305f77e9fd4426a392d33a0

SHA256 fb058205c945a83cc4a31842b9377428ff79b08247f3fb8bb4ff
30c125aa47ad

Version 1.0.10.12 (Released on 03/13/2019)


Contains fixes for issues in selecting Azure cloud in the appliance.
Hash values for upgrade package 1.0.10.12
ALGORITHM HASH VALUE

MD5 27704154082344c058238000dff9ae44

SHA1 41e9e2fb71a8dac14d64f91f0fd780e0d606785e

SHA256 c6e7504fcda46908b636bfe25b8c73f067e3465b748f77e5002
7e66f2727c2a9

One -time discovery (deprecated now): Previous upgrade versions

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.

Version 1.0.9.16 (Released on 10/29/2018)


Contains fixes for PowerCLI issues faced while setting up the appliance.
Hash values for upgrade package 1.0.9.16

ALGORITHM HASH VALUE

MD5 d2c53f683b0ec7aaf5ba3d532a7382e1

SHA1 e5f922a725d81026fa113b0c27da185911942a01

SHA256 a159063ff508e86b4b3b7b9a42d724262ec0f2315bdba8418b
ce95d973f80cfc

Version 1.0.9.14
Hash values for upgrade package 1.0.9.14

ALGORITHM HASH VALUE

MD5 c5bf029e9fac682c6b85078a61c5c79c

SHA1 af66656951105e42680dfcc3ec3abd3f4da8fdec

SHA256 58b685b2707f273aa76f2e1d45f97b0543a8c4d017cd27f0bd
b220e6984cc90e

Version 1.0.9.13
Hash values for upgrade package 1.0.9.13

ALGORITHM HASH VALUE

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.

Azure suitability analysis


Not all machines are suitable for running on cloud as cloud has its own limitations and requirements. Azure
Migrate assesses each on-premises machine for migration suitability to Azure and categorizes the machines into
one of the following categories:
Ready for Azure - The machine can be migrated as-is to Azure without any changes. It will boot in Azure with
full Azure support.
Conditionally ready for Azure - The machine may boot in Azure, but may not have full Azure support. For
example, a machine with an older version of Windows Server OS is not supported in Azure. You need to be
careful before migrating these machines to Azure and follow the remediation guidance suggested in the
assessment to fix the readiness issues before you migrate.
Not ready for Azure - The machine will not boot in Azure. For example, if an on-premises machine has a disk
of size more than 4 TB attached to it, it cannot be hosted on Azure. You need to follow the remediation
guidance suggested in the assessment to fix the readiness issue before migrating to Azure. Right-sizing and
cost estimation is not done for machines that are marked as not ready for Azure.
Readiness unknown - Azure Migrate could not find the readiness of the machine due to insufficient data
available in vCenter Server.
Azure Migrate reviews the machine properties and guest operating system to identify the Azure readiness of the
on-premises machine.
Machine properties
Azure Migrate reviews the following properties of the on-premises VM to identify whether a VM can run on
Azure.

PROPERTY DETAILS AZURE READINESS STATUS

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.

If performance history is available,


Azure Migrate considers the utilized
cores for comparison. If a comfort
factor is specified in the assessment
settings, the number of utilized cores is
multiplied by the comfort factor.

If there's no performance history, Azure


Migrate uses the allocated cores,
without applying the comfort factor.

Memory The machine memory size must be Ready if within limits.


equal to or less than the maximum
memory (3892 GB on Azure M series
Standard_M128m 2 ) allowed for an
Azure VM. Learn more.

If performance history is available,


Azure Migrate considers the utilized
memory for comparison. If a comfort
factor is specified, the utilized memory
is multiplied by the comfort factor.

If there's no history the allocated


memory is used, without applying the
comfort factor.

Storage disk Allocated size of a disk must be 4 TB Ready if within limits.


(4096 GB) or less.

The number of disks attached to the


machine must be 65 or less, including
the OS disk.

Networking A machine must have 32 or less NICs Ready if within limits.


attached to it.

Guest operating system


Along with VM properties, Azure Migrate also looks at the guest OS of the on-premises VM to identify if the VM
can run on Azure.

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:

AVAILABILITY OF DATA POINTS CONFIDENCE RATING

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.

Monthly cost estimation


After sizing recommendations are complete, Azure Migrate calculates post-migration compute and storage costs.
Compute cost: Using the recommended Azure VM size, Azure Migrate uses the Billing API to calculate the
monthly cost for the VM. The calculation takes the operating system, software assurance, reserved instances,
VM uptime, location, and currency settings into account. It aggregates the cost across all machines, to calculate
the total monthly compute cost.
Storage cost: The monthly storage cost for a machine is calculated by aggregating the monthly cost of all
disks attached to the machine. Azure Migrate calculates the total monthly storage costs by aggregating the
storage costs of all machines. Currently, the calculation doesn't take offers specified in the assessment settings
into account.
Costs are displayed in the currency specified in the assessment settings.

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.

How does it work?


Azure Migrate uses the Service Map solution in Azure Monitor logs for dependency visualization.
To leverage dependency visualization, you need to associate a Log Analytics workspace, either new or
existing, with an Azure Migrate project.
You can only create or attach a workspace in the same subscription where the migration project is created.
To attach a Log Analytics workspace to a project, go to Essentials section of the project Overview page and
click Requires configuration

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.

Do I need to pay for it?


Azure Migrate is available at no additional charge. Use of the dependency visualization feature in Azure Migrate
requires Service Map and requires you to associate a Log Analytics workspace, either new or existing, with the
Azure Migrate project. The dependency visualization functionality in Azure Migrate is free for the first 180 days in
Azure Migrate.
1. Use of any solutions other than Service Map within this Log Analytics workspace will incur standard Log
Analytics charges.
2. To support migration scenarios at no additional cost, the Service Map solution will not incur any charges for the
first 180 days from the day of associating the Log Analytics workspace with the Azure Migrate project. After
180 days, standard Log Analytics charges will apply.
When you register agents to the workspace, use the ID and the Key given by the project on the install agent steps
page.
When the Azure Migrate project is deleted, the workspace is not deleted along with it. Post the project deletion, the
Service Map usage will not be free, and each node will be charged as per the paid tier of Log Analytics workspace.

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.

Learn more about Azure Migrate pricing here.

How do I manage the workspace?


You can use the Log Analytics workspace outside Azure Migrate. It's not deleted if you delete the migration project
in which it was created. If you no longer need the workspace, delete it manually.
Don't delete the workspace created by Azure Migrate, unless you delete the migration project. If you do, the
dependency visualization functionality will not work as expected.

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 1: Overview Overview of the article series, Contoso's migration strategy,


and the sample apps that are used in the series.

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.

Plan your migration projects and discoveries


Based on the number of VMs you are planning to discover, you can create multiple projects and deploy multiple
appliances in your environment. An appliance can be connected to a single vCenter Server and a single project
(unless you stop the discovery and start afresh).
In case of one-time discovery (deprecated now ), the discovery works in a fire and forget model, once a discovery
is done, you can use the same collector to collect data from a different vCenter Server or send it to a different
migration project.

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.

Plan your discoveries and assessments based on the following limits:

ENTITY MACHINE LIMIT

Project 1,500

Discovery 1,500

Assessment 1,500

Keep these planning considerations in mind:


When you do a discovery by using the Azure Migrate collector, you can set the discovery scope to a vCenter
Server folder, datacenter, cluster, or host.
To do more than one discovery from the same vCenter Server, verify in vCenter Server that the VMs you want
to discover are in folders, datacenters, clusters, or hosts that support the limitation of 1,500 machines.
We recommend that for assessment purposes, you keep machines with interdependencies within the same
project and assessment. In vCenter Server, make sure that dependent machines are in the same folder,
datacenter, or cluster for the assessment.
Depending on your scenario, you can split your discoveries as prescribed below:
Multiple vCenter Servers with less than 1500 VMs
If you have multiple vCenter Servers in your environment, and the total number of virtual machines is less than
1500, you can use the following approach based on your scenario:
Continuous discovery: In case of continuous discovery, one appliance can be connected to only a single project.
So you need to deploy one appliance for each of your vCenter Servers and then create one project for each
appliance and trigger discoveries accordingly.
One-time discovery (deprecated now): You can use a single collector and a single migration project to discover
all the virtual machines across all vCenter Servers. Since the one-time discovery collector discovers one vCenter
Server at a time, you can run the same collector against all the vCenter Servers, one after another, and point the
collector to the same migration project. Once all the discoveries are complete, you can then create assessments for
the machines.
Multiple vCenter Servers with more than 1500 VMs
If you have multiple vCenter Servers with less than 1500 virtual machines per vCenter Server, but more than
1500 VMs across all vCenter Servers, you need to create multiple migration projects (one migration project can
hold only 1500 VMs). You can achieve this by creating a migration project per vCenter Server and splitting the
discoveries.
Continuous discovery: You need to create multiple collector appliances (one for each vCenter Server) and
connect each appliance to a project and trigger discovery accordingly.
One-time discovery (deprecated now): You can use a single collector to discover each vCenter Server (one
after another). If you want the discoveries to start at the same time, you can also deploy multiple appliances and
run the discoveries in parallel.
More than 1500 machines in a single vCenter Server
If you have more than 1500 virtual machines in a single vCenter Server, you need to split the discovery into
multiple migration projects. To split discoveries, you can leverage the Scope field in the appliance and specify the
host, cluster, folder of hosts, folder of clusters or datacenter that you want to discover. For example, if you have two
folders in vCenter Server, one with 1000 VMs (Folder1) and other with 800 VMs (Folder2), you can use the scope
field to split the discoveries between these folders.
Continuous discovery: In this case, you need to create two collector appliances, for the first collector, specify the
scope as Folder1 and connect it to the first migration project. You can in parallel start the discovery of Folder2
using the second collector appliance and connect it to the second migration project.
One-time discovery (deprecated now): You can use the same collector to trigger both the discoveries. In the
first discovery, you can specify Folder1 as the scope and point it to the first migration project, once the first
discovery is complete, you can use the same collector, change its scope to Folder2 and migration project details to
the second migration project and do the second discovery.
Multi-tenant environment
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.

Discover on-premises environment


Once you are ready with your plan, you can then start discovery of the on-premises virtual machines:
Create a project
Create an Azure Migrate project in accordance with your requirements:
1. In the Azure portal, select Create a resource.
2. Search for Azure Migrate, and select the service Azure Migrate in the search results. Then select Create.
3. Specify a project name and the Azure subscription for the project.
4. Create a new resource group.
5. Specify the location in which you want to create the project, and then select Create. Note that you can still
assess your VMs for a different target location. The location specified for the project is used to store the
metadata gathered from on-premises VMs.
Set up the collector appliance
Azure Migrate creates an on-premises VM known as the collector appliance. This VM discovers on-premises
VMware VMs, and it sends metadata about them to the Azure Migrate service. To set up the collector appliance,
you download an OVA file and import it to the on-premises vCenter Server instance.
Download the collector appliance
If you have multiple projects, you need to download the collector appliance only once to vCenter Server. After you
download and set up the appliance, you run it for each project, and you specify the unique project ID and key.
1. In the Azure Migrate project, click Getting Started > Discover & Assess > Discover Machines.
2. In Discover machines, click Download to download the appliance.
The Azure Migrate appliance communicates with vCenter Server and continuously profiles the on-premises
environment to gather real-time utilization data for each VM. It collects peak counters for each metric (CPU
utilization, memory utilization etc.). This model does not depend on the statistics settings of vCenter Server
for performance data collection. You can stop the continuous profiling anytime from the appliance.

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]

Example usage: C:\>CertUtil -HashFile C:\AzureMigrate\AzureMigrate.ova SHA256

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

One-time discovery (deprecated now)


For OVA version 1.0.9.15 (Released on 10/23/2018)

ALGORITHM HASH VALUE

MD5 e9ef16b0c837638c506b5fc0ef75ebfa

SHA1 37b4b1e92b3c6ac2782ff5258450df6686c89864

SHA256 8a86fc17f69b69968eb20a5c4c288c194cdcffb4ee6568d85ae
5ba96835559ba

For OVA version 1.0.9.14 (Released on 8/24/2018)

ALGORITHM HASH VALUE

MD5 6d8446c0eeba3de3ecc9bc3713f9c8bd

SHA1 e9f5bdfdd1a746c11910ed917511b5d91b9f939f

SHA256 7f7636d0959379502dfbda19b8e3f47f3a4744ee9453fc9ce54
8e6682a66f13c

For OVA version 1.0.9.12

ALGORITHM HASH VALUE

MD5 d0363e5d1b377a8eb08843cf034ac28a

SHA1 df4a0ada64bfa59c37acf521d15dcabe7f3f716b

SHA256 f677b6c255e3d4d529315a31b5947edfe46f45e4eb4dbc8019
d68d1d1b337c2e

For OVA version 1.0.9.8

ALGORITHM HASH VALUE

MD5 b5d9f0caf15ca357ac0563468c2e6251

SHA1 d6179b5bfe84e123fabd37f8a1e4930839eeb0e5

SHA256 09c68b168719cb93bd439ea6a5fe21a3b01beec0e15b84204
857061ca5b116ff
For OVA version 1.0.9.7

ALGORITHM HASH VALUE

MD5 d5b6a03701203ff556fa78694d6d7c35

SHA1 f039feaa10dccd811c3d22d9a59fb83d0b01151e

SHA256 e5e997c003e29036f62bf3fdce96acd4a271799211a84b34b3
5dfd290e9bea9c

Create the collector VM


Import the downloaded file to vCenter Server:
1. In the vSphere Client console, select File > Deploy OVF Template.

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.

Run the collector to discover VMs


For each discovery that you need to perform, you run the collector to discover VMs in the required scope. Run the
discoveries one after the other. Concurrent discoveries aren't supported, and each discovery must have a different
scope.
1. In the vSphere Client console, right-click the VM > Open Console.
2. Provide the language, time zone, and password preferences for the appliance.
3. On the desktop, select the Run collector shortcut.
4. In the Azure Migrate collector, open Set up prerequisites and then:
a. Accept the license terms, and read the third-party information.
The collector checks that the VM has internet access.
b. If the VM accesses the internet via a proxy, select Proxy settings, and specify the proxy address and
listening port. Specify credentials if the proxy needs authentication.
The collector checks that the collector service is running. The service is installed by default on the collector
VM.
c. Download and install VMware PowerCLI.
5. In Specify vCenter Server details, do the following:
Specify the name (FQDN ) or IP address of vCenter Server.
In User name and Password, specify the read-only account credentials that the collector will use to
discover VMs in vCenter Server.
In Select scope, select a scope for VM discovery. The collector can discover only VMs within the
specified scope. Scope can be set to a specific folder, datacenter, or cluster. It shouldn't contain more than
1,000 VMs.
6. In Specify migration project, specify the ID and key for the project. If you didn't copy them, open the
Azure portal from the collector VM. On the project's Overview page, select Discover Machines and copy
the values.
7. In View collection progress, monitor the discovery process and check that metadata collected from the
VMs is in scope. The collector provides an approximate discovery time.
Verify VMs in the portal
The collector will continuously profile the on-premises environment and will keep sending the performance data
at an hour interval. You can review the machines in the portal after an hour of kicking off the discovery. It is
strongly recommended to wait for at least a day before creating any performance-based assessments for the VMs.
1. In the migration project, click Manage > Machines.
2. Check that the VMs you want to discover appear in the portal.
Data collected from on-premises environment
The collector appliance discovers the following configuration data about the selected virtual machines.
1. VM Display name (on vCenter)
2. VM’s inventory path (host/folder in vCenter)
3. IP address
4. MAC address
5. Operating system
6. Number of cores, disks, NICs
7. Memory size, Disk sizes
8. And performance counters of the VM, disk and network as listed in the table below.
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 appliance then rolls-up the 20-second samples to create a single data point for
every 15 minutes by selecting the peak value from the 20-second samples and sends it to Azure. 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.

COUNTER IMPACT ON ASSESSMENT

cpu.usage.average Recommended VM size and cost

mem.usage.average Recommended VM size and cost

virtualDisk.read.average Calculates disk size, storage cost, VM size

virtualDisk.write.average Calculates disk size, storage cost, VM size

virtualDisk.numberReadAveraged.average Calculates disk size, storage cost, VM size

virtualDisk.numberWriteAveraged.average Calculates disk size, storage cost, VM size

net.received.average Calculates VM size

net.transmitted.average Calculates VM size

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.

Prepare for dependency visualization


Azure Migrate leverages Service Map solution in Azure Monitor logs to enable dependency visualization of
machines.
Associate a Log Analytics workspace
To leverage dependency visualization, you need to associate a Log Analytics workspace, either new or existing,
with an Azure Migrate project. You can only create or attach a workspace in the same subscription where the
migration project is created.
To attach a Log Analytics workspace to a project, in Overview, go to Essentials section of the project click
Requires configuration

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.

Download and install the VM agents


Once you configure a workspace, you need to download and install agents on each on-premises machine that you
want to evaluate. In addition, if you have machines with no internet connectivity, you need to download and install
Log Analytics gateway on them.
1. In Overview, click Manage > Machines, and select the required machine.
2. In the Dependencies column, click Install agents.
3. On the Dependencies page, download and install the Microsoft Monitoring Agent (MMA), and the
Dependency agent on each VM you want to evaluate.
4. Copy the workspace ID and key. You need these when you install the MMA on the on-premises machine.

NOTE
To automate the installation of agents you can use any deployment tool like System Center Configuration Manager or use
our partner tool, Intigua, that has an agent deployment solution for Azure Migrate.

Install the MMA


Install the agent on a Windows machine
To install the agent on a Windows machine:
1. Double-click the downloaded agent.
2. On the Welcome page, click Next. On the License Terms page, click I Agree to accept the license.
3. In Destination Folder, keep or modify the default installation folder > Next.
4. In Agent Setup Options, select Azure Log Analytics > Next.
5. Click Add to add a new Log Analytics workspace. Paste in the workspace ID and key that you copied from the
portal. Click Next.
You can install the agent from the command line or using an automated method such as System Center
Configuration Manager. Learn more about using these methods to install the MMA agent.
Install the agent on a Linux machine
To install the agent on a Linux machine:
1. Transfer the appropriate bundle (x86 or x64) to your Linux computer using scp/sftp.
2. Install the bundle by using the --install argument.
sudo sh ./omsagent-<version>.universal.x64.sh --install -w <workspace id> -s <workspace key>

Learn more about the list of Linux operating systems support by MMA.
Install the 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.

Query dependency data from Azure Monitor logs


Dependency data captured by Service Map is available for querying in the Log Analytics workspace associated
with your Azure Migrate project. Learn more about the Service Map data tables to query in Azure Monitor logs.
To run the Kusto queries:
1. After you install the agents, go to the portal and click Overview.
2. In Overview, go to Essentials section of the project and click on workspace name provided next to OMS
Workspace.
3. On the Log Analytics workspace page, click General > Logs.
4. Write your query to gather dependency data using Azure Monitor logs. Find sample queries in the next
section.
5. Run your query by clicking on Run.
Learn more about how to write Kusto queries.
Sample Azure Monitor logs queries
Following are sample queries you can use to extract dependency data. You can modify the queries to extract your
preferred data points. An exhaustive list of the fields in dependency data records is available here. Find more
sample queries here.
Summarize inbound connections on a set of machines
Note that the records in the table for connection metrics, VMConnection, do not represent individual physical
network connections. Multiple physical network connections are grouped into a logical connection. Learn more
about how physical network connection data is aggregated into a single logical record in VMConnection.
// the machines of interest
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

// the machines of interest


let ips=materialize(ServiceMapComputer_CL
| summarize ips=makeset(todynamic(Ipv4Addresses_s)) by MonitoredMachine=ResourceName_s
| mvexpand ips to typeof(string));
let StartDateTime = datetime(2019-03-25T00:00:00Z);
let EndDateTime = datetime(2019-03-30T01:00:00Z);
VMConnection
| where Direction == 'inbound'
| where TimeGenerated > StartDateTime and TimeGenerated < EndDateTime
| join kind=inner (ips) on $left.DestinationIp == $right.ips
| summarize sum(BytesSent), sum(BytesReceived) by Computer, Direction, SourceIp, DestinationIp,
DestinationPort

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.

Prepare for dependency visualization


Azure Migrate leverages Service Map solution in Azure Monitor logs to enable dependency visualization of
machines.

NOTE
The dependency visualization functionality is not available in Azure Government.

Associate a Log Analytics workspace


To leverage dependency visualization, you need to associate a Log Analytics workspace, either new or existing, with
an Azure Migrate project. You can only create or attach a workspace in the same subscription where the migration
project is created.
To attach a Log Analytics workspace to a project, in Overview, go to Essentials section of the project click
Requires configuration
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.

Download and install the VM agents


To view dependencies of a group, you need to download and install agents on each on-premises machine that is
part of the group. In addition, if you have machines with no internet connectivity, you need to download and install
Log Analytics gateway on them.
1. In Overview, click Manage > Groups, go to the required group.
2. In the list of machines, in the Dependency agent column, click Requires installation to see instructions
regarding how to download and install the agents.
3. On the Dependencies page, download and install the Microsoft Monitoring Agent (MMA), and the
Dependency agent on each VM that is part of the group.
4. Copy the workspace ID and key. You need these when you install the MMA on the on-premises machines.
Install the MMA
Install the agent on a Windows machine
To install the agent on a Windows machine:
1. Double-click the downloaded agent.
2. On the Welcome page, click Next. On the License Terms page, click I Agree to accept the license.
3. In Destination Folder, keep or modify the default installation folder > Next.
4. In Agent Setup Options, select Azure Log Analytics > Next.
5. Click Add to add a new Log Analytics workspace. Paste in the workspace ID and key that you copied from the
portal. Click Next.
You can install the agent from the command line or using an automated method such as System Center
Configuration Manager. Learn more about using these methods to install the MMA agent.
Install the agent on a Linux machine
To install the agent on a Linux machine:
1. Transfer the appropriate bundle (x86 or x64) to your Linux computer using scp/sftp.
2. Install the bundle by using the --install argument.
sudo sh ./omsagent-<version>.universal.x64.sh --install -w <workspace id> -s <workspace key>

Install the agent on a machine monitored by System Center Operations Manager


For machines monitored by Operations Manager 2012 R2 or later, there is no need to install the MMA agent.
Service Map has an integration with Operations Manager that leverages the Operations Manager MMA to gather
the necessary dependency data. You can enable the integration using the guidance here. Note, however, that the
dependency agent needs 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.

Refine the group based on dependency visualization


Once you have installed agents on all the machines of the group, you can visualize the dependencies of the group
and refine it by following the below steps.
1. In the Azure Migrate project, under Manage, clickGroups, and select the group.
2. On the group page, clickView Dependencies, to open the group dependency map.
3. The dependency map for the group shows the following details:
Inbound (Clients) and outbound (Servers) TCP connections to/from all the machines that are part of
the group
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

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.

Query dependency data from Azure Monitor logs


Dependency data captured by Service Map is available for querying in the Log Analytics workspace associated
with your Azure Migrate project. Learn more about the Service Map data tables to query in Azure Monitor logs.
To run the Kusto queries:
1. After you install the agents, go to the portal and click Overview.
2. In Overview, go to Essentials section of the project and click on workspace name provided next to OMS
Workspace.
3. On the Log Analytics workspace page, click General > Logs.
4. Write your query to gather dependency data using Azure Monitor logs. Find sample queries in the next section.
5. Run your query by clicking on Run.
Learn more about how to write Kusto queries.

Sample Azure Monitor logs queries


Following are sample queries you can use to extract dependency data. You can modify the queries to extract your
preferred data points. An exhaustive list of the fields in dependency data records is available here. Find more
sample queries here.
Summarize inbound connections on a set of machines
Note that the records in the table for connection metrics, VMConnection, do not represent individual physical
network connections. Multiple physical network connections are grouped into a logical connection. Learn more
about how physical network connection data is aggregated into a single logical record in VMConnection.

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

// the machines of interest


let ips=materialize(ServiceMapComputer_CL
| summarize ips=makeset(todynamic(Ipv4Addresses_s)) by MonitoredMachine=ResourceName_s
| mvexpand ips to typeof(string));
let StartDateTime = datetime(2019-03-25T00:00:00Z);
let EndDateTime = datetime(2019-03-30T01:00:00Z);
VMConnection
| where Direction == 'inbound'
| where TimeGenerated > StartDateTime and TimeGenerated < EndDateTime
| join kind=inner (ips) on $left.DestinationIp == $right.ips
| summarize sum(BytesSent), sum(BytesReceived) by Computer, Direction, SourceIp, DestinationIp,
DestinationPort

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.

Edit assessment properties


1. In the Assessments page of the migration project, select the assessment, and click Edit properties.
2. Customize the assessment properties based on the following details:

SETTING DETAILS DEFAULT

Target location The Azure location to which you want West US 2 is the default location.
to migrate.

Azure Migrate currently supports 30


regions including Australia East,
Australia Southeast, Brazil South,
Canada Central, Canada East, Central
India, Central US, China East, China
North, East Asia, East US, Germany
Central, Germany Northeast, East US
2, Japan East, Japan West, Korea
Central, Korea South, North Central
US, North Europe, South Central US,
Southeast Asia, South India, UK
South, UK West, US Gov Arizona, US
Gov Texas, US Gov Virginia, West
Central US, West Europe, West India,
West US, and West US2.

Storage type You can use this property to specify The 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.

Sizing criterion The criterion to be used by Azure Performance-based sizing is the


Migrate to right-size VMs for Azure. default option.
You can do either do performance-
based sizing or size the VMs as on-
premises, without considering the
performance history.

Performance history The duration to consider for Default is one day.


evaluating the performance of the
VMs. This property is only applicable
when sizing criterion is performance-
based sizing.

Percentile utilization The percentile value of the Default is 95th percentile.


performance sample set to be
considered for right-sizing. This
property is only applicable when
sizing criterion is performance-based
sizing.

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.

Comfort factor Azure Migrate considers a buffer Default setting is 1.3x.


(comfort factor) during assessment.
This buffer is applied on top of
machine utilization data for VMs
(CPU, memory, disk, and network).
The comfort factor accounts for
issues such as seasonal usage, short
performance history, and likely
increases in future usage.

For example, 10-core VM with 20%


utilization normally results in a 2-core
VM. However, with a comfort factor
of 2.0x, the result is a 4-core VM
instead.

Offer Azure Offer that you are enrolled to. Pay-as-you-go is the default.

Currency Billing currency. Default is US dollars.


SETTING DETAILS DEFAULT

Discount (%) Any subscription-specific discount The default setting is 0%.


you receive on top of the Azure offer.

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 Hybrid Benefit Specify if you have software Default is Yes.


assurance and are eligible for Azure
Hybrid Benefit. If set to Yes, non-
Windows Azure prices are considered
for Windows VMs.

3. Click Save to update the assessment.

FAQs on 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 8-GB 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.
Next steps
Learn more about how assessments are calculated.
Migrate machines after assessment
12/11/2018 • 2 minutes to read • Edit Online

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.

Migration tool suggestion


To get suggestions regarding migration tools, you need to do a deep discovery of the on-premises environment.
The deep discovery is done by installing agents on the on-premises machines.
1. Create an Azure Migrate project, discover on-premises machines, and create a migration assessment. Learn
more.
2. Download and install the Azure Migrate agents on each on-premises machine for which you want to see a
recommended migration method. Follow this procedure to install the agents.
3. Identify your on-premises machines that are suitable for lift-and-shift migration. These are the VMs that don't
require any changes to apps running on them, and can be migrated as is.
4. For lift-and-shift migration, we suggest using Azure Site Recovery. Learn more. Alternately, you can use third-
party tools that support migration to Azure.
5. If you have on-premises machines that aren't suitable for a lift-and-shift migration, that is, if you want to
migrate specific app rather than an entire VM, you can use other migration tools. For example, we suggest the
Azure Database Migration service if you want to migrate on-premises databases such a SQL Server, MySQL,
or Oracle to Azure.

Review suggested migration methods


1. Before you can get a suggested migration method, you need to create an Azure Migrate project, discover
on-premises machines, and run a migration assessment. Learn more.
2. After the assessment is created, view it in the project > Overview > Dashboard. Click Assessment
Readiness

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

How does it work?


Prerequisites
Before you get started, you need to do the following steps:
Ensure that the Site Recovery vault is created in your Azure subscription
Ensure that the Configuration Server and Process Server are installed in the source environment and the vault
is able to discover the environment
Ensure that a Replication Policy is created and associated with the Configuration Server
Ensure that you have added the VM admin account to the config server (that will be used to replicate the on
premises VMs)
Ensure that the target artifacts in Azure are created
Target Resource Group
Target Storage Account (and its Resource Group) - Create a premium storage account if you plan to
migrate to premium-managed disks
Cache Storage Account (and its Resource Group) - Create a standard storage account in the same region
as the vault
Target Virtual Network for failover (and its Resource Group)
Target Subnet
Target Virtual Network for Test failover (and its Resource Group)
Availability Set (if needed)
Target Network Security Group and its Resource Group
Ensure that you have decided on the properties of the target VM
Target VM name
Target VM size in Azure (can be decided using Azure Migrate assessment)
Private IP Address of the primary NIC in the VM
Download the scripts from Azure PowerShell Samples repo on GitHub
CSV Input file
Once you have all the pre-requisites completed, you need to create a CSV file, which has data for each source
machine that you want to migrate. The input CSV must have a header line with the input details and a row with
details for each machine that needs to be migrated. All the scripts are designed to work on the same CSV file. A
sample CSV template is available in the scripts folder for your reference.
Script execution
Once the CSV is ready, you can execute the following steps to perform migration of the on-premises VMs:

STEP # SCRIPT NAME DESCRIPTION

1 asr_startmigration.ps1 Enable replication for all the VMs listed


in the csv, the script creates a CSV
output with the job details for each VM

2 asr_replicationstatus.ps1 Check the status of replication, the


script creates a csv with the status for
each VM

3 asr_updateproperties.ps1 Once the VMs are replicated/protected,


use this script to update the target
properties of the VM (Compute and
Network properties)

4 asr_propertiescheck.ps1 Verify if the properties are appropriately


updated

5 asr_testmigration.ps1 Start the test failover of the VMs listed


in the csv, the script creates a CSV
output with the job details for each VM

6 asr_cleanuptestmigration.ps1 Once you manually validate the VMs


that were test failed-over, you can use
this script to clean up the test failover
VMs

7 asr_migration.ps1 Perform an unplanned failover for the


VMs listed in the csv, the script creates
a CSV output with the job details for
each VM. The script does not shut
down the on premises VMs before
triggering the failover, for application
consistency, it is recommended that you
manually shut down the VMs before
executing the script.

8 asr_completemigration.ps1 Perform the commit operation on the


VMs and delete the Azure Site Recovery
entities

9 asr_postmigration.ps1 If you plan to assign network security


groups to the NICs post-failover, you
can use this script to do that. It assigns
a NSG to any one NIC in the target VM.

How to migrate to managed disks?


The script, by default, migrates the VMs to managed disks in Azure. If the target storage account provided is a
premium storage account, premium-managed disks are created post migration. The cache storage account can still
be a standard account. If the target storage account is a standard storage account, standard disks are created post
migration.
Next steps
Learn more about migrating servers to Azure using Azure Site Recovery
Troubleshoot Azure Migrate
3/29/2019 • 20 minutes to read • Edit Online

Troubleshoot common errors


Azure Migrate assesses on-premises workloads for migration to Azure. Use this article to troubleshoot issues
when deploying and using Azure Migrate.
I am using the OVA that continuously discovers my on-premises environment, but the VMs that are deleted in
my on-premises environment are still being shown in the portal.
The continuous discovery 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.
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```

Sample request and output:


esourceGroups/ContosoDemo/providers/Microsoft.Migrate/projects/Demo/groups/contosopayroll/assessments/as
sessment_11_16_2
018_12_16_21/downloadUrl?api-version=2018-02-02
{
"assessmentReportUrl": "https://migsvcstoragewcus.blob.core.windows.net/4f7dddac-f33b-4368-8e6a-
45afcbd9d4df/contosopayrollassessment_11_16_2018_12_16_21?sv=2016-05-
31&sr=b&sig=litQmHuwi88WV%2FR%2BDZX0%2BIttlmPMzfVMS7r7dULK7Oc%3D&st=2018-11-20T16%3A09%3A30Z&se=2018-11-
20T16%3A19%3A30Z&sp=r",
"expirationTime": "2018-11-20T22:09:30.5681954+05:30"```

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

*.portal.azure.com Required to check connectivity with the Azure service and


validate time synchronization issues.

*.oneget.org Required to download the powershell based vCenter PowerCLI


module.

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

Dependency visualization issues


I am unable to find the dependency visualization functionality for Azure Government projects.
Azure Migrate depends on Service Map for the dependency visualization functionality and since Service Map is
currently unavailable in Azure Government, this functionality is not available in Azure Government.
I installed the Microsoft Monitoring Agent (MMA ) and the dependency agent on my on-premises VMs, but the
dependencies are now showing up in the Azure Migrate portal.
Once you have installed the agents, Azure Migrate typically takes 15-30 mins to display the dependencies in the
portal. If you have waited for more than 30 minutes, ensure that the MMA agent is able to talk to the OMS
workspace by following the below steps:
For Windows VM:
1. Go to Control Panel and launch Microsoft Monitoring Agent
2. Go to the Azure Log Analytics (OMS ) tab in the MMA properties pop-up
3. Ensure that the Status for the workspace is green.
4. If the status is not green, try removing the workspace and adding it again to MMA.
For Linux VM, ensure that the installation commands for MMA and dependency agent had succeeded.
What are the operating systems supported by MMA?
The list of Windows operating systems supported by MMA is here. The list of Linux operating systems supported
by MMA is here.
What are the operating systems supported by dependency agent?
The list of Windows operating systems supported by dependency agent is here. The list of Linux operating systems
supported by dependency agent is here.
I am unable to visualize dependencies in Azure Migrate for more than one hour duration?
Azure Migrate lets you visualize dependencies for up to one hour duration. Although, Azure Migrate allows you to
go back to a particular date in the history for up to last one month, the maximum duration for which you can
visualize the dependencies is up to 1 hour. For example, you can use the time duration functionality in the
dependency map, to view dependencies for yesterday, but can only view it for a one hour window. However, you
can use Azure Monitor logs to query the dependency data over a longer duration.
I am unable to visualize dependencies for groups with more than 10 VMs?
You can visualize dependencies for groups that have up to 10 VMs, if you have a group with more than 10 VMs, we
recommend you to split the group in to smaller groups and visualize the dependencies.
I installed agents and used the dependency visualization to create groups. Now post failover, the machines show
"Install agent" action instead of "View dependencies"
Post planned or unplanned failover, on-premises machines are turned off and equivalent machines are spun up
in Azure. These machines acquire a different MAC address. They may acquire a different IP address based on
whether the user chose to retain on-premises IP address or not. If both MAC and IP addresses differ, Azure
Migrate does not associate the on-premises machines with any Service Map dependency data and asks user to
install agents instead of viewing dependencies.
Post test failover, the on-premises machines remain turned on as expected. Equivalent machines spun up in
Azure acquire different MAC address and may acquire different IP address. Unless the user blocks outgoing
Azure Monitor logs traffic from these machines, Azure Migrate does not associate the on-premises machines
with any Service Map dependency data and asks user to install agents instead of viewing dependencies.
Troubleshoot Azure readiness issues
ISSUE FIX

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.

You can use Azure Site Recovery to do the migration of such


VMs as it will convert the boot type of the VM to BIOS during
the 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.

Unsupported Windows OS Azure supports only selected Windows OS versions, consider


upgrading the OS of the machine 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.

Unendorsed Linux OS The machine may boot in Azure, but no OS support is


provided by Azure, consider upgrading the OS to an endorsed
Linux version 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.

Unsupported OS bitness VMs with 32-bit OS may boot in Azure, but it is


recommended to upgrade the OS of the VM from 32-bit to
64-bit before migrating to Azure.

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.

Collector error codes and recommended actions


RECOMMENDED
ERROR CODE ERROR NAME MESSAGE POSSIBLE CAUSES ACTION

601 CollectorExpired Collector has expired. Collector Expired. Please download a


new version of
collector and retry.

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

758 GetPerfDataTimeout VCenter request vCenter Server Check vCenter Server


timed out. Message credentials are credentials and ensure
%Message; incorrect that vCenter Server is
reachable. Retry the
operation. If the issue
persists, contact
support.
RECOMMENDED
ERROR CODE ERROR NAME MESSAGE POSSIBLE CAUSES ACTION

759 VmwareDllNotFound VMWare.Vim DLL not PowerCLI is not Please check if


found. installed properly. PowerCLI is installed
properly. Retry the
operation. If the issue
persists, contact
support.

800 ServiceError Azure Migrate Azure Migrate Use services.msc to


Collector service is Collector service is start the service and
not running. not running. retry the operation.

801 PowerCLIError VMware PowerCLI VMware PowerCLI Retry the operation. If


installation failed. installation failed. the issue persists,
install it manually and
retry the operation.

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

Azure Government US Gov Virginia

Asia Southeast Asia

Europe North Europe or West Europe

Unites States East US or West Central US

How does the on-premises site connect to Azure Migrate?


The connection can be over the internet or use ExpressRoute with public peering.
What network connectivity requirements are needed for Azure Migrate?
For the URLs and ports needed for Azure Migrate to communicate with Azure, see URLs for connectivity.
Can I harden the VM set up with the OVA template?
Additional components (for example anti-virus) can be added into the OVA template as long as the
communication and firewall rules required for the Azure Migrate appliance to work are left as is.
To harden the Azure Migrate appliance, what are the recommended Antivirus (AV ) exclusions?
You need to exclude the following folders in the appliance for 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

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.

What is dependency visualization?


Dependency visualization enables you to assess groups of VMs for migration with greater confidence by cross-
checking machine dependencies before you run an assessment. Dependency visualization helps you to ensure that
nothing is left behind, avoiding unexpected outages when you migrate to Azure. Azure Migrate leverages the
Service Map solution in Azure Monitor logs to enable dependency visualization.
Do I need to pay to use the dependency visualization feature?
No. Learn more about Azure Migrate pricing here.
Do I need to install anything for dependency visualization?
To use dependency visualization, you need to download and install agents on each on-premises machine that you
want to evaluate.
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.
Can I use an existing workspace for dependency visualization?
Yes, Azure Migrate now allows you to attach an existing workspace to the migration project and leverage it for
dependency visualization. Learn more.
Can I export the dependency visualization report?
No, the dependency visualization cannot be exported. However, since Azure Migrate uses Service Map for
dependency visualization, you can use the Service Map REST APIs to get the dependencies in a json format.
How can I automate the installation of Microsoft Monitoring Agent (MMA ) and dependency agent?
Here is a script that you can use for installation of dependency agent. Here are instructions on how you can install
MMA using command line or automated methods. For MMA, you can also leverage a script available here on
Technet.
In addition to scripts, you can also leverage deployment tools like System Center Configuration Manager (SCCM ),
Intigua etc. to deploy the agents.
What are the operating systems supported by MMA?
The list of Windows operating systems supported by MMA is here. The list of Linux operating systems supported
by MMA is here.
What are the operating systems supported by dependency agent?
The list of Windows operating systems supported by dependency agent is here. The list of Linux operating
systems supported by dependency agent is here.
Can I visualize dependencies in Azure Migrate for more than one hour duration?
No, Azure Migrate lets you visualize dependencies for up to one hour duration. Azure Migrate allows you to go
back to a particular date in the history for up to last one month, but the maximum duration for which you can
visualize the dependencies is up to 1 hour. For example, you can use the time duration functionality in the
dependency map, to view dependencies for yesterday, but can only view it for a one hour window. However, you
can use Azure Monitor logs to query the dependency data over a longer duration.
Is dependency visualization supported for groups with more than 10 VMs?
You can visualize dependencies for groups that have up to 10 VMs. If you have a group with more than 10 VMs,
we recommend you to split the group in to smaller groups and visualize the dependencies.

Next steps
Read the Azure Migrate overview
Learn how you can discover and assess a VMware environment

You might also like