Azure Virtual Desktop (Classic) Retires September 30, 2026: Migration Checklist Before Connections Get Blocked

Azure Virtual Desktop (classic) retires September 30, 2026. After that date, connections to any remaining classic host pools are blocked outright, not degraded, blocked. If you still have classic AVD resources in production, this is not a “get to it eventually” item, the deadline is days away as of this writing, and the migration itself needs real planning, not a same-day scramble.

What actually happens on the retirement date

This isn’t a soft deprecation with a grace period. Microsoft’s own guidance is explicit: connections to classic AVD resources will be blocked after retirement. Any host pool, application group, or workspace still running on the classic (pre-ARM) architecture stops accepting connections entirely once the date passes. Users lose access, not gradually, but immediately.

Do you still have classic resources? Check now

Classic AVD (built on the original, pre-Azure Resource Manager architecture from Windows Virtual Desktop’s original release) is distinct from the current ARM-based host pool model most environments have been on for years. If your environment was provisioned recently, you likely have nothing to migrate, but don’t assume, verify:

# List AVD host pools and confirm they're ARM-based (modern) resources
Get-AzWvdHostPool | Select-Object Name, ResourceGroupName, HostPoolType

# Classic resources won't appear via the modern Az.DesktopVirtualization module
# at all in some cases, if you have any doubt, check the Azure portal directly
# under Azure Virtual Desktop > any "classic" labeled resource group or workspace

If you find nothing, and your environment has been on modern host pools since initial deployment, this retirement doesn’t affect you directly. If you find classic resources, or you’re not fully certain your environment never had any, treat verification as the first urgent step, not the migration itself.

Two real migration paths, and how to pick between them

Microsoft provides an automated migration tool, a set of PowerShell commands that moves metadata from classic host pools directly into ARM-integrated Azure Virtual Desktop, available since it became generally available in 2022. This is the recommended first option specifically for straightforward, well-documented host pools without unusual complexity.

For more complex environments, extensive RemoteApp publishing, large user populations, fragile or highly customized access policies, or configurations that took months to originally stabilize, a parallel ARM-integrated rebuild is the more reliable path rather than trusting the automated tool to preserve every nuance of a complex, organically-grown deployment.

Before running any migration: inventory first, don’t guess

Every classic host pool needs a real inventory before migration, not an assumption based on memory of how it was originally set up:

• Technical and business owners for each host pool.
• User and group assignments currently in effect.
• Published RemoteApps and full desktops, and exactly which users/groups can reach each one.
• Session host counts and their current health/state.
• Profile dependencies (FSLogix configuration, profile container locations).
• Conditional Access policies specifically governing access to this AVD deployment.

Guessing at any of these during a retirement-driven migration is how users lose access to something they needed, or end up with broader access than intended, discovered only after the fact. Build the inventory first, then plan the migration against it.

Exemptions, if you genuinely can’t make the deadline

Environments with more than 500 application groups, or genuinely complex multi-tenant configurations, can request an exemption from Microsoft rather than being forced into a rushed migration against an immovable deadline. This is not a casual opt-out, but if your environment is large and complex enough to hit that threshold, requesting an exemption and migrating properly is a better outcome than a rushed migration that breaks something for a large user population.

Frequently asked questions

If I’m past the point where I can safely migrate before September 30, what happens?
Users lose the ability to connect to any remaining classic resources once the retirement date passes, this is not a delayed or soft cutoff. If you’re genuinely at risk of missing the deadline, prioritize the inventory and migration for your highest-impact host pools immediately, and evaluate whether your environment qualifies for an exemption rather than assuming there’s flexibility in the date itself.

Does the automated migration tool preserve Conditional Access policies and FSLogix profile configuration automatically?
The automated tool migrates host pool metadata, but Conditional Access policies and profile configuration depend on how your specific environment has them structured, verify these specifically after running the automated migration rather than assuming full preservation, this is exactly the kind of detail the pre-migration inventory should already have documented so you have something concrete to verify against.

How do I know if a specific host pool is “simple enough” for the automated tool versus needing a parallel rebuild?
Host pools with straightforward, well-documented configurations, standard RemoteApp publishing, conventional access policies, moderate user populations, are generally good candidates for the automated path. Environments with extensive customization, unusual access policy chains, or configurations nobody fully remembers the original reasoning behind are better served by a parallel rebuild where you can verify each piece deliberately rather than trusting an automated tool to correctly interpret years of accumulated configuration decisions.