Running Citrix and an alternative in parallel is the normal reality of almost every migration, and it is where the licensing economics either hold together or quietly fall apart. No enterprise of any size flips off Citrix and turns on a replacement overnight. Users move across in waves over months, which means both platforms run together for a period, and during that period you carry cost and compliance obligations on each one. This article sets out the licensing implications of that overlap, the double cost trap that catches unprepared teams, and how to plan the parallel run so it does not erase the saving that justified the move.
Why running Citrix and an alternative in parallel is unavoidable
A clean cutover is a fantasy for any estate with real complexity. Applications have to be remapped and tested, users have to be trained, and the new platform has to be proven under genuine load before anyone trusts it with production work. That means a phased migration: a pilot group, then waves of users, then the long tail of difficult workloads that move last. Throughout that sequence the old and new systems coexist. This is healthy project discipline, because it lets you roll back if something breaks and it avoids a single high risk switch. The catch is that healthy project discipline collides with how Citrix is licensed, and the collision shows up as cost.
Both platforms run at once for months. The question is not whether you overlap, but how long, and who planned for it.
The double cost trap
Here is the trap. You begin paying for the alternative platform as you stand it up, while your Citrix commitment continues in full. Since perpetual licensing ended in October 2022, Citrix is subscription only, and a subscription commitment generally runs for its agreed term no matter how many users you have already moved away. Migrating half your users off Citrix does not, in most agreements, cut your Citrix bill in half. You keep paying the committed quantity until the term ends or the contract allows a reduction, and you are paying for the new platform at the same time. For the duration of the parallel run you are effectively paying twice for the users in transition. Teams that model an exit on the new platform cost alone, and forget this overlap, routinely find the project looks far worse in years one and two than the spreadsheet promised.
The size of the trap depends almost entirely on timing. An overlap of three months is a manageable bump. An overlap of two years, because the Citrix term was just renewed before the migration started, can swallow most of the first phase saving. This is why the renewal decision and the migration decision must be made together rather than in sequence, a point we develop in negotiating Citrix down while planning an exit.
Aligning the parallel run to the renewal
The single most effective control is timing the migration so the Citrix commitment ends as the parallel run ends. If your migration will take twelve months, you do not want to sign a fresh three year Citrix term the month before you start. Where a renewal is unavoidable during the transition, the goal is a shorter term, a smaller committed quantity, or explicit step down rights that let you reduce counts as users leave. These terms have to be negotiated before signing, because no agreement grants them after the fact. The renewal that precedes a migration is therefore not a routine renewal at all; it is the contract that governs the entire parallel period, and it should be negotiated with the migration plan already in hand. Our 18 month replatform plan shows how the timeline and the contract are sequenced together.
Sequencing to retire the costliest seats first
Even within a fixed overlap, the order in which you migrate changes the economics. Moving your most expensive Citrix seats and workloads first means that, if any reduction rights exist, you capture the largest saving as early as possible, and it builds the credibility of the exit as leverage. Moving the cheapest, easiest users first feels good because the early waves go smoothly, but it leaves the costly seats on Citrix longest and delays the financial benefit. A migration sequence should be driven by cost and leverage, not only by technical ease. The partial exit logic in our partial Citrix exit strategies applies directly to how a parallel run should be ordered.
The compliance dimension of a parallel run
Cost is only half the story. A parallel run is also a compliance event. Winding down an estate, reducing usage, and changing deployment are precisely the signals that draw a Citrix review, and as of 2026 license reviews are increasing as customers attempt to cut spend or exit. The parallel period also creates a window where entitlements and actual use diverge, sometimes in your favour and sometimes not, and that gap is exactly what an audit examines. The defense is documentation and discipline: keep a clean, evidenced record of who is licensed for what on each platform at each stage, do not let migrated users keep stale Citrix access that still counts against you, and avoid the assumption that reducing real usage automatically reduces your contractual liability. Our note on what breaks when you leave covers the technical and licensing failure points that surface mid migration.
There is one more trap worth naming. Users who have been migrated to the alternative but still hold active Citrix entitlements, because nobody cleaned up access, represent pure waste and potential audit exposure at once. A parallel run needs an active decommissioning discipline, removing Citrix access as each wave completes, so the estate genuinely shrinks rather than simply growing a second platform alongside the first.
Modeling the overlap cost before you start
Every parallel run should be modeled as an explicit line in the migration business case, not absorbed silently into a contingency. The model is straightforward once you commit to building it. Take the committed Citrix cost that will continue through the transition, add the standing up and run cost of the alternative platform across the same months, and lay both against the migration timeline wave by wave. The overlap cost is the area where the two curves run together, and it is real money that has to be funded from somewhere. Teams that skip this step are not avoiding the cost; they are simply discovering it later, usually when the year one budget comes in over plan and the project loses credibility with finance.
The model also tells you where to push. If the overlap cost is dominated by a Citrix commitment that runs long past the migration, the lever is the contract: a shorter term or step down rights. If it is dominated by a slow migration that drags the parallel period out, the lever is the project plan: more parallel capacity to move users faster and close the overlap sooner. Often the cheapest answer is to spend a little more on migration speed to shorten the period of paying twice, because the overlap cost usually outweighs the cost of accelerating. As of 2026, with Citrix commitments expensive and rigid, the value of compressing the overlap is higher than most plans assume, which is why the model is worth building before the first wave rather than after. The full sequencing of contract and timeline is covered in our replatform timeline plan.
Getting the parallel run right
Done well, a parallel run is a controlled, time boxed overlap whose cost was modeled before the project started, governed by a Citrix contract that was negotiated to allow the transition, and documented well enough to survive a review. Done badly, it is an open ended period of paying twice, exposed to an audit, with no contractual right to reduce the Citrix side. The difference is entirely in the planning that happens before the first user moves. For the full strategic context, including exit economics and timelines, see our Citrix alternatives and exit pillar. The migration is a technical project, but the parallel run is a licensing one, and treating it that way is what keeps the saving intact.
Frequently asked questions
What does running Citrix and an alternative in parallel mean?
It means operating Citrix and a replacement platform at the same time during a migration, so users move across in waves rather than all at once. The two systems run together for a period, which is normal and often necessary, but it has direct licensing consequences because you carry cost and compliance obligations on both platforms until the Citrix side is fully retired.
Do I keep paying full Citrix cost during a parallel run?
Usually yes, unless your agreement allows you to reduce counts mid term, which most subscription agreements do not. Since perpetual licensing ended in October 2022, Citrix is subscription only, and a subscription commitment generally holds for its term regardless of how many users you have migrated away. This is the double cost trap, and it has to be planned around rather than assumed away.
Can a parallel run trigger a Citrix audit?
It can. Reducing usage, changing deployment, and winding down an estate are exactly the signals that draw a review, and as of 2026 license reviews are increasing. A parallel run also creates a moment where entitlements and actual use diverge, which is the gap an audit looks for. Documenting the migration and keeping a clean license position throughout is the defense.
How do I avoid paying twice during a migration?
You cannot always avoid some overlap, but you can shrink it. Align the migration timeline to the Citrix renewal so the commitment ends as the parallel run ends, negotiate any reduction or step down rights before you sign, and sequence the migration to retire the most expensive Citrix seats first. The overlap cost is a planning problem, not a fixed cost.
When should licensing planning start for a parallel run?
Before the migration project is approved, not after. The licensing and contract terms that govern the parallel period are set at the renewal, so the time to secure reduction rights and align the timeline is during the negotiation that precedes the move. As of 2026, leaving licensing until the migration is underway forfeits most of the levers that control the overlap cost.