Kasm Workspaces → VMware Horizon
Kasm Workspaces ↔ VMware Horizon: integration to migration path.
Horizon's centre of gravity is Windows; Kasm's is Linux containers in a browser. The two stacks are not interchangeable, so we never flip a switch. Kasm stands up alongside Horizon first, RBI and Linux-shaped personas move onto it one at a time against a live fallback, and every step rolls back in minutes with no re-imaging event.
This is a partial path by design. Horizon stays the VDI of record for Windows desktops, smart-card app farms, and Teams-optimised personas, and we tell you which personas can move and which are permanently Horizon before Phase 1 — because the rest only matters if you can trust it.
The idea
One front door, two stacks. 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 your UAG, so it becomes a second entitlement plane without touching a single Horizon pool. Users route from one IdP launchpad — a Windows tile into Horizon, a browser-or-Linux tile into Kasm. Horizon keeps brokering AD-joined Windows over Blast Extreme; Kasm absorbs the browser-isolation and genuinely Linux-or-browser-shaped personas it was built for, each persona moved independently against a 30-day fallback, never a big-bang cutover.
The phases
Six steps. Each one reversible.
Baseline & inventory
We read your Horizon estate read-only: every pool classified by OS family and persistence model, App Volumes AppStacks and DEM policies counted, USB, smart-card and RTAV dependencies tagged per persona, Teams/Zoom optimisation usage, GPU profiles, and peak concurrency with login-storm windows.
Kasm goes live next to Horizon
Kasm stands up in HA — at least three web/api/agent nodes, external Postgres, S3 for recordings — federated over SAML to the same IdP that UAG uses. A canary of 5 to 20 users launches one ephemeral and one persistent image. No production persona has moved.
Move RBI / browser personas to Kasm
The third-party-browser-access persona becomes Kasm-only on an ephemeral kasmweb/chrome image, with CASB egress in the image env and per-session recording on. Any Horizon-published browser for that persona is decommissioned. Every other persona is untouched.
Move Linux and Linux-eligible developer personas
Personas already on a Horizon Linux Agent, plus genuinely Linux-or-browser-shaped developers, move to a CI-baked Kasm image. We pre-seed each persistent profile from the prior home directory with a one-shot rsync run as a maintenance job — never at login — then drain the Horizon Linux pool over 14 days.
Carve out specific Windows-app personas (partial)
For published-app personas that need no smart card or USB — read-only ERP, internal LOB — the launch surface becomes a Kasm image bookmarked to the Horizon HTML5 client. Horizon still hosts the app; Kasm hosts the wrapper. We ramp a 10% slice for 7 days, then to 100%, with the native client kept as a fallback link.
Steady state — persona-level decisions
Horizon hosts only what it must: Windows desktops, smart-card app farms, Teams/Zoom-optimised desktops, power-user workstations. Its licence cohort shrinks via a CCU or Named true-down at renewal, and Kasm holds everything Linux, browser, and HTML5-eligible. Both stacks coexist indefinitely.
Feature parity
Where Kasm matches Horizon — and where it honestly does not.
| Capability | Kasm Workspaces | VMware Horizon | Parity |
|---|---|---|---|
| Display/remoting protocol | KasmVNC over WSS (plus CasterStream/WebRTC) | Horizon Blast Extreme (adaptive UDP) / PCoIP | Partial |
| Browser isolation (RBI) | Native kasmweb/chrome per-tab isolation, ephemeral on logout | Published browser via Horizon Apps — not isolation-grade | OSS only |
| Linux app delivery | First-class Linux images (kasmweb/ubuntu-focal-desktop) | Horizon Linux Agent — second-class to Windows | At parity |
| Windows desktop delivery | Not credible — no Windows OS layer | Horizon Agent on a Windows VM plus Instant Clones | SaaS only |
| Profile management | Kasm persistent profile volume (SMB-mounted) | App Volumes (writable/AppStacks) plus DEM | Partial |
| IdP federation (SAML/OIDC) | SAML 2.0 SP and OIDC; group maps to image entitlement | SAML 2.0 SP on UAG; Workspace ONE Access | At parity |
| GPU acceleration | Docker --gpus whole-GPU or MIG slice; NVENC | NVIDIA vGPU profile bound at VM boot; Blast NVENC | Partial |
| Unified-comms optimisation (Teams/Zoom) | WebRTC re-encoded through KasmVNC — no offload | Horizon Media Engine plus Teams VDI / Zoom VDI plugins | SaaS only |
| Smart-card / True SSO | Per-origin browser APIs only — no AD-cert injection | True SSO plus UAG smart-card passthrough | SaaS only |
| Session recording | Native per-workspace MP4/WebM to S3 (session_recordings) | No native — third-party (Imprivata, Proofpoint) | OSS only |
| Monitoring/analytics | Kasm audit API (get_session_history, flat JSON) | Aria Operations for Horizon plus Connection Server event DB | Partial |
| Instant-clone / pool scaling | Per-container start (single-digit to 30s); no pool-warm vmFork | Horizon Instant Clones (vmFork) at thousand-user scale | SaaS only |
| Deployment model | Self-hosted Docker/K8s, multi-zone in one control plane | On-prem pod-per-vCenter or Horizon Cloud / Next-gen | At parity |
| Cost model | Self-hosted compute plus concurrent-session licence | Per-CCU/Named plus vSphere plus UAG plus Windows multi-session entitlement | Partial |
| Compliance (HIPAA/PCI/FedRAMP/SOC 2) | Self-hosted under customer SSP; FedRAMP status to be verified | Horizon Cloud Government; current FedRAMP status to be verified | Partial |
What we're honest about
The caveats most vendors leave out.
Blast Extreme on hostile WANs has no Kasm parity
KasmVNC over WSS rides TCP with no proprietary congestion control. On 3 to 8 percent loss, asymmetric RTT, bonded LTE or MPLS, Blast Extreme and PCoIP outperform it meaningfully after two decades of tuning. We pilot a representative WAN slice before any move, and hostile-WAN personas stay on Horizon.
Teams and Zoom optimisation stays on Horizon
Horizon's Media Engine and the Teams/Zoom VDI plugins terminate media on the endpoint. Kasm has no equivalent — WebRTC through KasmVNC is re-encoded, fine for screen share but materially worse for multi-party video at scale. Teams and Zoom-heavy personas stay on Horizon; we never sell Kasm as a media replacement.
True SSO, smart card, USB and App Volumes do not move
UAG smart-card passthrough and True SSO inject an AD certificate into a Windows logon — Kasm containers are Linux and not AD-joined, and browser smart-card APIs are per-origin and don't bridge in. USB redirection, RTAV, and App Volumes/DEM filter-driver layering have no Kasm analogue. These personas stay on Horizon by design.
FSLogix is non-portable; self-hosting means you own uptime
FSLogix VHDs aren't Linux-readable, so migrated users start fresh on a Kasm volume and cross-stack state moves through disjoint SMB subtrees or a third location — never a co-mounted path, which corrupts data. And if the Kasm cluster is down, those personas have no fallback unless we built one: HA across at least three nodes, Postgres backup, a documented DR runbook with an RTO target, and break-glass Horizon reactivation.
Why this beats a flag day
Reversible per persona, then soaked before anything is cancelled.
Every persona move is reversible in under 15 minutes through an IdP toggle while the Horizon entitlement is still live, so no single wave can take down delivery. And we never true down a Horizon licence on faith: Linux-or-browser-eligible personas run on Kasm — with zero Horizon sessions for at least 14 days — and stay there for a 30-day soak with no unexplained cross-stack escalations before any CCU or Named reduction goes to finance for sign-off.
See which personas move cleanly off Horizon.
A call with a senior EUC engineer. We classify your pools, capture two weeks of per-persona telemetry to separate genuine Linux work from hidden Windows dependencies, and tell you honestly which browser and Linux personas can move to Kasm — and which smart-card, USB-bound, and Teams-optimised personas stay on Horizon — before you commit to anything.
Map my migration →