Modern Citrix Architecture
I design Citrix for a living. Not the marketing version — the version that has to survive a maintenance window at 2am, a licence true-up at renewal, and a sceptical infrastructure lead who has been burned before.
So I want to be honest from the first line. Citrix in 2026 is a smaller, sharper proposition than it was five years ago, and a lot of the people still buying it are buying it out of habit. My job, when I sit in front of a customer, is not to sell Citrix. It is to work out whether they need it, and if they do, design something that will not become an operational millstone.
This article is the design thinking I bring to that conversation: where Citrix sits now, the trade-offs of moving the control plane to the cloud, how I build hybrid deployments, how identity has changed, and — the bit most vendors skip — when I tell a customer to walk away from Citrix entirely.
Where Citrix actually sits in 2026
The platform has been through an ownership change and a consolidation, and the messaging has shifted with it. The product family has been pruned and repackaged into platform bundles, the sales motion is cloud-first, and the language leans hard on “the platform” rather than the components engineers actually deploy. Some of that is genuine simplification. A lot is repricing dressed up as strategy.
What has not changed is the engineering reality. Underneath the bundles you still have the same moving parts: Delivery Controllers or the cloud-hosted equivalent, VDAs, StoreFront or Workspace, a Gateway, a licensing mechanism, a SQL database or its managed substitute, and a provisioning method. The brochure changes faster than the architecture does. I design the architecture and decode the brochure at procurement.
The single most important shift is that Citrix now expects you to run the control plane in their cloud. That is the centre of gravity for every design decision below.
CVAD versus DaaS — what moving the control plane really costs
The classic deployment, Citrix Virtual Apps and Desktops (CVAD), keeps everything on-premises or in your own tenancy: Delivery Controllers, the SQL Server site database, StoreFront, the licensing server, Director, Studio. You own the lot — you patch it, back it up, design its high availability, and when it breaks at 2am it is your runbook.
DaaS — the Citrix Cloud control plane — lifts the Delivery Controllers, the site database, the consoles, and the licensing brokerage into Citrix’s cloud. You keep the VDAs, the machines that actually run the workloads, wherever your users’ data and applications live, and connect them back through Cloud Connectors. On paper this is attractive: no more controller patching, no SQL HA design, no StoreFront upgrade weekends, evergreen consoles, faster features. Here is the honest trade-off I walk customers through.
Resilience changes shape; it does not disappear. The marketing implies the cloud control plane removes your availability problem. It moves it. Citrix builds in a Local Host Cache so that if the connection to the cloud is lost, the Cloud Connectors keep brokering existing resources from a cached copy of the site data. That is good engineering and it works — but it is a degraded mode: no configuration changes, reduced capabilities, and a reliance on the Connectors and their local SQL Express instance staying healthy. So your resilience story becomes a hard dependency on Citrix’s cloud uptime, mitigated by a cache that buys survival, not normality. For most customers that is a sensible trade. For a hospital or a trading floor, I make them stare at that dependency until they are comfortable, because it is now outside their change control.
Cloud Connectors are the new thing you own. People hear “DaaS, fully managed” and forget the Cloud Connectors are theirs. They are Windows servers, you need at least two per resource location, they need patching, they auto-update on Citrix’s schedule, and they are the lifeline between your VDAs and the brain in the cloud. Lightweight, but not nothing. I have seen “managed” deployments fall over because someone treated the Connectors as fire-and-forget and let them drift.
Licensing and cost is where the real argument lives. CVAD has historically been perpetual-with-maintenance; DaaS is subscription, per user or per concurrent, billed annually. Over a three-to-five year horizon the subscription frequently costs more in raw licence spend than the perpetual model did. The counter-argument is that you also remove the cost of running and patching the control-plane infrastructure, the SQL licensing, the upgrade labour, and the on-call burden. Sometimes that nets out in DaaS’s favour, sometimes not. I model it properly at the proposal stage rather than asserting it, exactly as I describe in from proposal to production — a cost claim you cannot defend at renewal is how trust evaporates.
Who owns what becomes a contractual question, not just a technical one. With DaaS the line of demarcation moves. Citrix owns the control plane SLA; you own everything from the Cloud Connector inwards. When something breaks, the first ten minutes of the incident go on working out whose side of the line it is on. I make sure that boundary is written down before go-live, because an ambiguous boundary is an outage extender.
My default position in 2026: for greenfield and genuinely cloud-committed customers, DaaS is the right starting assumption. For customers with hard data-residency, latency, or air-gap requirements, or a healthy CVAD estate with years of perpetual value left, I do not move them just because the slide says cloud. I have rejected DaaS more than once, and been right to.
How I build a hybrid deployment
The realistic 2026 design for most mid-to-large customers is hybrid: the control plane in Citrix Cloud, VDAs spread across one or more resource locations — on-premises hypervisor, a public cloud region, sometimes both. A resource location is just a logical grouping of compute plus its pair of Cloud Connectors, and the pattern scales by adding resource locations, not by scaling a central controller. The topology I most commonly draw:
The design rule that matters most is keep the VDAs next to the data. A virtual desktop is a frame-buffer renderer that happens to run Windows; the experience is governed by the round trip between the VDA and the data it touches, not by where the control plane lives. So if the applications and file shares are on-premises, the VDAs go on-premises even though the brain is in the cloud. Mid-migration to Azure, you run two resource locations and shift the VDAs as the data follows. Getting this wrong is the most common cause of “Citrix is slow” tickets, and it is almost never Citrix’s fault — it is a topology decision made without thinking about data gravity. It is the same locality thinking I apply to designing infrastructure for AI workloads: put the compute where the data is, or pay for it in latency forever.
Image management — MCS, PVS, or App Layering
How you build and deliver the machine images quietly determines your operational life for the next three years.
Machine Creation Services (MCS) is my default now. It uses the hypervisor or cloud platform’s native cloning and snapshots to spin VDAs from a master image. It is simple, has no extra infrastructure to run, and works natively across on-prem hypervisors and Azure.
Provisioning Services (PVS) streams a disk image over the network to target devices. It was the right tool when storage was expensive and you wanted to boot hundreds of identical machines from one shared vDisk over the wire. It still has a place at very large scale or with specific streaming requirements, but it brings its own infrastructure — PVS servers, a streaming network design, a store — and that is more to own and more to break. I reach for PVS deliberately and rarely, and I make the customer prove they need it.
App Layering composes images from independently maintained layers — OS, platform, apps — so you can update one application without rebuilding the gold image. Elegant in theory, and genuinely useful when you have a sprawling, frequently-changing application estate maintained by different teams. In practice it adds real complexity, and I have watched it become shelfware at customers who adopted it for the demo and never operationalised it. The honest summary: MCS unless you can articulate exactly why not.
Identity and access in 2026
This is the area that has changed the most, and for the better. The old world was a Gateway appliance pre-authenticating against on-prem AD with maybe RADIUS for the second factor. The new world is identity-first, and runs through Entra ID.
I now design almost every new Citrix access path with Entra ID as the identity provider for Workspace, so authentication, Conditional Access, and MFA are governed by the same policies as the rest of the Microsoft estate. A user’s access to their virtual desktop becomes subject to the same risk-based Conditional Access and device-compliance checks that gate their email and SharePoint. One identity plane, one set of policies, one audit story. This is exactly the posture I look for when I run a Microsoft 365 health check — Citrix access that bypasses Conditional Access is a finding, not a feature.
Adaptive authentication lets you vary authentication and the resulting access by context — where the user is, what device they are on, what network they came from. Combined with adaptive access policies you can allow full desktop access from a compliant managed device but restrict clipboard, printing, and downloads from an unmanaged one. That contextual control is genuinely one of the better reasons to still choose Citrix, and I will come back to it.
The Gateway service in Citrix Cloud handles secure remote access without you publishing a StoreFront and an appliance to the internet yourself. Hybrid customers who still run on-prem Gateway appliances keep patching them promptly, because Gateway appliances have a long history of being a target. Patch hygiene on internet-facing Citrix components is not optional, and it goes in every design document I write.
The decision that matters most — do they even need Citrix?
This is the part of my job I take most seriously, and the part that separates an architect from a reseller. The question I ask before any Citrix design is: what problem are we actually solving? Citrix earns its complexity when you have a real, specific need. The genuine reasons are: keeping data off the endpoint for security or regulatory reasons; delivering heavy, awkward, latency-sensitive legacy applications to a wide audience; centralising compute next to a large dataset; supporting unmanaged or BYOD devices with strong contextual control; or graphics-intensive workloads that need a GPU the endpoint does not have. Where one of those is true, Citrix is excellent and I will happily design it.
But a great many organisations bought Citrix for “remote access to Windows apps”, and in 2026 that problem has cheaper answers.
If the honest requirement is “let people use Office and a line-of-business web app from anywhere”, you probably do not need Citrix.
For pooled or personal cloud desktops on Azure, Azure Virtual Desktop (AVD) does the core VDI job natively, integrated with Entra ID, often at lower licence cost, with no Citrix layer to operate. Windows 365 goes further and gives each user a persistent Cloud PC as a fixed monthly per-user item — dead simple to buy and to reason about, and the right answer for a lot of knowledge workers who just need a managed Windows machine in the cloud. And in a surprising number of cases the right answer is the boring one: the applications are now SaaS, and the user needs a managed laptop, a browser, and good Conditional Access — no virtual desktop at all.
I tell customers this even when it costs me a Citrix sale, because the alternative is selling them a platform they will resent paying to operate. Citrix on top of AVD does add value — HDX for tough networks, richer image and app management, the adaptive access controls, a single pane across hybrid estates — but that value has to clear a bar. If the customer’s whole world is Microsoft, their apps are SaaS or web, and their users are on managed devices, layering Citrix over the top is complexity they will pay for and rarely use. When NOT to use Citrix is the most valuable slide in my deck, and usually the one the customer remembers.
This is the presales discipline I keep coming back to: design for the customer’s actual problem, not for the product you happen to represent. It is the through-line of the future of technical presales — the architect who tells you not to buy the thing is the one you trust with the next project.
Lifecycle and operations — the burden people underestimate
The proposal is where Citrix looks cheap. Operations is where the real cost lives, and it is the single most underestimated line item in every Citrix project I have seen. Three things drive that.
LTSR versus Current Release is the first lifecycle decision. The Long Term Service Release gives you a stable, long-supported baseline with cumulative updates and a multi-year support window — boring, predictable, and what most production estates should run. The Current Release track gives you features sooner but a much shorter support life, so you are on a faster upgrade treadmill. My default for production is LTSR, with a deliberate, tested move to each new LTSR baseline rather than chasing every CR. I only put a customer on CR when they have a specific feature need and the operational maturity to keep up with the cadence.
Image pipelines are where good operations are won or lost. An image you update by hand, at night, by clicking through a console, is one you will eventually break and struggle to roll back. I push customers towards a repeatable build — a documented gold image, updates applied through a controlled process, validated in a staging delivery group, then promoted. Even modest automation pays for itself the first time you need to back out a bad update. Some PowerShell of the kind that lives in that pipeline, rolling a catalogue onto a new master image:
# Update an MCS catalogue to a new master image snapshot, staged then promoted
$catalogue = "Win11-Knowledge-Workers"
$newSnapshot = "XDHyp:\HostingUnits\AzureUKSouth\win11-gold-2026-06.snapshot"
# Publish the new image to the catalogue's provisioning scheme
Publish-ProvMasterVmImage -ProvisioningSchemeName $catalogue `
-MasterImageVM $newSnapshot
# Roll existing machines onto the new image on next reboot, in controlled batches
Request-ProvVMUpdate -ProvisioningSchemeName $catalogue `
-StartsNow $true -DurationInMinutes 0
Write-Output "Catalogue $catalogue scheduled to update to $newSnapshot"
The point of writing it as code is not cleverness — it is that the next engineer, or the customer’s own team, can read exactly what happened and reproduce it. That is the build-knowledge-not-documents instinct I argue for in from proposal to production: the runbook is the deliverable.
Monitoring and observability. Director (or the Monitor service in DaaS) gives you the Citrix-native view: session launch times, logon duration broken down by phase, machine health, failure reasons. It is good, and customers underuse it. But I never rely on it alone. The questions that cause escalations — is it the broker, the VDA, the profile, the network, the storage, or the application — are answered by correlating Citrix’s view with the platform underneath it. So I wire Citrix health into the same monitoring spine the rest of the estate uses rather than leaving it on an island, the instinct behind building repeatable customer health checks. A green Director dashboard next to red storage latency is a story you want in one place.
Capacity is the slow leak. Citrix estates grow by accretion — a new application group here, a department migrated there — and the sizing that was right at go-live is quietly wrong eighteen months later. Logon storms at 9am, oversubscribed hosts, profile bloat and “it’s slow on Mondays” all trace back to capacity assumptions nobody revisited. I build a capacity review into the operational handover, because the deployment perfectly sized on day one is guaranteed to be mis-sized by year two. And note what DaaS does and does not buy you here: it reduces the control-plane share of the burden, but it does not touch the VDA, image, profile, capacity, and application-management share — which is most of it.
Where this goes next
The direction of travel is clear and I design towards it. The control plane will keep moving to the cloud; that argument is largely over. Identity will keep consolidating into Entra ID until Citrix is just another relying party with very good contextual controls. As AVD and Windows 365 mature, the space where Citrix adds defensible value narrows to the genuinely hard cases — tough networks, demanding graphics, deep contextual security, and large heterogeneous estates that need one pane of glass. That is a smaller, more defensible Citrix, and I am comfortable designing for it.
For my own practice, the improvement I am working on is treating Citrix designs the way I treat everything else on this site: as code and repeatable patterns rather than bespoke snowflakes. Reference architectures for the common shapes, parameterised image pipelines, and health-check tooling that audits a live Citrix estate the way my Microsoft 365 tooling audits a tenant. The value is in the repeatability now, not the novelty.
Closing thought
The best Citrix design I do this year might be the one where I talk a customer out of Citrix. That is not a failure of the product — it is the product finding its proper place. Citrix is no longer the default answer to “how do people get to their applications”, and pretending otherwise serves nobody.
When it is the right tool it is genuinely excellent, and designing it well — VDAs next to the data, MCS unless proven otherwise, identity through Entra ID, LTSR for stability, operations taken seriously from day one — produces something that quietly works for years. When it is the wrong tool, the most professional thing I can do is say so. Designing for the problem rather than the product is the whole job, the thread that runs from the first conversation through to a live system in proposal to production.