Skip to content

Migration · /// Citrix → AVD

Migrate Citrix → AVD with data, not slide decks.

LoadGen runs the same .lgs scenario on Citrix and on AVD. Same auth flow, same workload, same per-step measurement — overlaid on one cockpit. Baseline Citrix, validate AVD, sign the cutover behind a measured gate.

Plan the migration with dataTalk to a migration engineer

Same scenario, both stacksHDX vs ARM, side-by-sideWave-gated cutover

Migration cockpit — wave-by-wave + baseline overlay + sign-off.

The Problem

Most Citrix → 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 30-user AVD pilot passing does not mean 1,500-user finance-close 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, FSLogix share size, and connection-broker capacity all drive Azure spend. Without measured concurrency from a real workload, every spend forecast is a hand-wave Azure invoices 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 — which is what every migration sign-off conversation actually needs.

Same .lgs scenario, both stacks

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

Protocol-honest measurement

HDX p95 on Citrix vs AVD-broker latency on AVD. Login time, FSLogix profile-load, host-pool density — all captured natively per stack, overlaid on one timeline.

Wave-gated cutover

Promote 50 → 250 → 1,500 users behind a measured validation gate. Every wave 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 wave 1 against AVD wave 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.
  • Up to 5 runs overlaid — drill from KPI summary into Moments, Errors, per-step.
  • Protocol-honest measurement: HDX p95 on Citrix, AVD-broker latency on AVD.
  • Delta tracked vs the original Citrix baseline at every wave.

Multi-test overlay — 5 runs, same scenario shape.

The 4-step migration testing motion

Baseline · Author · Execute · Cutover.

Step 01

Baseline Citrix

Capture the .lgs scenario from your existing Citrix deployment — same auth flow, same app set, same per-step workload. HDX p95, login latency, and host-pool density become the reference numbers.

Step 02

Author the AVD pool

The 7-step AVD wizard reads ARM inline — Subscription, Resource Group, Host Pool, FSLogix share, connection-broker auth. 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 HDX p95 against AVD-broker latency, login time, host-pool density, FSLogix profile-load — on one scrub bar.

Step 04

Sign the cutover

Promote wave-by-wave behind a measured validation gate. Every wave is a re-run of the same scenario, with delta tracked against the original Citrix baseline. Cutover is a data decision.

Wave-gated cutover

Promote behind a measured capacity gate.

50 → 250 → 1,500 users moved with phase-by-phase validation. Each wave 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 SLA threshold — see the breakpoint as it happens.
  • AVD breakpoint banner fires when host-pool density or FSLogix profile-load exceeds SLA.
  • Same engine drives post-cutover continuous monitoring — no re-authoring needed.

Capacity validation — phase-by-phase under load.

Citrix → 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.

MetricCitrix baselineAVD target
Authentication flowStoreFront · Gateway · PNAgentAAD · Connection broker
ProtocolHDX / ICAAVD protocol over ARM
Session density measurementPer session hostPer host pool · per host SKU
Profile / stateCitrix Profile MgmtFSLogix profile share
Per-step p95Captured nativelyCaptured natively, same shape
Login latencyPre-cutover baselinePost-migration measurement

Outcomes

What the platform delivers on the cutover.

Time to first AVD test

Before

7 days

After

4 hrs

−97 %
Scenarios authored per migration

Before

Two

After

One

reuse
Host pool right-sizing accuracy

Before

±40 %

After

±5 %

−87 %
Cutover-week incidents

Before

8

After

1

−87 %

See it in action

Three surfaces a migration program runs through.

Baseline Citrix

7-step Citrix wizard — auth + scenario capture.

Author AVD

7-step AVD wizard — ARM discovery + FSLogix.

Migration cockpit

Wave-by-wave + sign-off audit trail.

Where teams plug this in

Three migration-testing programs.

Pre-cutover capacity validation

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

See use case

Wave-by-wave promotion

50 → 250 → 1,500 users 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 every minute. SLA-grade evidence the migration delivered.

See use case

Migrate Citrix → 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 — not stack-specific protocol details. Citrix-side, it’s bound to the 7-step Citrix wizard; AVD-side, it’s bound to the AVD wizard. Per-step measurement carries over identically; protocol-specific signals (HDX p95 vs AVD-broker latency) are captured natively on each side.

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 auth and Basic (ICA) / Enhanced (HDX) modes in minutes; the resulting .lgs becomes both your migration baseline and your post-cutover continuous-monitoring scenario.

How does LoadGen handle FSLogix during the migration test?

The AVD wizard captures the FSLogix profile share inline alongside Subscription / Resource Group / Host Pool. Profile-load time is bound to SUT Monitoring as a first-class signal, so the cockpit shows FSLogix profile-load latency overlaid against AVD-broker latency and login time.

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

That’s the standard pattern. Wave 1 typically targets a 50-user pilot pool against a representative workload. Wave 2 grows to 250 users. Wave 3 hits production scale (1,500–5,000+ users). Each wave is the same scenario at growing scale; delta is tracked against the original Citrix baseline.

What does the engagement look like — and how long?

A typical migration-testing engagement runs 2–8 weeks depending on AVD scale. Week 1: baseline Citrix + author AVD pool. Weeks 2–4: pilot validation + delta analysis. Subsequent weeks: wave-by-wave promotion behind validation gates. LoadGen Services (consulting + 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, scaling to 25,000 vUsers. End-to-End Monitoring is €899 per Agent per month if you want continuous post-cutover monitoring. Migration engagements typically run the Load Testing module during the cutover window, then add Monitoring after go-live.

LoadGen Official Logo