Migrating to Horizon Overview

Overview

Let’s resurface some age-old questions about moving to Horizon from Citrix. In short, there are few key questions customers typically ask or think about when the idea of a platform transition is presented:

• How easy is it to migrate from to Horizon?
• What are the steps, tips and tricks needed for a successful migration?
• Do I have to slow-roll (gradual/controlled) or light-switch (all or nothing) the migration?
• How do I handle the “technical debt” from my old Citrix or RDS environments?
• What will the end users and IT experience when you make the switch?

While customers may have varying answers for these questions, the general flow and process to move to Horizon is relatively similar. This article will break the migration down into simple, easy to understand phases that will help guide you down the path towards a successful migration.

The Migration Superhighway

Any migration typically has several moving parts and phases, and in many cases – migrations become more complex than they really need to be. It’s important to keep your plan simple, focused and outcome driven. Focus on the tasks and milestones at hand and avoid getting into the weeds at either a technical or planning level. Don’t strive for perfection. Be prepared to compromise and track any technical debt that can be addressed later. If you don’t you will never even go beyond planning your migration.

Here's a simple recipe to help guide you through the migration process. Migrations can be broken down into 5 simple phases. Each of these phases takes people, process and technology into account.

• Plan It – Simply put, it’s planning the work. Understanding the current virtual desktop and application state, developing success criteria and achievable outcomes (the “why”), developing tasks and milestones (the “what”), staffing and task assignment (“who” will be doing the “what”), and communications to your platform users are some of the major elements you need to consider when planning your migration.
• Test It – Take your plan, validate your plan, modify your plan. Testing with some controlled, friendly use cases will put some substance behind your migration effort. Developing run books and documentation will allow you to engage others to help accelerate the migration while reducing human error and minimizing unexpected issues/problems.
• Move It – Once you have your plan tested and validated, resources assigned, tasks and milestones captured, documentation ready – it’s time for the rubber to meet the road and migrate your users. Execute your plan, communicate with your users, and make things happen. You will most likely need to fix unexpected problems along the way.
• Run It – This is one of the most ignored items in any migration – how do you run your Horizon platform during and after the migration. This phase should run in parallel to the planning, testing and moving phases of the project. Having your operational and support processes in place (i.e., application packaging, image lifecycle management, patching, etc.) for the platform will keep it healthy and operationally efficient.
• Improve It – When your migration is done, it’s time to make the service better – simple to access, simple to use, simple to run. You may have to address technical debt from your legacy implementation, or work towards rationalizing your environment, implementing App Volumes, upgrade to Windows 11, etc.

The Migration Mindset

As you plan and execute your migration, there are some overarching considerations that apply to all phases of the project. They can (and will) affect the speed, technical approach, end user experience impact, etc. of the migration.

• End User Experience is FIRST and FOREMOST – As IT professionals, we typically focused on the tech and not the end user. The focus of your migration should be on the end user; the technical and behind the scenes aspects should be secondary. Experience needs to be optimized. The system needs to be easy to use and seen as a productive tool for your end users to consume.
• Migration speed and approach is driven by your business and technical needs/strategy – How fast you can move and how you approach the migration from a technical perspective could and will be driven by several non-technical factors. It’s important to do your homework, keep an open mind, and adapt your migration plan around your business and technical objectives.

For example, if you need to move off hardware or get onto a supported hypervisor platform - you may choose an agent swap migration approach vs. building a new image and delivering applications using App Volumes due to time and formalized supportability.

• Compromise is necessary – As with any migration, there are several factors that drive the migration approach and timeline. In the case of migrations – perfection will significantly hinder progress. Sometimes, trade-offs need to be made to meet the business and technical objectives. Be aware of everyone’s concerns and needs – and be willing to compromise. Consider whether you can revisit the challenge after the major milestones and tasks are completed (a.k.a. “Improve It” phase).
• Technical Debt Management – A migration is a great time to remove any technical debt (a.k.a. bad technical decisions) that may be in the legacy platform. It’s preferred you don’t bring this debt into the target platform. However, you may have to carry over or add some technical debt to achieve the goals and objectives of the migration. Track the technical debt you need to remove and defer to later phases of the migration (a.k.a. “Improve It” phase).
• Just because you can doesn’t mean you should – Many customers also take the opportunity to introduce new features and functionality during the migration. One example is the move towards using App Volumes to deliver applications dynamically to virtual desktops and RDS servers. Another example would be to upgrade the virtual desktops to Windows 11.

While this may make sense and tick a few more items off the “To Do” list, it will slow down the overall migration timeline, increase complexity and increase the level of effort for the migration. Balance your migration capabilities and capacity with the desired business and technical outcomes. It’s OK to put these types of items off until the “Improve It” phase. It’s better to do a few things well than many things haphazardly.

Mapping Citrix & Horizon Components

When mapping Citrix to Horizon, it’s important to remember to focus on the outcomes and work backwards to decide what capabilities you need.  Comparing the two products feature by feature can incorrectly lead to issues because Citrix and Horizon have different approaches when it comes to grouping functionality into features.  For example, if an administrator wants to create a group of virtual resources, these capabilities have quite different mappings between the two products.

The following table lists the most common function mappings to specific features in each product.

*Note: NetScaler provides a diverse set of functionalities but can vary widely between deployments in terms of what it is configured to do.

Another important aspect when mapping is how to conceptualize the relationships between the overall solution.  To help with that, it’s easy to visualize the Omnissa solution in several layers. By taking this approach, these definitions can help clearly map business and technical goals to the corresponding functions within the plan by categorizing them into broader categories.

Planning the Move

One of the most important parts of a migration is planning and discovery. Understanding the current Citrix or RDS environment, the user communities and customer who consume the platform, how end users access the environment, what will they experience when the switch is flipped, etc. are all important considerations that need to be reviewed, planned and communicated. Let’s touch on some of the major elements that will make your migration successful.

Analyzing the Estate

If you don’t know what you have, you don’t know what you need to move. Getting a quick but comprehensive view of what you have today in Citrix makes mapping requirements and services to Horizon more straightforward and will streamline migration effort.

Outcome Mapping and Validation

With any migration, there’s a necessity to ensure you can map current outcomes with Citrix or RDS to Horizon. Additionally, there are other fundamental differences that need to be accounted for – such as network ports and protocols, client installation and configuration, etc.

Making the Lists, Checking it Twice

It’s also important to start making some important “lists” to help track a few key variables important to migration.

• The Technical Debt List– start tracking the changes you need to make to facilitate the migration, as well as clean up any legacy decisions that were made prior to the migration. As previously mentioned, there may be some items you will have to come back to keep the migration moving forward. Keeping track of these items will allow you to incorporate them into the “Improve It” phase of the migration.
• The High-Level Gap Analysis List – Capture any niche or unique requirements and vet out what you can and cannot do, in addition to the criticality of the gap. Unless it breaks the business or blocks progress, it should not be considered a blocker to the migration effort.
• The Wish List – it’s also important to list out other low-hanging fruit objectives or items that have been out there for some time, such as updating operating systems, moving to a managed user profile solution, or dynamic application delivery using App Volumes. Taking the opportunity to improve or resolve those during the migration may help you achieve some forward-looking goals that could have been stalled or stuck in the work pipeline.

Choose your Migration Method

There are a few ways to move from an RDS or Citrix XenApp/XenDesktop platform to Horizon. Choosing the migration option will be dependent on risk and technical debt tolerance, as well as other goals that will drive the speed and needs of the organization. Migration methods will generally be the same whether you use on-premises or cloud infrastructure.

The following table outlines the most common migration methods, and the benefits and considerations of each option. 

Testing your Plan

Testing Basics

Once the plan has been formulated and finalized, it’s time to test your migration plan and refine your schedule/timeline. Select some friendly user communities and service consumers from your assessment. You should also choose user communities that represent a good cross-section of who will be migrated. Finally, choose user communities that will be “quick wins” – low-risk, high benefit/impacts. Complex use cases should be avoided as they may require extensive amounts of time and resources to support.

Training and Enablement

During testing, take the time to build your migration run books, finalize plans, and identify early issues that typically surface during a migration. Documentation will allow others to be trained and used for the overall migration effort. Many hands make light work. Put timelines around testing and validation efforts to keep forward momentum on the migration project and avoid analysis paralysis.

Refine your Plan and Schedule

Finally, use the testing phase to build your project timeline and schedule. Begin to develop communications for your users about migration expectations, timelines, and how to get support if problems arise. This will set things up for the next phase – the migration.

Executing the Migration

Migration Reality

Once your testing is done – it’s time to make things happen. This is the “Move IT” phase of the migration. Make sure you work on your plan – including Horizon Client deployments, Agent Swaps, etc. Ensure your help desk or support group is ready to aid users in the event they encounter issues. There may be a need to adjust the plan and/or timeline based on real-world migrations. Migration speeds will be driven based on the organization’s business and technical needs, risks, and/or constraints.

In some cases, you may want to roll in some of the items captured for the “Improve It” phase. Since there is some work being done, certain tasks and enhancements can be staged or implemented based on the level of effort, if it makes sense, brings technical and business value, etc. This topic will be covered later in the document.

Managing the Issues

Be prepared for issues – no migration is perfect, and even with extensive planning and analysis, problems will arise. Assess the problem accordingly by asking some simple questions:

• Does the issue block migration efforts?
• Does it have a business impact?
• Is this an end user education issue? Were things done differently in Citrix than Horizon?
• Is it user impacting or administrative/back-end impacting?
• Is there a workaround?
• Is it an annoyance?
• Can this wait to be addressed at a later phase of the project?

Based on the answers to these questions, many issues are minor annoyances, end user education issues or problems with workarounds. Blockers should be considered just that – a technical blocker that renders the system unusable for users.

Help desk/support teams should be in place to handle any issues. Having any “quick fix” or common problem guidance will reduce the support and escalation burden. Track your issues and remediation measures accordingly, as they are your proof of progress and success. It will also help you trend problematic behaviors and issues that may have not been found during testing.

Iterative Improvements

Enhancing the Experience

Now that the migration is underway and/or nearing completion, it’s time to start thinking about improving the Horizon experience from an operational and end user experience perspective. There are a few key areas that customers need to consider:

• End User Experience – One of the MOST important and overlooked areas of virtual desktop and application is ensuring optimal end user experience. This not only includes usability, but the entire FLOW – from login to launch. Just as important is usability and performance, as well as access to all necessary applications. This should be one of the first (if not the first) items that is evaluated after migration activities are well underway or slowing down.
• Technical Debt – Review the technical debt list and prioritize what needs to get fixed, how soon it needs to be fixed, and the level of effort to work through this backlog list. This list will need to be balanced with other improvements, depending on resource capacity. It’s important to remember that not all debt can or should be fixed due to dependencies outside of your control (i.e., application dependencies).
• Backlog & Wish List – Review the backlog list of things that have been low hanging fruit or things that you wanted to do with the platform but did not have time. These may include cleaning up old/stale items, decommissioning VMs or services you never got around to doing, etc. These should be balanced and prioritized based on other lists, like technical debt and modernization.
• Modernization Considerations – Consider other improvements and modernization considerations as part of the migration process. Implementing technologies like Omnissa Dynamic Environment Manager (DEM) and FSLogix offer the ability to move from persistent to non-persistent/instant clones (in most cases), or upgrading the images and desktops to Windows 11 can help modernize the end user experience and bring some operational efficiency and benefit to the Horizon service.

Prioritizing and Implementing Improvements

Implementing improvements for Horizon requires some planning and prioritization. For example, some changes may be better suited (i.e., DEM and FSLogix) when preparing and deploying instant clone pools in Horizon if those services don’t require any migration from legacy profile management. Other enhancements, such as Windows 11 upgrades, may be better suited once users are migrated and accustomed to the Horizon user experience.  Balancing technical debt into the improvement plan may also take precedent and fall under either example of implementing during or after a Horizon migration.

Here are some things to think about that will help with properly planning and prioritizing your “Improve It” list:

• Risks vs. Benefits – Is this a “quick” win that will bring benefit to the organization and the user community? Does the risk of implementing this change outweigh the reward? What are the measurable benefits to the business?
• Necessity – Is the improvement something from the technical debt list that was a compromise or workaround to keep the migration moving forward? What is the business impact if the change is not implemented?
• Affected Population – How many users are at risk, or benefit from this change?
• Complexity – How complex is the issue? How many users will be impacted by the enhancement?  Is it a simple change or complex change?
• Testing and Validation – Does this change require extensive testing? Is end user testing needed?
• Time to implement –How long will it take to implement the change?
• Dependencies – Does the improvement require engagement of other IT or business partners? Are there technical components (i.e., file shares) that need to be managed, setup or configured?
• Executive – Are there any improvements being driven by the company executives?

Building your “improve it” plan is essential and should be evaluated and changed during the project. Remember – make as many forward gains as possible, while minimizing risk and maximizing success. Don’t let an improvement become a blocker for your migration!

Running the Engine

Finally, one overlooked area with any virtual application and desktop platform is the proper operation and caring and feeding of the platform. The “Run It” phase should be developed and matured during the entire migration process, and will ensure you have the right people, process and technology to deliver the best end user experience. Customers will also reap the benefits of operational efficiency with the right processes and proactive mindset in place.

Virtual desktop and application delivery platforms have traditionally been designed around specific "use cases." This means that the environment is tailored to meet the needs of a particular business unit or user community. While this approach works well for large use cases, such as call center agents, it can create challenges when dealing with use cases with varying resource requirements. This leads to a situation where the platform becomes "customized" for each use case, making it difficult to scale and operate, especially when considering factors like unpredictable scale and variations in infrastructure configurations.

These customized environments pose technical and operational challenges for system integrators and service providers. An enterprise service platform (ESP) approach is recommended to address these challenges. This approach uses data obtained from desktop and application assessments to classify user segments into desktop "classes" with fixed settings and configurations. The result is a more straightforward solution with a predictable scale and standardized configurations that are consistent and supportable across all virtual desktop and application environments.

The following table outlines some sample desktop standards with varying Operating Systems and configurations that would commonly leverage the service offering.

To properly design, assess and on-board consumers onto the virtual desktop and application platform, it's important to follow a methodical approach to ensure accuracy and consistency which will deliver a solution that meets or exceeds the user’s expectations. Customers that avoid or forego design and assessment activities may encounter connectivity, functional or performance-related issues that could have been mitigated with proper discovery and planning. 

To predict scale, keep service level agreements and provide an optimized user experience, it is important to clearly understand the user segments, where they are connecting from, what endpoint devices they will use, and what are their expectations. Having a clear understanding of the customer requirements and their actual (vs. perceived) service needs will allow customers to properly onboard users into the right service offering. 

The following diagram provides a structured, consistent approach to adding new user segments, virtual desktops and applications and enhanced platform capabilities to the platform. 

In addition to understanding the user segment, it is also important to assess any existing physical/virtual desktop or remote application environment in use. Gathering essential metrics and baseline performance data will aid in sizing and designing the infrastructure in the data center accordingly. It also allows customers to place users in a specific desktop class of service or ensure the RDSH farms are proactively and appropriately sized – removing any guesswork or uncertainty.

Summary and Additional Resources

In this article we discussed the approach to migrating to Horizon from Citrix platforms.  By standardizing on a migration process that consists of simple steps the project can quickly deliver a quality end user experience that can be iteratively improved upon.  Additionally, by mapping the Horizon platform into layers, focused on functions rather than features, you can ensure that the environment has the correct set of tools to allow quick return on investment.

Additional Resources

What is Horizon?

Changelog

About the Author and Contributors

Authors

Justin Venezia, Adoption Product Manager

Mike Erb, Staff Architect

Contributors and Reviewers

Graeme Gordon, Senior Staff Architect

Questions and Feedback

Your feedback is valuable. To comment on this paper, either use the feedback button or contact us at tech_content_feedback@omnissa.com.