Migrating to Horizon from Citrix - Considerations for Better Outcomes

A migration to a new system can be a daunting task for any enterprise, especially when that system involves how employees utilize corporate resources. Downtime for employees translates to lost revenue, which means minimizing downtime is critical to any migration’s success. 

This is the first of a series of articles where we deep dive into migrating to Horizon from Citrix. Up first is what I’d call my list of big rocks. From past, to present and future, the topics here are the major hurdles that can trip up any project if ignored. In point of fact, like virtual desktops and apps themselves, the items here represent the upfront work required to simplify the path forward: technical adjacent, but very important.

To that end, here are some of my top considerations when migrating to Horizon. 

Understanding the Present

Doing more with less is a mainstay of virtual desktops and apps, and nowhere does this become more apparent than when considering how to swap systems. There are two key areas to focus on when trying to rationalize the present:

The Lexicon

First and foremost, everyone must be speaking the same language. Changing systems is a hard enough learning curve for an enterprise without an added language barrier.

Protocol latencies, data access times, app launch times, logon times, provisioning, host density; there is a huge collection of data that can be considered, but each business has a different set of priorities in terms of how they relate the quantitative data to the qualitative user experience. In fact, I can’t think of a metric for desktop or app delivery that someone hasn’t figured out a way to quantify.

In addition to metrics, terminology can vary widely as well. For instance, when moving from Citrix to Horizon, the concept of a Farm exists on both sides: In the Citrix world, a Farm is the top level of the logical groups of provisioning infrastructure. For Horizon, a Farm is a collection of RDS Hosts upon which desktop or app sessions are hosted.

Thus, defining communication of both concepts and measures at the onset of a migration project helps to set clear milestones for what success entails for the enterprise.

The Infrastructure

Virtual desktops and apps are a great way to maximize the value of capital expenditures on hardware. As a result, during the design phase, most of the infrastructure is planned to run at or near capacity (taking BC/DR into account), which can leave little room for additional systems and tools.

Horizon has a set of minimal infrastructure required for operation, typically for a production system at least two Connection Servers, one or more pools or farms, and typically one or more Unified Access Gateways for external access. Even a simple agent swap will require this infrastructure to get started, so a current breakdown of utilization is important.

Getting a handle on the use cases of the current environment is also critical to understanding how the infrastructure is being allocated. For example, if a hospital is performing a migration and they have several Citrix Farms dedicated to their EMR system, and maybe a few servers for clinical desktops scattered about, will an update to the EMR system require changes to how access is handled?  Are users accessing that EMR in a nested way, that is, connecting to a clinical desktop session and then launching that EMR from within it? 

Rationalization of hardware and software, with a keen focus on the relationships between the two, becomes critical to the communication process. It also leads me to my next major consideration.

Understanding the Past

Technical debt. Everyone everywhere has tech debt in one shape or another. In many circles, it’s spoken of in hushed voices, if only from fear of having to deal with it. As the rationalization process occurs, it’s important to keep a couple of major points in mind:

• What is the typical end-user experience?
• Where are the current pain points?
• Why is the environment structured the way it is?

The end-user experience is single-handedly the reason why virtual desktops and apps exist, so understanding what a typical user sees day-to-day interacting with the system is foundational. This goes beyond the quantitative measures we previously defined into the qualitative experience. 

For example, if we’re running virtual desktops into a call center environment and the user logon time is 180 seconds, that might look OK on paper in isolation, but over the course of a typical working year, that’s over eight hours that user waits for their desktop to load. If my hypothetical call center has 250 users, that works out to 2,166 2/3 hours of downtime per year. That’s more than a standard working year of time for most single employees around the world and translates easily into lost revenue.

Sticking with my call center’s newfound logon time pain point, the next item to rationalize is why it happens. In the case of my users, it could be something as simple as a data location issue, say they are accessing user profile information stored centrally in my data center in Canada, but my call center is based out of Ireland, and my administrators sit in the United States. In such a case, the profile data crossing the Atlantic could most certainly cause issues.

It's a completely hypothetical example, but situations such as that are very common. A clean slate isn’t a requirement for a migration process, but a clear understanding of the starting point and end point are required to create a route to success, which leads me to my final consideration.

Understanding the Future

The last thing to consider is a simple question that turns into a highly complex discussion:

“What does good look like for us?”

Simple, right?  In practice, there are two major guardrails to consider for success as we answer that question:

1. How can we simplify our design to minimize the uniqueness of configurations?
2. What do we use to measure success?

The first question boils down to coming up with good use case definitions. This typically needs working sessions which would take up more space to define than I can in a blog, but results in several buckets of users, apps, and infrastructure that we can put together like blocks. By abstracting the three from each other up front, which is admittedly a lot of work, it saves time in the future as it allows more rapid adaptation to a new use case that comes up.

Jumping back to my call center example, we could make up a very solid hypothetical requirements dataset:

OS: Windows 11 Enterprise
Apps: Firefox, Softphone, Microsoft Office, Notepad++, Zoom Client

From that, we can say our call center use case is a generic Windows 11 image with no apps installed, and we will package and deliver the required apps via App Volumes. This leaves us with a single image to maintain, and a couple of app packages that can be reused for our future use cases. Simply put, do the work upfront to simplify the administrative burdens down the road.

The second question then comes into play, measuring success. There is an endless array of metrics that can be used to determine the health of a VDI system. My advice to you? Pick one to start with. Yes, all of the metrics are important and will need consideration, but as the old saying goes “Don’t lose the forest for the trees”. Pick one metric to chase down first and run with it. A lot of the data points are correlative, so fixing one thing may drive out other problems.

Let’s go back to our call center one final time to round out the example. Our users earlier had an issue with logon times, so that’s a great metric to surface. Horizon will surface this metric for each session and feed that into Intelligence for Horizon, so we can see an aggregate and breakdown over time. Since our use case called for App Volumes delivery of the apps, we can configure those packages to be Apps on Demand delivered to ensure users get a desktop as quickly as possible. We can also configure as much of their user profile information in Dynamic Environment Manager to utilize its DirectFlex capabilities to load when required not at startup as well.

Putting it All Together

Putting it all together, a migration to Horizon doesn’t need to be a fresh start, but it is a great opportunity to reset expectations. It’s a unique system and, as such, moving in with preconceived ideas on Horizon working exactly like Citrix will hinder progress. The two are like different models of cars, they serve the same purpose, there are some commonalities, but there are many differences that set them apart from each other. By laying the groundwork with a focus on what I’ve briefly called out, you can set your migration up for success.

While short, there’s a lot to consider here. Hopefully, this blog helps to at least lay a foundation for the kinds of questions that need to be asked and gives a rough map to the end of the road. My colleague, Rick Terlep, recently updated our Horizon for Citrix Practitioners guide here on Tech Zone, I’d highly recommend it as a next stop for more information.