From terminal server to Azure Virtual Desktop

A classic terminal server farm is a fixed number of rooms in one building. However many desks you bought at deployment time is however many you have, whether it’s a quiet Tuesday in August or the one week in December when every seasonal worker logs on at once. You either overbuilt for the quiet months or you run out of rooms in the busy one.

That’s the actual problem, not that RDS is old technology. Plenty of RDS farms still run fine technically. What they can’t do is flex, and flexing is exactly what the business needs now that remote and hybrid work aren’t an exception anymore.

We still find these farms everywhere, usually aging alongside the hardware they were built on. Nobody planned to still be running Server 2016 session hosts on hardware that’s five years past its refresh cycle. It happened because the farm worked well enough for long enough that replacing it never became urgent, until a hardware failure or a Windows Server end-of-support date forces the question.

Azure Virtual Desktop solves the same underlying need, remote access to a full desktop or specific applications, but the compute exists only when someone’s using it. Session hosts scale out for the morning login rush and scale back down overnight, instead of sitting fully provisioned around the clock for a peak that happens twice a day.

How the move actually works

AVD is a management plane, not a virtual machine you buy once and forget. The session hosts are Azure VMs you control, joined to Entra ID, and everything else, the pool, the workspace, the app groups, is orchestration on top. The parts worth understanding before you start:

• Pooled versus personal. A pooled host pool puts multiple users on one multi-session Windows 11 VM, which is cheaper per user and right for standard office work. A personal host pool gives each user a dedicated VM, which costs more but is what you need for workloads that require persistent local state or local admin rights.
• FSLogix for profiles. User profiles live in FSLogix containers on Azure Files or a file share, not on the session host itself, which is what lets a pooled session survive a host reboot or a scale-in event without losing the user’s settings.
• Autoscale, not always-on. Scaling plans ramp session hosts up and down on a schedule or based on load, which is the actual mechanism behind most of the cost saving compared to a farm that’s fully provisioned all day.

In practice, a migration starts with an application assessment, not a lift and shift of the whole farm. Some apps run fine unmodified in a multi-session pool. Some need FSLogix app masking or an isolated personal pool because they weren’t built to be multi-user aware. Finding that out during planning is a lot cheaper than finding it out after go-live.

What this costs

AVD itself has no separate licence fee. What you pay for is the Windows entitlement and the Azure consumption underneath it. A user needs Windows 11 Enterprise multi-session rights, which come through Microsoft 365 E3, E5 or Business Premium, or through a Windows VDA licence if a full Microsoft 365 SKU doesn’t make sense for that user. On top of that, the Azure VM compute, storage for FSLogix profiles, and any networking cost, the same consumption model as any other Azure resource, and the same reservation and savings plan trade-offs apply, size for actual usage before committing to a discount, not the other way around.

The trade-off runs both directions. A pooled multi-session desktop is genuinely cheaper per user than a personal VM, but it means shared resource contention during peak hours, which shows up as sluggish performance if the pool is undersized for the login pattern. A personal desktop avoids that entirely, at close to the cost of a small always-on VM per user, which stops making sense once you’re provisioning it for more than a handful of people with genuinely special requirements.

What I’d actually recommend

Default to pooled Windows 11 multi-session with autoscale for standard office users, that’s where AVD earns its cost advantage over a legacy farm. Reserve personal host pools for the specific roles that actually need persistent local state, not as the default because it feels safer. Run the application assessment before touching a single session host, because the apps that don’t behave in a multi-session environment are the ones that turn a straightforward migration into a support ticket queue. And retire the old farm on a schedule, not on the day the hardware finally fails, because that’s when the migration gets rushed and the cost analysis gets skipped entirely.