► Score Your AVD or Windows 365 Environment in Under 5 Minutes: Find out where you stand and what to fix next.

Get the FREE scorecard →

Citrix, Horizon, and Physical Endpoints Do Not Migrate the Same Way | Workspace Weekly

July 1, 2026

Most migration plans start with the destination.

Are we moving to AVD? Windows 365? Citrix DaaS? A hybrid model? Which users need pooled desktops? Which users need personal desktops? What happens to the image, profiles, apps, and access model?

Those are the right questions, but there are not enough because the source environment is just as important. If the plan treats every starting point as a generic “VDI migration,” the team misses issues that will impact whether the migration is successful to users.

Your source environment defines the risks you need to validate first.

Click to View Details

Figure 1: Citrix, Horizon, and physical endpoint migrations may share a destination, but each path brings different risks, dependencies, and validation priorities.

Why Your VDI Migration Destination Does Not Tell the Whole Story

If you are responsible for moving users into AVD or Windows 365, on paper, the destination strategy may seem clear.

The landing zone is approved, the target desktop model is selected, and the first user groups are identified. The team follows a rollout plan, then the source-specific issues start showing up.

The Citrix users depend on NetScaler behavior that was never fully documented. A WEM policy controls something users rely on every day. Profile behavior does not match expectations after the move.

The Horizon users are coming from persistent desktops that have years of user-specific history. Workspace ONE policies need to be rebuilt in Intune. App Volumes or ThinApp assumptions do not map cleanly to the new app delivery model.

Users with physical endpoints are not just moving into a new destination platform. They may still work directly from those devices, use them to access virtual resources, or both.

The target platform may be the same. The migration path is not.

Citrix Migration to AVD or Windows 365 Brings Its Own Dependencies

Citrix environments are often mature, deeply integrated, and operationally familiar, making them tricky to migrate.

The risk is not only whether AVD or Windows 365 can host the workload. It is whether the team has accounted for the Citrix-specific pieces that have held the experience together. That may include:

  • NetScaler or ADC dependencies
  • StoreFront or gateway behavior
  • Citrix policies and WEM settings
  • Profile management
  • Published app, printing, and session behavior

A Citrix migration can look like a desktop migration when it is really an access, policy, profile, and app delivery migration all at once.

That is why the first step is not only to choose the target platform. It is to map what Citrix is doing today.

A good Citrix migration plan needs to understand how access, policy, session behavior, profiles, app delivery, and user expectations are handled today.

Those are the areas that need validation before the team gets deep into a rollout.

Omnissa Horizon Migration Creates Different Validation Questions

Omnissa Horizon environments create a different set of questions.

Some organizations have persistent desktops with user-specific history. Some depend on App Volumes, ThinApp, Workspace ONE, Persona Management, or tightly coupled vSphere operations. Some have users who expect their desktop to behave like “their machine,” not like a clean new workspace.

A Horizon migration may need to validate:

  • How profile data moves
  • Whether persistent desktop expectations still apply
  • How Workspace ONE policies translate into the new model
  • How app layering or packaging changes
  • Whether user workflows, access, and performance still behave as expected

This is where migration plans often get too clean. They say “move users from Horizon to Windows 365” or “move users from Horizon to AVD.”

The actual work is more specific, a good Horizon migration plan needs to understand:

  • which users still depend on persistent desktop behavior
  • which apps rely on the current delivery model
  • which settings live in Workspace ONE
  • which profile assumptions are part of the user experience
  • which workflows need to be validated before a larger wave

Those are different questions than Citrix migration; that is the point.

Physical Endpoint Migration is Not a Lighter Version of VDI Migration

Migrations involving physical endpoints can look simpler because there may be no broker to retire and no shared VDI platform to unwind. That can be misleading.

Physical endpoints carry their own risk because the device in front of the user can still shape the experience after the move.

That risk can come from hardware, drivers, peripherals, local browser controls, VPN posture, security agents, Windows Update timing, or the way users depend on the device to complete their workflow.

A clean test from a standard endpoint does not prove every endpoint group is ready. That is especially true for users with specialized workflows such as:

  • Call center users with headsets or softphones
  • Printer, scanner, or badge reader users
  • Users with local browser or USB dependencies
  • Users on older hardware, stricter security controls, or unique VPN posture

Physical endpoint migration requires validating the physical device, access method, and workflow the user depends on.

Same Destination, Different VDI Migration Plan

A useful way to frame the migration is to separate the source path from the destination decision.

The destination may be AVD, Windows 365, Citrix DaaS, or a hybrid end state. But the validation plan should still reflect where users are coming from.

Source pathCommon hidden riskWhat to validate
CitrixNetScaler, WEM, profile management, published app behavior, policy translationAccess path, policy behavior, profile behavior, app launch, workflow completion
HorizonPersistent desktop expectations, Workspace ONE policy rebuild, App Volumes or ThinApp assumptions, profile dataProfile migration, app delivery changes, user workflow, session behavior, performance
Physical endpoint-dependent usersDevice variance, peripherals, local dependencies, security agents, Windows Update cadenceRepresentative endpoint groups, device-dependent workflows, security stack, peripherals, app behavior
Hybrid estateDifferent user groups landing on different modelsSegment-specific validation, baseline comparison, operational ownership, rollout readiness

This table is not meant to replace the migration plan. It is meant to keep the team from pretending one plan covers every path.

Why One Migration Checklist is Not Enough

A single migration checklist can be useful, but it can also hide the difference between paths.

If every workstream is treated the same way, teams may not spend enough time validating the risks that belong to the source environment.

For Citrix, that may mean access and policy translation. For Horizon, that may mean profiles, persistence, and app delivery changes. For physical endpoints, that may mean hardware variance, security agents, and peripherals. For a hybrid estate, that may mean governance and ownership across multiple landing zones.

The better approach is to start with segmentation.

Which users are coming from Citrix? Which is coming from Horizon? Which comes from physical endpoints? Which will land on AVD pooled, AVD personal, Windows 365, Citrix DaaS, or an on-prem retained model?

And most importantly: which risks belong to each path? Only then does the validation plan become specific enough to be useful.

How Login Enterprise Validates the Migration Experience Across Paths

The best form of validation gives teams a repeatable way to test what matters to users.

That may be login time, app launch, workflow completion, session behavior, or performance compared to a known-good baseline.

For Citrix and Horizon migrations, Login Enterprise can help validate that critical apps and workflows still perform as expected before, during, and after a migration wave.

For AVD and Windows 365 migrations, it can help test access, session launch, app behavior, and regression over time.

For representative physical endpoint groups, Login Enterprise can help validate the device, workspace, and workflow experience together, especially where local device conditions, security agents, peripherals, or endpoint updates may affect the workflow.

The point is not to test everything; the point is to validate the specific risks that belong to the path users are actually on.

Use Migration Planning Tools to Avoid Starting from Scratch

Michael Kent, CPO at Login VSI, has shared migration resources that help teams evaluate migration paths, compare deployment patterns, and identify risk before the rollout starts.

The goal is to make the migration path visible before the team is deep into execution.  For this topic, the most relevant resources are:

Watch the Migration Webinars

For more context, watch the first two migration webinars:

Figure 2: Migration Series 1 covers why change is unavoidable and how to start framing the migration decision before the technical work begins.

Figure 3: Migration Series 2 covers how to spot platform-specific gaps before they become migration problems.

These sessions are useful companion resources because they show the broader migration framework around Citrix, Omnissa Horizon, AVD, Windows 365, and physical endpoint paths.

Pick the Path Before You Pick the Plan

Citrix, Horizon, and physical endpoint migrations do not fail in the same places. That is why the source environment is important.

A migration plan that starts only with the destination can miss the dependencies, assumptions, and user experience risks that already exist in the current environment.

Before the team commits to a rollout plan, it should be able to answer a few practical questions:

  • Which source path is this user group coming from?
  • Which destination model are they moving to?
  • Which risks are specific to that path?
  • Which workflows need to be validated?
  • Which migration resources will help the team see the gaps early?

A migration is easier to manage when the team stops treating every starting point the same.

Pick the path. Name the risks. Validate the experience that belongs to that path.

To get started, review Michael Kent’s public migration resources and use the Platform Evaluation Worksheet, Deployment Pattern Comparison, and Migration Toolchain Reference Card alongside your next migration planning conversation. And to see how Login Enterprise can help validate user experience before, during, and after migration, schedule a demo with our team and we’ll walk you through how it works.

Login EnterpriseWorkspace Weekly

Contact Us

Related Resources

Windows 365 Connector Management in Login Enterprise 6.7 | Workspace Weekly
BlogJuly 15, 2026

Windows 365 Connector Management in Login Enterprise 6.7 | Workspace Weekly

What’s New in Login Enterprise 6.7 | Workspace Weekly
BlogJuly 8, 2026

What’s New in Login Enterprise 6.7 | Workspace Weekly

What Does a Mature AVD or Windows 365 Environment Actually Look Like? We Built the Scorecard
BlogJuly 7, 2026

What Does a Mature AVD or Windows 365 Environment Actually Look Like? We Built the Scorecard

Ready to see how you can transform with Login VSI?