The core difference between Azure Virtual Desktop and Windows 365 is the shape of the cost, not just the size of it. Azure Virtual Desktop is variable infrastructure spend: you pay for the compute, storage, images and profiles you run, and you carry the operational time to size, patch and monitor it. Windows 365 is a flat, predictable per-user, per-month licence with the underlying infrastructure managed for you. That makes an AVD to Windows 365 migration less a like-for-like price swap and more a choice about which cost model fits each part of your estate. Personal desktops usually compare naturally to Windows 365 Enterprise, intermittent and shift-based users to Windows 365 Flex, while high-density multi-session and GPU workloads often stay on AVD. The reliable way to decide is a directional comparison per cohort, then a piloted migration in waves.
The two cost models, side by side
Azure Virtual Desktop is a highly flexible virtualisation service where you pay only for what you use on consumption-based pricing, and it can lower operating-system overhead by running Windows multi-session so several users share a host. That flexibility is genuinely valuable, but it means the bill moves with your choices: VM sizes, how much host capacity you keep running, storage, and the images and profiles behind it all.
Windows 365 takes the opposite approach. Cloud PCs are billed in a per-user, per-month model, which Microsoft designs specifically so that organisations do not have to manage the variability of compute and storage costs that come with a traditional hosted desktop. Neither model is inherently cheaper. The question in any Azure Virtual Desktop vs Windows 365 cost exercise is which shape of spend, variable and tunable, or flat and predictable, fits a given cohort better.
Where AVD costs hide
The published rate card is the easy part. When organisations find their AVD number higher than expected, it is usually because of costs that do not appear as a single obvious line.
- Host pool headroom. To meet peak demand without degrading the experience, pooled deployments keep spare capacity running. That headroom is real compute you pay for even when it is idle between peaks.
- Image and profile management. Golden images need building, patching and versioning, and user profiles need somewhere to live and stay performant. This is ongoing work and ongoing storage, not a one-off.
- Monitoring and operations overhead. Scaling automation, patching, diagnostics, and day-to-day break-fix all take engineering time. That operational effort is a true part of Windows 365 TCO comparisons even though it never shows on the invoice.
None of this makes AVD the wrong choice. It is a powerful platform. It simply means a fair comparison has to count the operational time and the always-on capacity, not just the on-demand compute.
Personal vs pooled: the decision that drives the comparison
The single most useful cut through the numbers is whether a cohort uses personal or pooled desktops, because that determines the natural Windows 365 comparison.
Personal, dedicated desktops map cleanly to Windows 365 Enterprise, where each user has a one-to-one relationship with their own Cloud PC, their own persistent Windows environment in the cloud. If someone needs their desktop to be theirs all day, every day, that is the like-for-like comparison.
Pooled, intermittent and shift-based usage maps instead to Windows 365 Flex. Flex provides a single licence to provision Cloud PCs for non-concurrent use, aimed at people who need Cloud PC access for a limited part of the day. It suits rotation schedules, part-time and contingent staff, and customer-facing or shift patterns where not everyone is active at once. That is the cohort where a flat per-user licence and lower concurrency can line up well.
Match each cohort by usage pattern: personal desktops to Windows 365 Enterprise, pooled and shift work to Windows 365 Flex, high-density multi-session and GPU to AVD.
Moving with the Windows 365 migration capability
Microsoft has made the Windows 365 migration API generally available, moving it out of preview. It is a REST-based interface, built on the Microsoft Graph API and integrating with Microsoft Intune, that lets partners and customers migrate Azure-based virtual machines into Windows 365 Cloud PCs with less manual effort. It works by taking a snapshot of a prepared virtual hard disk and using that to provision a Cloud PC for the target user.
It is worth being precise about what the capability does and does not cover today, because the boundaries shape planning. The migration API targets persistent, single-session virtual machines: it supports Entra joined and Entra hybrid joined Azure VMs, uses snapshot-based provisioning rather than image imports, and provisions into Windows 365 Enterprise Cloud PCs. At the time of writing it is available in the commercial cloud first, with government cloud and GPU scenarios flagged for future phases, and it comes with practical requirements such as Gen2 VMs, an OS disk only, third-party agents removed, and one imported disk per user at a time. The takeaway is that it streamlines the lift for personal, single-session desktops. Pooled multi-session host pools are a redesign rather than a snapshot-and-move, so plan those as new Windows 365 or Flex builds instead.
When AVD remains the right answer
Moving is not always the goal, and part of a credible plan to move from AVD to Windows 365 is being honest about the cohorts that should stay. AVD tends to remain the stronger fit when:
- High-density multi-session economics dominate. Where many users share Windows multi-session hosts efficiently, the per-user cost of that shared infrastructure can be very hard to beat with per-user licences.
- GPU workloads are involved. Graphics-intensive users often need GPU-backed hosts, which AVD supports and which the Windows 365 migration path does not yet cover.
- Demand is bursty or scheduled. Where usage spikes and troughs sharply, consumption-based billing plus scaling automation can track demand more tightly than a flat per-user licence, and the control AVD gives over sizing and customisation is worth keeping.
The right estate is often a mix: personal and shift-based cohorts on Windows 365, and specific high-density or GPU workloads left on a leaner, well-run AVD footprint.
A migration flow that de-risks the move
A dependable AVD to Windows 365 migration follows a sequence rather than a single leap:
- Assess the estate. Capture what you actually run: hosts, sizes, images, profiles, usage patterns and the operational effort behind them.
- Segment personal versus pooled. Split cohorts by dedicated and shared usage, since that decides the Enterprise versus Flex comparison, and flag the multi-session and GPU workloads that may stay on AVD.
- Run a directional cost comparison. Compare each cohort's current AVD cost, including headroom and operations, against the equivalent Windows 365 model. Treat every figure as directional and build it from your own estate.
- Pilot. Move a representative group first, validate the experience and the real running cost, and confirm the migration approach.
- Migrate in waves. Roll cohorts across in controlled waves, using the migration capability for persistent desktops and fresh builds for pooled scenarios.
- Decommission. Retire the AVD capacity a wave no longer needs, so you stop paying for infrastructure the migration has replaced.
An Intune reporting tool helps keep device readiness, enrolment, update, and compliance evidence visible during each migration wave.
Where EtherInsights fits
The hard part of this is not the theory, it is producing numbers you trust for your specific estate and then executing without surprises. EtherInsights helps translate a messy AVD footprint into clear cohorts, showing where personal desktops, shift-based users and multi-session workloads actually sit, and giving the evidence to plan the move with confidence rather than assumption.
From there, Windows 365 migration turns that picture into a sequenced, waved plan with the day-two operating cost in view. Because every comparison here is directional, the sensible next step is to run your own directional numbers against your real cohorts rather than a generic average, and to fold the result into wider cloud cost optimisation so the desktop estate keeps paying only for the work it supports.
Get the model right per cohort and the migration stops being a gamble on a single average. It becomes a set of grounded, evidence-backed decisions.
Explore Windows 365 migration to move the right cohorts, keep the right ones on AVD, and prove the cost either way.