Migrate On-Premises AD to Azure

Simulate an on-prem data center and migrate it to Azure using Azure Migrate.

Introduction

30 Second Summary

Every company with physical servers eventually faces the same question: how do we move all of this to the cloud without breaking everything? The answer is a structured migration process that covers assessment, identity, and workloads.

In this project, you will simulate an on-premises data center inside Azure, then perform a full enterprise cloud migration. You will set up Active Directory, assess your environment for cloud readiness, sync identities, and migrate a server workload to a native Azure VM.

What You'll Build

You will build a complete simulated on-premises environment using nested Hyper-V in Azure, then migrate it to the cloud following the same process enterprises use in production.

By the end of this project, you'll have:

  • A simulated on-premises environment running Active Directory with domain-joined servers inside Azure using nested virtualization.
  • A cloud assessment report from Azure Migrate showing readiness, recommended VM sizes, and monthly cost estimates for your on-prem workloads.
  • On-premises identities synced to Microsoft Entra ID using Cloud Sync, proving hybrid identity works across your environment.
  • A migrated Azure VM running a former on-prem workload after a full replication and cutover with Azure Migrate.
  • Secret Mission: Deploy Microsoft Entra Domain Services to fully retire the on-prem Domain Controller.

Are there any prerequisites?

You need an Azure subscription with sufficient credit. The $200 free trial credit is enough to complete this project. You should also have basic familiarity with Windows Server and PowerShell.

Set Up Your Azure Environment

Every cloud migration starts with a solid foundation. Before you build your simulated on-premises environment or run any assessments, you need a properly configured Azure subscription and the tools to manage it from your terminal.

In this step, you will sign in to the Azure Portal, install the Azure CLI, and create two separate resource groups. One resource group holds your simulated on-premises environment. The other holds the migration target where your workloads will land after migration.

In this step, get ready to:
  • Sign in to the Azure Portal and verify your subscription credit.
  • Install and verify the Azure CLI on your Windows machine.
  • Create two resource groups for your on-prem simulation and migration target.
Sign in to the Azure Portal

The Azure Portal is your central dashboard for managing all cloud resources. You need to confirm your subscription has enough credit to cover the project's compute and storage costs.

  • Open your browser and navigate to https://portal.azure.com.
  • Sign in with the Microsoft account tied to your Azure subscription.
  • Once signed in, click Cost Management + Billing in the left sidebar.
  • Select your subscription and confirm you have credit available.

How much credit do I need?

This project costs approximately $15-25 in Azure resources if completed within 3 hours. The $200 free trial credit covers this easily.

If you are on a pay-as-you-go subscription, the same estimate applies. You will delete all resources at the end to stop charges.

Install the Azure CLI

The Azure CLI lets you create and manage Azure resources directly from your terminal. You will use it throughout this project to provision VMs, create resource groups, and manage migration tools.

  • Open PowerShell by pressing the Windows key, typing PowerShell, and pressing Enter.
  • Check if the Azure CLI is already installed by running:
az version

✔️ I see a version number

The Azure CLI is already installed. You should see version information including a azure-cli entry. Move on to the next substep.

ⓧ Command not found

The Azure CLI is not installed yet. Install it now.

  • Install the Azure CLI by running this command:
winget install --exact --id Microsoft.AzureCLI

What does this command do?

This uses winget, the Windows package manager, to download and install the exact Azure CLI package from Microsoft. The --exact flag ensures the correct package ID is matched.

  • Close and reopen PowerShell after the installation completes.
  • Verify the installation by running:
az version

You should now see version information displayed, confirming the CLI is ready.

Still seeing command not found?

Make sure you closed and reopened your terminal after installation. The Azure CLI path is only added to new terminal sessions.

If winget itself is not recognized, your Windows version may not include it. Update the App Installer package from the Microsoft Store, then try again.

help me install the Azure CLI on my Windows machine

Create your resource groups

A resource group is a logical container that holds related Azure resources. Keeping your simulated on-premises resources separate from your migration target resources makes cleanup straightforward and mirrors how real migrations are organized.

  • Authenticate the Azure CLI to your subscription by running:
az login

What happens when you run this?

A browser window opens asking you to sign in with your Microsoft account. After you authenticate, the terminal displays a list of your Azure subscriptions. If you have multiple subscriptions, the CLI automatically selects your default one.

You should see your subscription details printed in the terminal, confirming authentication succeeded.

Browser not opening?

If the browser does not open automatically, the terminal displays a URL and a device code. Open the URL manually and enter the code to complete authentication.

help me log in to Azure CLI

  • Create the resource group for your simulated on-premises environment by running:
az group create --name onprem-rg --location eastus

What does this command do?

This creates a resource group named onprem-rg in the East US region. All your simulated on-premises resources (the Hyper-V host VM and its nested VMs) will live here.

You should see a JSON response with "provisioningState": "Succeeded" confirming the resource group was created.

  • Create the resource group for your migration target by running:
az group create --name migration-target-rg --location eastus

What does this command do?

This creates a second resource group named migration-target-rg in the same region. After migration, your workload VM and Azure Migrate project will live here.

You should see the same "provisioningState": "Succeeded" response.

  • Verify both resource groups exist by running:
az group list --output table

You should see both onprem-rg and migration-target-rg listed in the table output.

Resource group creation failed?

If you see an authorization error, make sure az login completed successfully. Run az login again and re-authenticate.

If you see a location error, double check that you typed eastus (no spaces, all lowercase). Azure region names do not contain spaces.

help me create resource groups in Azure CLI

Why two separate resource groups?

In real enterprise migrations, the source environment and target environment are kept in separate resource groups (or even separate subscriptions). This separation makes it easy to clean up the source resources after migration without affecting the newly migrated workloads.

Your Azure environment is ready. Next up, you will deploy a Hyper-V host VM that simulates your on-premises server rack.

Deploy the Simulated On-Premises Hyper-V Host

To simulate an on-premises environment, you need a server that can run virtual machines inside it. In a real data center, this would be a physical server rack. Since you do not have one at home, you will use an Azure VM with nested virtualization to emulate the same thing.

In this step, you will deploy a Windows Server VM in Azure, install the Hyper-V role on it, and configure networking so that any VMs you create inside it can reach the internet.

In this step, get ready to:
  • Deploy an Azure VM with nested virtualization support.
  • Install the Hyper-V role and management tools via PowerShell.
  • Configure an internal NAT virtual switch for nested VM internet access.
Create the Hyper-V host VM

The Standard_D4s_v3 VM size provides 4 vCPUs and 16 GB RAM. It supports nested virtualization, which means it exposes hardware virtualization extensions to the guest OS.

  • Deploy the Hyper-V host VM by running this command in your local terminal:
az vm create \
  --resource-group onprem-rg \
  --name hyper-v-host \
  --image Win2022Datacenter \
  --size Standard_D4s_v3 \
  --admin-username azureuser \
  --admin-password your-strong-password-here \
  --public-ip-sku Standard

What does this command do?

  • --image Win2022Datacenter selects the Windows Server 2022 Datacenter marketplace image.
  • --size Standard_D4s_v3 picks a VM size that supports nested virtualization (4 vCPUs, 16 GB RAM).
  • --admin-password sets the login password. Replace your-strong-password-here with a password that is 12+ characters and includes uppercase, lowercase, a number, and a symbol.
  • --public-ip-sku Standard assigns a public IP so you can connect via RDP.

Save your password

Record the admin password you chose. You will need it to RDP into the VM in the next substep.

  • Wait for the deployment to complete. This typically takes 2-3 minutes.
  • Note the publicIpAddress value from the JSON output. You will use this to connect via RDP.

Seeing a quota or size error?

Some Azure subscriptions have regional vCPU quotas. If your region does not have capacity for a Standard_D4s_v3, try a different region by adding --location eastus2 (or another region) to the command.

Help me troubleshoot this VM creation error

Connect via RDP and install the Hyper-V role

With the VM running, you need to connect to it and install Hyper-V. The Hyper-V role turns your Azure VM into a virtualization host capable of running its own VMs inside.

  • Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
  • Type Remote Desktop Connection (Windows) or Microsoft Remote Desktop (macOS) and press Enter to open the app.
  • Enter the public IP address from the previous substep as the computer/PC name.
  • Enter azureuser as the username and the password you set during VM creation.
  • Click Connect. Accept any certificate warnings that appear.

What is RDP?

Remote Desktop Protocol (RDP) lets you control a remote Windows machine as if you were sitting in front of it. You will see the full Windows Server desktop of your Azure VM.

Once connected to the VM's desktop, you need to open PowerShell and install Hyper-V.

  • Right-click the Start button and select Windows PowerShell (Admin).
  • Install the Hyper-V role by running this command:
Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart

What does this command do?

Install-WindowsFeature adds a Windows Server role. -Name Hyper-V specifies the Hyper-V role. -IncludeManagementTools adds the Hyper-V Manager GUI.

-Restart automatically reboots the VM when the install finishes. The reboot is required because Hyper-V modifies low-level system components.

  • Wait for the VM to restart. Your RDP session will disconnect during the reboot.
  • Reconnect via RDP using the same IP address and credentials once the VM is back online (usually 1-2 minutes).

RDP connection dropped and won't reconnect?

The VM needs a minute or two to reboot after installing Hyper-V. If RDP still fails after 3 minutes, check the Azure Portal to confirm the VM's status shows Running.

Help me reconnect to my Hyper-V host

Configure the internal NAT virtual switch

Azure does not support Layer 2 networking for nested VMs. This means nested VMs cannot use an external Hyper-V switch to get internet access. Instead, you create an internal switch with NAT so nested VMs route traffic through the host.

  • On the Hyper-V host, open Windows PowerShell (Admin) again (right-click Start).
  • Create the internal virtual switch by running this command:
# Create an internal Hyper-V switch for nested VM networking
New-VMSwitch -SwitchName "InternalNAT" -SwitchType Internal
  • Assign a gateway IP address to the switch's virtual adapter by running:
# Set the gateway IP that nested VMs will use as their default gateway
New-NetIPAddress -IPAddress 192.168.0.1 -PrefixLength 24 -InterfaceAlias "vEthernet (InternalNAT)"
  • Create the NAT network that maps internal traffic to the host's internet connection by running:
# Create the NAT rule so the 192.168.0.0/24 subnet routes through the host
New-NetNat -Name "InternalNAT" -InternalIPInterfaceAddressPrefix 192.168.0.0/24

What do these three commands do?

  • New-VMSwitch creates a virtual network switch inside Hyper-V. The Internal type means it connects nested VMs to the host but not directly to a physical NIC.
  • New-NetIPAddress assigns 192.168.0.1 as the gateway. Nested VMs will use this IP as their default gateway to reach the internet.
  • New-NetNat creates a NAT rule so all traffic from the 192.168.0.0/24 subnet gets translated through the host's internet connection. This is the same concept as a home router performing NAT for your devices.
  • Verify the NAT switch is working by running:
Get-NetNat

You should see an entry named InternalNAT with the prefix 192.168.0.0/24 in the output.

Get-NetNat returns nothing?

Make sure you ran all three commands in order. If you see an error about the interface alias not being found, run Get-NetAdapter to confirm the adapter name matches vEthernet (InternalNAT). The name is case-sensitive and must include the space after vEthernet.

Help me troubleshoot my NAT switch configuration

Your Hyper-V host is ready. It has the virtualization role installed and a NAT network configured for nested VMs. Next up, you will build an Active Directory domain inside this host to simulate a real corporate environment.

Build the On-Premises Active Directory

Every enterprise network starts with a directory service that manages users, computers, and permissions. Active Directory Domain Services is that directory service for Windows environments.

In this step, you will create a nested VM inside your Hyper-V host, install Active Directory, and populate it with the organizational units, users, and groups that a real company would have. This gives Azure Migrate something realistic to discover later.

In this step, get ready to:
  • Create a nested Hyper-V VM for the Domain Controller.
  • Install Active Directory Domain Services and promote it to a Domain Controller.
  • Populate the directory with organizational units, users, and security groups.
Create a nested VM for the Domain Controller

Your Hyper-V host needs a virtual machine that will become the Domain Controller. You will use a Windows Server 2022 evaluation ISO from the Microsoft Evaluation Center (free, 180-day trial).

  • On your local machine, open a browser and navigate to the Microsoft Evaluation Center.
  • Download the Windows Server 2022 64-bit ISO (English).
  • Copy the ISO file into your hyper-v-host VM using the RDP clipboard or by uploading it to a temporary Azure Blob and downloading inside the VM.

Save time with a direct download

Inside your RDP session on hyper-v-host, you can open Edge and download the ISO directly from the Evaluation Center. This avoids transferring a large file over RDP.

  • Once the ISO is on hyper-v-host, open PowerShell as Administrator inside the RDP session.
  • Create the Domain Controller VM by running this command:
# Create a new Generation 2 VM named DC01 with 4 GB RAM and a 40 GB disk
New-VM -Name "DC01" `
  -MemoryStartupBytes 4GB `
  -NewVHDPath "C:\VMs\DC01.vhdx" `
  -NewVHDSizeBytes 40GB `
  -Generation 2 `
  -SwitchName "InternalNAT"

What does this command do?

  • -Name "DC01" names the virtual machine so you can identify it in Hyper-V Manager.
  • -MemoryStartupBytes 4GB allocates 4 GB of RAM, enough to run Active Directory comfortably.
  • -NewVHDPath and -NewVHDSizeBytes create a fresh 40 GB virtual hard disk for the OS.
  • -Generation 2 uses the modern UEFI-based VM type required for Windows Server 2022.
  • -SwitchName "InternalNAT" connects DC01 to the NAT switch you configured in the previous step, giving it internet access.
  • Mount the Windows Server 2022 ISO to DC01 by running:
# Attach the evaluation ISO so DC01 can boot from it
Add-VMDvdDrive -VMName "DC01" -Path "C:\ISOs\WindowsServer2022.iso"

Adjust the ISO path

Replace C:\ISOs\WindowsServer2022.iso with the actual path where you saved the downloaded ISO file.

  • Set DC01 to boot from the DVD drive first by running:
# Set the boot order so the VM boots from the ISO on first start
$dvd = Get-VMDvdDrive -VMName "DC01"
Set-VMFirmware -VMName "DC01" -FirstBootDevice $dvd
  • Start DC01 and connect to it by running:
# Start the VM and open a console window
Start-VM -Name "DC01"
VMConnect.exe localhost DC01
  • In the VMConnect console, complete the Windows Server 2022 installation wizard.
  • Select Windows Server 2022 Datacenter Evaluation (Desktop Experience) as the edition.
  • Accept the license terms and choose Custom: Install Windows only.
  • Select the 40 GB virtual disk and click Next to begin installation.
  • After the install completes and the VM reboots, set a strong Administrator password when prompted.
  • Once logged in to DC01, configure a static IP address so other VMs can find it. Open PowerShell as Administrator inside DC01 and run:
# Set a static IP on the Ethernet adapter for the DC
New-NetIPAddress -InterfaceAlias "Ethernet" -IPAddress 192.168.0.10 -PrefixLength 24 -DefaultGateway 192.168.0.1
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 127.0.0.1

Why a static IP?

A Domain Controller must have a predictable address because every domain-joined machine uses it for DNS lookups. The IP 192.168.0.10 falls inside the NAT subnet you created earlier (192.168.0.0/24).

  • Verify internet connectivity from DC01 by running:
ping 8.8.8.8

You should see reply packets confirming that DC01 can reach the internet through the NAT switch.

No reply from ping?

Make sure DC01's network adapter is connected to the InternalNAT switch. Confirm that your static IP, prefix length, and gateway match the NAT configuration from the previous step.

Help me troubleshoot DC01 network connectivity

Install AD DS and promote to Domain Controller

With DC01 running and connected, you can now install the Active Directory role and create a brand-new forest. This is the same process enterprise admins follow when standing up a new domain.

  • Inside DC01's PowerShell (running as Administrator), install the AD DS role by running:
# Install the Active Directory Domain Services role and management tools
Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools

What does this command do?

This installs the AD DS binaries and administrative tools (like Active Directory Users and Computers) onto DC01. It does not yet create a domain. The promotion step below handles that.

  • Promote DC01 to a Domain Controller for a new forest called contoso.local by running:
# Promote to Domain Controller and create the contoso.local forest
Install-ADDSForest -DomainName "contoso.local" -InstallDns -Force

What does this command do?

  • -DomainName "contoso.local" names the new Active Directory forest and root domain.
  • -InstallDns sets up DNS on this server, which AD requires for service location.
  • -Force suppresses confirmation prompts so the command runs unattended.

You will be prompted to set a Directory Services Restore Mode (DSRM) password. Choose a strong password and remember it.

  • Wait for the promotion to complete. DC01 will restart automatically.
  • After the restart, log in to DC01 using CONTOSO\Administrator and the password you set during Windows setup.

You should see the Server Manager dashboard. The AD DS and DNS roles now appear in the left sidebar.

Cannot log in after promotion?

After promotion, local accounts no longer exist. You must log in as CONTOSO\Administrator (the domain admin). If you see a trust relationship error, allow a few minutes for DNS to fully initialize after the reboot.

Help me troubleshoot login after DC promotion

Create organizational units, users, and security groups

A realistic directory has structure. Organizational units (OUs) group objects by department or function. You will create OUs, users, and groups that simulate a small company.

  • In DC01's PowerShell, create the organizational units by running:
# Create OUs to organize users and servers
New-ADOrganizationalUnit -Name "Employees" -Path "DC=contoso,DC=local"
New-ADOrganizationalUnit -Name "Servers" -Path "DC=contoso,DC=local"

What does this code do?

Each command creates an OU at the top level of the contoso.local domain. The Employees OU will hold user accounts. The Servers OU will hold computer accounts for servers you join to the domain.

  • Create test user accounts by running:
# Create test user accounts in the Employees OU
New-ADUser -Name "John Smith" -SamAccountName "jsmith" `
  -UserPrincipalName "jsmith@contoso.local" `
  -Path "OU=Employees,DC=contoso,DC=local" `
  -AccountPassword (ConvertTo-SecureString "P@ssw0rd123" -AsPlainText -Force) `
  -Enabled $true

New-ADUser -Name "Alice Doe" -SamAccountName "adoe" `
  -UserPrincipalName "adoe@contoso.local" `
  -Path "OU=Employees,DC=contoso,DC=local" `
  -AccountPassword (ConvertTo-SecureString "P@ssw0rd123" -AsPlainText -Force) `
  -Enabled $true

What does this code do?

  • -SamAccountName sets the pre-Windows 2000 login name (e.g. jsmith).
  • -UserPrincipalName sets the modern login format (e.g. jsmith@contoso.local).
  • -Path places the user inside the Employees OU you just created.
  • -Enabled $true activates the account immediately so it can be used for login.

These are lab accounts with a simple password. In production, you would enforce complex password policies.

  • Create security groups and add the users to them by running:
# Create security groups
New-ADGroup -Name "IT-Staff" -GroupScope Global -Path "OU=Employees,DC=contoso,DC=local"
New-ADGroup -Name "HR-Staff" -GroupScope Global -Path "OU=Employees,DC=contoso,DC=local"

# Add users to their respective groups
Add-ADGroupMember -Identity "IT-Staff" -Members "jsmith"
Add-ADGroupMember -Identity "HR-Staff" -Members "adoe"

What does this code do?

Security groups control access to resources. IT-Staff and HR-Staff are Global groups, meaning they can be used across the domain. Adding users to groups mirrors how real companies assign permissions by team rather than by individual.

  • Verify your directory structure by running:
# List all users in the Employees OU
Get-ADUser -Filter * -SearchBase "OU=Employees,DC=contoso,DC=local" | Select-Object Name, SamAccountName

You should see both jsmith and adoe listed with their full names.

Users not showing up?

Make sure you ran the New-ADUser commands after logging in as CONTOSO\Administrator (the domain admin account). If you see access denied errors, confirm you are in an elevated PowerShell session.

Help me troubleshoot missing AD users

Your simulated on-premises Active Directory is now live with a domain, users, and groups. Next up, you will create a workload server, join it to this domain, and give Azure Migrate a real server to discover.

Create a Workload Server to Migrate

Your on-premises Active Directory environment is up and running with a domain controller, users, and security groups. Now you need something to actually migrate.

In a real enterprise, this would be a production server running a business application. You will create a second nested VM that acts as a member server, join it to the domain, and install IIS as a representative workload.

In this step, get ready to:
  • Create a second nested Hyper-V VM and join it to the contoso.local domain.
  • Install IIS as a workload to verify the server is functional.
  • Verify domain authentication by logging in with a domain user account.
Create the workload VM in Hyper-V

This VM represents the server you will migrate to Azure later in the project. It needs its own virtual hard disk, a connection to the NAT switch, and enough resources to run a web server.

  • In your RDP session on hyper-v-host, open an elevated PowerShell window.
  • Create the VM by running this command:
# Create a new Generation 2 VM with 4 GB RAM and a 40 GB disk
New-VM -Name "WebServer01" `
  -MemoryStartupBytes 4GB `
  -NewVHDPath "C:\VMs\WebServer01.vhdx" `
  -NewVHDSizeBytes 40GB `
  -Generation 2 `
  -SwitchName "InternalNAT"

What does this command do?

  • -Name "WebServer01" gives the VM a descriptive name you will recognize later in Azure Migrate.
  • -MemoryStartupBytes 4GB allocates 4 GB of RAM to the VM at boot.
  • -NewVHDPath creates a brand new virtual hard disk at the specified path.
  • -Generation 2 uses the modern UEFI firmware (required for Windows Server 2022).
  • -SwitchName "InternalNAT" connects the VM to the same NAT switch your Domain Controller uses for internet access.
  • Mount the Windows Server 2022 evaluation ISO to the VM by running:
# Attach the evaluation ISO so the VM can boot from it
Add-VMDvdDrive -VMName "WebServer01" -Path "C:\ISO\WindowsServer2022.iso"
  • Start the VM and connect to its console by running:
# Boot the VM and open its console window
Start-VM -Name "WebServer01"
VMConnect.exe localhost WebServer01

What will you see next?

A VM console window opens showing the Windows Server installation wizard. This is the same process you followed when setting up DC01 in the previous step.

  • Complete the Windows Server installation wizard inside the VM console.
  • When prompted for an edition, choose Windows Server 2022 Standard Evaluation (Desktop Experience).
  • Set a local Administrator password when the installation finishes.
  • Once logged in, configure a static IP address so the VM can communicate with DC01 by opening PowerShell inside WebServer01 and running:
# Configure a static IP on the Ethernet adapter
New-NetIPAddress -IPAddress 192.168.0.3 -PrefixLength 24 -InterfaceAlias "Ethernet" -DefaultGateway 192.168.0.1

# Point DNS to the Domain Controller so domain join works
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 192.168.0.2

Why these network settings?

Your NAT switch uses the 192.168.0.0/24 subnet with a gateway at 192.168.0.1. DC01 sits at 192.168.0.2, so pointing DNS there lets WebServer01 resolve the contoso.local domain name.

  • Verify connectivity to the Domain Controller by running:
ping 192.168.0.2

You should see successful replies from 192.168.0.2.

No response from the DC?

  • Confirm DC01 is running in Hyper-V Manager on the host.
  • Double check that both VMs are connected to the InternalNAT switch.
  • Make sure you set the correct gateway (192.168.0.1) and DNS (192.168.0.2) on WebServer01.

help me troubleshoot why my nested VM cannot reach the Domain Controller

  • Join WebServer01 to the contoso.local domain by running:
# Join this server to the contoso.local domain and restart
Add-Computer -DomainName contoso.local -Credential contoso\Administrator -Restart

What does this command do?

The Add-Computer cmdlet registers this server with your Active Directory domain. The -Credential parameter specifies a domain account with permission to join machines. The -Restart flag reboots the machine to complete the join.

  • When prompted, enter the password for the contoso\Administrator account you set when promoting DC01.
  • Wait for the VM to restart, then reconnect via VMConnect once it comes back up.

After the restart, WebServer01 is a domain member of contoso.local.

Install IIS as the workload

A migration needs a workload to carry across. IIS gives you a running web server that you can verify both before and after migration.

  • Log back into WebServer01 as contoso\Administrator after the domain-join restart.
  • Open an elevated PowerShell window and install IIS by running:
# Install the IIS web server role with management tools
Install-WindowsFeature -Name Web-Server -IncludeManagementTools

What does this command do?

This installs the Web-Server role (IIS) on Windows Server. The -IncludeManagementTools flag adds the IIS Manager console so you can configure sites through a GUI.

  • Once the installation completes, verify IIS is serving the default page by opening a browser on WebServer01 and navigating to http://localhost.

You should see the default IIS welcome page with the blue Windows Server banner.

Not seeing the IIS welcome page?

  • Confirm the installation completed successfully by looking for Success in the Exit Code column of the PowerShell output.
  • If you see a restart required message, restart WebServer01 and try again.
  • Run Get-Service W3SVC and confirm the service status is Running.

help me troubleshoot why IIS is not serving the default page on my Windows Server

Verify domain authentication

The final check confirms that domain authentication works end-to-end on this member server. If a domain user can log in, the server is properly integrated with your directory.

  • Sign out of the Administrator session on WebServer01.
  • At the Windows login screen, click Other user.
  • Enter contoso\jsmith as the username and the password you set for this test user in Step 3.
  • Press Enter to log in.

You should land on the Windows desktop, logged in as jsmith. This confirms the server can authenticate against your Domain Controller.

Login failing with domain credentials?

  • Ensure you are using the format contoso\jsmith (domain prefix before the username).
  • Verify DC01 is running and reachable from WebServer01 by running ping 192.168.0.2 in PowerShell.
  • Confirm the user account exists in Active Directory and is not disabled or locked out.

help me troubleshoot why domain login is failing on my member server

Your simulated on-premises environment is now complete with a Domain Controller, a domain-joined workload server running IIS, and real directory users. Next up, you will assess this environment for cloud readiness using Azure Migrate.

Run a Cloud Assessment with Azure Migrate

You now have a working on-premises environment with a Domain Controller and a domain-joined web server. Before migrating anything, real cloud engineers always run a formal assessment first.

An assessment tells you whether your workloads are ready for Azure, what VM sizes to target, and how much the migration will cost per month. In this step, you will use Azure Migrate to discover your nested VMs and generate a full readiness report.

In this step, get ready to:
  • Create an Azure Migrate project and deploy the discovery appliance.
  • Configure discovery credentials and discover your on-prem VMs.
  • Create an Azure VM assessment and review the readiness report.
Create an Azure Migrate project and deploy the appliance

Azure Migrate is a free hub that coordinates discovery, assessment, and migration of on-premises servers to Azure. The first thing you need is a project to store all your assessment data.

  • In the Azure Portal search bar, type Azure Migrate and select Azure Migrate under Services.
  • In Get started, select Discover, assess and migrate.
  • Under Servers, databases and web apps, select Create project.
  • Select your subscription and choose the migration-target-rg resource group.
  • In Project Details, enter contoso-migrate as the project name.
  • Select a geography close to your Azure region (this only controls where metadata is stored).
  • Click Create and wait for the project to deploy.

What is an Azure Migrate project?

A project is the container that holds all discovery, assessment, and migration metadata for your environment. It stores information about what servers you have, whether they are ready for Azure, and how much they will cost to run in the cloud.

The discovery and assessment tools within Azure Migrate are free. You only pay for storage and compute during replication later.

Now you need to generate a project key and download the appliance VHD. The appliance is a lightweight VM that runs on your Hyper-V host and sends discovery data to Azure.

  • In your Azure Migrate project, navigate to Servers, databases and web apps and find Azure Migrate: Discovery and assessment.
  • Click Discover.
  • Under Are your servers virtualized? select Yes, with Hyper-V.
  • In 1: Generate project key, enter an appliance name (alphanumeric, 14 characters or fewer, e.g. contosoappli).
  • Click Generate key and wait for the Azure resources to be created.
  • Copy the generated project key and save it somewhere safe. You will need it during appliance registration.
  • In 2: Download Azure Migrate appliance, select the .VHD file option and click Download.
  • Transfer the downloaded VHD zip file to your Hyper-V host (hyper-v-host) via the RDP session.
  • Extract the zip file to a folder on the host (e.g. C:\AzureMigrateAppliance).

Why does the appliance need so many resources?

The Azure Migrate appliance requires approximately 16 GB RAM, 8 vCPUs, and 80 GB of disk space. It runs multiple discovery agents that communicate with the Hyper-V host over WinRM to collect metadata and performance data from all nested VMs.

Now import and start the appliance VM in Hyper-V Manager.

  • On hyper-v-host, open Hyper-V Manager.
  • In the Actions pane on the right, click Import Virtual Machine.
  • In the Locate Folder step, browse to the folder where you extracted the VHD. Click Next.
  • Select the virtual machine listed and click Next.
  • In Choose Import Type, select Copy the virtual machine (create a new unique ID). Click Next.
  • Accept the default settings for destination, storage, and network. Click Finish.
  • In Hyper-V Manager under Virtual Machines, right-click the newly imported appliance VM.
  • Go to Settings and change the network adapter to use your InternalNAT switch so the appliance can reach the internet and your nested VMs.
  • Start the appliance VM.
  • Right-click the appliance VM and select Connect to open a console session.
  • Set an administrator password when prompted during the initial boot.
  • Assign a static IP address to the appliance in the 192.168.0.0/24 range (e.g. 192.168.0.10) with gateway 192.168.0.1 and DNS pointing to your DC01 IP or an external DNS.

Now register the appliance with your Azure Migrate project.

  • On the appliance VM (or from any machine that can reach it), open a browser and navigate to https://<appliance-IP>:44368.
  • The appliance configuration manager opens. Accept the license terms and complete the prerequisite checks.
  • Paste the project key you saved earlier into the key field.
  • Click Login. In the Continue with Azure Login prompt, select Copy code & Login.
  • A new browser tab opens. Paste the device code and sign in with your Azure account credentials.
  • Return to the appliance configuration manager tab. The registration should complete and show a success message.

Registration not completing?

Make sure the appliance VM has internet access through the NAT switch. Verify it can resolve DNS and reach Azure endpoints on port 443. If you have a pop-up blocker enabled, disable it before clicking Copy code & Login.

Also confirm your Azure account has at least the Azure Migrate Owner role on the subscription. Help me troubleshoot appliance registration

Configure discovery and start it

The appliance needs credentials to connect to your Hyper-V host and discover the nested VMs running on it. It communicates with the host over WinRM port 5985 (HTTP).

Before configuring discovery, enable PowerShell remoting on your Hyper-V host so the appliance can connect.

  • On hyper-v-host (not the appliance), open a PowerShell window as Administrator and enable WinRM by running:
Enable-PSRemoting -Force

What does this command do?

This enables PowerShell remoting on the host so the Azure Migrate appliance can execute remote commands via WinRM. The appliance uses a CIM session over port 5985 (HTTP) to pull server metadata and performance data from the Hyper-V host.

Now configure the discovery source in the appliance configuration manager.

  • In the appliance configuration manager, find Step 1: Provide Hyper-V host credentials.
  • Click Add credentials.
  • Enter a friendly name (e.g. HostAdmin), plus the username and password for an account with Administrator privileges on hyper-v-host.
  • Click Save.
  • In Step 2: Provide Hyper-V host/cluster details, click Add discovery source.
  • Select Add single item.
  • Enter the IP address of your Hyper-V host (192.168.0.1 if you are using the internal NAT address, or the host's actual hostname/IP that the appliance can reach).
  • Select the friendly name for the credentials you just created (HostAdmin).
  • Click Save.
  • For Step 3: Provide server credentials, you can skip this for now (disable the slider). This step is optional for software inventory and dependency analysis.
  • Click Start discovery.

Discovery takes approximately 2 minutes per Hyper-V host in a small lab. You should see DC01 and WebServer01 appear in the discovery status table.

Discovery failing or showing zero servers?

Check that WinRM port 5985 (HTTP) is accessible from the appliance to the host. Verify that Enable-PSRemoting -Force ran successfully on the host. Also confirm the credentials you entered match an account with Administrator permissions on the host.

If you see a validation error for the host, try using the host's actual computer name instead of the IP address. Help me fix Azure Migrate discovery issues

  • Wait for discovery to complete. In the Azure Portal, navigate to your Azure Migrate project.
  • Under Azure Migrate: Discovery and assessment, check the Discovered servers count. You should see 2 servers (DC01 and WebServer01).
Create and review the Azure VM assessment

Now that your servers are discovered, you can create an assessment. The assessment evaluates whether each VM is ready for Azure, recommends a target VM size, and estimates monthly costs.

  • In your Azure Migrate project under Azure Migrate: Discovery and assessment, click Assess and select Azure VM.
  • For Assessment type, confirm Azure VM is selected.
  • Under Discovery source, select Servers discovered from Azure Migrate appliance.
  • Click Next to proceed to assessment settings.
  • For Sizing criteria, select As on-premises. This matches the Azure VM size to your current on-prem VM configuration.
  • Leave the target region set to your preferred Azure region. Accept the other defaults.
  • Click Next.
  • In Select servers to assess, provide an assessment name (e.g. contoso-assessment).
  • Select Create New to create a group. Name the group (e.g. contoso-servers).
  • Select both DC01 and WebServer01 from the discovered servers list. Click Next.
  • In Review + create assessment, review the details and click Create Assessment.

Why use As on-premises sizing?

Performance-based sizing uses CPU and memory utilization data collected over time to right-size VMs. In a lab environment with minimal usage history, this data would not be meaningful.

As on-premises sizing simply matches the Azure VM size to your current VM configuration. This gives you a reliable baseline for a lab scenario.

The assessment takes a few moments to compute. Once it completes, review the results.

  • In your Azure Migrate project, navigate to Assessments and click on your newly created assessment.
  • Review the Azure readiness section. Each server shows a status: Ready, Ready with conditions, or Not ready.
  • Check the Recommended VM size column to see what Azure VM SKU each server maps to.
  • Review the Monthly cost estimate to understand what running these servers in Azure would cost.
  • Check for any migration blockers or warnings listed for each VM.

What should I see in the assessment?

For your lab VMs, you should see both DC01 and WebServer01 marked as Ready (or Ready with conditions). The recommended VM sizes reflect the CPU and RAM you allocated to each nested VM.

The monthly cost estimate shows the projected Azure compute and storage costs. This is the same report enterprise teams present to leadership when planning a migration budget.

Export your assessment

You can click Export assessment to download the full report as an Excel file. This is useful for sharing with stakeholders or keeping as documentation for your migration plan.

Your assessment is complete. You now have data-driven evidence of what your on-premises workloads need in Azure. Next up, you will sync your Active Directory identities to the cloud using Microsoft Entra Cloud Sync.

Sync Identities with Microsoft Entra Cloud Sync

Your assessment proved the on-prem workloads are ready for Azure. But migrating servers is only half the story.

Users still authenticate against the on-premises Domain Controller. If you migrated the workload server without syncing identities first, users would lose access to cloud resources entirely. Microsoft Entra Cloud Sync solves this by syncing your on-prem Active Directory users to the cloud using a lightweight provisioning agent.

In this step, get ready to:
  • Confirm your tenant domain in the Microsoft Entra Admin Center.
  • Install the Microsoft Entra Cloud Sync provisioning agent on DC01.
  • Configure Cloud Sync to sync on-prem users and verify they appear in Microsoft Entra ID.
Confirm your tenant domain

Before Cloud Sync can provision users, your Microsoft Entra tenant needs a domain to assign them to. Every tenant comes with a default .onmicrosoft.com domain. For this project, the default domain works perfectly.

  • Open a new browser tab and navigate to https://entra.microsoft.com.
  • Sign in with an account that has at least the Hybrid Identity Administrator role.
  • In the left navigation pane, browse to Entra ID > Domain names.
  • Confirm that your default domain (e.g. yourtenantname.onmicrosoft.com) is listed and shows a status of Verified.

Why use the default domain?

In production, companies register custom domains (like contoso.com) so users sign in with familiar email addresses. Registering a custom domain requires DNS TXT record verification, which takes time and a real domain.

For this lab, the default .onmicrosoft.com domain lets you complete the sync without purchasing or configuring a domain.

Note your tenant domain name

Write down your full tenant domain (e.g. contosolab123.onmicrosoft.com). You will reference it when verifying synced users later in this step.

Install the Cloud Sync provisioning agent on DC01

The provisioning agent is a lightweight service that runs on a domain-joined server and pushes identity data to the cloud. You will install it directly on DC01, your Domain Controller.

  • RDP into your Hyper-V host (hyper-v-host), then open Hyper-V Manager and connect to the DC01 virtual machine.
  • On DC01, open a browser and navigate to https://entra.microsoft.com.
  • Sign in with your Hybrid Identity Administrator account.
  • In the left pane, select Entra Connect, then select Cloud Sync.
  • On the left pane, select Agents.
  • Select Download on-premises agent, then select Accept terms & download.
  • Once the download completes, run AADConnectProvisioningAgentSetup.exe from your Downloads folder.
  • On the splash screen, select the I agree to the license terms and conditions checkbox, then select Install.
  • After the installation finishes, the configuration wizard opens. Select Next to start the configuration.

What happens during agent configuration?

The wizard walks you through several screens. It asks you to sign in with your Hybrid Identity Administrator credentials to authenticate against Microsoft Entra ID.

It then creates a group Managed Service Account (gMSA) that the agent runs under. This requires Domain Administrator credentials for your contoso.local domain.

  • On the Select Extension screen, select HR-driven provisioning (Workday and SuccessFactors) / Microsoft Entra Connect cloud sync and select Next.
  • Sign in with your Microsoft Entra Hybrid Identity Administrator account when prompted.
  • On the Configure Service Account screen, select Create gMSA and select Next.
  • When prompted for domain credentials, enter your Domain Administrator account (e.g. CONTOSO\Administrator) and select OK.
  • On the Connect Active Directory screen, verify that contoso.local appears under Configured domains. Select Next.
  • On the Configuration complete screen, select Confirm.
  • Wait until you see the message Your agent configuration was successfully verified. Select Exit.

Return to the Microsoft Entra Admin Center in your browser. Navigate back to Entra Connect > Cloud Sync > Agents and verify that the agent appears with a status of Active.

Agent not showing as Active?

The agent can take a minute or two to register. Refresh the page after 60 seconds.

If it remains inactive, ensure DC01 has outbound internet access on port 443. The agent uses outbound-only HTTPS connections to communicate with Microsoft Entra ID.

help me troubleshoot why my Cloud Sync provisioning agent is not showing as Active in the Entra Admin Center

Configure Cloud Sync and verify the initial sync

The agent is running, but it does not sync anything until you create a configuration. You will scope the sync to the OUs you created earlier and enable password hash sync so users can authenticate to cloud resources.

  • In the Microsoft Entra Admin Center, browse to Entra ID > Entra Connect > Cloud sync.
  • Select New configuration.
  • Select AD to Microsoft Entra ID sync.
  • On the configuration screen, select your domain (contoso.local), check the box for Enable password hash sync, and click Create.

What is password hash sync?

Password hash sync copies a secured hash of each user's on-prem password to Microsoft Entra ID. This means synced users can sign into cloud services using the same password they use on-prem.

The actual plaintext password never leaves your Domain Controller. Only a further-processed hash is transmitted over an encrypted connection.

Now scope the configuration to only sync the OUs that contain your users and servers.

  • On the Get started screen, click Add scoping filters.
  • Under Scoping filters, select Selected organizational units.
  • Check the boxes for the Employees and Servers OUs.
  • Click Save.
  • Return to the configuration overview and click Enable configuration to start syncing.

How long does the initial sync take?

Cloud Sync provisions changes every 2 minutes. For a small lab with just a few users, the initial sync typically completes within a single cycle. Password hash sync runs every 2 to 5 minutes after the initial provisioning.

Verify that your on-prem users now appear in Microsoft Entra ID.

  • Wait approximately 3-5 minutes for the initial sync to complete.
  • In the Microsoft Entra Admin Center, browse to Entra ID > Users > All users.
  • Look for the test users you created earlier (e.g. jsmith, adoe). They should appear with a Source value of Windows Server AD.

Users not appearing after 5 minutes?

Go back to Entra Connect > Cloud sync and select your configuration. Check the Provisioning logs for any errors.

A common first-run issue is the gMSA permissions not propagating immediately. Select Restart sync at the top of the configuration page and wait another cycle.

help me troubleshoot why my on-premises Active Directory users are not syncing to Microsoft Entra ID via Cloud Sync

Why Cloud Sync instead of Entra Connect Sync?

Microsoft Entra Cloud Sync is the strategic direction for hybrid identity. It stores its configuration in the cloud and uses a lightweight agent that auto-updates.

The older Entra Connect Sync requires a full on-premises synchronization server and stores its configuration locally. Microsoft is phasing Connect Sync toward retirement as Cloud Sync reaches feature parity. For new deployments, Cloud Sync is the recommended approach.

Your on-premises identities are now synced to the cloud. Users can authenticate to Microsoft Entra ID with their existing passwords. Next, you will migrate the workload server itself to Azure using Azure Migrate.

Migrate the Workload Server with Azure Migrate

Your identities are now synced to the cloud. The next piece of the migration puzzle is moving the actual workload server from on-premises to Azure.

In this step, you will use the Migration and modernization tool in Azure Migrate to replicate your WebServer01 VM to Azure, validate the migration with a test, and then perform the final cutover. This is the same process enterprises use to move production workloads with minimal downtime.

In this step, get ready to:
  • Set up the Migration and modernization tool and install the Azure Site Recovery Provider on the Hyper-V host.
  • Start replication of the workload server and perform a test migration.
  • Execute the final migration cutover so the on-prem VM shuts down and the Azure VM takes over.
Set up the Migration and modernization tool and install the provider

Azure Migrate uses a dedicated Hyper-V migration flow that installs the Azure Site Recovery Provider directly on the Hyper-V host. No separate appliance is needed for the migration step itself.

  • In the Azure Portal, navigate to your contoso-migrate project.
  • Select Servers, databases, and web apps.
  • Under Migration and modernization, select Discover.
  • In Discover machines, for Are your machines virtualized?, select Yes, with Hyper-V.
  • In Target region, select the same Azure region you used for your resource groups.
  • Check the box to confirm the target region, then select Create resources. This creates a Recovery Services vault in the background.

After the resources are created, the portal shows a section for preparing the Hyper-V host.

  • In Prepare Hyper-V host servers, download the Hyper-V Replication provider and the registration key file.
  • Copy both files to your hyper-v-host VM (you can paste them into the RDP session).
  • On the Hyper-V host, run AzureSiteRecoveryProvider.exe to start the installation wizard.
  • In the provider installation wizard, ensure On (recommended) is selected for Microsoft Update, then select Next.
  • Select Install to accept the default installation folder.
  • Select Register to register the server with the Recovery Services vault.
  • Select Browse, locate the registration key file you downloaded, and select Open.
  • Select Next.
  • Ensure Connect directly to Azure Site Recovery without a proxy server is selected, then select Next.
  • Select Finish.
  • Back in the Azure Portal, in the Discover machines pane, select Finalize registration.

What does the Site Recovery Provider do?

The Azure Site Recovery Provider orchestrates replication from Hyper-V VMs to Azure. It works alongside the Recovery Services agent (installed automatically) to upload disk data over outbound HTTPS on port 443.

No agent is installed inside the nested VMs themselves. The replication is agentless from the VM's perspective.

Registration failing?

The registration key expires after five days. If your key has expired, go back to the portal and download a new one.

If you see a 400 Bad Request error, check that outbound HTTPS (port 443) is open from the Hyper-V host to Azure endpoints. Also verify that TLS 1.2 is enabled on the host.

help me troubleshoot Azure Site Recovery Provider registration failures on my Hyper-V host

Start replication and perform a test migration

With the provider registered, you can now replicate your workload VM to Azure. Replication copies the VM's disks to an Azure storage account, then processes that data into replica managed disks.

  • In the Azure Migrate project, select Servers, databases, and web apps.
  • Under Migration and modernization, select Replicate.
  • In Source settings, for Are your machines virtualized?, select Yes, with Hyper-V. Then select Next: Virtual machines.
  • In Virtual machines, check the box next to WebServer01. Then select Next: Target settings.
  • In Target settings, select your subscription, your target region, and set the resource group to migration-target-rg.
  • Accept the defaults for remaining settings and select Next through each tab until you reach Review and start replication.
  • Review the settings, then select Replicate to start the initial replication.

How long does initial replication take?

Initial replication copies all disk data to Azure. In this lab, the workload VM has a small disk so replication should complete in 10-30 minutes. For production VMs with large disks, this can take hours.

You can monitor progress by selecting Replicated servers under Replications in the Migration and modernization section. Wait until the status shows delta sync is active before proceeding.

Once delta replication begins, you can run a test migration. This creates a test Azure VM from replicated data without affecting the on-prem machine.

  • Before proceeding, create a test virtual network. In the Azure Portal, search for Virtual networks and create a new VNet named test-migration-vnet in migration-target-rg with default address space settings.
  • Navigate back to your Azure Migrate project.
  • Select Servers, databases, and web apps.
  • Under Migration and modernization, select Replicated servers under Replications.
  • In the Replicating machines tab, right-click WebServer01 and select Test migrate.
  • In Test Migration, select your test-migration-vnet virtual network, then confirm to start the test.
  • Monitor the test migration job in the portal notifications. After it completes, go to Virtual Machines in the Azure Portal. You should see a VM with the suffix -Test.
  • Connect to the test VM via RDP and open a browser. Navigate to http://localhost to verify IIS responds with the default website.

Your test VM proves the workload survived migration. Now clean up the test.

  • Back in your Azure Migrate project, navigate to Replicated servers under Replications.
  • Right-click WebServer01 and select Clean up test migration. This deletes the test VM and its resources.

Why run a test migration?

A test migration creates a copy of the VM using replicated data without shutting down the source. The on-prem machine keeps running and replicating during the test.

This lets you validate that the workload boots correctly and applications respond in Azure before committing to the final cutover. In production, teams use this to perform user acceptance testing (UAT) with zero risk to the live workload.

Test migrate button disabled?

The button stays disabled until the initial replication completes and delta sync begins. If you just started replication, wait 10-30 minutes and refresh the page.

If a previous test migration completed but you did not clean it up, the button also stays disabled. Run the cleanup first.

help me troubleshoot why the Test migrate button is disabled in Azure Migrate

Execute the final migration cutover

Your test migration confirmed the workload runs correctly in Azure. Now it is time to perform the real cutover. This shuts down the on-prem VM, applies the final delta of disk changes, and boots the migrated Azure VM.

  • In the Azure Migrate project, select Servers, databases, and web apps.
  • Under Migration and modernization, select Replicated servers under Replications.
  • In the Replicating machines tab, right-click WebServer01 and select Migrate.
  • In the Migrate dialog, for Shut down virtual machines and perform a planned migration with no data loss, select Yes, then select OK.

What happens during cutover?

Selecting Yes for the planned migration option tells Azure Migrate to shut down the on-prem VM first, apply the final disk delta, then boot the Azure VM. This ensures zero data loss.

The cutover typically takes 5-15 minutes per VM. During this window, the workload is unavailable. In production, teams schedule this during a maintenance window.

  • Monitor the migration job in portal notifications. Wait for the job to show as completed.
  • Navigate to Virtual Machines in the Azure Portal. You should see your migrated VM (named WebServer01 or similar) running in migration-target-rg.
  • Connect to the migrated VM via RDP and open a browser. Navigate to http://localhost to verify IIS is operational.

Now complete the migration to stop replication and clean up the replication state.

  • Back in your Azure Migrate project under Replicated servers, right-click the VM and select Stop replication. This stops replication and removes replication state data.
  • Optionally, rename the migrated VM to WebServer01-migrated in the Azure Portal to distinguish it from the original.

What about the on-prem VM?

The nested VM WebServer01 was shut down automatically during cutover. It remains on the Hyper-V host in a stopped state. In a real migration, you would decommission it after confirming the Azure VM operates correctly.

Migration job failing?

If the cutover fails, check that the Hyper-V host has outbound HTTPS connectivity to Azure. The host needs to upload the final delta before the Azure VM can boot.

Also verify that the on-prem VM was not already shut down manually before you triggered the migration. Azure Migrate expects to shut it down as part of the planned migration flow.

help me troubleshoot a failed Azure Migrate cutover for my Hyper-V VM

Secret mission

Deploy Microsoft Entra Domain Services

You have synced identities and migrated a server. But the on-prem Domain Controller is still running. What if you could retire it entirely and let Azure handle domain services for you? In this secret mission, you will deploy Microsoft Entra Domain Services to create a fully managed domain, join your migrated VM to it, and decommission the on-prem DC.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project uses Azure VMs with nested virtualization, and the Hyper-V host alone costs approximately $4.50 per day if left running.

Cost warning

The Hyper-V host VM (Standard_D4s_v3) costs ~$0.19/hour. The migrated Azure VM adds additional compute charges. If you completed the Secret Mission, Microsoft Entra Domain Services costs ~$0.05/hour.

Delete all resources immediately after completing the project to avoid unexpected charges. Even stopped VMs incur storage costs.

Resources you used:

  • Hyper-V host VM (Standard_D4s_v3) in Azure.
  • Nested VMs (Domain Controller and workload server) running inside the host.
  • Azure Migrate project and discovery appliance.
  • Storage account used for replication.
  • Migrated Azure VM (the workload server now running natively in Azure).
  • Microsoft Entra Cloud Sync configuration and provisioning agent.
  • If Secret Mission: Microsoft Entra Domain Services managed domain.

Keep everything running

No action needed. Choose this if you are still actively building or experimenting with the environment.

  • Be aware the Hyper-V host costs approximately $4.50/day in compute charges alone.
  • The migrated Azure VM adds additional hourly charges depending on its assessed size.
  • If you enabled Microsoft Entra Domain Services, it costs ~$0.05/hour.
  • Monitor your Azure spending in the Cost Management blade of the Azure Portal.

Pause - I'll come back to this later

Deallocate your VMs to stop compute charges. Storage charges continue at a lower rate, but you save significantly on hourly costs.

  • In the Azure Portal, navigate to each VM (the Hyper-V host and the migrated VM).
  • Click Stop on each VM's Overview page to deallocate it.
  • Alternatively, deallocate the Hyper-V host VM from the CLI by running:
az vm deallocate --resource-group [[ONPREM_RG="your on-prem resource group name"]] --name [[YOURVM="your Hyper-V host VM name"]]
  • Deallocate the migrated VM by running:
az vm deallocate --resource-group [[TARGET_RG="your target resource group name"]] --name [[MIGRATED_VM="your migrated VM name"]]
  • When you are ready to resume, start the VMs from the Azure Portal or CLI.

Delete - I don't want to use this again

Remove all project resources completely. This is the recommended option to avoid any ongoing charges.

  • Delete the on-premises simulation resource group by running:
az group delete --name [[ONPREM_RG="your on-prem resource group name"]] --yes --no-wait
  • Delete the migration target resource group by running:
az group delete --name [[TARGET_RG="your target resource group name"]] --yes --no-wait

These two commands remove the Hyper-V host, nested VMs, Azure Migrate project, storage accounts, and the migrated Azure VM.

  • Remove the Cloud Sync configuration from the Microsoft Entra Admin Center. Browse to Entra Connect then Cloud sync.
  • Select your configuration, then click Delete configuration at the top of the configuration screen.
  • If you completed the Secret Mission, delete Microsoft Entra Domain Services. In the Microsoft Entra admin center, search for Microsoft Entra Domain Services and select it.
  • Select your managed domain, then click Delete on the Overview page. Re-enter your domain name to confirm the deletion.

Why delete the resource groups first?

Deleting a resource group removes every resource inside it in a single operation. The --no-wait flag lets the deletion run in the background so you can proceed with the Cloud Sync and Domain Services cleanup immediately.

That's a Wrap!

That's a Wrap!

You just completed a full enterprise cloud migration. You built a simulated on-premises data center, assessed it for cloud readiness, synced identities, and migrated a server workload to Azure.

Here's what you accomplished:

  • Built a simulated on-premises environment with Active Directory and nested Hyper-V, replicating what enterprises run in their data centers.
  • Ran a full cloud assessment using Azure Migrate to evaluate readiness, get right-sizing recommendations, and estimate monthly costs.
  • Synced on-prem identities to Microsoft Entra ID with Cloud Sync and migrated a workload server to Azure using replication and cutover.
  • Secret Mission: Deployed Microsoft Entra Domain Services as a managed domain to fully retire the on-prem Domain Controller.

Ready to quiz yourself?