Kasm Workspaces → Citrix Virtual Apps & Desktops

Kasm Workspaces ↔ Citrix Virtual Apps & Desktops: integration to migration path.

Kasm and Citrix are architecturally mismatched — Linux containers in a browser versus AD-joined Windows over HDX — so we never flip a switch. Kasm stands up alongside your Citrix farm first, browser and Linux workloads move onto it one cohort at a time against a parallel fallback, and every step rolls back in minutes with no forced re-credentialing.

This is a partial path by design. Citrix keeps every Windows-bound workload — full desktops, smart-card logon, Teams optimisation — and we tell you which cohorts can move and which cannot before Phase 1, because the rest only matters if you can trust it.

The idea

Add a second front door. Move only what is browser- or Linux-shaped.

The topology that makes this zero-downtime: Kasm federates over SAML 2.0 to the very same identity provider that already fronts Citrix Gateway and StoreFront, so it becomes a second entitlement plane without touching a single Citrix Delivery Group. Users see a "Browser/Linux (Kasm)" tile and a "Windows (Citrix)" tile in one IdP dashboard. Citrix keeps validating and brokering Windows; Kasm absorbs the RBI, Linux published apps, and verified browser-only cohorts it was purpose-built for — each cohort moved independently, each reversible, never a big-bang cutover.

The phases

Seven steps. Each one reversible.

0

Baseline & inventory

We read your Citrix estate without touching it: every Delivery Group classified, 90 days of Director session-launch counts per user, profile backends (UPM share plus FSLogix VHD sizes), smart-card and PIV usage, GPU sessions, Teams/Zoom Optimization Pack reliance, and the CCU licence baseline.

Users see: No user impact.

Rollback: N/A.

1

Kasm goes live next to Citrix

Kasm stands up in HA — Web App plus at least two agents, an image registry mirror, and SAML federation against the same IdP that already fronts Citrix Gateway. A canary group of IT plus five pilot users proves the path. No production user is entitled yet.

Users see: None for production; the pilot sees a Kasm portal alongside StoreFront.

Rollback: Tear down Kasm — no production session ever touched it.

2

Pilot the browser-isolation use case

One genuine production use case — clinician browse-out, contractor SaaS access, or KYC public-web review — runs on Kasm exclusively for that population. Container egress routes through your SWG/CASB so PCI and HIPAA controls hold. Everyone else stays on Citrix.

Users see: The pilot opens the Kasm tile instead of the old Citrix-published browser; bookmark loss is communicated.

Rollback: Remove the group; the Citrix-published-browser entitlement is still live. Under 15 minutes.

3

Expand RBI and Linux apps to the full eligible population

Every RBI and Linux-published-app cohort moves to Kasm in waves. We build a hardened image, entitle the cohort by IdP group, and keep the Citrix Delivery Group access live for 14 days as a parallel fallback before revoking it.

Users see: Per cohort: the RBI or Linux tile in the IdP dashboard now points at Kasm; the Citrix tile is removed after a 14-day bake.

Rollback: Re-add the cohort to the Citrix AD group. Under 15 minutes within the bake; up to 30 minutes after revocation while AD replicates.

4

Migrate the verified browser-only cohort

Using the 90-day Director data, we identify users with zero Windows-app launches, send each a 14-day notice listing every app they actually launched, then move qualifying users to a browser-only Kasm entitlement and revoke their Citrix desktop. There is nothing to migrate — browser state lives in SSO-backed sync.

Users see: Migrated users lose their Citrix desktop tile; Kasm becomes their full stack.

Rollback: Re-add to the Citrix Delivery Group AD group. Under 30 minutes including AD replication.

5

CCU true-down and image-pipeline maturation

Citrix CCU or User/Device licensing is reduced at the next quarterly cycle to match the remaining Windows-heavy population, and the Kasm image pipeline — upstream CVE trigger to scan to registry push to deployment bump — runs unattended. A joint cross-stack triage runbook is signed off.

Users see: None.

Rollback: Image pipeline reverts to the previous config and last good image; a licence true-down, once reduced, needs a new Citrix order to scale back up.

6

Final state — partial by design

This is a partial programme, so retirement is a deliberate decision, not an automatic event. For most enterprises with real Windows investment, steady-state coexistence is the answer: Citrix keeps Windows, Kasm keeps browser and Linux, and the programme closes with a joint runbook and joint licensing cadence. Leaving Windows app delivery behind is a separate programme, out of scope here.

Users see: None from this programme.

Rollback: N/A — coexistence is the documented end state.

Feature parity

Where Kasm matches Citrix — and where it honestly does not.

Capability Kasm Workspaces Citrix Virtual Apps & Desktops Parity
Display/remoting protocol KasmVNC over WSS (plus CasterStream/WebRTC) HDX/ICA with EDT adaptive UDP transport Partial
Browser isolation (RBI) Native kasmweb/chrome, ephemeral container, container-level network isolation Published Chrome from Server VDA — a process boundary, not isolation-grade OSS only
Linux app delivery First-class Linux desktop and app images (kasmweb/ubuntu-focal-desktop) Citrix Linux VDA on a secondary protocol path At parity
Windows desktop delivery Not credible — no Wine at enterprise scope Desktop VDA single-session / Server VDA multi-session, AD-joined SaaS only
Profile management Kasm persistent volume, per image and user Citrix Profile Management (UPM) plus FSLogix containers Partial
IdP federation (SAML/OIDC) SAML 2.0 SP and native OIDC; group claim maps to Kasm group SAML via Citrix Gateway/StoreFront (nFactor) At parity
GPU acceleration Docker --gpus whole-GPU or MIG slice; NVENC to KasmVNC HDX 3D Pro with an NVIDIA vGPU profile bound at VM boot Partial
Unified-comms optimisation (Teams/Zoom) WebRTC re-encoded through KasmVNC — no VDI-optimised badge Citrix HDX Optimization Pack (endpoint redirection) SaaS only
Smart-card / True SSO Per-site browser smart-card only (WebAuthn) — not enterprise-grade Citrix FAS (True SSO) certificate injection into Windows logon SaaS only
Session recording Per-workspace MP4/WebM to S3 (session_recordings) Citrix Session Recording of the ICA stream (.icl/.icll) At parity
Monitoring/analytics Kasm audit API (get_session_history) to SIEM Citrix Director plus Analytics for Security (UEBA/risk) Partial
App layering Image-as-code (Dockerfile plus CI rebuild) Citrix App Layering filter-driver plus Image Portability SaaS only
Deployment model Self-hosted Docker (Web App plus Agents), OSS Community Edition On-prem CVAD or Citrix DaaS (*.cloud.com) At parity
Cost model Concurrent-session licence plus hosting; Community Edition free CCU or User/Device plus CVAD/DaaS subscription plus Windows licensing Partial
Compliance (HIPAA/PCI/FedRAMP/SOC 2) On-prem under customer ATO; SaaS FedRAMP status to be verified on the Marketplace Known FedRAMP/CJIS reference architectures Partial

What we're honest about

The caveats most vendors leave out.

HDX EDT adaptive transport has no Kasm parity

KasmVNC ships pixels over TCP/WSS with no proprietary congestion control. On lossy, high-RTT, bonded-MPLS or satellite links, Citrix HDX over EDT measurably wins after twenty years of WAN tuning. We measure per-population RTT and loss before assigning, and keep remote and branch users on Citrix.

Teams and Zoom optimisation stays on Citrix

Citrix HDX Optimization Pack redirects unified-comms media to the endpoint. In Kasm, Teams and Zoom are re-encoded through KasmVNC with no VDI-optimised badge — quality and host CPU are both worse. Heavy callers stay on Citrix or move to local apps; we never present Kasm as a Teams-VDI replacement.

Smart-card True SSO and Windows logon cannot move

Citrix FAS injects a short-lived certificate into Windows logon from the SAML assertion — the bridge from SAML to Kerberos. Kasm containers are Linux and not AD-joined, so browser smart-card APIs (WebAuthn, per-site) are not a substitute. Smart-card and PIV-mandated populations stay on Citrix.

FSLogix profiles are non-portable; self-hosting means you own uptime

FSLogix VHDs are not Linux-readable, so migrated users start fresh on a Kasm volume and cross-stack files move through a third location like OneDrive or NFS — never a co-mounted share, which corrupts data. And once a cohort is on Kasm, Kasm being down means their logins are down: that is why we run it HA across nodes with a tested DR runbook and an RTO target.

Why this beats a flag day

Reversible per cohort, then soaked before anything is cancelled.

Every cohort move rolls back in under 15 minutes while the parallel Citrix entitlement is still live, so no single wave can take down delivery. And we never true down a Citrix licence on faith: in-scope cohorts run on Kasm and off their equivalent Citrix Delivery Groups for at least 30 consecutive days, with session establishment above 99.5% and helpdesk tickets within 10% of the prior baseline, before any CCU reduction is proposed at the next quarterly renewal.

See which cohorts move cleanly off Citrix.

A call with a senior EUC engineer. We classify your Delivery Groups, join 90 days of Director data to per-app launch counts, and tell you honestly which browser and Linux cohorts can move to Kasm — and which Windows, smart-card, and Teams-optimised populations stay on Citrix — before you commit to anything.

Map my migration →