When Cloud Software Group’s repricing prompts a Citrix DaaS review, the teams with the most to gain are often the ones delivering published applications and non-persistent desktops rather than heavily personalized, stateful VDI. For that pattern, Kasm Workspaces is a more natural landing spot than a plain remote-access gateway, because it does something a gateway cannot: it provisions and streams the workspace itself. Understanding where that similarity ends is the whole job of scoping this migration well.
The Kasm delivery model in one paragraph
Kasm Workspaces streams containerized apps and desktops to the browser. Instead of installing a client or brokering access to a long-lived session host, Kasm spins up an ephemeral container from an image, runs the app or desktop inside it, and streams the result to the user’s browser. When the session ends, the container is disposed. This is why Kasm sits closer to app and desktop delivery than Guacamole-style gateways: it actually creates the workspace rather than fronting something that already exists.
It is still, however, container streaming and not traditional persistent-VDI brokering. There is no golden-image-to-persistent-pool lifecycle in the classic Citrix sense, and personalization survives only through storage you design in. Say this plainly to stakeholders early, because the mental model of “a desktop I keep and customize” is exactly what Kasm intentionally does not provide by default.
Where Citrix concepts land in Kasm
Lining the two up avoids painful surprises mid-project:
- Citrix published apps become Kasm workspaces built from per-application images. This is the closest and most satisfying mapping.
- Non-persistent, pooled desktops map cleanly to Kasm’s ephemeral containerized desktops. If this was most of your estate, Kasm is a strong fit.
- Persistent, personalized desktops map awkwardly. Kasm can serve them only with a deliberate persistence design, and some users may belong on a different platform entirely.
- StoreFront and Workspace app become the Kasm browser experience: clientless access, no installed endpoint agent.
- Secure browser and web isolation use cases map extremely well, because a disposable container per session is exactly the isolation model here.
Deploying the platform
The build is more involved than a bare gateway because you are standing up an orchestration and streaming platform, not just a protocol broker. Deploy the Kasm server and its agents, which run the containerized workspaces, and then turn to the part that carries the real weight: images.
You will either build or adopt workspace images. For each Citrix published app or desktop you intend to replace, you produce a Kasm image containing that application and its dependencies, then expose it as a workspace. This is genuine engineering work, closer to building golden images than to configuring connections, and it is where most of the migration effort actually lives. Adopt community or prebuilt images where they fit, and build custom ones where your apps are bespoke.
Turning published apps into workspaces
Work through the published-app catalog methodically. For each app family, decide whether it belongs in its own single-app workspace or inside a fuller containerized desktop, build or adopt the image, and validate the streamed experience end to end: launch time, interaction quality, printing and clipboard, file access, and any peripheral needs. Because Kasm provisions from an image, you get consistency for free, but you also inherit the responsibility to keep those images patched and current, the same discipline MCS golden images demanded, just expressed in container terms.
Integrate SSO against your identity provider so authentication and MFA are enforced before a workspace is provisioned, and confirm that group and role mappings gate who can launch which workspace.
Handling state and persistence
This is the design decision teams most often defer and most often regret. Kasm containers are disposable, so any durable user data must live outside them: mounted persistent volumes, external home directories, or a profile strategy you supply. For users whose Citrix desktops were genuinely personalized, decide per group whether mounted persistence recreates enough of that experience or whether those users should stay on stateful VDI. Do not migrate a personalization-heavy cohort into an ephemeral model and hope the storage story catches up afterward.
Rolling out group by group
Sequence the rollout by workspace readiness, not by calendar. Start with a cohort whose apps map onto a small set of well-tested images, integrate SSO, validate the full streamed experience, and measure it honestly against their Citrix baseline. Then expand image by image and group by group. The users who expose the limits of container streaming, persistent personalization, exotic peripherals, sustained high-motion graphics, are precisely the ones to scope last or to leave on a different platform. Let validated images and real user feedback pace the migration.
Reading the fit
Citrix DaaS to Kasm Workspaces is a genuinely good match when your delivery is published apps and non-persistent desktops, when secure browser isolation is a goal, and when you are willing to invest in image building as the core of the project. It removes the Citrix per-user subscription and gives you a clientless, container-streamed experience that is closer to real app delivery than any gateway. It is a poor match for heavily personalized persistent desktops unless you engineer persistence deliberately, and it trades subscription cost for image and orchestration ownership. Run your own figures through the calculator above, treat them as illustrative rather than vendor quotes, size the Kasm edition to your rollout, and verify any Windows and RDS licensing against your own agreements before you bank a saving.