Azure Virtual Desktop Classic: Migrate Before September 30, 2026

Azure Virtual Desktop (classic) retires on September 30, 2026, and most organizations should not treat the deadline as a one-click control-plane upgrade. Use Microsoft’s automated migration for straightforward, documented host pools; choose a parallel Azure Resource Manager-integrated rebuild for complex environments with extensive RemoteApp publishing, large user populations, fragile access policies, or configurations that took months to stabilize.
Microsoft states in its Q&A retirement guidance that Azure Virtual Desktop (classic) will no longer be supported after the cutoff and directs customers to migrate to Azure Resource Manager-integrated Azure Virtual Desktop. The immediate task is to identify every classic host pool, assign an accountable owner, and decide whether each workload should be migrated, rebuilt, retired, or investigated.
The following matrix is WindowsForum’s operational recommendation. Microsoft specifically recommends migrating in small groups and cautions that complex configurations or environments with many users can require substantial manual work.

Deployment characteristic	Recommended path	Why	Minimum cutover method
Well-documented, limited complexity, understood assignments	Automated migration	Minimizes rebuilding when Microsoft’s current eligibility rules are met	Representative pilot, staged user groups, owner approval
Complex RemoteApps, fragile policies, high user count	Parallel rebuild	Isolates change from the working environment	New modern resources, pilot hosts, wave-based reassignment
Obsolete or unused workload	Retire	Avoids migrating unnecessary cost and risk	Confirm no active users, obtain owner approval, preserve required records
Unknown owner, dependencies, or usage	Investigate	Migration without evidence can break an unidentified service	Hold changes until ownership and test coverage are established

Find Classic Host Pools Before Planning the Move​

Azure Virtual Desktop with Azure Resource Manager integration became generally available in July 2020. The earlier Fall 2019 release was subsequently designated Azure Virtual Desktop (classic).
The reliable distinction is that classic does not use the current Azure Resource Manager-integrated model. Microsoft’s retirement Q&A distinguishes the classic and Azure Resource Manager experiences, so administrators should not assume that a view of modern AVD resources proves no classic deployment remains.
Use Microsoft’s automatic migration guidance, classic-environment records, billing data, support records, and service-owner interviews to establish the inventory. Portal labels and navigation can change; in the current Azure portal experience, reconcile findings with the Azure Virtual Desktop views for host pools, application groups, workspaces, and session hosts.
Do not build an oversized discovery workbook that nobody can finish. Create one downloadable-style evidence record per host pool containing this minimum set:

Required evidence	What to capture
Owner	Named technical owner and accountable business owner
User/group assignment export	Current users and Microsoft Entra groups, with export date
Published app list	Desktops and RemoteApps visible to users
Host count and state	Total hosts and whether each is available, unavailable, draining, or otherwise impaired
Profile dependency	Profile technology, storage location, and responsible team
Conditional Access policy IDs	Policy identifiers affecting AVD access—not only policy names
Test users	Representative users covering applications, devices, locations, and access conditions
Rollback trigger	Measurable condition that stops or reverses cutover
Approval owner	Person authorized to accept production or invoke rollback

Similar names in classic and modern environments do not establish that a workload was migrated. Evidence must connect the users, published resources, hosts, profiles, policies, and approval chain.
WindowsForum user reports about managed service providers moving Citrix workloads to AVD reinforce the operational point: the control plane is only one part of a usable desktop service. Other WindowsForum lifecycle discussions, including the reported NVv4 retirement, are useful prompts to inspect VM sizing and application compatibility separately. They do not change the AVD classic retirement scope or prove that a particular host pool is ready to move.

Separate Control-Plane Migration From Workload Validation​

A reported successful migration operation is not production validation. Production acceptance requires evidence that users can discover the correct resources, authenticate under the expected policies, launch required desktops or RemoteApps, load the right profile, and reach necessary network services.
Use the minimum evidence set as the baseline, then run a concrete pilot with pass/fail criteria:

• Feed discovery: Pass only if every pilot user sees exactly the assigned desktop and RemoteApps, with no missing or unintended resources.
• Authentication: Pass only if expected multifactor authentication, device, location, and sign-in controls apply; record the relevant Conditional Access policy IDs.
• Session launch: Pass only if each test user can establish a session through the approved production client without repeated or unexplained failures.
• Profiles: Pass only if the expected profile loads and a test change persists—or intentionally does not persist—according to the documented design.
• Applications: Pass only if every business-critical application launches and completes a representative transaction or workflow.
• Network dependencies: Pass only if required storage, databases, line-of-business endpoints, printing, and management paths are reachable.
• User experience: Pass only if logon time and interactive behavior stay within the service owner’s preapproved tolerance.
• Operations: Pass only if monitoring detects the pilot sessions and support staff can identify the user, host, application group, and failure path.
• Rollback: Pass only if the team can execute the documented rollback before the approved window expires.
• Approval: Pass only when the named technical and business approval owners sign the pilot record.

A single failure does not always require abandoning the migration, but it must produce an owner, remediation action, retest result, and explicit exception approval. “Command completed” is never an acceptance criterion.

Use Microsoft’s Automated Migration Only Within Its Current Scope​

Automated migration is appropriate when the classic inventory is complete, assignments are understood, published resources can be mapped without redesign, and a representative pilot group can test the result.
Microsoft establishes that automated migration uses PowerShell, but administrators should obtain the current commands, parameters, supported operation values, permissions, eligibility rules, and prerequisites directly from the current Microsoft procedure. Do not copy an unverified command template from a forum post or assume that an older module example remains valid.
Before making changes, confirm in Microsoft’s current automatic-migration documentation:

• Whether the specific classic host pool is eligible.
• Which identities and Azure permissions are required.
• Which PowerShell components and versions Microsoft currently supports.
• Which target-resource decisions must be made in advance.
• What the operation migrates and, equally important, what remains outside its scope.
• How Microsoft defines start, monitoring, completion, failure, and recovery for the current process.
• What actions could affect existing host registrations, assignments, or rollback options.

WindowsForum’s editorial recommendation is to use automation only when every pool has an owner and disposition, desktop and RemoteApp assignments are documented, existing hosts remain suitable, access-policy changes can be tested safely, and the classic environment can remain available through a defined rollback window.
After the documented operation, inspect the resulting Azure Resource Manager-integrated resources in the current Azure Virtual Desktop portal experience. Verify host pools, application groups, workspace associations, assignments, and registered session hosts. Because portal navigation and labels can evolve, use Microsoft’s current interface documentation rather than treating any fixed click path as permanent. Then complete the pilot acceptance checklist through the real client and feed.

Parallel Rebuilds Reduce Risk in Fragile Environments​

A parallel Azure Resource Manager-integrated rebuild is safer when the existing deployment is difficult to explain, reproduce, or support. Microsoft cautions that advanced configurations and environments serving many users can require complex manual work. The decision to prefer a rebuild in those cases is WindowsForum’s operational recommendation, not a Microsoft mandate.
The rebuild path creates modern host pools, application groups, workspaces, assignments, and session hosts beside classic production. Coexistence temporarily costs more, but it creates a clean testing boundary and avoids restructuring the only working environment.
Prefer a parallel rebuild when several of these conditions apply:

• The pool serves a large or operationally critical population.
• RemoteApp publishing contains undocumented dependencies.
• Session-host drift makes existing machines difficult to trust.
• Assignments are inconsistent or tied to legacy practices.
• Conditional Access requires substantial redesign.
• Images, profiles, networking, or management tooling must change.
• No credible rollback route exists.
• The migration is also becoming a VM-family or application-platform redesign.

Decide separately whether existing session hosts can be reused or clean hosts should be deployed. Consult Microsoft’s current manual migration guidance before changing registrations, assignments, or virtual machines. The detailed contents of that linked procedure are not reproduced or independently verified here, so administrators must confirm its current requirements and supported actions directly.
WindowsForum users discussing Citrix-to-AVD projects describe the same need for parallel validation: publishing an application is not enough if identity, profiles, networking, client behavior, or support procedures fail. Likewise, WindowsForum’s NVv4 retirement report is a reason to review GPU dependencies, but VM-family migration requires its own design, compatibility evidence, and rollback plan.

Staged Cutover Keeps the Working Environment Intact​

Microsoft recommends moving session hosts and users in small groups to reduce disruption. Apply that guidance whether the chosen path is automated migration or a parallel rebuild.
A practical sequence is:

1. Identify every classic pool and assign an owner, approval owner, risk rating, and disposition.
2. Complete the minimum evidence set, including assignment exports and Conditional Access policy IDs.
3. Create or migrate the modern host pool, application groups, workspace association, and required assignments using the current Microsoft procedure.
4. Keep working classic access intact unless Microsoft’s documented method requires a specific change.
5. Prepare suitable pilot capacity and named test users.
6. Run the acceptance checklist and record each result as pass, fail, or approved exception.
7. Stop if the documented rollback trigger is reached.
8. Expand through controlled waves while retaining enough capacity and time to reverse the move.
9. Freeze avoidable configuration changes before the final wave.
10. Obtain technical and business approval before removing classic configuration.

Define rollback before moving the first user. For a parallel rebuild, rollback may mean restoring the classic assignment and returning users to capacity deliberately kept available. If a planned action changes host registration, assignments, or available capacity, verify its consequences in Microsoft’s current documentation before proceeding.
Rollback triggers should be measurable. Examples include failure of a critical application workflow, profile corruption affecting any pilot user, widespread feed-assignment errors, an access-policy result that differs from the approved design, or session-launch failure beyond the owner’s stated tolerance. Avoid vague triggers such as “poor experience.”

Retirement Reporting Must Track User Experience​

Track discovery, evidence completion, owner approval, object creation, workspace association, session-host state, identity assignments, Conditional Access testing, pilot acceptance, production cutover, rollback expiry, and classic decommissioning as separate milestones.
Adjacent Azure lifecycle risks should remain separate workstreams. A VM reservation, GPU-family retirement, image change, or application upgrade may influence migration planning, but none proves that the AVD control-plane migration is complete. If multiple changes must coincide, give each one its own owner, evidence, acceptance criteria, and rollback decision.
Any pool still marked “unknown owner,” “testing,” or “operation completed” near the retirement date remains an operational risk. Escalate it to both the Azure platform owner and the business owner whose users depend on the service.
By September 30, 2026, the meaningful metric will not be how many classic entries disappeared. It will be how many users can reach the required applications, profiles, and network resources through Azure Resource Manager-integrated Azure Virtual Desktop—with tested policies, visible ownership, recorded approval, and a rollback path retired deliberately rather than lost accidentally.

Frequently Asked Questions​

When does Azure Virtual Desktop (classic) retire?​

Microsoft’s Q&A retirement guidance gives September 30, 2026 as the retirement date.

Should every classic host pool use automated migration?​

No. WindowsForum recommends automated migration for eligible, well-understood deployments and a parallel rebuild for complex or fragile environments. Confirm eligibility and current prerequisites in Microsoft’s automatic-migration documentation.

Where should administrators validate the migrated resources?​

Inspect the current Azure Virtual Desktop portal views for host pools, application groups, workspaces, assignments, and session hosts. Portal labels can change, and portal objects are only part of validation; users must test the actual client, feed, applications, profiles, policies, and network paths.

Does a successful migration command mean the workload is finished?​

No. Production completion requires the pilot acceptance criteria to pass and the named technical and business owners to approve the result.

What should happen first?​

Inventory every classic host pool and complete the minimum evidence set: owner, user/group assignment export, published app list, host count and state, profile dependency, Conditional Access policy IDs, test users, rollback trigger, and approval owner. Then assign one of four dispositions: automate, rebuild, retire, or investigate.

---

References​

1. Primary source: learn.microsoft.com
   
   

   What's new in Azure Virtual Desktop? - Azure - Azure Virtual Desktop | Microsoft Learn

   Learn about new features and product updates for Azure Virtual Desktop.

   learn.microsoft.com
2. Primary source: WindowsForum
   
   

   Azure Reserved VM Instance Cutoff July 1, 2026: Migration Deadline for Legacy SKUs | Windows Forum

   Microsoft will stop new purchases and renewals of Azure Reserved VM Instances for select older virtual-machine series on July 1, 2026, affecting one-year...

   windowsforum.com

 

[ChatGPT]

Azure Virtual Desktop (classic) retires on September 30, 2026, and every classic host pool should now be routed deliberately to automated migration, a parallel ARM-integrated rebuild, retirement, or investigation—not pushed through a tool simply because a deadline is approaching.
WindowsForum’s classic-retirement coverage has stressed that this is not a one-click control-plane upgrade. Microsoft provides a PowerShell-based automatic migration capability, but the useful question is whether a particular host pool is understood well enough to use it safely. A simple pooled desktop with documented profiles and assignments is not the same project as a heavily customized RemoteApp service with undocumented scripts.
The current Azure Virtual Desktop platform uses Azure Resource Manager integration, Azure portal management, and Azure RBAC delegation rather than the separate administrative approach used by classic. That makes the retirement deadline an operational triage exercise: identify what users receive, who owns it, how it is managed, and how the service can be recovered if cutover fails.

Build the Host-Pool Scorecard Before Selecting a Route​

Create one scorecard row for every classic host pool. Include its application groups, user population, desktop or RemoteApp delivery, session-host image, profile behavior, access groups, administrative roles, scheduled tasks, scripts, pipelines, and rollback plan.
Score each factor from 0 to 2:

• 0 / Green: Documented, tested, and routine.
• 1 / Amber: Known but requires work or limited validation.
• 2 / Red: Complex, fragile, or materially customized—but still understood and owned.

Three conditions are hard stops, regardless of total score:

1. Unknown owner: No named business owner and support owner can approve the route.
2. Unknown automation: A script, runbook, scheduled task, or pipeline may affect the pool, but its purpose or accountable maintainer is unknown.
3. Untested rollback: The team cannot explain and test how users would return to a working service after a failed cutover.

Any hard stop sends the pool to Investigation. Do not average an unknown out of the score.

Factor	0 — Green	1 — Amber	2 — Red
Delivery design	Simple pooled desktop or limited, standard publishing	Mixed delivery or a few special cases	Complex RemoteApps, many exceptions, or fragile user workflows
Identity and access	Groups, assignments, and Azure RBAC responsibilities are documented	Some access cleanup or role redesign is needed	Delegation and access dependencies are complex but understood
Profiles and user data	Profile creation, attachment, recovery, and validation are documented	Known issue or dependency requires testing	Complex storage, permissions, or recovery behavior
Automation	No automation, or owned automation is minimal and documented	Scripts need revision or replacement	Multiple maintained scripts or integrations affect operations
Image and host condition	Consistent, maintained image; little manual drift	Some drift or application cleanup required	Significant customization, drift, or one-off application dependencies
User impact and testability	Pilot group is available and business impact is manageable	Broader pilot coordination is needed	Sensitive or high-impact service requiring extensive pilot coverage
Rollback readiness	Rollback is documented and successfully tested	Rollback is documented but needs a rehearsal	Rollback is possible but complex and has known constraints

Exact Routing Thresholds​

Apply the routing rules in this order:

1. Retirement: Route to retirement when the accountable application owner confirms there is no continuing business requirement, required data can be retained or exported, and a final-access date is approved. This route takes precedence over the numerical score.
2. Investigation: Route to investigation if any hard stop exists: unknown owner, unknown automation, or untested rollback. Also use investigation if the scorecard cannot be completed with evidence.
3. Automated migration: Route to automated migration only when the total score is 0–4, no factor is red, all hard-stop conditions are cleared, and the workload remains required.
4. Parallel ARM-integrated rebuild: Route to rebuild when the total is 5–14, or when one or more factors are red but understood, all hard-stop conditions are cleared, and the workload remains required.

The score does not replace judgment. It makes the judgment reviewable. A complex but well-understood RemoteApp pool can be rebuilt safely; an apparently simple pool with an ownerless script cannot be migrated safely until that unknown is closed.

Fillable Scorecard With Representative Examples​

Use this table as a working template. Replace the example notes with evidence from your own inventory.

Host pool	Delivery	Identity	Profiles	Automation	Image	User impact	Rollback	Total	Hard stop?	Route	Evidence / next action
Simple pooled desktop	0	0	1	0	0	1	1	3	No	Automated migration	Validate profile behavior and rehearse rollback with a pilot group.
Complex RemoteApp service	2	1	2	1	2	2	1	11	No	Parallel rebuild	Recreate application groups, assignments, roles, profiles, and launch behavior in a target environment.
Abandoned low-use pool	1	0	1	0	1	0	1	4	No	Retirement, if owner signs off	Confirm the application is no longer required, export required data, and approve a final-access date.
Ownerless, script-dependent pool	1	1	1	2	1	1	2	9	Yes: owner, automation, rollback	Investigation	Assign owners, identify every script and its effect, then test a rollback procedure before rescoring.

The abandoned pool example is important. Low session counts alone do not prove a workload is disposable; a lightly used service may support payroll, reporting, emergency response, or a specialist application. Retirement requires owner approval and an explicit data and access plan, not an assumption based on usage.

A One-Page Decision Workflow​

1. Inventory every classic host pool​

For each pool, identify the business owner, support owner, user groups, application groups, delivery type, session hosts, image source, profile and user-data dependencies, administrative access, and every automation component.
Specifically collect scheduled tasks, PowerShell scripts, runbooks, pipelines, and monitoring or provisioning integrations. Record who owns each item, where its source is maintained, and whether it depends on the classic environment.

2. Complete the scorecard and clear hard stops​

Score the seven factors using evidence, not memory. If an owner is missing, automation is unknown, or rollback has not been tested, stop route selection and open an investigation work item.
WindowsForum readers have repeatedly raised the practical issue behind this step: the technical migration may be manageable, while the undocumented operational dependency is what causes the outage. The scorecard is meant to find those dependencies before a production window.

3. Follow the selected route​

Automated migration route​

Use this route only for scores of 0–4 with no red factors and no hard stops.

1. Complete the inventory and preserve the scorecard evidence.
2. Run a nonproduction migration or equivalent test against a representative workload.
3. Validate assigned users, published desktops or RemoteApps, profile behavior, and Azure RBAC delegation.
4. Confirm that support staff can perform routine administration and resolve a basic user issue.
5. Rehearse the rollback plan.
6. Obtain business-owner approval and schedule cutover.
7. Monitor the first production users and document the final operational handoff.

Microsoft’s PowerShell-based automatic migration capability is useful here because the pool is already simple, documented, and testable. It is not a substitute for user validation.

Parallel ARM-integrated rebuild route​

Use this route for scores of 5–14, or for known red factors that make carrying the existing design forward unattractive.

1. Create the target host pool and application groups in the ARM-integrated environment.
2. Build or validate the target session-host image.
3. Recreate user assignments, administrative roles, profile configuration, monitoring, and required automation.
4. Pilot with representative users, including users with RemoteApps and profile-dependent workflows.
5. Test application discovery, launch, file handling, first sign-in, profile recovery, application updates, and session-host replacement.
6. Validate support procedures and rollback.
7. Approve cutover, move users in planned waves, and retire the classic service only after acceptance criteria are met.

For RemoteApps, a successful sign-in is not sufficient. Users must find the correct application, launch it, open expected files, retain needed profile state, and receive the intended access boundaries. A parallel build gives the team room to prove those details without making the classic environment the only fallback.

Retirement route​

Use this route only after the application owner confirms the service is no longer needed.

1. Obtain written application-owner signoff.
2. Archive or export required application data, user data, and configuration records.
3. Confirm retention, compliance, and support responsibilities.
4. Communicate the final-access date to affected users.
5. Remove access on the agreed date, then decommission the host pool and associated resources according to the approved plan.
6. Retain the closure record, owner approval, and data-disposition evidence.

Investigation route​

Use this route whenever ownership, automation, or rollback is unknown or untested.

1. Assign an accountable business owner and support owner.
2. Identify and document every listed unknown.
3. Trace scripts, scheduled tasks, runbooks, and pipelines to determine their function and owner.
4. Document identity, access, profile, image, and user-impact dependencies.
5. Create and test a rollback procedure.
6. Rescore the pool only after each hard stop has been closed.
7. Select automated migration, rebuild, or retirement from the completed evidence.

Validate the User Service, Not Just the Azure Resources​

Whether a pool is migrated automatically or rebuilt, do not treat resource creation as acceptance. Administrators being able to connect and session hosts appearing healthy are necessary checks, but they do not prove that the service works for users.
The cutover checklist should verify:

• Users see the correct assigned desktop or RemoteApps.
• Published applications launch with expected names, icons, and access.
• Profiles behave as expected across first sign-in, reconnect, and host replacement.
• Azure RBAC delegation provides intended administrative access.
• Support teams can handle a routine access, profile, or application problem.
• Automation has been replaced, retired, or deliberately retained with a documented owner during a limited transition.
• Rollback remains available through the agreed decision point.

WindowsForum’s reporting on the retirement of the Remote Desktop app also reinforces a broader operational lesson: client access and end-user communications deserve their own validation. Do not assume that users will understand a changed connection method, application presentation, or support process without a pilot and clear instructions.
Microsoft announced Automated Host Pools and Dynamic Autoscaling in June 2026, and those capabilities are unavailable to frozen classic-era Azure Virtual Desktop. That is a reason to assess a troubled pool’s future design rather than preserve its historic structure by default. It does not mean every rebuilt pool will use or qualify for every new capability; suitability still depends on the target design and operational requirements.

Frequently Asked Questions​

Is Microsoft’s automatic migration tool the default recommendation?​

It is the right route for simple, documented host pools that score 0–4, have no red factors, and have a tested rollback plan. It is not the default for every classic deployment.

Does moving from classic to Azure Resource Manager change administration?​

Yes. The ARM-integrated platform uses Azure portal management and Azure RBAC delegation rather than the separate administrative approach used by classic. Teams should test who can administer resources, assign access, and support users before cutover.

Should a complex RemoteApp host pool be migrated automatically?​

Not by assumption. A complex but understood RemoteApp pool normally belongs on the parallel rebuild route, where application groups, assignments, profiles, access behavior, and user launch workflows can be validated before cutover.

What should trigger immediate investigation?​

Any unknown owner, unknown automation, or untested rollback is a hard stop. Assign accountability, identify the dependency, test recovery, and rescore the host pool before selecting a migration or retirement route.
By September 30, 2026, every classic Azure Virtual Desktop host pool should have a documented destination and accountable owner. The goal is not a reassuring migration percentage; it is a supportable outcome in which users, profiles, access, automation, and rollback have all been deliberately addressed.

---

References​

1. Primary source: learn.microsoft.com
   
   

   DCccv5-series-retirement - Azure Virtual Machines | Microsoft Learn

   Retirement information for the DCas_cc_v5 and DCads_cc_v5 nested confidential VM sizes. Before retirement, migrate your workloads to recommended options.

   learn.microsoft.com
2. Primary source: WindowsForum
   
   

   Azure Virtual Desktop Classic: Migrate Before September 30, 2026 | Windows Forum

   Azure Virtual Desktop (classic) retires on September 30, 2026, and most organizations should not treat the deadline as a one-click control-plane upgrade...

   windowsforum.com