If your firm runs a cloud desktop that was set up before late 2023, there's a reasonable chance it sits on a platform Microsoft switches off on September 30, 2026.
Azure Virtual Desktop (classic) is the original version of the service—the one that predates the current Azure Resource Manager platform. Microsoft stopped allowing new classic deployments back in September 2023. Existing ones keep running and stay migratable right up to the retirement date, and then they don't. There's no announced grace period.
The awkward part is that classic deployments tend to be invisible. They were set up years ago, they work, nobody touches them, and the firm running one often has no idea it's on a retiring platform. The environment doesn't warn you.
Not to be confused with the current version. Azure Virtual Desktop itself isn't going anywhere. It's specifically the original "classic" deployment model being retired. If your host pool shows up in the Azure portal, you're already on the current platform and this doesn't apply to you.
How to Tell If This Affects You
The fastest check takes about thirty seconds and doesn't require anyone to log into a server. Open the Azure portal, go to Azure Virtual Desktop, and look for your host pool. If you have staff connecting to a cloud desktop every day but the portal shows you no host pool at all, you're on classic. The classic service keeps its configuration somewhere the modern portal can't see.
Classic vs. Current Azure Virtual Desktop
| What You'd See | Classic (retiring) | Current (ARM) |
|---|---|---|
| Host pool in the Azure portal | Not visible | Visible and manageable |
| Where the configuration lives | United States, always | Your choice, including Canada |
| New deployments allowed | Blocked since September 2023 | Yes |
| Supported after Sept 30, 2026 | No | Yes |
There are more definitive technical checks—a classic session host points at a broker address starting with rdbroker-g, and the deployment is administered with a retired PowerShell module rather than the current one. But the portal test is usually enough to tell you whether you need to make a phone call.
The Easy Migration Path Sends Your Data to the US
Microsoft publishes an automatic migration tool, and it looks like the obvious answer. For Canadian firms, it's the wrong one.
The migration module only creates the new service objects in the United States geography. There's no option to choose otherwise. That means your host pool name, workspace name, application group names, the VM name, every user's sign-in name, and all of your connection diagnostics end up permanently hosted in the US.
For an accounting firm handling Canadian client tax data, or an engineering firm with public sector contracts, that's a meaningful change to make by accident on a Tuesday afternoon.
The part that cuts both ways
Classic deployments are frequently already in this state. The virtual machine itself sits in Canada Central—holding the actual files and applications—while the service metadata has been in the United States the entire time. That's just how the classic service was built.
So migrating manually to Canadian metadata doesn't only avoid a downgrade. It closes a data residency gap that's quietly been open for years. That's a genuine improvement worth raising with your accountant or your insurer, not something to file under IT maintenance.
The manual path is also what Microsoft recommends for small deployments. For a single host pool serving a handful of users, it's faster than fighting the automated module anyway.
What the Migration Actually Looks Like
Less disruptive than most firms expect. We recently moved a Calgary accounting firm off classic in a single evening—roughly three hours from start to finish, staff back to normal the next morning, no lost work.
Total evening work
Actual user outage
Business hours lost
The reason it isn't a weekend project is that the classic deployment keeps running while you build its replacement. The new environment gets created alongside the old one, permissions get assigned, applications get lined up, and a rollback snapshot gets taken—all while users carry on working. Only one step actually interrupts anyone: re-registering the session host so it reports to the new service instead of the old one.
The rollback plan matters as much as the migration itself. Before touching anything, we snapshot the machine's disk, which restores as a straight disk swap—same machine name, same network address, same domain membership, still pointed at classic.
One trap worth naming. There's a tempting button in the Azure portal labelled Capture that sounds like it takes a backup. It doesn't. It wipes the machine's identity and domain join in the process, which on a server carrying years of accounting software is a very bad afternoon. The snapshot is the right tool. The button that sounds right is not.
We also leave the classic deployment intact for at least a full business day afterward. It costs nothing to keep and it's the real safety net.
The Things That Quietly Break
Most of what goes wrong in an AVD migration doesn't announce itself. Users log in successfully and then something is subtly wrong.
Blank Application Icons
The platform pulls icons off a running session host at the moment you publish an application. Publish in the wrong order and every icon comes back as a generic placeholder. Every setting is technically correct—it just looks broken, which for a staff member is the same thing.
No Clipboard or Printing
Classic deployments frequently shipped with redirection settings left blank. Nothing looks wrong until someone tries to copy a figure out of a spreadsheet or print a client return.
Apps Pointing at Nothing
Classic tenants often carry published applications aimed at software uninstalled years ago, and user groups with no server behind them. Those staff have been unable to launch anything for a long time—and usually stopped reporting it.
The redirection one has a genuinely confusing wrinkle: those settings only apply to brand new sessions. Closing a remote application window doesn't end the session, it just hides it. A user who closes everything and reconnects lands right back in the same session with the same old settings, and reports that the fix didn't work.
They have to properly sign out, and their app list has to refresh first. Knowing that in advance is the difference between a clean cutover and a morning of support calls.
What we verify before calling a migration done
- The session host reports healthy in the new environment—not just "connected"
- Application count matches the old inventory, minus anything deliberately dropped
- Every tile shows its real icon, not a placeholder
- A real staff member on their own computer opens a data file in the apps that carry the business—launching an app is not the same as opening a file, and a broken mapped drive only shows up at that point
- Clipboard and printing confirmed by a regular user, not by an admin account
What Else You Should Check While You're In There
Two things usually come up. The first is the operating system. Classic hosts are old by definition, and most run Windows 10 22H2 multi-session, which reached end of support in October 2025. Extended security updates are free and automatic for that OS on Azure Virtual Desktop through October 2028—but only if the policy is actually switched on. Worth verifying while you're in there.
The second is Conditional Access. If your security policies were scoped to the classic application IDs, they need repointing at the current Azure Virtual Desktop application or they silently stop applying. A security policy that quietly stops enforcing is worse than one that was never there, because everyone assumes it's working.
What we don't do is treat the deadline as an excuse to rebuild everything. If a server hasn't been touched in five years it probably deserves a rebuild—but a retirement deadline is not the window to also reinstall a decade of accounting software. Migrate as it stands, then have the modernization conversation separately.
If You're Still on Classic
Check the portal. If your cloud desktop doesn't appear as a host pool, you're on the retiring platform and you have a hard deadline.
If you have an IT provider, ask them two specific questions: whether your deployment is on classic, and if it is, whether their migration plan keeps your data in Canada. The second question matters more than it sounds, because the default tool doesn't.
If you're not sure who to ask, we're happy to take a look and tell you plainly where you stand. It's a short conversation and it usually ends with good news.
