Skip to content

Migration · /// Citrix to AVD

Migrate Citrix to AVD with data, not slide decks.

LoadGen runs the same `.lgs` scenario on Citrix (7-step wizard) and on AVD (7-step wizard) on a single scenario engine. Generic p95 captured per transaction on each side, overlaid on one cockpit. Migration validation is a positioning/workflow motion, not a separate engine.

Plan the migration with dataTalk to an engineer

Same scenario, both stacksGeneric p95 on each sideCompare and sign cutover

Migration cockpit. Baseline overlay across stacks.

The Problem

Most Citrix-to-AVD cutovers are slide decks masquerading as plans.

The decision to leave Citrix usually arrives with a target date, a budget, and an Azure subscription, and very little measured before-and-after on the actual workload. Migrations fail on the components nobody tested.

No before-and-after on the same scenario.

Pilot teams typically write one workload for Citrix and a different workload for AVD. The comparison is apples-to-oranges. The board sign-off arrives with a measurement gap nobody acknowledges.

Pilot pools that lie about production.

A small AVD pilot passing does not mean a production cohort will pass. Without parity testing across host pools (same auth, same load shape), regression surfaces on cutover weekend.

Azure cost numbers built on guesses.

Host-pool density and session-host SKU drive Azure spend. Without measured concurrency from a real workload, every spend forecast is a hand-wave the Azure invoice will refute.

Why LoadGen for this migration

The same scenario engine on both stacks.

LoadGen authors a Citrix workload once. The same `.lgs` runs on AVD without re-authoring. The before-and-after lives in one cockpit. That’s what every migration sign-off conversation actually needs, a positioning/workflow motion over two wizards plus comparison overlay on the same scenario engine.

Same `.lgs` scenario, both stacks

Auth flow, app set, and per-step workload captured once on the 7-step Citrix wizard. Reused unmodified against the 7-step AVD wizard. The PoC delta is real, not an artefact of two different test designs.

Generic p95 on each side

Generic p95 tracked per transaction on Citrix and on AVD, the same measurement shape on both sides, overlaid on one timeline.

Compare and sign cutover

Promote pilot, scale, and production cohorts behind measured validation. Each cohort re-runs the same scenario, with delta tracked against the original Citrix baseline. Roll back on data, not opinion.

Side-by-side validation

Same scenario shape. Both stacks. One scrub bar.

The cockpit overlays up to 5 runs against each other: Citrix baseline against AVD pilot, AVD cohort 1 against AVD cohort 2, post-cutover monitoring against pre-cutover baseline. The before-and-after every migration board demands.

  • Same `.lgs` scenario authored once. Runs unmodified on Citrix and AVD on the same engine.
  • Up to 5 runs overlaid. Drill from KPI summary into Moments, Errors, and per-step.
  • Generic p95 captured on each side, on the same scenario shape.
  • Delta tracked vs the original Citrix baseline at every cohort.

Multi-test overlay. Up to 5 runs, same scenario shape.

The 4-step migration testing motion

Baseline · Author · Execute · Cutover.

Step 01

Baseline Citrix

Capture the `.lgs` scenario in the 7-step Citrix wizard. Basic (ICA) and Enhanced (HDX) modes with StoreFront / Gateway / PNAgent / External Login auth surfaces. Generic p95 becomes the reference measurement.

Step 02

Author the AVD pool

The 7-step AVD wizard captures Tenant, Client, Resource, and a Classic/ARM toggle. The same workload from step 1 is bound to the AVD target. No re-authoring.

Step 03

Execute side-by-side

Fire the workload from VDI agents on both Citrix and AVD. The live cockpit overlays generic p95 on each side and per-step latency on one scrub bar.

Step 04

Sign the cutover

Promote pilot, scale, and production cohorts behind measured validation. Every cohort is a re-run of the same scenario, with delta tracked against the original Citrix baseline. Cutover is a data decision.

Cohort-by-cohort cutover

Promote behind measured validation.

Pilot, scale, and production cohorts moved with phase-by-phase validation. Each cohort re-runs the same scenario at growing scale. Spike-tests verify AVD breakpoint before production users feel it. Roll back on data, not opinion.

  • 5-phase load shape: Idle, RampUp, Sustain, SPIKE, RampDown.
  • Concurrency curve overlaid against measured threshold. See the breakpoint as it happens.
  • AVD breakpoint banner fires when host-pool density or generic p95 exceeds the threshold.
  • Same engine drives post-cutover continuous monitoring. No re-authoring needed.

Capacity validation. Phase-by-phase under load.

Citrix to AVD on one workload

What gets measured, on both stacks.

The same per-step measurement shape lives on both sides of the cutover. The differences below are stack-specific. The measurement is identical, generic p95 captured per transaction on each side.

MetricCitrix baselineAVD target
Wizard7-step Citrix wizard7-step AVD wizard
Auth surfacesStoreFront · Gateway · PNAgent · External LoginTenant · Client · Resource · Classic/ARM toggle
ModesBasic (ICA) · Enhanced (HDX)Classic / ARM toggle
WorkloadCaptured at scenario levelSame `.lgs`, captured at scenario level
MeasurementGeneric p95Generic p95
Agent fleetVDI agents (port 4841)VDI agents (port 4841)

Proof

Numbers from the platform.

1.45M+

Tests run

across the customer base

6

Platforms covered

Citrix · AVD · Horizon · RDS · Web · FAT

1×

Scenario authored

reused on both stacks

From €1,099

Per week · transparent

starts at 50 vUsers

See it in action

Three surfaces a migration program runs through.

Baseline Citrix

7-step Citrix wizard. Basic (ICA) + Enhanced (HDX).

Author AVD

7-step AVD wizard. Tenant · Client · Resource · Classic/ARM.

Migration cockpit

Comparison overlay across stacks.

Where teams plug this in

Three migration-testing programs.

Pre-cutover capacity validation

Stress AVD against the modelled Citrix concurrency. Right-size host pools, storage sizing, and session-host SKU before the board sees the spend number.

See use case

Cohort-by-cohort promotion

Pilot, scale, and production cohorts moved with measured validation between waves. Same scenario, growing scale, observed delta. Cutover signs on data.

See use case

Continuous post-cutover monitoring

Same scenario engine flips into continuous monitoring mode after cutover. Synthetic AVD sessions on a configurable schedule. Service Levels evidence the migration delivered.

See use case

Migrate Citrix to AVD with measured before-and-after.

We’ll baseline a representative workload on your existing Citrix farm and run it against a pilot AVD host pool on a call. The cutover conversation gets a data-anchored start.

Plan the migration with dataRead the migration checklist

Questions

Frequently asked.

Can the same `.lgs` workload really run on both Citrix and AVD?

Yes. The `.lgs` scenario captures auth flow, app set, and per-step workload shape on the same engine. Citrix-side, it’s bound to the 7-step Citrix wizard (Basic ICA or Enhanced HDX). AVD-side, it’s bound to the 7-step AVD wizard (Tenant · Client · Resource · Classic/ARM). Per-step measurement carries over identically. Generic p95 is captured per transaction on each side.

Is Citrix-to-AVD migration a dedicated product or a separate workflow?

It is a positioning/workflow motion over two wizards (7-step Citrix and 7-step AVD) plus the multi-test comparison overlay, all driven by the same scenario engine. There is no dedicated migration product or separate execution engine: same engine, two targets, one comparison view.

What if our existing Citrix workload is hand-scripted in another tool?

LoadGen authors the scenario in the 7-step Citrix wizard during the PoC. No upstream translation required. The wizard captures StoreFront / Gateway / PNAgent / External Login auth surfaces and Basic (ICA) / Enhanced (HDX) modes. The resulting `.lgs` becomes both your migration baseline and your post-cutover continuous-monitoring scenario.

What does the AVD wizard capture?

The 7-step AVD wizard captures Tenant, Client, Resource, and a Classic/ARM toggle. Workload behaviour is configured at scenario level on the same engine that runs Citrix, Horizon, and RDS. Generic p95 is captured per transaction.

Can we test against a pilot AVD environment before committing to scale?

That’s the standard pattern. Pilot, scale, and production cohorts moved with phase-by-phase validation between cohorts. Each cohort is the same scenario at growing scale, and delta is tracked against the original Citrix baseline.

What does the engagement look like, and how long?

A migration-testing engagement begins with a baseline of Citrix and a pilot AVD pool, then promotes cohort-by-cohort behind validation gates. Exact timeline depends on AVD scale and operational readiness. We’ll size it on the discovery call. LoadGen Services (consulting and managed runs) is available where in-house bandwidth is tight.

What does it cost?

The Load Testing module is €1,099 per week at 50 vUsers. License tiers run from 50 to 25,000 vUsers; 25,000+ users have been tested by LoadGen, and LoadGen scales with available test infrastructure and agent capacity. End-to-End Monitoring is €899 per Agent per month if you want continuous post-cutover monitoring. Migration engagements typically run Load Testing during the cutover window, then add Monitoring after go-live.

LoadGen Official Logo