Earlier this year, two of the largest virtual desktop platforms repriced their services within the space of a month. In April, Citrix made its cloud-based Licence Activation Service (LAS) the only way to activate its on-premises components, and in May Omnissa raised prices on new and expansion purchases.
Each move traces to its own ownership change, not to the other vendor’s pricing. Broadcom, which acquired VMware in 2023, removed VMware’s perpetual licensing and sold the end-user computing division – Horizon – to KKR, which now runs Horizon as Omnissa. Omnissa’s price increases this year were roughly +7% to +21%.
Citrix was taken private in 2022, folded into Cloud Software Group, and then moved onto consolidated subscription bundles, with increases reported in the first half of this year running up to around 200% – and higher in some large accounts. Citrix doesn’t publish list pricing, so those figures come from customer accounts rather than a price book, which makes them indicative of a direction, not a rate anyone can hold the vendor to.
In response to these price increases and uncertainty, many organisations will be looking at exit programmes. But Citrix’s LAS change, which forced companies to upgrade, provided a preview of the challenges this involves. IT estates on older virtual apps and desktops releases had to upgrade to stay supported, and that upgrade cost weeks of testing and deployment that IT budgets and plans wouldn’t have factored for.
The business case for an exit usually comes from a licence comparison: the current annual cost of the existing platform against the annual cost of the new/target platform, plus a professional services figure for the migration. Often, however, the applications in the virtual desktop estate don’t appear in this comparison – it’s presumed that they will simply transfer over, but as this is never written down, it’s never tested.
Yet nothing in a Citrix or Omnissa estate transfers, because every application was originally prepared for that specific estate, meaning they have dependencies tied to the virtual desktop. As such, all of the estate has to be rebuilt for a different delivery model, and that process has to be completed before the first production user uses the new system.
Therefore, instead of basing a decision on an exit programme on licensing costs alone, what organisations also need to understand is how much time and money packaging their apps will cost as well.
Where an exit programme’s estimate comes from
The packaging labour needed to migrate apps usually gets absorbed into a desktop team’s week and never appears as an actual figure. So, when an exit programme needs a number for the timeline of the project, it comes from asking developers how long one application takes and then multiplying this by the total count in the asset register. Yet both these figures are generally understated.
The per-application estimate gets made based on an application somebody can describe from memory, which is the maintained end of the estate – the apps regularly updated – and not the actual median of all the apps. And the asset register only counts what was procured centrally, so it misses whatever project teams installed and whatever application arrived bundled inside something else. As a result, when these two understatements are multiplied together, the total figure is wrong by a multiple. Juriba’s State of Windows App Packaging Nation survey puts unmanaged or uncounted apps at roughly 43% of the estate, an indicative industry figure rather than this estate’s actual number, but enough on its own to make a near-doubling unremarkable.
Anyone who’s inventoried an estate before a platform move will recognise how counts can vary from the figure in the software asset management tool, the number the delivery platform reports, and the total the desktop team recognises are three different numbers. The gap between them comes from duplicates and decommissioned entries, as well as apps with no owner, and nothing about the discrepancy between them says which is which. Until that’s reconciled, the estimate is resting on whichever count was easiest to export.
This is the shape of every migration wave. But with Citrix and Omnissa, a licence renewal date is setting the timeline instead of an end-of-support notice.
What to do before the next renewal quote arrives
The timeline for an exit should follow the number of applications that need a person to rebuild them instead of the number of applications the estate has. Anything that installs cleanly and unattended can be repackaged for the new delivery platform at a predictable rate, and, crucially, this can be largely automated.
However, the apps that need to connect to a specific licence server to be installed, or have certain switches/configuration settings that haven’t been recorded, will each need a person to rebuild them, and the percentage of these apps can vary enormously between estates that look alike from the outside. That percentage is what decides whether a migration date is realistic or notional.
The standard first step is to run automated scanning tools that can count what’s in an estate, which most exit programmes eventually do and which answers the easier half. What a count on its own won’t tell you is how much of the work repeats.
So my view is that the two numbers worth having before a renewal quote arrives are the size of the estate and the proportion of it that can be rebuilt without a person, because the first is what the vendor is pricing and the second is what the plan runs on. Both come out of data the estate already emits: the delivery platform knows what’s published and to whom, launch telemetry shows which of those anybody opens, and the package repository holds the installers along with the switches they were built with.
Neither vendor in the negotiation will produce those numbers, because both of them price on users and the exit gets delivered in applications. The second number is also the one that’s worth raising. Every point the automatable share goes up shortens the migration and the end-of-support deadline behind it, which is why it’s worth building this capability once rather than assembling it again at the next renewal.
With both these numbers at hand, IT leaders can secure better quotes and understand how to carry out an exit programme in a much more cost-effective way.
