XenApp and XenDesktop Today: How Citrix Renamed Them and What It Means for Legacy Farms

What Are XenApp and XenDesktop Called Today?

The direct replacement name for the combined XenApp and XenDesktop product line is Citrix Virtual Apps and Desktops . Citrix recorded that change in August 2018, then applied the Citrix DaaS name specifically to its cloud service in March 2022 . Citrix DaaS was not simply a new label applied to every historical XenApp or XenDesktop deployment.

Current commercial terminology adds another layer. At the time of writing, Citrix product-specific licensing terms describe Citrix DaaS Local as the former Citrix Virtual Apps and Desktops product and DaaS Cloud as the former Citrix DaaS product. The following timeline separates the historical lineage from those current names.

Date or period	Name	What it referred to	Source
Historical	MetaFrame	An earlier name in the server-based Windows application delivery line which later became XenApp.	TechTarget history by Jack Madden
Historical	MetaFrame Presentation Server and Presentation Server	Successive names between MetaFrame and XenApp.	TechTarget history by Jack Madden
Before August 2018	XenApp	Primarily associated with published Windows applications and shared server sessions.	TechTarget and Citrix documentation
Before August 2018	XenDesktop	Primarily associated with managed virtual desktops and VDI.	Citrix documentation
August 2018	Citrix Virtual Apps and Desktops	The combined product name which replaced XenApp and XenDesktop.	Citrix DaaS What's New
March 2022	Citrix DaaS	This renamed Citrix cloud service. The on-premises product retained the Citrix Virtual Apps and Desktops name at that time.	Citrix DaaS What's New
Current terminology at time of writing	Citrix DaaS Local and DaaS Cloud	Commercial terms for the former Citrix Virtual Apps and Desktops and Citrix DaaS offerings.	Citrix product-specific licensing terms

A rename is not an automatic migration

An installed XenApp server did not become a cloud-managed Citrix DaaS deployment just because Citrix changed its product terminology. Moving between those environments can indeed involve a different control plane, supported versions, licensing model, infrastructure design and migration process.

Keep the following four aspects separate:

product name, product version, deployment model and support status. A correct name mapping answers only the first question.

XenApp and XenDesktop Served Different Delivery Needs

XenApp and XenDesktop were eventually sold and managed as a combined product line, but their traditional workloads were not identical. Microsoft Learn also treats published applications, multi-session desktops, pooled VDI and personal VDI as distinct deployment models. Microsoft recommends choosing the right mix according to cost, performance and user experience, which supports a workload-first decision rather than a name-first decision.

XenApp focused on published applications and shared sessions

A traditional XenApp deployment delivered individual Windows applications or a shared desktop from multi-session Windows Server infrastructure. Multiple users could connect to the same server while receiving separate sessions, with access controlled by application, group or delivery policy.

An accounting team that only needs remote access to one Windows ERP application does not automatically need a personal virtual desktop for every employee. Application publishing may meet that requirement with fewer desktop images, profiles and capacity-planning decisions.

XenDesktop focused on managed virtual desktops

XenDesktop primarily addressed desktop virtualization , commonly using single-session desktops assigned from pooled or personal catalogues . That model brings broader requirements around desktop images, profiles, provisioning, storage, brokering and capacity management.

Those capabilities matter when an organization must standardize and manage complete desktops at scale. Yet t hey are harder to justify when the actual requirement is access to a small set of Windows applications.

The practical decision rule

If users need a few Windows applications or a shared desktop, evaluate application publishing first. If the organization must manage personal or standardized desktops at scale with mature image and profile management, an enterprise VDI or DaaS product is the stronger fit. Avoid starting a full VDI project solely to deliver a handful of business applications.

A Legacy Farm's Name Does Not Reveal its Support Status

The label XenApp can describe releases from very different generations. Support status depends on the exact release and servicing track, not on whether an administrator casually calls the environment XenApp, XenDesktop or Citrix Virtual Apps and Desktops.

Citrix lifecycle documents use several milestones. End of Sale, or EOS, concerns commercial availability. End of Maintenance, or EOM, ends regular maintenance for the specified release. End of Life, or EOL, marks the end of standard lifecycle support, while End of Extended Support, or EOES, marks the end of any listed extended-support period.

Check the exact release before using any lifecycle date

Identify the installed version on the Delivery Controllers and other core components, then compare it with the live Citrix Product Matrix or Legacy Product Matrix. Citrix's legacy documentation archive is useful for historical configuration details, but an archived manual does not establish that the release remains supported.

For example, the Citrix Legacy Product Matrix lists XenApp and XenDesktop 7.6 LTSR as reaching EOL on January 11, 2021 , with EOES on January 11, 2026. This date cannot be applied to a different XenApp or XenDesktop release, so lifecycle dates should always be checked against the current official matrix when making the decision.

Support also depends on Windows and related components

A supported Citrix component cannot make an unsupported operating system, database, StoreFront server, gateway or authentication dependency supported. Check the Windows Server versions used by controllers and Virtual Delivery Agents (VDAs), along with database compatibility, gateway software, profile components and any application-specific prerequisites.

Dependency warning:

a farm can appear operational while relying on components which are no longer supported in combination. Treat the Citrix release and its underlying platform as one dependency chain, while checking each product's lifecycle separately.

What Should You Inventory Before Retaining or Migrating the Farm?

A useful assessment describes what the farm delivers, how it is built and how it is operated. This prevents a familiar product name from becoming the sole reason to retain or replace the environment.

Workloads, users and delivery model

• List every published application, shared desktop, pooled desktop and personal desktop.
• Record which employees, contractors, customers or partners use each workload.
• Measure normal and peak concurrency rather than relying only on the number of named accounts.
• Identify whether each workload uses multi-session servers or single-session desktops.
• Document application compatibility requirements, including supported Windows versions and application dependencies.

This classification often reveals that a mixed farm contains both simple application-publishing workloads and genuine VDI workloads. Those categories do not have to follow the same modernization path.

Components and dependencies

• Delivery Controllers, StoreFront servers, VDAs, databases and Citrix licensing components.
• Machine catalogues, delivery groups, provisioning methods, images and profile management.
• Gateways, certificates, authentication providers, multifactor authentication and network entry points.
• Printers, print drivers, scanners, smart cards, local drives and other peripheral requirements.
• Application servers, file shares, databases, middleware, service accounts and scheduled tasks.

Printing, profiles, gateways and authentication should be treated as migration dependencies, not as settings to automatically transfer to another delivery layer. Validate each application and connection method before planning a cutover.

Monitoring, performance and exposure

Citrix Director is the built-in console for real-time and historical health monitoring, user-experience visibility and session troubleshooting. Check which Director capabilities remain operational in the installed release and whether administrators actually review login failures, session data, application behaviour and server health.

Also record how the farm is exposed to remote users. Check gateway and certificate ownership, multifactor authentication, account lockout controls, patching, network segmentation, logging, backups and restore testing. Monitoring collecting data which is never reviewed does not provide an operational decision process.

AWS, pricing and licensing are separate decisions

AWS can serve as a Citrix resource location, but it neither is a new name for XenDesktop nor removes the need for Citrix architecture or cloud-infrastructure planning. Citrix documentation still requires decisions about AWS regions, networks, subnets, security groups, credentials and the placement of Citrix components.

Pricing also requires a separate commercial assessment of Citrix licensing costs . As we write , Citrix's public How to buy page routes prospects to sales or a partner rather than displaying a numerical self-service license price. That does not mean negotiated or partner pricing is unavailable, only that a current quote is needed for an accurate comparison.

Microsoft licensing remains your responsibility. Depending on the deployment, this may include Windows Server licenses, RDS CALs and appropriate Office or Microsoft 365 licensing. For precise RDS CAL requirements you should validate your complete configuration with Microsoft or a qualified licensing partner.

Choose a Path Based On the Workload, Not the Old Product Label

Once the farm has been classified, four main paths are available. Workload type, support state, internal skills, contractual commitments and the dependencies uncovered during inventory should direct you to the ideal choice.

Retain or upgrade Citrix

Staying with Citrix can be the right choice when the organization depends on mature image management, enterprise integrations, a current enterprise contract, hybrid delivery or a large standardized desktop estate. Citrix product documentation positions Long Term Service Releases for large production environments prioritizing a stable base, while Current Releases provide faster access to new features.

Citrix upgrade and migration documentation also makes clear that not every legacy XenApp or XenDesktop release has a supported direct path. Older farms may require a new site, component realignment and application validation rather than an in-place upgrade.

Move to Citrix DaaS

Citrix DaaS can retain Citrix application and desktop delivery capabilities while changing the control plane and commercial model. Current Citrix licensing terms show that subscriptions can include DaaS Local and DaaS Cloud, reflecting a broader offer than the historical XenApp application-publishing requirement.

This is an architectural and operational decision, not just a terminology update. Merely moving workload machines to AWS does not create a Citrix DaaS deployment.

Reconsider the delivery layer for application-focused farms

When the farm mainly publishes Windows applications or shared desktops, a simpler self-managed delivery layer may fit the requirement for publishing legacy Windows applications to the web without VDI . TSplus Remote Access can publish applications and assign them to users or groups , deliver full shared desktops from customer-controlled infrastructure and support standard RDP clients, a generated one-click client, RemoteApp-style presentation and browser connections.

Browser access requires the Web Mobile edition or above . Farm Manager, Gateway and load balancing require the Enterprise edition, and each server requires licensing. A server farm is optional, since an organization can deploy TSplus Remote Access on a single server when that architecture meets its needs.

TSplus Remote Access is not a full VDI replacement, therefore certain infrastructures and dependencies should be validated during the trial rather than assumed to work unchanged. For example, graphics-heavy applications or particular extensive corporate builds need prior Proof of Concept testing.

If your farm mainly publishes a small set of Windows applications or shared desktops, use this TSplus vs Citrix comparison to see whether Web Mobile or Enterprise matches the access model you need.

Retain temporarily with a documented exit plan

An immediate migration may be impractical when an application owner, replacement server or licensing decision is not ready. In that case, document ownership, patching, exposure controls, monitoring, backups, licensing responsibilities and a target decision date.

Temporary retention is not a substitute for vendor support. It is a controlled holding position while the organization validates applications, dependencies and the destination architecture.

In Conclusion: the Old Name is Only the Starting Point

XenApp and XenDesktop naming can be decoded quickly, but the correct next step depends on what the infrastructure delivers, its exact support state and the components around it. Classify the workload first, then decide whether Citrix, Citrix DaaS, a simpler application-publishing layer or temporary retention with an exit plan is the appropriate path.

To test with your applications and connection methods, how about downloading TSplus software for your 15-day free trial before deciding whether our delivery layer fits your legacy farm.