Mastering Your Hyper-V Migration to Azure: A Comprehensive Guide for SMBs

Step 1: Plan Your Migration and Prepare Azure

az group create --name SkyCore-HyperVMigration-RG --location eastus
az migrate project create --resource-group SkyCore-HyperVMigration-RG --name SkyCore-HyperV-Project --location eastus

• --resource-group SkyCore-HyperVMigration-RG: Specifies the name of the resource group to create for your migration project. We recommend a dedicated resource group for clear organization.
• --name SkyCore-HyperV-Project: The name for your Azure Migrate project. This hub will centralize your assessment and migration activities.
• --location eastus: The Azure region where your project will reside. Choose a region geographically close to your on-premises environment for optimal performance during replication and for your future cloud services.

Portal alternative: Go to the Azure portal, search for "Azure Migrate", and create a new project. Select the subscription, resource group, and desired region. The portal wizard will often prompt you to create a new resource group if one doesn't exist.

Run this to verify:

az migrate project show --resource-group SkyCore-HyperVMigration-RG --name SkyCore-HyperV-Project --query "properties.provisioningState"

This command should return `Succeeded` indicating your project is ready.

Step 2: Deploy Azure Migrate Appliance for VM Discovery and Assessment

As of the current documentation, deploying the Azure Migrate appliance and initiating discovery for assessment is primarily a portal-driven process to simplify setup for SMBs.

Portal steps:

1. Navigate to your Azure Migrate project (SkyCore-HyperV-Project) in the Azure portal.
2. Under Migration goals > Servers, databases and web apps, select Discover under the Azure Migrate: Server Assessment tool.
3. Select Discover machines. For virtualization type, choose Hyper-V.
4. Follow the prompts to download the VHD file for the Azure Migrate appliance.
5. Import this VHD onto one of your Hyper-V hosts to create a new VM for the appliance.
6. Power on the appliance VM. Open a browser on the appliance to access its configuration manager.
7. Configure connectivity, specify credentials for Hyper-V host access (ensure they have necessary permissions to discover VMs), and complete the registration to your Azure Migrate project.
8. The appliance will then start discovering VMs on your Hyper-V hosts. This process can take up to 15-30 minutes for initial discovery.

Run this to verify (after ~30 minutes):

az migrate project show --resource-group SkyCore-HyperVMigration-RG --name SkyCore-HyperV-Project --query "properties.discoveryStatus"

This command should indicate `Active` or `InProgress` if discovery is running. You can also check the Azure portal under Azure Migrate > Servers, databases and web apps > Discovered servers for a count of your discovered VMs.

Step 3: Analyze Your Assessment and Right-Size VMs

Portal steps:

1. In your Azure Migrate project, navigate to Servers, databases and web apps > Azure Migrate: Server Assessment.
2. Click on Assess > Azure VM.
3. In the Assess servers to Azure VMs wizard:
   • Assessment name: Provide a meaningful name (e.g., SkyCore-HyperV-Assessment-Phase1).
   • Source settings: Select your discovered Hyper-V appliance.
   • Target settings: Choose your target Azure region (e.g., East US) and desired Azure storage type (recommend `Premium SSD` for most production SMB workloads for better performance).
   • VM sizing properties: For SMBs, we recommend selecting Performance-based sizing criteria. This uses collected performance data to recommend optimal Azure VM SKUs, preventing guesswork. For instance, if a VM typically uses 30% CPU, it won't be recommended an oversized Azure VM.
   • Compute savings: Consider `Azure Hybrid Benefit` if you have existing Windows Server licenses with Software Assurance, and `Reserved Instances` for stable workloads to significantly reduce costs.
   • Select VMs to assess: Choose the specific VMs or groups of VMs you wish to include in this assessment.
4. Review the assessment details and click Create assessment.

Allow a few minutes for the assessment to generate. Once complete, you can drill down into the assessment report to view:

• Azure readiness: Identifies any compatibility issues.
• Monthly cost estimate: Provides a projected cost for compute and storage.
• Suggested Azure VM SKUs: Recommended VM sizes (e.g., Standard_D2s_v5 for general purpose SMB applications, Standard_E4s_v5 for memory-intensive workloads).
• Storage type recommendations: SSDs are almost always recommended for better performance.

Run this to verify: Review the generated assessment report directly in the Azure portal. There isn't a direct CLI command to export a full assessment report, but you can see the assessment status:

az migrate assessment list --resource-group SkyCore-HyperVMigration-RG --project-name SkyCore-HyperV-Project --query "[].{Name:name, Status:properties.status}"

Ensure the status of your assessment is `Created` or `Completed`.

Step 4: Prepare for Replication: Install Azure Site Recovery Provider

Portal steps to download the provider and key:

1. In your Azure Migrate project (SkyCore-HyperV-Project), go to Servers, databases and web apps.
2. Under Azure Migrate: Server Migration, click Replicate.
3. On the Specify intent page, ensure Servers or virtual machines (VMs) is selected for "What do you want to migrate".
4. For "Where do you want to migrate to", select Azure VM.
5. Under "How will you select workloads", choose From replication provider (Hyper-V).
6. Select your target region (e.g., East US) and confirm. Click Create resources. This action creates the necessary Recovery Services vault in the background.
7. On the Prepare Hyper-V host servers step, you'll find links to Download the Hyper-V Replication provider (AzureSiteRecoveryProvider.exe) and Download the registration key file. Copy both these files to each Hyper-V host you intend to protect.

CLI-like commands for installation on Hyper-V Host:

On each Hyper-V host, open an elevated PowerShell or Command Prompt, navigate to the directory where you copied the installer and key file, and run the following:

# Extract the contents of the installer to a temporary folder
.\AzureSiteRecoveryProvider.exe /q /x:C:\Temp\ExtractedASR

# Navigate into the extracted directory
cd C:\Temp\ExtractedASR

# Install the Hyper-V replication provider (this includes the MARS agent)
.\setupdr.exe /i

• /q /x:C:\Temp\ExtractedASR: Specifies a quiet extraction (`/q`) to the specified path (`/x`). This is a standard command-line switch for many executables.
• cd C:\Temp\ExtractedASR: Changes the directory to where the setup files were extracted.
• .\setupdr.exe /i: Executes the installation of the Site Recovery provider. This command handles the core installation logic.

After running `setupdr.exe /i`, the Microsoft Azure Site Recovery Registration Wizard will launch (or should be launched separately if running Hyper-V Core Server) to complete the registration. While the main installation has CLI switches, the registration step often involves a guided wizard due to the need to browse for the vault key file and select Azure subscription details.

Portal steps to register the provider (after installation):

1. After running `setupdr.exe /i`, the Microsoft Azure Site Recovery Registration Wizard should appear.
2. For Vault Settings, click Browse and locate the vault registration key file you downloaded earlier.
3. Select your Azure Site Recovery subscription, the Recovery Services vault (created in Step 1), and the Hyper-V site. If it's your first host, you'll define a new Hyper-V site name (e.g., SkyCoreHyperVSite).
4. For Proxy Settings, for SMBs, typically select Connect directly to Azure Site Recovery without a proxy server unless your network requires a proxy.
5. Complete the wizard. The Hyper-V host will then register with your Recovery Services vault.

Run this to verify (after ~30 minutes):

Portal verification: In your Azure Migrate project, navigate to Servers, databases and web apps > Azure Migrate: Server Migration. Under "Migration and modernization" click on Replicate. On the Prepare Hyper-V host servers step, check that your Hyper-V hosts appear as registered under Hyper-V servers. Metadata collection can take some time.

Step 5: Enable Replication for Hyper-V VMs

Portal steps:

1. In your Azure Migrate project, navigate to Servers, databases and web apps > Azure Migrate: Server Migration.
2. Click Replicate.
3. On the Replicate page:
   • Source settings: Ensure your Hyper-V hosts are registered.
   • Virtual machines: Select the VMs you want to replicate. You can select multiple VMs here.
   • Target settings:
     • Target location: Confirm the Azure region (e.g., East US).
     • Subscription/Resource group: Choose the target subscription and resource group where your Azure VMs will be created.
     • Virtual network: Select the Azure Virtual Network and subnet where your future Azure VMs will connect. Plan this carefully.
     • Disaster recovery type: This guide focuses on migration, so the primary purpose is moving VMs.
     • Cache storage account: A temporary storage account automatically created in the background to handle replication data.
     • Availability options: For SMBs, consider `Availability Sets` for critical multi-VM applications to ensure high availability within an Azure region. For single VMs, `No infrastructure redundancy required` is common.
     • Azure Hybrid Benefit: Enable this if you qualify to save costs on Windows Server VMs.
   • Replication settings:
     • OS disk: Confirm the OS disk type and size.
     • Data disks: Review and adjust as needed.
     • Target VM size: The assessment recommendations (Step 3) are crucial here. Select the appropriate VM size (e.g., Standard_D4s_v5).
     • OS type: Windows or Linux.
   • Review your settings and click Enable replication.

Allow time for initial replication to complete. This can vary significantly based on the size of your VMs and available bandwidth. You can monitor replication progress in the Azure portal.

Run this to verify:

az site-recovery replicated-item list --resource-group SkyCore-HyperVMigration-RG --vault-name  --query "[].{VMName:properties.friendlyName, Status:properties.replicationHealth}"

• --vault-name : Replace with the actual name of the Recovery Services Vault created by Azure Migrate. You can find this in the Azure portal within your migration project.

You should see `Normal` under the `Status` column for your replicated VMs once initial synchronization is complete.

Step 6: Perform a Test Migration (Dry Run)

Portal steps:

1. In your Azure Migrate project, navigate to Servers, databases and web apps > Azure Migrate: Server Migration.
2. Click on Replicating servers. Select the VM(s) you wish to test.
3. Click Test migration.
4. On the Test migration blade, select the isolation Azure Virtual Network that you've prepared for testing (e.g., `SkyCore-TestVNet`). This network should not be connected to your on-premises network to avoid IP conflicts or unintended communication.
5. Click Test migration.

Azure Site Recovery creates a test Azure VM from the latest replicated data. This process takes some time to complete. Once the test VM is running, you can connect to it via RDP/SSH using its public IP (if configured, or via Azure Bastion/VPN) and perform your validation checks:

• Verify OS boots correctly.
• Check if applications start and function as expected.
• Confirm network connectivity within the test VNet.

After validation, remember to clean up the test resources:

Portal steps to clean up test migration:

1. Go back to Replicating servers, select the VM you just tested.
2. Click Clean up test migration. This will delete the test Azure VM and associated resources.

Run this to verify: There are no direct CLI commands to initiate or clean up a test migration from the provided documentation. Verification relies on monitoring the Azure portal for the status of the `Test Failover` job and checking for the creation and deletion of the test VM.

Step 7: Execute the Full Migration (Failover)

Portal steps:

1. Before initiating, ensure your on-premises Hyper-V VM is shut down or gracefully powered off to prevent data loss or inconsistencies during the cutover.
2. In your Azure Migrate project, navigate to Servers, databases and web apps > Azure Migrate: Server Migration.
3. Click on Replicating servers. Select the VM(s) you wish to migrate.
4. Click Migrate.
5. On the Migrate blade, confirm that you want to shut down the on-premises VM (this is recommended for a clean migration).
6. Click Migrate.

Azure Site Recovery initiates the failover process. This will:

• Perform a final data synchronization to ensure the latest changes are replicated.
• Create the production Azure VM(s) in your designated Azure VNet.
• Power on the Azure VM(s).

Once the migration job completes, you should have your production applications running on the Azure VMs. Perform thorough post-migration validations, just as you did in the test migration, but this time on your production network segment in Azure.

Run this to verify:

az vm show --resource-group  --name  --query "powerState"

• : The Azure resource group where your migrated VM resides.
• : The name of your newly migrated Azure VM.

This command should return `VM running`, indicating your VM has successfully started in Azure.

Step 8: Post-Migration Optimization and Cleanup

Portal steps:

1. Finalize migration: Once satisfied that your workloads are stable in Azure, go to Azure Migrate > Servers, databases and web apps > Azure Migrate: Server Migration > Replicating servers. Select the migrated VM, and click Stop replication. This marks the migration as complete and stops billing for Azure Site Recovery for that VM.
2. Decommission on-premises VMs: Safely power off and eventually decommission your original Hyper-V VMs. Ensure you retain backups or snapshots according to your retention policies before complete removal.
3. Optimize Azure resources:
   • Review VM sizing: Based on real-world usage in Azure, adjust VM sizes if your assessment was slightly off.
   • Implement auto-shutdown: For non-production VMs, configure auto-shutdown schedules to save costs.
   • Monitor costs: Use Azure Cost Management + Billing to track and analyze your cloud spending.
   • Apply Azure Hybrid Benefit/Reserved Instances: If not already done, apply these for further cost savings.
4. Security hardening: Implement Azure Security Center recommendations, configure Network Security Groups (NSGs), and consider Azure Firewall for enhanced security.
5. Backup strategy: Implement Azure Backup for your migrated Azure VMs to ensure data protection.

Example CLI for stopping replication (after successful migration):

$vaultName = ""
$resourceGroupName = "SkyCore-HyperVMigration-RG"
$siteName = "SkyCoreHyperVSite"
$vmName = ""

# Get the Site Recovery context
Set-AzContext -SubscriptionId (Get-AzSubscription | Select-Object -First 1).Id # Adjust if multiple subscriptions

# Get the ASR protected item for the VM
$protectedItem = Get-AzRecoveryServicesAsrReplicatedItem -VaultId (Get-AzRecoveryServicesVault -Name $vaultName -ResourceGroupName $resourceGroupName).ID | Where-Object { $_.Properties.OsDiskName -eq "$vmName" }

# Stop replication and delete the replicated item
if ($protectedItem) {
    Remove-AzRecoveryServicesAsrReplicatedItem -InputObject $protectedItem -ReplicationProvider HyperV -Force
    Write-Host "Replication stopped for VM: $vmName"
} else {
    Write-Host "Protected item for VM $vmName not found."
}

• : Replace with the actual name of your Recovery Services Vault.
• : The original name of the VM you migrated.
• This PowerShell script requires the `Az.RecoveryServices` module and finds the replicated item by its OS disk name, then removes it.

Run this to verify (replication status after stopping):

Portal verification: Navigate to Azure Migrate > Servers, databases and web apps > Azure Migrate: Server Migration > Replicating servers. The VM should no longer appear in the list, or its status should indicate replication has stopped.