Best practices for creating assessments
Azure Migrate provides a hub of tools that help you to discover, assess, and migrate apps, infrastructure, and workloads to Azure. The hub includes Azure Migrate tools, and non-Microsoft independent software vendor (ISV) offerings.
This article summarizes the best practices when creating assessments using the Azure Migrate Discovery and assessment tool.
Assessments you create with Azure Migrate: Discovery and assessment tool are a point-in-time snapshot of data. There are four types of assessments you can create using Azure Migrate: Discovery and assessment:
Assessment Type | Details |
---|---|
Azure VM | Assessments to migrate your on-premises servers to Azure virtual machines. You can assess your on-premises servers in VMware and Hyper-V environment, and physical servers for migration to Azure using this assessment type. Learn more |
Note
If the number of Azure VM assessments are incorrect on the Discovery and assessment tool, click on the total number of assessments to navigate to all the assessments and recalculate the Azure VM assessments. The Discovery and assessment tool will then show the correct count for that assessment type.
Sizing criteria
Sizing criteria options in Azure Migrate assessments:
Sizing criteria | Details | Data |
---|---|---|
Performance-based | Assessments that make recommendations based on collected performance data. | Azure VM assessment: VM size recommendation is based on CPU and memory utilization data. Disk type recommendation (standard HDD/SSD, or premium-managed disks) is based on the IOPS (Input/output per second) and throughput of the on-premises disks.. |
As-is on-premises | Assessments that don't use performance data to make recommendations. | Azure VM assessment: VM size recommendation is based on the on-premises VM size The recommended disk type is based on what you select in the storage type setting for the assessment. |
Note
If the data is being discovered using an Azure migrate appliance, VMs in disconnected or powered-off hosts are not discovered and considered for assessment.
Example
As an example, if you have an on-premises VM with four cores at 20% utilization, and memory of 8 GB with 10% utilization, the Azure VM assessment is as follows:
Performance-based assessment:
- Identifies effective cores and memory based on core (4 x 0.20 = 0.8), and memory (8 GB x 0.10 = 0.8) utilization.
- Applies the comfort factor specified in assessment properties (let's say 1.3x) to get the values to be used for sizing.
- Recommends the nearest VM size in Azure that can support ~1.04 cores (0.8 x 1.3) and ~1.04 GB (0.8 x 1.3) memory.
As-is (as on-premises) assessment:
- Recommends a VM with four cores; 8 GB of memory.
Best practices for creating assessments
The Azure Migrate appliance continuously profiles your on-premises environment, and sends metadata and performance data to Azure. Follow these best practices for assessments of servers discovered using an appliance:
- Create as-is assessments: You can create as-is assessments immediately once your servers show up in the Azure Migrate portal. You can't create an Azure SQL assessment with sizing criteria "As on-premises". Azure App Service assessment by default is "As on-premises".
- Create performance-based assessment: After setting up discovery, we recommend that you wait at least a day before running a performance-based assessment:
- Collecting performance data takes time. Waiting at least a day ensures that there are enough performance data points before you run the assessment.
- When you're running performance-based assessments, make sure you profile your environment for the assessment duration. For example, if you create an assessment with a performance duration set to one week, you need to wait for at least a week after you start discovery, for all the data points to be collected. If you don't, the assessment doesn't get a five-star rating.
- Recalculate assessments: Since assessments are point-in-time snapshots, they aren't automatically updated with the latest data. To update an assessment with the latest data, you need to recalculate it.
Follow these best practices for assessments of servers imported into Azure Migrate via .CSV file:
- Create as-is assessments: You can create as-is assessments immediately once your servers show up in the Azure Migrate portal.
- Create performance-based assessment: This helps to get a better cost estimate, especially if you have overprovisioned server capacity on-premises. However, the accuracy of the performance-based assessment depends on the performance data specified by you for the servers.
- Recalculate assessments: Since assessments are point-in-time snapshots, they aren't automatically updated with the latest data. To update an assessment with the latest imported data, you need to recalculate it.
Best practices for confidence ratings
When you run performance-based assessments, a confidence rating from 1-star (lowest) to 5-star (highest) is awarded to the assessment. To use confidence ratings effectively:
- Azure VM assessments need:
- The CPU and memory utilization data for each of the servers
- The read/write IOPS/throughput data for each disk attached to the on-premises server
- The network in/out data for each network adapter attached to the server.
Depending on the percentage of data points available for the selected duration, the confidence rating for an assessment is provided as summarized in the following table.
Data point availability | Confidence rating |
---|---|
0%-20% | 1 Star |
21%-40% | 2 Star |
41%-60% | 3 Star |
61%-80% | 4 Star |
81%-100% | 5 Star |
Common assessment issues
Here's how to address some common environment issues that affect assessments.
Out-of-sync assessments
If you add or remove servers from a group after you create an assessment, the assessment you created will be marked out-of-sync. Run the assessment again (Recalculate) to reflect the group changes.
Outdated assessments
Azure VM assessment
If there are changes on the on-premises servers that are in a group that's been assessed, the assessment is marked outdated. An assessment can be marked as "Outdated" because of one or more changes in below properties:
- Number of processor cores
- Allocated memory
- Boot type or firmware
- Operating system name, version and architecture
- Number of disks
- Number of network adaptor
- Disk size change(GB Allocated)
- Nic properties update. Example: Mac address changes, IP address addition etc.
Run the assessment again (Recalculate) to reflect the changes.
Low confidence rating
An assessment might not have all the data points for many reasons:
You didn't profile your environment for the duration for which you're creating the assessment. For example, if you're creating an assessment with performance duration set to one week, you need to wait for at least a week after you start the discovery for all the data points to get collected. If you can't wait for the duration, change the performance duration to a smaller period and "Recalculate" the assessment.
Assessment isn't able to collect the performance data for some or all the servers in the assessment period. For a high confidence rating, ensure that:
- Servers are powered on during the assessment
- Outbound connections on ports 443 are allowed
- For Hyper-V servers, dynamic memory is enabled
- The connection status of agents in Azure Migrate is "Connected" and check the last heartbeat
- For Azure SQL assessments, Azure Migrate connection status for all SQL instances is "Connected" in the discovered SQL instance tab.
Recalculate the assessment to reflect the latest changes in confidence rating.
For Azure VM assessments, few servers were created after discovery had started. For example, if you are creating an assessment for the performance history of last one month, but few servers were created in the environment only a week ago. In this case, the performance data for the new servers will not be available for the entire duration and the confidence rating would be low.
For Azure SQL assessments, few SQL instances or databases were created after discovery had started. For example, if you're creating an assessment for the performance history of last one month, but few SQL instances or databases were created in the environment only a week ago. In this case, the performance data for the new servers won't be available for the entire duration and the confidence rating would be low.