Citrix is capable and entrenched, which is why the per-user bill is so hard to swallow when Cloud Software Group raises it. The instinct is to look for a single product that replaces Citrix DaaS or Virtual Apps and Desktops outright. That product does not exist in open source, and chasing it leads to disappointment. What does exist is a set of open tools that each cover part of what Citrix does, and the smart move is to match them to your actual use cases rather than to Citrix’s feature list.
Start with what your users really do
Citrix estates usually serve a mix: some users just need secure access to a handful of published Windows apps or a shared session host, while others depend on persistent, customized desktops with layered applications and profile management. Those two groups have very different replacement paths. Sort your users this way before you evaluate anything, because it determines whether the migration is straightforward or genuinely involved.
Two open directions, for two kinds of users
Apache Guacamole is a clientless HTML5 gateway to RDP, VNC, and SSH. It gives users browser access to desktops and session hosts you already run, with single sign-on and MFA enforced at the gateway. It is not a desktop broker: it will not provision pools, manage images, or layer apps. For the large share of users whose real need is “reach my existing Windows session host securely from anywhere,” it is a clean, low-cost replacement for the Citrix access layer.
Kasm Workspaces takes a different tack, streaming containerized apps and desktops to the browser. Because it provisions ephemeral workspaces from images, it maps well onto published-app delivery and non-persistent desktops, and it adds browser isolation as a bonus. It is container streaming rather than a traditional persistent-VDI broker, so it fits some Citrix workloads squarely and others not at all.
Be realistic about the gap
For image lifecycle, instant provisioning of large persistent-desktop pools, or GPU-accelerated CAD workstations, the open tools cover part of the ground and you will keep some of that machinery on your hypervisor or accept a change in model. The honest framing is that a Citrix exit is usually a phased, use-case-by-use-case migration, not a single swap, and the savings are realized as each group moves. Pilot one low-risk group end to end, wire SSO and MFA, validate printing, USB, and multi-monitor behavior, then widen.
The dependencies that decide a Citrix exit
VDI migrations are unusual in that the blockers are rarely the desktops. They are the peripherals and the habits attached to them, and they surface in user acceptance testing rather than in design.
Printing is the classic one. Citrix’s universal print driver quietly solves a genuinely hard problem, and estates that have relied on it for a decade often have no idea how many printer models are in play. Inventory printing early, per user group, and test it in the pilot rather than assuming it will behave.
Peripherals follow the same pattern. Signature pads, card readers, scanners, barcode guns, headsets tied to a telephony client, and dongles for engineering software all depend on how the remoting protocol handles USB redirection. Each protocol handles it differently and none handle it identically to Citrix, so this needs testing with the actual device rather than a specification comparison.
Profiles and personalisation. If you run profile management with folder redirection and application layering, that machinery is doing more work than anyone remembers. Users notice the loss of personalisation immediately and express it as the migration having broken things, even when everything technically functions.
Protocol behaviour on poor connections. Citrix’s protocol is very good over high-latency, lossy links, which is precisely the condition remote and branch users experience. An alternative that performs identically in an office test can perform noticeably worse from a home connection, and that comparison should be part of the pilot, not a discovery afterwards.
Licensing that follows the desktop. Windows licensing for virtual desktops has its own rules independent of the broker. Changing broker does not change those obligations, and it is worth confirming your position rather than assuming the saving is larger than it is.
The partial migration is the win
The most common mistake here is treating anything short of a complete Citrix removal as a failure. For most estates the complete removal is not achievable at acceptable risk, and pursuing it wastes the saving that was available.
Citrix licensing is generally per user, which means every user group you move reduces the bill proportionally. That property makes partial migration genuinely valuable in a way it is not for, say, a hypervisor, where you keep paying for the platform until the last workload leaves. Moving the sixty per cent of users who only need browser access to a handful of published applications captures most of the available saving while leaving the demanding minority undisturbed.
So sequence by ease rather than by ambition. Task workers and contractors on published applications first, since they are the largest group and the simplest to satisfy. Knowledge workers with standard desktops second. Power users with persistent, personalised, GPU-accelerated desktops last, or never, and be relaxed about never.
Ending with a small, well-understood Citrix estate serving the users who genuinely need it, at a fraction of the previous licence count, is a successful outcome. It is also a considerably better negotiating position at the next renewal than either a full migration attempt that stalled or no alternative at all. Each path below opens to a full cost model, a plan, and an in-depth guide.