Do not start by migrating desktop VMs
Virtual desktops are assembled from more than a virtual machine: image, applications, user entitlements, profile or user environment, protocol settings, policies, identity, network access, peripherals, support processes, and automation. Migrating the VM without those relationships produces a machine that may boot but is not a replacement service.
Omnissa’s current Horizon architecture still distinguishes dedicated and floating pools, single-session and multi-session delivery, golden images, application delivery, and control-plane components. Those concepts can inform discovery, but AVD uses different objects such as host pools, application groups, workspaces, FSLogix, and Azure-native scaling.
| Horizon discovery object | AVD design question | Migration implication |
|---|---|---|
| Dedicated or floating pool | Personal versus pooled AVD host pool? | User state and ownership model may change |
| RDSH or published apps | RemoteApp or full desktop? | Application delivery can be redesigned |
| Golden image | How many AVD images or host pools are actually needed? | Do not copy image sprawl blindly |
| Profile or user environment | FSLogix, OneDrive, policy, or another target? | State must be mapped and tested |
| App layering | Install, package, attach, or dedicated pool alternative? | Application delivery may require redesign |
| Remote access edge | AVD reverse connect, Shortpath, private design? | Network edge changes materially |
| Horizon policy | AVD, Intune, GPO, or RDP-property equivalent? | Recreate outcome, not setting name |
Migration rule: migrate the user outcome, not the old platform object. If a Horizon setting exists only because of a historical workaround, do not automatically rebuild it in AVD.
Classify workloads by migration readiness
Create three candidate groups. “Ready” personas use supported Windows applications, have understood profiles and network paths, and do not depend on unique Horizon capabilities. “Redesign” personas can move but need new application packaging, personal desktops, network changes, or policy design. “Retain or replace later” personas depend on specialized peripherals, unsupported applications, graphics or protocol requirements, or business constraints that need separate work.
| Candidate signal | Ready | Needs redesign | Hold |
|---|---|---|---|
| Applications | Supported and owned | Complex packaging or dependencies | Unsupported or vendor-blocked |
| Profile/state | Known and portable | Large or custom user environment | Unknown or critical unmanaged local state |
| Network | Mapped and reachable from Azure | Hybrid change required | Latency or security blocker |
| Peripherals | Standard tested devices | Special redirection required | Unsupported critical device |
| User experience | Mainstream workload | High-performance or graphics tuning | No acceptable AVD path yet |
| Operations | Target owner exists | New process required | No support capacity |
Discovery should capture hidden dependencies
Interview help desk and desktop engineers, not only architects. The strangest migration blockers are often known through support tickets: a specific print driver, a script that repairs a profile, a legacy authentication dependency, a USB device, a vendor license server, or a policy that nobody remembers creating.
Rebuild the target image strategy
Horizon estates can accumulate golden images over time. Before recreating them in AVD, identify which differences are still required. Consolidating images can reduce patching and troubleshooting, but combining incompatible applications or user personas can increase risk.
Create an AVD image pipeline with versioning, testing, emergency patching, and rollback. Where possible, move user data and settings out of the base image and use modern application and user-configuration methods. Every separate image should have a technical reason, an owner, and a release process.
Profiles require explicit migration choices
Horizon environments may use persistent disks, FSLogix, Dynamic Environment Manager, folder redirection, local profiles, or combinations. AVD commonly uses FSLogix profile containers. Decide which parts of the existing user state should migrate, which should be recreated, and which data belongs in OneDrive, SharePoint, or a business data service.
Do not copy profile containers blindly between incompatible operating-system or application contexts. Test sign-in, Outlook and Teams caches, browser state, application settings, file associations, and profile growth. During coexistence, define which platform is authoritative for each user’s profile and business data so rollback does not create two divergent states.
Application migration is often more work than desktop migration
Inventory every application with owner, version, installer, dependencies, licensing, data path, authentication, update cadence, peripheral requirements, and current delivery method. Then decide whether it belongs in the base image, a separate host pool, RemoteApp, a personal desktop, or should be modernized or delivered as SaaS instead.
Application-layering constructs do not always map one-for-one to AVD. The target may use image-installed applications, app-attach or packaging patterns where appropriate, other deployment technology, or dedicated pools. The migration plan should focus on supported outcomes rather than reproducing the old packaging mechanism.
Network and protocol behavior must be re-tested
Horizon display-protocol expectations do not predict AVD RDP behavior for every user. AVD uses RDP reverse connect and can use RDP Shortpath under supported network conditions. Test from the actual branch, home, VPN, and international locations represented in the migration.
Map application dependencies to Azure: DNS, Active Directory, Microsoft Entra, databases, file shares, print servers, license servers, proxies, security appliances, and internet egress. A desktop migration can expose latency that the old datacenter location masked. User-to-desktop latency and desktop-to-application latency are separate and both need attention.
Wave design should preserve rollback
A migration wave is safe when users can return to the previous Horizon resource for a defined period without corrupting profile or business data. Decide which system is authoritative for each data type during coexistence and when rollback access will be removed. Ambiguous coexistence is more dangerous than the cutover itself.
Map operational capabilities before the first wave
| Current capability | AVD target question |
|---|---|
| Pool provisioning | How are host pools and session hosts built and updated? |
| Image lifecycle | Who patches, tests, versions and rolls back images? |
| Application delivery | Who packages and validates apps? |
| Profile/user environment | Who owns FSLogix, policy and user state? |
| Monitoring | Which AVD, Azure, Windows and app signals reach operations? |
| Help desk | Can support teams identify session, host, profile, app and network issues? |
| Capacity | Who tunes autoscale, maximum sessions and business-hour schedules? |
| Security | Who owns Conditional Access, host hardening, privilege and logging? |
Migration waves should increase in complexity gradually
The first wave should prove the migration machinery, not the hardest use case. Move a low-risk but representative persona, fix operational gaps, then add complexity. This creates evidence for capacity, support, application packaging, and profile decisions before the organization reaches critical users.
A wave should have entry criteria: applications packaged, target entitlements ready, profile plan validated, support documentation complete, user communication sent, rollback available, and monitoring active. Exit criteria should include user workflow validation, support-ticket review, capacity observation, and unresolved blockers.
A practical migration sequence
- Inventory: Horizon pools, users, apps, images, profiles, policies, network, devices, support, and licensing.
- Persona segmentation: classify ready, redesign, and hold populations.
- Target architecture: define AVD pools, images, identity, profiles, network, apps, security, monitoring, and scaling.
- Pilot: test representative users and the highest-risk dependencies.
- Prepare coexistence: profile and data authority, entitlement, communications, and support routing.
- Wave 1: move low-risk users and observe production behavior.
- Expand: migrate larger or more complex waves as evidence grows.
- Retire: decommission Horizon components only after dependencies and rollback windows close.
Rollback criteria
- Critical line-of-business application cannot complete an agreed workflow.
- User profile or business data integrity is at risk.
- Network latency or display performance materially disrupts the target persona.
- Required peripheral or print workflow is unsupported.
- Security control or monitoring coverage is below the approved baseline.
- AVD support teams cannot diagnose high-frequency incidents.
- Capacity or cost behavior differs materially from the approved model and cannot be corrected inside the wave.
Cost model should include coexistence
During migration the organization may pay for Horizon subscriptions and support, on-premises infrastructure, Azure session hosts, AVD supporting services, profile storage, network, and migration operations at the same time. Include that overlap in the business case. A target-state AVD cost can be accurate and still understate the migration-year spend.
Also include the operational effort to rebuild applications, images, policies, monitoring, and support. A migration justified only by license removal can disappoint if these transition costs are ignored. The business case should show both the steady-state target and the temporary migration curve.
Retirement requires dependency proof
Before removing Horizon infrastructure, verify no users, applications, gateways, scripts, monitoring systems, license servers, profile paths, automation jobs, certificates, DNS records, or support processes still depend on it. Decommissioning should be a checklist with owners, not a calendar event.
Keep enough evidence to understand what was retired and why. This helps later troubleshooting when an old integration or vendor workflow surfaces. If a small set of users remains, separate their required Horizon components from those that can be removed so the residual platform is intentional rather than abandoned infrastructure.
When to keep some Horizon workloads
A phased roadmap can retain workloads that depend on specialized Horizon features, difficult peripherals, unsupported applications, graphics or protocol behavior, or location-specific infrastructure. The retained set should have a documented reason and review trigger. The goal is not a 100 percent migration score; it is a simpler, supportable end-user computing platform aligned with business requirements.
Retaining one workload can also buy time for application modernization. If an old application is scheduled for replacement, rebuilding a complicated AVD workaround may create more cost than keeping a limited Horizon pool until the application exits. Migration sequencing should consider the application roadmap, not only the desktop platform.
Common migration failure patterns
- Treating the project as VM conversion instead of service redesign.
- Rebuilding every old policy without understanding why it exists.
- Migrating profiles without testing operating-system and application compatibility.
- Ignoring support-desk workflows until after cutover.
- Assuming AVD protocol performance from Azure-region proximity alone.
- Migrating applications with no vendor owner or installation source.
- Decommissioning Horizon before rollback windows and dependency checks are complete.
Leadership questions before approving broad migration
- Which personas are ready, which need redesign, and which should remain temporarily?
- Which Horizon-specific capabilities have no validated AVD replacement?
- What is the authoritative user profile and data path during coexistence?
- How long will the two platforms run in parallel and what does that cost?
- Which migration waves expose the greatest application or peripheral risk?
- Can the AVD support team diagnose incidents without Horizon-era tools?
- What evidence is required before each Horizon component is retired?
Horizon policy migration should be outcome-based
Horizon policies can encode display settings, USB and peripheral behavior, clipboard, printing, session timeouts, application behavior, and historical workarounds. Export and classify those policies before design. For every material rule, identify the security, user-experience, compliance, or application objective it supports and then choose the AVD, Windows, Intune, Group Policy, or network control that delivers the same outcome.
Do not copy settings simply because they exist. A policy that was introduced for a retired thin client or an old application may no longer be required. Removing stale policy during migration can simplify the target and reduce troubleshooting, but the decision should be based on evidence rather than guesswork.
Pilot success should include operations and business workflow
The pilot should validate representative applications, profiles, printing, multimedia, peripherals, sign-in, session reconnect, network paths, and user experience. It should also test image deployment, host replacement, scaling, monitoring, ticket routing, and one rollback scenario. That produces evidence about the service, not only the desktop.
Use a small set of success criteria that matter to the business. Examples include completing a critical application workflow, acceptable qualitative responsiveness from a branch office, consistent profile behavior across hosts, a help-desk team able to diagnose common issues, and a measured cost or capacity baseline that is credible enough for production planning.
User communication is part of migration readiness
Even when the Windows desktop looks familiar, connection clients, sign-in prompts, application presentation, printer behavior, and support processes can change. Communicate what users should expect, how to connect, where files live, what to do with old Horizon shortcuts, and how long rollback remains available.
Pilot feedback should be categorized rather than treated as anecdotal noise. Separate platform defects, application defects, training issues, endpoint problems, and user preference. This helps the project fix real blockers without redesigning the platform around every individual difference.
Decommissioning should remove security exposure as well as cost
Old brokers, gateways, service accounts, firewall rules, certificates, monitoring agents, and administrative groups can remain exploitable after users move. Retirement should therefore include access removal, credential cleanup, network-rule removal, certificate handling, DNS changes, and confirmation that legacy management interfaces are no longer reachable.
Keep configuration exports and decision records for an appropriate period so the support team can reconstruct historical behavior if a post-migration issue appears. Decommissioning should reduce both recurring cost and attack surface.
Where BI Cloud Tech can help
BI Cloud Tech can combine Azure Virtual Desktop expertise, a Migration Readiness Assessment, and broader Azure Migration expertise to inventory the current Horizon estate, segment candidates, design AVD, pilot representative workloads, and plan migration waves. The process treats Horizon or Omnissa configuration as source evidence, not as a guarantee that every capability has a direct AVD equivalent.
A practical next step
Export the current desktop and application pools and choose one mainstream pool. List its users, applications, image, profile method, policies, network dependencies, peripherals, and support tickets. If that one pool cannot be described clearly, broad migration planning is premature. Contact BI Cloud Tech to request a VMware or Omnissa Horizon-to-AVD migration assessment.