Most teams evaluate a VDI replacement by lining up feature matrices next to their Citrix or Horizon deployment and checking boxes: instant clones, image layering, GPU passthrough, profile management, protocol options. That comparison almost always ends badly, because the open alternatives are not smaller versions of a commercial VDI suite, they are different tools that solve different slices of the problem. Score them on a broker’s feature list and they look inadequate; that tells you nothing about whether they fit what you actually run. The better method is to decide the few factors that genuinely change the answer, measure your real user groups against them, and only then look at products. This guide gives you that rubric.
Start with the decision, not the broker
Before you shortlist anything, answer one question honestly: are you replacing a full VDI broker, or just replacing secure remote access to hosts you already run? A great many estates carry Citrix or Horizon licensing but really only use it so people can reach existing Windows session hosts or desktops from anywhere. If that is you, the migration is modest. If instead you depend on the desktop-lifecycle machinery (provisioning pools, non-persistent images, app layering, elastic scale), the migration is a phased, use-case-by-use-case effort, not a single swap. Which of those two situations you are in decides everything that follows, so establish it before comparing anything.
The factors that matter here
- What you are truly replacing. A full broker versus secure remote access to existing hosts. Be precise, because it is the difference between a weekend gateway deployment and a multi-quarter program.
- Persistent versus non-persistent desktops. Users tied to a personal, stateful desktop are served very differently from users who can be handed a clean, ephemeral session each morning. The two models point at different tools.
- Image and profile management. Ask where desktop images and user profiles live today and where they will live after. The open access tools do not own that lifecycle; if you rely on it heavily, plan for your hypervisor or a separate tool to keep it.
- GPU and graphics workloads. CAD, 3D, GIS, and video users need accelerated graphics that a browser-based access gateway does not provide on its own. If you have them, they are the group most likely to stay on the incumbent longest.
- How your user groups actually differ. Segment by what people do, not by the license tier they hold. Task workers, power users, contractors, and graphics users each justify a different answer, and treating them as one population is how projects stall.
- Protocol and peripheral needs. Printing, USB redirection, smart cards, and multi-monitor behavior vary by tool. Confirm the ones your users genuinely depend on rather than the full list the datasheet advertises.
Which tool suits which user group
Score your user groups against the criteria, then use these as starting points. When the real requirement is “let people reach their existing Windows desktops and session hosts from a browser, securely,” Apache Guacamole is an excellent, low-cost fit: it is a clientless HTML5 gateway to RDP, VNC, and SSH with single sign-on and MFA at the gateway. It does not manage images or provision pools, so pair it with your hypervisor for lifecycle. When you need published-app or non-persistent delivery, Kasm Workspaces streams containerized apps and desktops to the browser and suits app-streaming and browser-isolation use cases well, though it is container streaming rather than a traditional persistent-VDI broker. Citrix DaaS and Omnissa Horizon remain the sources you are leaving. The honest framing: neither open target is a feature-complete VDI broker, so the right answer is usually a mix, one tool for one group, the incumbent retained for the users who genuinely need what only it provides.
Where these migrations go wrong
The most common error is scoping this as a like-for-like replacement of the whole broker, then judging the open tools as failures for not being one. The second is ignoring image and profile lifecycle until mid-project, when it turns out no open access gateway was ever going to own it. The third is moving the GPU and graphics users first because they are the loudest, when they are exactly the group that should move last or not at all. A quieter fourth: forgetting to get a real renewal quote from the incumbent, so you are comparing against a guess instead of the number you are trying to beat.
Prove it group by group
Turn your top candidate into a pilot with written acceptance criteria, run against your lowest-risk user group end to end. Wire single sign-on and MFA, then exercise the peripherals that matter (printing, USB, smart cards, multi-monitor) and let real users work long enough to surface the operational reality rather than the demo. Model the per-user savings with the tool at /calculator/ and treat the figures as illustrative until you price your own infrastructure and support. Then widen one group at a time, keeping the incumbent running for the users whose workloads only it can serve, and retire the commercial licenses only as each group clears its criteria.