What are the best practices for migrating from VDI to DaaS or RDS, or vice versa?

test perspective test perspective test perspective test perspective test perspective test perspective test perspective test perspective test perspective test perspective

VDI refers to a technology where virtualized desktops run on a centralized server, but are delivered over a network to end-users. Companies have direct control over the hardware, software, and user experience. It's especially useful when dealing with sensitive data, as everything stays in the data center.

VDI or DaaS - it's (mostly) all about the network. This still is one of the biggest culprits in VDI or DaaS performance. The performance of network connectivity, not only between the end user and the backend, but between backend components themselves (apps and their databases, IAM infrastructure- stuff that can increase login times, server-to-server communications, etc.) is crucial to a good experience on either DaaS or VDI.

RDS solutions should not be discounted as they usually give you the best bang for the buck in terms of user density and efficiency. Unfortunately, many modern applications run best with a client OS versus a server OS which can complicate your deployment. That being said, there are many tools available that allow users to personalize their experience, while also allowing IT teams to maintain stability and security.

In my experience, when migrating between virtualisation platforms, it is key to run a proof of concept (POC). Not all virtualisation platforms act in the same way when users open applications and what works on one platform might not necessarily work in the same way on the other. In order to have a smooth migration you need to test, test and test again in you POC environment with at least one person from every department, this way you will have less headaches when the system goes live.

In my experience, migration planning TO a DaaS or RDS solution should start with the "why?", and be looked at from a value engineering viewpoint. Pricing models/terms are different than traditional on-prem VDI - the shift to an OpEx model and the financials that go with it should be carefully considered early in the process to avoid costly surprises when the consumption bills come in. Additionally, the DaaS end user experience is highly dependent on what users are doing, where the apps and data they're using are hosted, and the networks that connect it all. Migrating to DaaS should be a prescriptive, case-based approach. It doesn't have to be (and in most cases probably doesn't need to be) a replacement from on premise hosted VDI.

I'll agree with Matthew here... One of the most important things to do is to work with each group that will be using the new solution -under the conditions that they'll be using-! Each group will have different requirements and wants, and as many of those as possible need to be dealt with. Gone are the days of dialing up, downloading all your email for the day, then disconnecting to work offline. With always-on broadband available in many areas, it is important to ensure that the user experience works under all conditions. Where I live, until a few years ago, my 'broadband' was 3700kbps (yes, kbps, so 3.7Mbps or so) down and 384kbps up... I could get video down, but couldn't send video and voice out. Make sure it works everywhere!

Migrating a financial client from on-prem VDI to AWS Workspaces was a big win! The key? Rigorous testing of the DaaS environment for security & performance prioritized data security & user adoption. We implemented a phased rollout by department, starting with IT, for a controlled transition. And a burndown chart to track progress, ensuring a smooth transition compliant with regulations.

A common miss in these types of projects is where the back-end data the apps are accessing lives. For example, most Database driven apps will typically not tolerate latency over 1-2ms. Throw as much bandwidth at it as you want, you can't get around physics. Latency matters on those situations. Conversely, some apps can tolerate latency but require large amounts of data transfer. CAD and GIS, some accounting programs can be examples. Speaking of... Virtualized Graphics can be make or break. All that said... the last few migrations and projects I can think of, it really came down to one thing: Protocol. RDSH still can't touch Citrix ICA (HDX) in user perception. HTML5 only works for limited scenarios. _ UNDERSTAND, PLAN, CHANGE, MAINTAIN