Info2soft use cookies to help you have a superior and more admissible browsing experience on our website. Privacy Policy
Loading...
By:
Migrating VMware or Horizon workloads to Azure Virtual Desktop (AVD) involves more than moving virtual machines. VM dependencies, application compatibility, user profiles, security policies, and cutover planning all affect whether a migration wave succeeds, so automation works best when these dependencies are mapped before the move.
This guide covers:
Before automating the migration, prepare the source VMware environment, Azure resources, application dependencies, and a recovery plan. Skipping any of these steps increases the risk of automating a migration that only reveals its problems during cutover.
The migration workflow requires enough access to inventory VMware resources, configure replication, and collect information about the VMs being moved. Exact permission requirements depend on the migration method and the VMware environment, so validate the required roles against current Azure Migrate or Azure Site Recovery documentation before deployment.
At minimum, the migration team needs visibility into:
For large VMware environments, PowerCLI can help export VM inventory from vCenter in bulk rather than collecting it manually.
AVD needs more than a destination for the migrated VM. Before replication or deployment begins, plan out:
Disk and storage planning is particularly important because AVD session hosts are deployed as new Azure VMs, not an imported copy of the original VMware VM. Factor in VM sizing, OS disk requirements, user profile storage, network connectivity, and expected concurrent sessions before finalizing the target architecture.
Automation can reproduce a defined migration workflow, but it cannot compensate for missing dependencies. Map out dependencies such as:
This is a common failure point in VMware-to-AVD projects. A session host can migrate successfully while an application still points to an on-premises server or a network path Azure cannot reach, turning a technically successful VM migration into a failed user migration.
Create a recoverable copy of the source workloads before replication and cutover. A VMware snapshot can serve as a short-term recovery point, but it should not be treated as a complete backup strategy for production workloads. Understanding the difference between a backup and a snapshot helps set the right expectations for this step.
The migration plan should also define how long the original VMware environment stays available after each migration wave. Keeping the source workloads intact until validation is complete gives the team a practical rollback path if applications, profiles, or user access do not behave as expected.
There is no single automation path for every VMware to AVD project. Azure Migrate is Microsoft’s recommended tool for VM migration, PowerShell can automate repetitive provisioning and inventory tasks on top of it, and Azure Site Recovery fits teams that are already using it for disaster recovery and want to extend that same replication into a migration.
Azure Migrate can discover VMware VMs, assess their Azure readiness, and replicate supported workloads using its agentless migration method. For AVD projects, replication is only one part of the process because the resulting Azure VM still needs to fit the planned AVD session host architecture.
A typical workflow includes:
Azure Migrate automates the replication and cutover mechanics, but it does not validate application dependencies or convert a VMware Horizon desktop into a complete AVD deployment on its own. Session host configuration, user profile setup, application delivery, AVD registration, and identity still need separate review before users move to the new environment.
PowerShell fits migrations involving many VMs or requiring integration with an existing provisioning pipeline. Instead of manually collecting inventory and configuring each workload through the portal, administrators can combine VMware PowerCLI with the Azure Migrate PowerShell module to standardize repeatable tasks.
Step 1: Export VMware VM inventory with PowerCLI
Connect-VIServer -Server vcenter.contoso.com
Get-VM | Select-Object Name, PowerState, NumCpu, MemoryGB, `
@{N='OS'; E={$_.Guest.OSFullName}} |
Export-Csv -Path .\vm-inventory.csv -NoTypeInformation
This produces a CSV of VM names, power states, CPU and memory allocation, and guest OS, which the migration team can review before deciding which VMs to move.
Step 2: Connect to Azure and retrieve the Azure Migrate project
Connect-AzAccount
Set-AzContext -SubscriptionId ""
$ResourceGroup = Get-AzResourceGroup -Name "MigrateRG"
$MigrateProject = Get-AzMigrateProject -Name "MyMigrateProject" `
-ResourceGroupName $ResourceGroup.ResourceGroupName
Step 3: Retrieve discovered servers and start replication
$DiscoveredServers = Get-AzMigrateDiscoveredServer `
-ProjectName $MigrateProject.Name `
-ResourceGroupName $ResourceGroup.ResourceGroupName
$TargetResourceGroup = Get-AzResourceGroup -Name "TargetRG"
$TargetVirtualNetwork = Get-AzVirtualNetwork -Name "TargetVNet"
foreach ($server in $DiscoveredServers) {
New-AzMigrateServerReplication -InputObject $server `
-TargetResourceGroupId $TargetResourceGroup.ResourceId `
-TargetNetworkId $TargetVirtualNetwork.Id `
-TargetSubnetName $TargetVirtualNetwork.Subnets[0].Name `
-OSDiskID $server.Disk[0].Uuid `
-DiskType Standard_LRS `
-LicenseType NoLicenseType `
-TargetVMName $server.DisplayName `
-TargetVMSize Standard_D2s_v3
}
Step 4: Track jobs, then test and complete migration
$ReplicatingServer = Get-AzMigrateServerReplication `
-ProjectName $MigrateProject.Name `
-ResourceGroupName $ResourceGroup.ResourceGroupName `
-MachineName "MyTestVM"
Start-AzMigrateTestMigration -InputObject $ReplicatingServer -TestNetworkID $TargetVirtualNetwork.Id
Start-AzMigrateServerMigration -InputObject $ReplicatingServer -TurnOffSourceServer
Each of these cmdlets returns a job object that can be polled with Get-AzMigrateJob until its state changes to Succeeded. For custom pipelines that need finer control, the Azure Site Recovery REST API exposes the same replication and migration operations for direct integration.
The main advantage of this approach is consistency rather than complete hands-off migration. PowerShell can standardize repetitive operations, but engineers should retain manual approval points for dependency checks, application validation, test migration, and production cutover.
Microsoft currently positions Azure Site Recovery (ASR) as a disaster recovery service and recommends Azure Migrate for VM migration projects. ASR still supports replicating VMware VMs to Azure and failing over to them, so it remains a practical option for businesses that are already using it for VMware disaster recovery and want to extend that same replication into an AVD migration wave, rather than a first choice for a migration-only project.
If ASR is already part of the environment, a typical workflow includes:
For Horizon environments, a replicated VMware VM is not automatically an AVD session host. The migration architecture still needs to determine whether workloads become individual Azure VMs, are rebuilt from a golden image, or are redeployed as AVD session hosts before this path is finalized.
VM migration does not automatically preserve the user experience from VMware Horizon. Horizon environments often rely on VMware UEM, Persona, or roaming profiles, so profile data needs its own migration plan when moving users to AVD.
AVD commonly uses FSLogix profile containers, which store user profiles separately from session hosts so users get a consistent experience across any host they land on.
Simply copying an existing profile directory into an FSLogix container can carry over broken permissions or references to the old environment. Microsoft’s FSLogix Profile Migration Module, currently a private preview tool, can help convert roaming profiles and UPD disks into FSLogix containers, but it should be tested outside production first since preview tools carry no SLA.
FSLogix Cloud Cache writes profile data to more than one storage location at once, which can ease the transition while users move between VMware and AVD. It does not replace planning the actual migration; storage permissions, identity, and network access still need validation before cutover.
Migrate a small group of profiles first. Check sign-in, app settings, and permissions on AVD before rolling out to everyone else.
A successful replication or profile migration does not prove that users can work normally in AVD. A pilot should reproduce the key identity, application, network, profile, and security dependencies of production before the first migration wave gets cut over, the same logic behind disaster recovery testing best practices: validate the failover path before you actually need it.
Start with a small AVD host pool covering different application requirements, profile sizes, user roles, and access patterns rather than only the simplest desktops.
The pilot should walk the full user path: authentication, AVD client access, session host registration, profile loading, application launch, file access, printing, and other peripherals. Checking only whether the Azure VM boots can miss problems that only show up once a real session starts.
Keep the validation environment isolated enough that testing cannot affect active users or business data, while still reproducing production dependencies such as Active Directory, DNS, network connectivity, application servers, file shares, and identity policies.
For each migrated workload, compare the AVD session against its VMware equivalent. Focus on application licensing, drive mappings, Group Policy behavior, clipboard restrictions, USB or peripheral access, and network-dependent applications.
Issues caught at this stage are far easier to fix than issues discovered after users have already moved.
Define measurable acceptance criteria before the migration wave begins, so successful VM replication alone is not mistaken for a successful migration.
Record results for each wave instead of relying on informal feedback. A consistent checklist makes it easier to decide whether a workload is ready for production, needs remediation, or should stay on VMware a bit longer.
Automation speeds up the mechanics of a VMware to AVD migration, but it does not protect the source environment while replication, testing, and cutover are in progress. A snapshot taken just before a migration wave gives a short-term recovery point, but it is not a substitute for a real backup if a cutover fails or a rollback decision comes days later.
i2Backup gives the source VMware environment a recoverable copy that stays independent of the migration process itself, so a bad cutover does not also become a data-loss event.
For teams also building a pilot host pool or validation environment, i2CDM can spin up ready-to-use virtual copies of production data in minutes, which is useful for testing migration waves without touching live workloads.
Q: Can I move an existing VMware VM directly into an AVD host pool?
No, not directly. It still needs AVD agent components, identity integration, and host pool registration first. Rebuilding session hosts from a standardized Azure image is usually more practical than converting migrated VMs one by one.
Q: What happens to VMware Horizon user profiles?
They don’t automatically become FSLogix containers. Depending on the source, teams either convert data into FSLogix, keep the old profile system temporarily, migrate select user data only, or start users on fresh profiles. Test with real users before rolling out, since a profile can look migrated and still fail at sign-in.
Q: Can I keep the same applications?
Usually yes, but test each app separately from the VM migration. Apps tied to specific drivers, licensing servers, or Horizon-specific components may need RemoteApp or dynamic delivery instead of a straight image install.
Q: How do I preserve VMware security policies?
Map each Horizon policy (clipboard, drive redirection, USB access, session timeouts, conditional access, and similar controls) to its GPO, Intune, or AVD equivalent before migration. Matching names on paper isn’t enough, so test the actual behavior in a real AVD session.
Q: Can I roll back to VMware?
Yes, if you keep the VMware environment running until each migration wave passes validation. Define rollback triggers in advance (failed authentication, broken apps, profile corruption) and test the rollback process itself, not just plan it on paper.
Automating a VMware to AVD migration removes a lot of repetitive work in VM replication and provisioning, but the mechanics of moving a VM are only part of the project. FSLogix profile conversion, application testing, and policy mapping typically decide whether users have a smooth transition, not the replication tooling itself.
Pilot testing before cutover, clear rollback criteria, and a backup that stays independent of the migration process all reduce the risk of a migration wave that looks successful on the VM level but fails for actual users.
Info2soft offers backup and copy data management tools that can support this kind of migration project, from protecting the source VMware environment to spinning up test copies for validation.
· Enterprise & Mid-market Customers Worldwide
· Support team available to assist you throughout your trial
· Start a 60-day free trial or view demo to see how Info2Soft protects enterprise data.
