Citrix to AVD Migration Checklist | LoadGen

You can't measure migration success against a memory. Capture a Citrix baseline first, before any AVD configuration is touched.

1. Create a Citrix load profile at /config/load-profiles/new/citrix.
2. Configure your real connection — StoreFront, Gateway, PNAgent, or External Login. The wizard knows each topology.
3. Set users, agents, display, and scenario to match your peak working pattern. Use the same .lgs workloads you'll later replay against AVD.
4. Run the test at /testing/run. Watch it live at /testing/active.
5. Capture the result at /testing/results — P90 / P95 response times, throughput, error rate per phase, per-action timing.

That result is your baseline. Every AVD comparison will measure against it. Don't skip step 1 — every migration that breaks at cutover broke at this step.

The migration is not a flag day. Configure AVD alongside Citrix and run them in parallel for as long as it takes to build comparison data.

1. Create an AVD load profile at /config/load-profiles/new/wvd.
2. The AVD wizard surfaces ARM-native configuration: Subscription, Resource Group, and Host Pool. Discovery is built in — no CLI scripts.
3. Reuse the same scenario shape from step 1 — same workloads, same phases, same think time, same vUser ramp. The whole point is that only the platform changes.
4. Run the AVD test against your AVD pilot pool. Watch it live, just like the Citrix run.
5. Compare side-by-side at /testing/results.

If you authored the scenario differently for AVD than for Citrix, you broke the comparison. The wizard is per-platform; the scenario shape is shared. Keep them honest.

The comparison view is where the migration decision actually gets made.

• Filters — Date range, profile, status. Pull up the Citrix baseline and the most recent AVD test together.
• Overlay — P90, P95, error rate, throughput. Up to five runs at once, so you can chart how AVD is converging toward (or surpassing) the Citrix baseline as you tune host pools and FSLogix settings.
• Detail modal — Drill into Overview, Moments, Measurements, and Errors. The Moments view shows when in the run the gap appeared — was it logon, was it sustained load, was it a specific app?
• Trend strip — The same scenario across releases. Watch your AVD numbers improve as the team optimizes; freeze the comparison the day they cross the baseline.

This is the artifact you take to leadership when you ask for the cutover decision. "AVD performs within tolerance of the Citrix baseline at peak concurrency, with these specific exceptions" — backed by the evidence trail under it.

Migration is not "done" the day the last user moves. The first month on AVD is when the silent regressions land.

Configure E2E monitoring at /monitoring/profiles for the AVD environment immediately after cutover:

• Continuous UX monitoring — Synthetic + real-user perspective, running on the same scenarios you tested with.
• Threshold alerting — When P95 climbs past your post-migration target, you get paged before the helpdesk queue fills.
• SessionSight — Heatmaps, session replay, and journey analysis at /sessionsight/dashboard. Specifically useful for catching UX regressions a synthetic check would miss — the post-migration "everything feels slow" complaint that has no error.

The same agents, the same scenario engine, and the same audit trail you used for testing now run continuously. There's no separate monitoring stack to stand up.

The single most expensive migration mistake is "we'll set up alerts later." Later doesn't happen until the first incident.

Configure alerts at /alerting/profiles and triggers at /alerting/triggers. Wire notifications across the channels your team actually watches — email, webhook, SMS, WhatsApp. Add uptime checks for the AVD endpoint and any dependent services so availability becomes a continuous signal rather than a quarterly sample.

Three alert classes that should be live before any user is migrated:

• Logon latency breach — When average login time exceeds a threshold, page on-call.
• Concurrency cap — When session count climbs above your AVD pool's tested capacity, escalate.
• Error-rate spike — When error rate exceeds the Citrix baseline plus tolerance, escalate.

These thresholds are derived from steps 1 and 3 — the baseline you captured and the comparison you ran. Without those, you're picking thresholds out of the air.