Azure Migrate : Server Migration Overview

---

---

• • • Two Versions: Azure Migrate previously supported only discovery and assessment. The current version supports discovery, assessment, and migration. New projects can only be created in the current version.
    • Core Tools: For server migration, Azure Migrate provides (1) Server Assessment Tool and (2) Server Migration Tool. You may also use third-party (ISV) tools integrated into Azure Migrate.
    • Free with Exceptions: Azure Migrate is a free service. However, third-party ISV tools may incur costs depending on the vendor.
    • Dependency Visualization Costs: Data from dependency visualization is stored in a Log Analytics workspace. Standard charges apply after 180 days.
    • No SLA: Azure Migrate doesn’t offer any service-level agreement (SLA), since it’s a free service.
    • Network Requirements: Replication traffic occurs over port 443 and can use Internet or ExpressRoute.
    • Encrypted Disks: Migration of encrypted disks is generally not supported. For VMware VMs with CMK-encrypted disks, see this document on using REST APIs for migration.

---

Azure Migrate offers two migration approaches — agent-based and agent-less. Each has its own advantages, limitations, and use cases.

Agent-based Migration

Agent-based migration supports almost all workloads: VMware, Hyper-V, AWS, GCP, physical servers, and other platforms.

It leverages backend components from Azure Site Recovery.

A Replication Appliance must be deployed, which contains the Configuration Server and Process Server roles. These components coordinate replication and transfer data securely to Azure.

You must also install the mobility agent on each source machine to send data to the Process Server. The data is then compressed, encrypted, and sent to Azure, where it’s written to managed disks.

Note: The Azure Migrate appliance is not mandatory for agent-based migration unless you’re also performing a server assessment.

Refer to the official Agent-based Migration Architecture for more details.

Agent-less Migration

No mobility agent is required on each machine. Azure Migrate handles assessment, replication, and migration end-to-end.

Azure Migrate appliance is mandatory in this approach, as it performs all necessary orchestration and replication activities.

For VMware VMs: Both agent-based and agent-less options are available. In agent-less migration, Azure Migrate auto-creates a Key Vault to manage replication credentials.

Agent-based vs Agent-less: When to Choose What?

Thumb rule: Opt for agent-less migration wherever it’s supported — it’s easier, faster, and requires fewer touchpoints on the source machines.

However, agent-less has limitations. Agent-based migration is more versatile and works in nearly all scenarios.

Recommended: Use agent-less migration for VMware or Hyper-V environments if supported. For Hyper-V specifically, Microsoft provides only an agent-less method.

Some scenarios where agent-based is necessary for VMware VMs:

• • When using RDM / pass-through disks
  • When the VM uses UEFI boot

Azure Migrate supports Availability Zones since September 2020. You can now target specific zones during migration.

If you’re unsure which approach to choose, refer to this comparison guide.

Hyper-V: Only the Hyper-V host or cluster node needs the agent installed, not individual VMs. See Hyper-V Architecture.

Other platforms (e.g., AWS, GCP, Physical): The mobility agent must be installed on each machine. See the Agent-based Migration Architecture documentation for details.

---

Before initiating a server migration using Azure Migrate, you should plan thoroughly. Consider the following areas:

1) Support Matrix

Refer to the official Azure Migrate Support Matrix to check compatibility, limitations, and specific considerations for VMware, Hyper-V, and physical server migrations.

2) Supported Geographies

Azure Migrate projects can be created in specific regions only. However, you can migrate workloads to any Azure region regardless of where the project resides. Refer to this table for valid project regions.

3) Permissions Required

• • • Contributor or Owner access in the target subscription is required to create the Azure Migrate project and register the appliance.
    • For agent-less VMware migration, Azure Migrate will create a Key Vault — ensure your account has permission to create Key Vaults.
    • You must also have the privilege to create Azure AD App Registrations.
    • Proper privileges in the source environment (vCenter, Hyper-V, OS-level access) are needed to deploy appliances and trigger migration.

4) Network Planning

Ensure required ports are open for communication between source servers, the Azure Migrate appliance, and Azure. This depends on your migration type, source environment, and whether a proxy or firewall is in use.

5) Target Setup

Before triggering replication or migration, ensure that the following components are available in the target Azure region:

• • • Target Resource Group where the Azure VM will be created
    • Target Virtual Network and Subnet for migrated VMs
    • Optional isolated network for performing test migrations

Here are useful links for preparing various source environments:

• • • Prepare VMware VMs for Azure migration
    • Prepare Hyper-V VMs for Azure migration
    • Prepare physical servers for Azure migration

---

An Azure Migrate Project acts as the top-level container for organizing your migration activities. It stores metadata related to discovery, assessment, and migration operations.

You must have an Azure subscription and sufficient permissions (Contributor or Owner) to create the project.

You can create multiple Azure Migrate projects under a single subscription. Each project can be configured to discover and migrate workloads from various environments like VMware, Hyper-V, or physical servers.

Geography selection during project creation is only for metadata storage. You can still choose any target region for actual migration.

During project creation, you’ll be prompted to select tools:

• • • Server Assessment Tool
    • Server Migration Tool

You can also skip tool selection during project creation and add them later.

Refer to the official guide on how to add tools to an Azure Migrate project.

---

After creating an Azure Migrate project and adding the Server Assessment tool, the next step is machine discovery. This step identifies on-premises machines and adds them to the Azure Migrate inventory.

Note: To perform discovery and assessment, you must deploy the Azure Migrate appliance in your source environment.

Azure Migrate Appliance

The Azure Migrate appliance performs the following functions:

• • • Discovers machines from the source environment
    • Collects machine metadata (e.g., OS type, configuration, disk details)
    • Collects performance data for right-sizing during assessment
    • Replicates and migrates VMs (only in agent-less migration)

For VMware environments, the appliance also:

• • • Detects installed applications (agent-less)
    • Maps server dependencies
    • Handles agent-less replication

Refer to: Azure Migrate Appliance Architecture

Replication Appliance

The Replication Appliance is used only in agent-based migration scenarios.

While the Azure Migrate appliance is responsible for discovery and assessment, the replication appliance handles the actual data replication and cutover in agent-based approaches.

More details here: Azure Migrate Replication Appliance

Appliance: Important Points

• • Agent-less: The Azure Migrate appliance is used for assessment, replication, and migration.
  • Agent-based: Azure Migrate appliance is only for assessment. Replication is handled by the replication appliance.
  • OS is Windows Server 2016 with a 180-day evaluation license.
  • Internet or proxy access is required for the appliance to communicate with Azure.
  • VMware: The appliance is deployed as an OVA on an ESXi host. One-to-one mapping is required between vCenter and appliance.
  • Hyper-V: A ZIP with a VHD is downloaded and deployed on a Hyper-V host.
  • Physical servers: Scripts are used to deploy the appliance on a physical or virtual machine.
  • Data is sent to Azure over port 443 (SSL).
  • Connectivity to Azure can be over Internet or ExpressRoute (with public or Microsoft peering).

Setup references:
• Appliance Overview
• Setup for VMware
• Setup for Hyper-V

---

Before migrating servers to Azure, it’s crucial to understand their interdependencies. This helps identify groups of servers that should be migrated together to avoid application outages.

Dependency Visualization provides a graphical view of inbound and outbound connections, helping you decide which servers are tightly coupled.

It can also help you determine whether a server is still active or can be decommissioned. If there’s no activity (inbound/outbound) for a period, the server might be idle and not needed in Azure.

Create Dependency Visualization

Follow these steps to enable dependency visualization:

1. 1. Associate a Log Analytics Workspace: The workspace and Azure Migrate project must be in the same subscription. The workspace should be in East US, Southeast Asia, or West Europe — other regions are not supported for this feature.
   2. Install Azure Monitoring Agent (AMA): While the legacy Microsoft Monitoring Agent (MMA) was previously used, Microsoft now recommends using AMA for new deployments, as MMA is being deprecated.
      During AMA installation, ensure that the VMs are connected to the correct Log Analytics Workspace, which is linked to your Azure Migrate project for dependency data collection.
   3. Install Dependency Agent: This agent collects detailed network dependency data and must be installed on each VM.

Note: All dependency logs are stored in the associated Log Analytics Workspace and may incur costs after 180 days.

Analyze Dependency

You can view dependency data from two locations:

1. 1. From Azure Migrate Console:
      Go to Azure Migrate: Server Assessment → Discovered Servers → Dependencies → View Dependencies for each VM. You’ll see traffic details between machines to identify dependencies.
   2. From Log Analytics Workspace:
      Use KQL queries to extract and visualize dependency data. This is useful for custom analysis or reporting.

For further reference, including sample queries, check this official Microsoft guide.

---

Machine groups are logical collections of VMs or servers that share application dependencies. They allow you to assess and migrate related machines together in a controlled way.

Azure Migrate allows you to create machine groups in two ways:

1) Manual Grouping

If you’re already aware of the application topology or server relationships, you can manually group the machines. For example, if an application relies on five different servers (e.g., app, DB, cache, auth, and gateway), you can create a group containing those five servers.

2) Dependency-Based Grouping

If you’re unsure about which machines are interdependent, use Dependency Visualization to identify those relationships. Based on the visualization, you can create a group from the discovered dependencies.

Machine groups are crucial for planning phased migrations and minimizing business disruption.

For more details, refer to How to Create a Machine Group.

---

Server assessment is a crucial step in the migration journey. A thorough assessment ensures that you choose the right target VM size, disk type, and cost optimization strategy — all while minimizing post-migration issues.

Note: Assessment is performed on machine groups, not on individual VMs.

Assessment Properties

When you create an assessment, you’ll configure the following parameters:

• • Target Location: Azure region where VMs will be migrated
  • Disk Type: Automatic / Standard HDD / Standard SSD / Premium SSD
  • Reserved Instances: None / 1-year / 3-year reserved instance pricing
  • VM Sizing Criteria: Performance-based or As-on-premises
  • Performance History: Number of days to collect usage metrics (applicable only for performance-based assessments)
  • Performance Utilization: Percentage buffer to factor in future growth
  • VM Series: Select VM families allowed (e.g., D-series, E-series)
  • Comfort Factor: Safety margin for CPU, memory, disk, and network sizing
  • Pricing Preferences: Currency, offer type, VM uptime hours, and applicable discounts
  • Azure Hybrid Benefit: Specify whether you’re eligible to bring your own Windows Server licenses

Assessment Type

There are two types of assessments:

1) Performance-Based (Recommended)

• • Collects CPU, memory, disk IOPS, and throughput metrics from the source machine over a period
  • Suggests optimal Azure VM size based on actual usage, not provisioned capacity
  • Uses data collected from the Log Analytics Workspace (via MMA/AMA)

Best Practices:

• • Wait until enough performance data is collected (e.g., 2 weeks) before running the assessment
  • Assessment results are not updated automatically. Manually recalculate for up-to-date results

2) As-On-Premises

• • Does not consider performance metrics
  • Provisions equivalent VM size in Azure based on existing configuration (CPU, RAM, disks)

Assessment Output

Each assessment generates the following key insights:

• • Azure Readiness: Indicates whether the VM can be migrated to Azure (flags issues like EFI boot, encrypted disks)
  • Monthly Cost Estimate: Projected cost of compute and storage in Azure
  • Storage Cost Estimate: Summary of storage cost for the entire machine group

You can drill down into each report for detailed VM-level or disk-level recommendations.

Confidence Rating

Azure Migrate provides a Confidence Rating (1–5 stars) to indicate the reliability of an assessment.

• • 5 stars: Ample and recent performance data
  • Lower rating: Incomplete, stale, or insufficient data points

To improve your rating, allow more time for performance data collection before running the assessment.

Further reading:

• About Assessment Calculations
• How to Create an Assessment
• Best Practices for Server Assessments

---

After completing the assessment, the next step is to replicate the servers to Azure. This prepares the environment for final migration or test migration.

Before starting replication:

• • Ensure that the target Resource Group, Virtual Network, and Subnet are already created
  • Validate all required ports and network rules are configured properly

As previously discussed:

• • Agent-based migration: Requires the Replication Appliance to handle replication
  • Agent-less migration: Replication is managed by the Azure Migrate appliance

Replication can occur over Internet or ExpressRoute, using port 443 (SSL).

Best Practices for Replication

• • Start replication in small batches to avoid bandwidth saturation
  • Monitor initial replication duration — it depends on the size of the VM and your network throughput
  • After the initial sync, delta replication begins and syncs only changes
  • Disk type (Standard/Premium) cannot be changed post-replication — choose carefully
  • You can change target resource group or network at migration time, but not disk type
  • Replication status is viewable in Azure Migrate → Server Migration → Replicating Servers

What Happens During First-Time Replication?

For VMware and Hyper-V agent-less replication, Azure Migrate provisions the following components in the Azure Migrate Resource Group (first time only):

1. Service Bus
2. Gateway Storage Account
3. Log Storage Account
4. Key Vault

More info: Provisioning Details

---

Test migration is an optional but highly recommended step — especially for critical workloads and complex application servers.

It helps you verify how the server and application behave in Azure without affecting the production environment.

Key Points about Test Migration

• • You can perform a test migration only after the initial replication is complete
  • The source server remains online during test migration. It is not powered off or disconnected
  • To avoid hostname conflicts, Azure appends a -Test suffix to the VM name in Azure
  • However, inside the OS, the hostname remains the same — update it manually to avoid application or network conflicts
  • Always use an isolated Virtual Network for test migration. It should not be peered with production or connected back to on-prem
  • During test migration, ensure no writes are made to the production database by the test VM — this can cause data inconsistency
  • Clean up the test VM after validation by selecting “Clean up test migration” in the portal
  • You cannot initiate actual migration until the test VM is cleaned up

Billing Note: Test migrated VMs are billed as standard Azure VMs. Delete them after use to avoid unwanted costs.

---

Now that replication and optional test migration are complete, it’s time to perform the actual cutover — moving the server(s) into Azure production.

Pre-Migration Activities

• • Notify stakeholders and secure a downtime window, including rollback time
  • Perform a pre-migration check: Ensure admin credentials, connectivity, and service readiness
  • Take final backups of both application and database (on-prem)
  • If migrating an app-server & DB pair, stop or make the DB read-only before cutover
  • Check the replication health. Resolve any sync issues before proceeding
  • Validate target VM size, disk type, VNet, and resource group. Some parameters can’t be changed later
  • Ensure appliance health (Azure Migrate appliance or Replication Appliance) and connectivity to Azure
  • Check NSG (Network Security Group) rules — ensure RDP/SSH is allowed

Important: Once a migration is complete, you cannot re-use the same replication. If you delete the Azure VM and want to migrate again, you must start from scratch.

Initiate Migration

Once everything is validated and downtime starts:

• • Use the “Migrate” option from the Azure Migrate portal
  • You’ll be prompted to shut down the source server. Choose Yes (recommended)
  • If Azure fails to shut it down, do it manually before proceeding

Post-Migration Activities

Once the Azure VM is provisioned successfully:

• • Verify resource group, network, and storage allocation
  • Login to the VM using local or domain credentials
  • Verify all drives, services, and application functionality
  • Check Event Viewer for critical issues
  • Take disk snapshots before making any changes
  • Uninstall on-prem agents like backup/monitoring tools not needed in Azure
  • If migrated from VMware, uninstall VMware tools
  • Uninstall MMA / Dependency agent used during discovery phase (if not needed anymore)
  • Install the Azure VM Agent if not already present — this is required for extensions
  • Configure backup using Azure Backup or third-party tools
  • Monitor VM performance for a few days to ensure proper sizing

Final Step: Handover the VM to application and testing teams. Ensure it connects to the correct DB, functions as expected, and meets all business requirements.

---

In this article, we explored the end-to-end journey of Server Migration using Azure Migrate, covering assessment, replication, test migration, and production cutover.

We used Microsoft-native tools (Server Assessment and Server Migration) which are available at no extra cost and support both agent-based and agent-less approaches.

Key takeaways include:

• • Plan your migration carefully — assess compatibility, dependencies, and sizing before taking action
  • Involve all stakeholders including application teams, DBAs, infra and network admins
  • Always take a backup before and after migration
  • Test migrations are strongly recommended for critical apps
  • Post-migration tuning is vital to optimize performance and cost

By following these practices, your server migration to Azure can be smooth, predictable, and cost-effective.

---

• • Azure Migrate Documentation
  • Azure Migrate Services Overview
  • Azure Migrate FAQs
  • Troubleshooting Azure Migrate
  • Azure Migrate Pricing