Microsoft has confirmed that Azure Virtual Desktop (classic) will reach end of life on September 30, 2026, after which it will no longer be supported. Organizations still running the older platform must migrate to the current Azure Resource Manager-integrated version to maintain service continuity and receive security updates.

The Clock Is Ticking: What’s Changing?

Azure Virtual Desktop (classic) was the original Fall 2019 release of the service. Unlike the modern ARM-integrated version, it operated outside Azure Resource Manager, with separate management blades and limited integration. Microsoft began blocking new classic tenants in September 2023, and the final support cutoff is now firm: September 30, 2026.

After that date, the service won’t just lack support—it will stop working. You won’t be able to create new session hosts, access existing ones, or manage any classic resources. According to Microsoft’s retirement Q&A, the only path forward is migration to the Azure Resource Manager-integrated Azure Virtual Desktop.

Not All Migrations Are Equal: Assessing Your Current Setup

The first challenge is simply knowing what you have. Many organizations adopted Azure Virtual Desktop early and may have classic host pools lurking in their environments, especially if they haven’t touched the configuration in years. Because the Azure portal has evolved, a modern-looking resource view doesn’t guarantee there are no classic remnants.

Classic deployments don’t show up in the standard Azure Virtual Desktop portal experience. To find them, you need to:
- Check the dedicated “Azure Virtual Desktop (classic)” blade (if still accessible in your portal).
- Use PowerShell cmdlets from the old Microsoft.Azure.Management.DesktopVirtualization module.
- Review billing data for classic-related resource charges.
- Interview service owners and check support records.

Once identified, each classic host pool must be inventoried in detail: owners (technical and business), user assignments, published RemoteApps and desktops, session host counts and states, profile dependencies, and the Conditional Access policies that govern access. Anything less is guesswork, and guessing during a retirement migration is a recipe for user disruption.

Two Paths Forward: Automated Migration or Parallel Rebuild

Microsoft provides an automated migration tool—a set of PowerShell commands that move metadata from classic to ARM-integrated Azure Virtual Desktop. It became generally available in January 2022 and is the company’s recommended first option.

But the tool isn’t magic. Microsoft’s own guidance warns that “complex configurations or environments with many users can require substantial manual work.” If your deployment has fragile RemoteApp dependencies, deeply nested access policies, session host drift, or unpublished customizations, an automated migration may cause as many problems as it solves.

This is where a parallel rebuild comes in. Instead of transforming the existing classic environment in place, you stand up a completely new ARM-integrated host pool alongside the old one. You then move users in controlled waves, testing every aspect of their experience before decommissioning the classic side. This approach isolates risk and gives you a clean slate for modern configurations—new image baselines, updated policies, and alignment with current best practices.

The choice comes down to a single question: how well do you understand your current deployment? If you have complete documentation, limited complexity, and owners who can sign off on changes, automate. If any part of that equation is shaky—or if the host pool is critical to the business—rebuild.

Making the Move Without Disrupting Users

Microsoft recommends moving “session hosts and users in small groups to reduce disruption.” That advice works whether you’re automating or rebuilding. The process begins with a pilot group of representative users who cover the full range of applications, devices, and access patterns.

A pilot must prove more than just that the remote desktop loads. You need concrete pass/fail criteria:
- Each pilot user sees exactly the assigned desktops and RemoteApps.
- Authentication applies expected multi-factor authentication, device compliance, and location checks.
- Sessions launch reliably through the approved client.
- User profiles load correctly and persist (or don’t persist) according to design.
- Every critical application completes a representative transaction.
- Network paths to storage, databases, and line-of-business systems remain reachable.
- Logon time and interactive responsiveness stay within agreed tolerances.
- Support staff can identify user sessions, hosts, and failure points.
- A documented rollback can be executed within a defined window.

Only after the pilot passes these gates—and gets explicit approval from the named technical and business owners—should you begin moving production users. Each subsequent wave should be small enough that, if something breaks, you can roll back before widespread impact.

Rollback isn’t a vague concept; it’s a measurable trigger. If a critical application workflow fails, profiles corrupt, or feed assignments go haywire, the team must immediately revert users to the classic environment, which you’ve deliberately kept operational. The classic side stays in place until the very last user is validated on the new platform.

Your To-Do List: Steps to Take Right Now

Even with two years to go, procrastination is the enemy. The operational burden of a migration doesn’t shrink by waiting; it amplifies as memories fade, staff turn over, and undocumented dependencies pile up.

Start with these six actions:

  1. Inventory everything. Use PowerShell, portal checks, and billing audits to find every classic host pool. If you discover any pool with no known owner, assign one immediately.
  2. Assign a disposition to each pool. Decide whether it will be migrated, rebuilt, retired (if unused), or held for investigation. Don’t let “unknown” pools fester.
  3. Gather the minimum evidence set. For each active pool, document the owner, user/group assignment export, published app list, host count and state, profile configuration, relevant Conditional Access policy IDs, and a list of test users.
  4. Choose your migration path. If the pool is simple and well-understood, plan for automation. If not, start designing the parallel rebuild: new ARM host pools, application groups, workspaces, and session hosts.
  5. Define rollback and approval criteria. Before moving a single user, agree on what constitutes a failure that triggers a rollback, and who has the authority to approve each wave’s cutover.
  6. Schedule the pilot. Identify a week when representative users can test thoroughly, and make sure support staff are briefed on what to watch for.

Only after all these steps are complete should you run a migration script or begin building parallel resources. The goal isn’t speed; it’s a successful user experience on Day One after the cutover.

Looking Ahead

Migrating off classic isn’t just a compliance exercise; it’s an opportunity to modernize. Azure Resource Manager-integrated Azure Virtual Desktop has evolved rapidly since 2020, adding features like RDP Shortpath for better network performance, multimedia redirection, new Microsoft Teams optimizations, and enhanced security through Conditional Access and managed identities. Classic users missed out on all of this.

By completing the migration well before September 2026, you position your virtual desktop environment to take advantage of everything the current service offers—and avoid the last-minute scramble that invariably leads to mistakes. The deadline is real, but it’s also generous if you start now. The organizations that treat it as a long-term project with clear milestones will be the ones that transition without a hitch.