Skip to content

Migration · /// Horizon → AVD

Migrate Horizon → AVD with data, not slide decks.

The same scenario engine runs on VMware / Omnissa Horizon and on Azure Virtual Desktop. Baseline Connection Server today, test ARM-discovered AVD tomorrow. Compare connection-broker latency vs AVD-specific p95, login time, host-pool density — wave-gated, sign cutover with evidence.

Plan the Horizon → AVD migration with dataTalk to a migration engineer

Same scenario, both stacksConnection Server vs ARM, side-by-sideWave-gated cutover sign-off

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

The Problem

Horizon → AVD migrations live on slide decks.

Most Horizon → AVD migrations are pitched on architectural slide decks. Production discovers the gap on cutover weekend, when Connection Server reliability gives way to ARM-discovered AVD behaviour. The missing piece is measured side-by-side validation.

Two stacks, two test plans.

Without one scenario engine spanning both, teams maintain a Horizon test plan and an AVD test plan separately — different definitions of "working", different per-step measurements, no direct comparison.

Azure cost forecasts built on guesses.

AVD host-pool sizing depends on measured concurrency on real session hosts, not Horizon-equivalent calculations. Wrong session-host SKU + wrong host-pool count = Azure invoice surprises.

Brand transition + platform transition compound.

The VMware → Omnissa Horizon brand transition plus the Horizon → AVD platform transition layer on top of each other. Test data scattered across versions; cutover decisions made on incomplete information.

Why LoadGen for Horizon → AVD migration

One scenario engine. Both stacks. Measured.

Author the scenario once. Replay on Horizon (Connection Server + published apps). Replay unmodified on AVD (ARM discovery + FSLogix). Compare both on the same chart — cutover signs on data.

Horizon-native baseline

Horizon scenarios run on the same engine — Connection Server auth, published-app launch, multi-session host. Captures the current state honestly, regardless of VMware vs Omnissa branding.

AVD ARM-native target

The same .lgs scenario replays on AVD via the 7-step ARM-native wizard — Subscription / Resource Group / Host Pool, FSLogix profile-load, AAD auth.

Cross-stack overlay

Multi-test overlay compares connection-broker latency on Horizon vs AVD-specific p95 on AVD, login time, host-pool density — one chart, both stacks.

Multi-test overlay

Horizon vs AVD on one scrub bar.

Stack-honest comparison — connection-broker latency on Horizon against AVD-specific p95 on AVD, login time against login time, host-pool density against session-host density.

  • Same .lgs scenario authored once, runs unmodified on Horizon + AVD.
  • Up to 5 runs overlaid on one chart — drill into Moments, Errors, per-step.
  • Protocol-honest measurement on each stack.
  • Same data drives wave-gated cutover sign-off.

Multi-test overlay — Horizon baseline vs AVD target.

How the engagement runs

Baseline → Author → Execute → Cutover.

Step 01

Baseline Horizon

Capture the current Horizon scenario shape — Connection Server auth, published apps + desktops, multi-session host density. The baseline against which AVD progress will be measured.

Step 02

Author AVD pool

Use the 7-step ARM-native wizard to spin up a pilot AVD host pool. Same scenario shape, ARM discovery + FSLogix capture done in minutes.

Step 03

Execute side-by-side

Run the .lgs scenario against both stacks. The live cockpit overlays connection-broker latency against AVD-specific p95, login time, host-pool density — on one scrub bar.

Step 04

Wave-gated cutover

Promote users from Horizon to AVD wave by wave. Each wave re-runs the same scenario at growing scale; delta tracked against the original Horizon baseline. Roll back on data, not opinion.

Stack-honest comparison

Same workload, both stacks — what changes.

SignalHorizon (baseline)AVD (target)
Broker latencyConnection ServerAVD-specific p95
AuthoringHorizon-aware wizardARM-native wizard
Profile modelPersona / instant cloneFSLogix profile share
IdentityAD / SAMLAAD / Microsoft Entra
Session host SKUvSphere VMAzure VM SKU
Capacity sizingvCenter clustersHost pool + region density

Outcomes

Measured Horizon → AVD migration.

Scenario reuse

Before

2 scenarios

After

1 scenario

one engine
AVD host-pool right-sizing

Before

±40 %

After

±5 %

−87 %
Time to first AVD test

Before

7 days

After

4 hrs

−97 %
Cutover-week incidents

Before

8

After

1

−87 %

See it in action

Three migration surfaces.

Migration cockpit

Wave-by-wave + baseline overlay + sign-off.

AVD wizard

ARM-native discovery + FSLogix capture.

Run comparison

Horizon vs AVD overlay on one chart.

Where Horizon → AVD lives

Three migration patterns.

Full Horizon → AVD cutover

Baseline Horizon, build pilot AVD pool, validate per-wave, cut over by wave. Same scenario shape across the entire engagement.

See use case

Hybrid Horizon + AVD

Some workloads stay on Horizon (vSphere-anchored apps), others move to AVD. Same engine monitors both — one SLA report, one cockpit.

See use case

Vendor consolidation review

For organisations evaluating Omnissa Horizon vs Azure-native AVD strategically, LoadGen captures both on the same scenario — strategic decisions on measured data.

See use case

Plan your Horizon → AVD migration with data.

We’ll baseline your Horizon scenario in the wizard, build a pilot AVD pool against your subscription, and run the same workload across both — on a call.

Plan the Horizon → AVD migration with dataRead the migration checklist

Questions

Frequently asked.

Does the same scenario really run on both Horizon and AVD?

Yes — that’s the migration-testing primary use case. Same .lgs scenario authored once runs unmodified on both stacks. The cockpit overlays connection-broker latency on Horizon against AVD-specific p95 on AVD, login time, and host-pool density.

How does LoadGen handle the VMware → Omnissa rebrand?

LoadGen runs real Horizon sessions end-to-end — Connection Server, published apps, full desktops — regardless of console branding. The synthetic test is stack-honest about user experience, not vendor API state.

What about hybrid Horizon + AVD?

Many estates run both for an extended period. The same scenario engine monitors and tests both — one SLA report, one cockpit, one audit trail across the hybrid window.

How accurate is the AVD sizing produced by the migration test?

Published target is ±5% host-pool right-sizing accuracy, compared against ±40% typical of spreadsheet sizing models. Numbers come from per-host measured concurrency on real ARM-discovered Host Pools.

How long is a Horizon → AVD migration testing engagement?

The engagement begins with a baseline of Horizon and a pilot AVD pool, then promotes wave-by-wave behind validation gates. Exact timeline depends on AVD scale and operational readiness — we’ll size it on the discovery call. LoadGen Services (consulting + managed runs) is available where in-house bandwidth is tight.

What does Horizon → AVD migration testing cost?

Load Testing is €1,099 per week at the 50-vUser tier; End-to-End Monitoring is €899 per Agent per month (annual subs include two months free). Migration engagements typically combine both modules + LoadGen Services for the cutover window.

LoadGen Official Logo