Migrating from VMware Horizon to Azure Virtual Desktop After the Broadcom Changes

By David, 2026-09-11

If you run VMware Horizon, the last three years have handed you a vendor change, a licensing change and, for most teams, a renewal date that now comes with a business case attached. This guide is for the teams that have already decided to look seriously at Azure Virtual Desktop (AVD) and want to know how the move actually works.

If you're still deciding whether to move, start with our Azure Virtual Desktop vs VMware Horizon comparison. This article doesn't repeat it. It assumes the destination is AVD and covers the route: what to inventory, how Horizon concepts map to AVD, a phased plan with a rollback, sizing, and the traps that catch most migrations.

The short version: don't convert your Horizon estate. Rebuild it on AVD from clean images, prove it on a pilot pool, and move users in department waves while Horizon is still there to fall back to. Most of the calendar goes on discovery, app packaging and profiles, not on standing up AVD.

Why Horizon customers are moving now

The facts, with dates, because there is a lot of rumor around this topic:

What that means in practice:

• Horizon itself is now an Omnissa product, not a Broadcom one. Omnissa said in May 2024 it had no plans to raise Horizon list prices beyond normal annual adjustments, and that's worth knowing before you build a case on rumor.
• The infrastructure underneath an on-premises Horizon estate is still VMware. vSphere, vCenter and vSAN are Broadcom products, now sold only as subscriptions. Omnissa's own guidance describes customers receiving separate emails and support portals from Omnissa and from Broadcom.
• That leaves two vendors, two support relationships and two renewal calendars where there used to be one. That, more than any single price, is why so many teams are re-evaluating.

The renewal clock. For most teams the real deadline is whichever comes first: the Horizon subscription term, the vSphere subscription or the end of support on perpetual licenses, or the next hardware refresh. Write all three dates down. A migration that starts planning two or three quarters before the earliest of them can finish on its own schedule. One that starts a month before ends up renewing for another year anyway.

Staying on Horizon is a legitimate outcome, and for some estates it's the right one. The rest of this guide is for the teams that have decided to move.

Step 1: Discovery. Inventory what you actually run

The most common reason a VDI migration goes badly is that the team migrated what they thought they ran. Spend the first weeks finding out what you really run.

Desktop and application pools

• Every pool: floating or dedicated, instant clone or full clone, desktop or published apps (RDSH farms), and the entitlements on each.
• Real concurrency, not entitled users. Peak concurrent sessions per pool over a normal month is the number your AVD sizing will be built on.
• Pools nobody uses. Horizon estates accumulate them, and the cheapest pool to migrate is the one you retire.

Golden images

• For each parent VM: Windows version, installed apps, agents, and any tuning (the VMware OS Optimization Tool and similar).
• Plan to rebuild, not convert. A Horizon parent VM carries the Horizon Agent, App Volumes and Dynamic Environment Manager agents, VMware Tools, and years of drift. A fresh Windows 11 Enterprise multi-session image from the Azure Marketplace, with your apps reinstalled, is less work than cleaning one up.

App delivery

• App Volumes packages (AppStacks): list them and decide per app. The options are to install it in the image, deliver it at deploy time with WinGet, or repackage it for App Attach (MSIX, CIM or VHDX).
• ThinApp packages have no AVD equivalent. Each one needs a native install or an MSIX repackage, so find them early.
• Licensing servers, dongles and apps tied to a MAC address or hostname. Pooled AVD hosts get rebuilt from images, so anything bound to a machine identity needs a plan.

Profiles and policy

• How profiles work today: Dynamic Environment Manager (DEM), the older Persona Management, roaming profiles, folder redirection, or a mix.
• Which DEM settings actually matter to users: app settings, drive maps, printer maps and conditions. These become Group Policy, Intune or logon scripts on AVD.
• Every GPO linked to the Horizon OUs, including the Horizon ADMX templates and Smart Policies (USB, clipboard, client drive and printing rules).

Endpoints, identity and network

• What users connect from. Windows, macOS, iOS, Android and web are all covered by Windows App, but older thin clients and zero clients built only for Blast or PCoIP will not connect to AVD. Count them, because their replacement goes in the budget.
• Identity: whether your desktops depend on on-premises Active Directory, and whether you use True SSO or smart cards.
• Where the apps' back ends live. A desktop in Azure talking to a database that stays in your data center adds latency to every query, so map those dependencies before you choose a region.

Peripherals

• Scanners, signature pads, dictation devices, label and receipt printers, smart card readers, webcams and headsets, per department. This list is what your pilot tests against.

Step 2: Map Horizon concepts to AVD

Most Horizon concepts have a direct AVD equivalent. A few don't, and those are where the planning effort goes. This table maps concepts only. For which platform does each one better, see the comparison page.

Step 3: A phased plan, with a rollback at every step

Run the migration as four phases. The rule that makes it safe: Horizon stays fully available to every user until their wave has signed off.

Phase 0: Landing zone (two to four weeks)

Build the AVD side before anyone moves:

• Networking to wherever your apps live (VPN or ExpressRoute), DNS, and the region choice from discovery.
• Identity: AD DS, hybrid, or Entra ID join for the session hosts.
• FSLogix storage on Azure Files or Azure NetApp Files, with the share permissions and antivirus exclusions set.
• A first golden image, a pooled host pool, and monitoring wired to Log Analytics.

Phase 1: Pilot pool (two to four weeks)

Start with IT and one friendly department that uses a representative mix of apps and peripherals. Before the pilot starts, write down the success criteria:

• Logon time at or below what users get on Horizon today.
• Every app in the pilot department's list launches and works.
• A Teams call with video and screen sharing passes.
• Printing works to each printer type the department uses.
• Every peripheral on the discovery list works.

Measure with real data, not impressions. AVD Insights shows logon duration per phase, so you can see whether a slow logon is the profile, Group Policy or the shell.

Phase 2: Department waves

Order the waves from simplest to hardest: task workers on a small app set first, and departments with specialist apps or peripherals last. Each wave follows the same cycle:

1. Two weeks out, confirm the wave's apps are in the image or catalog, and their peripherals passed the pilot.
2. Migrate profile data. The safest pattern is a fresh FSLogix profile, with documents moved through OneDrive Known Folder Move and the important app settings re-applied by policy.
3. Assign the wave's groups to the AVD application groups and send users the Windows App setup instructions.
4. Run a week or two of hypercare with a named contact for the wave.
5. Sign off, then remove the wave's Horizon entitlements.

Rollback plan

Write it down before Phase 1, not during an incident:

• Trigger. Agree in advance what forces a rollback, such as a blocking app failure or logon times over a set threshold for a set number of users.
• Mechanism. Rolling back is an assignment change. Remove the wave's groups from the AVD application group and restore their Horizon entitlement. Users go back to the Horizon Client they still have installed.
• Capacity. Keep enough Horizon capacity powered for the largest wave in flight. Don't shrink the Horizon cluster until the wave after has signed off.
• Data. Profile moves are one-way. Anything a user changed only inside their AVD profile won't be in their old Horizon profile, which is another reason documents should live in OneDrive rather than the profile.

Phase 3: Decommission

Once the last wave signs off, remove the remaining entitlements and pools. Keep the final images and a backup of the Connection Server configuration for an agreed period. Then time the end of the vSphere hosts, storage and licenses to the renewal dates you wrote down at the start.

Step 4: Sizing and cost

Horizon density numbers don't carry over directly, because the hardware, hypervisor and protocol are all different. Size from the peak concurrency you measured in discovery:

• Multi-session density. Windows 11 Enterprise multi-session lets several users share one VM, which changes the arithmetic compared with one VM per floating desktop. Our AVD sizing guide covers users per vCPU, VM sizes and storage.
• Pay for hours, not peak. On-premises you paid for peak capacity around the clock. On AVD, autoscaling shuts down hosts nobody is using, so off-hours capacity costs little. The AVD cost calculator models it for your headcount and hours, and Cut Idle AVD Compute: Our Cost Model Shows Up to 60% covers the levers.
• Licensing. AVD has no per-user broker license. Access rights come with eligible Microsoft 365 and Windows licenses many organizations already own, and you pay for the Azure infrastructure. Check your current agreements before you build the model.
• Validate in the pilot. Treat your first density figure as a hypothesis. The pilot's CPU, memory and logon data tells you whether to adjust it before the big waves.

Step 5: The traps that catch most migrations

Profiles. Trying to convert DEM or Persona profiles into FSLogix containers usually brings years of profile bloat and corruption with it. Start users on fresh profiles, move documents through OneDrive, and re-apply the settings that matter by policy. Size FSLogix storage for the logon storm, not just capacity. Our FSLogix optimization guide covers the details.

Printing. Horizon's integrated printing doesn't come with you. On AVD your options are client printer redirection over RDP, Universal Print, or direct-IP printers installed on the session hosts. Whichever you pick, test every printer model on the discovery list, and watch for drivers that misbehave on multi-session Windows.

Peripherals and USB. AVD redirects most devices through high-level redirection: printers, drives, cameras, audio, smart cards and the clipboard. Devices that don't fit those categories need opaque low-level USB redirection, which must be enabled on the client and the session host. Scanners, signature pads and dictation devices are the usual suspects. Test each one in the pilot, and set redirection per host pool with RDP properties.

Teams. Use the new Teams app. Microsoft's support for the classic Teams app in VDI environments ended on 1 October 2026, and the app reaches end of availability on 1 April 2027. For optimized calls and meetings on AVD:

• Set the IsWVDEnvironment registry key and install the WebRTC Redirector Service on the session hosts.
• Install Teams per machine on pooled hosts.
• If you use FSLogix, run FSLogix 2210 hotfix 3 or later.

Then confirm in the pilot that Teams reports AVD SlimCore Media Optimized or AVD Media Optimized, not "AVD Media not connected".

Zero and legacy thin clients. Devices that only speak Blast or PCoIP have to be replaced or repurposed. If that surfaces in wave three instead of in discovery, it delays the whole schedule.

Data gravity. If a department's app back end stays on-premises, test it over the real network path from Azure before its wave. Moving the desktop away from the data can make a fast app slow.

Where Atlas AVD shortens the timeline

To be clear about what Atlas AVD doesn't do: it doesn't import Horizon pools. No tool converts a Horizon estate into AVD without rebuilding, and the discovery and app decisions above are still yours. What Atlas AVD removes is most of the build-and-operate work on the AVD side, which is where a migration's weeks go once the decisions are made.

Imaging. Customize a VM, then capture it from Imaging into an Azure Compute Gallery image version. The capture can generalize with Sysprep, install the AVD agent and pre-install FSLogix, and you choose the replication regions as part of the build (Full vs Shallow replication explains that choice). When a new version is published, the Outdated Image view lists the hosts still on an older image. From there you can move them to it with Rolling Replace (Zero Downtime) or a Scheduled Re-Image.

Scaling. Each host pool's Scaling & Intelligence settings cover Start VM on Connect, a minimum number of idle hosts, and weekday schedules. DrainGuard drains a host and re-checks the live session count before any automated shutdown, re-image or replacement, so moving hosts onto a new image never logs anyone off. Adaptive Density tunes users per host from measured usage once the waves are live.

App catalog. The Application Catalog sets which WinGet apps each host pool installs. It inherits from global to tenant to host pool, so a common baseline is defined once and department apps are added per pool. New hosts get their apps at deploy time, running hosts can be given apps on demand, and Winget History shows what Winget-AutoUpdate patched on each host. The WinGet integration post goes deeper. For apps you repackage, Atlas also keeps a registry of your App Attach packages.

Profiles. FSLogix is configured per host pool: storage location, size limit, profile type and the related settings, pushed to every session host. Atlas can create the storage account and file share for you. FSLogix Operations then shows host coverage, health and capacity across pools, which is the view you want open during the first Monday of each wave.

Pilot evidence. With AVD Insights connected, the Logon Breakdown on the Analytics Experience tab shows logon time by phase, median and 95th percentile. That's the data your pilot's success criteria need. The host pool settings also include an Optimize Teams switch and an option to install the WebRTC Redirector Service on new hosts, which takes two of the Teams steps above off the checklist. For printing, Atlas Spool assigns direct-IP printers to pools, hosts, users or groups with no print server.

Atlas AVD runs in your own Azure tenant (why that matters), and a first host pool can be up quickly: see How to Deploy AVD in Under 30 Minutes.

Atlas AVD consulting can run the migration with you

You don't have to do this alone. Atlas AVD offers consulting for every stage of a Horizon migration, from the first inventory to switching off the last vSphere host. Organizations moving off VMware Horizon, Citrix or legacy RDS are one of the core groups the practice works with.

Engagements map onto the phases above:

• Discovery and business case: AVD Assessment. An environment review and cost audit that ends in a prioritized roadmap, including the sizing and cost model your renewal decision needs.
• Landing zone and pilot: AVD QuickStart. A production-ready AVD architecture, secure and scalable host pool design, and image and FSLogix configuration.
• The waves: migration execution. Hands-on help moving departments, with the rollback plan written before the first one goes.
• Through decommission and after: Fractional AVD Architect. Ongoing design reviews, decision support and escalation help without a full-time hire.

You work directly with Atlas AVD's founder: more than 20 years in remote desktop, from PC Anywhere through RDS and Citrix to Azure Virtual Desktop, and AZ-140 certified. Consulting is a separate engagement from the platform, and engagements receive preferential pricing on Atlas AVD if you choose to run your new environment on it.

Running Citrix alongside Horizon? Citrix to Azure Virtual Desktop Migration: A Step-by-Step Plan maps delivery groups, catalogs, UPM and StoreFront onto the same phased plan.

Planning a move off Horizon? Book a 30-minute strategy call and we'll map your renewal dates, pools and apps to a phased plan.

Book a Horizon migration call or see the consulting packages.

FAQ

How long does a Horizon to AVD migration take? It depends on the number of pools, apps and peripherals more than on user count. The landing zone and pilot usually take one to two months together, and each department wave takes a few weeks including hypercare. Discovery and app packaging take most of the calendar.

Can I move my Horizon VMs to Azure as they are? Tools such as Azure Migrate can move VMs, but for pooled desktops a rebuild is better. Horizon parent VMs carry Horizon, App Volumes and DEM agents plus years of drift. Build fresh images on Windows 11 Enterprise multi-session, and keep VM-level migration for the few dedicated desktops that truly can't be rebuilt.

Can Horizon and AVD run side by side? Yes, and they should during the migration. Users keep their Horizon entitlement until their AVD wave signs off, and that overlap is your rollback plan.

What replaces App Volumes? For each app, one of three things: install it in the golden image, deploy it with WinGet when hosts are built, or repackage it for App Attach. Commonly used apps usually belong in the image, and apps only a few users need are the best candidates for App Attach.

Do user profiles migrate automatically? Not well. Converting DEM or Persona profiles tends to carry corruption and bloat across. Start users on fresh FSLogix profiles, move documents through OneDrive, and re-apply the settings that matter by policy.

Does Atlas AVD migrate Horizon for me? Not automatically. No tool converts a Horizon estate without rebuilding it. Atlas AVD automates the AVD side: images, host pools, scaling, apps and profiles. Atlas AVD consulting can plan and run the migration itself with you.

Do I need to buy Atlas AVD to use Atlas AVD consulting? No. Consulting engagements stand on their own. If you then choose to run your new environment on Atlas AVD, consulting customers receive preferential pricing.

Where can I compare the two platforms feature by feature? On the Azure Virtual Desktop vs VMware Horizon comparison page.

Licensing and corporate events are as reported in the sources linked above, with the dates shown. Microsoft product details are taken from Microsoft Learn as of October 2026. Check current terms with Omnissa, Broadcom and Microsoft before you make a renewal decision.