RDS to Azure Virtual Desktop (AVD) Migration
IT Partner migrates on-premises Remote Desktop Services estates to Azure Virtual Desktop as a wave-planned project: an inventory of every session collection, RemoteApp, session host, RD Gateway, RD Web Access, Connection Broker and RD Licensing server; an AVD design with pooled host pools on Windows 11 Enterprise multi-session, Windows Server session hosts where an application still needs a server OS, FSLogix profile containers on Azure Files, autoscale, Windows App on the endpoints and Conditional Access in front; a written map from the RDS CALs you own to the per-user access rights AVD actually needs; landing-zone and network prerequisite checks; every application tested on multi-session Windows 11 before anyone moves; conversion of User Profile Disks or roaming profiles to FSLogix; a pilot cohort; wave cutovers with the RDS farm kept as the fallback; and retirement of the RDS roles once the last wave signs off. Users who need a desktop of their own get an AVD personal host pool or a Windows 365 Cloud PC in the same design. $35 per user plus a $3,950 tenant fee, an estimate confirmed in a written quote, for about 4 weeks on a typical estate of 50 to 1,000 users in one region; larger, multi-region and Citrix or Omnissa Horizon estates are quoted per estate. Windows Server 2016 — the operating system under most of the RDS farms we are asked about — leaves extended support on 12 January 2027 per Microsoft's product lifecycle, and that date, more than the AVD feature list, is usually what starts the conversation. Azure consumption and Microsoft licensing are Microsoft's charges to you, separate from our fee.
What this engagement is
Most Remote Desktop Services farms we are asked to move were built between 2016 and 2019 and have been quietly doing their job since: a Connection Broker or two, an RD Gateway published on the edge, RD Web Access for the icons, an RD Licensing server holding a stack of CALs, and a row of session hosts running the applications the business actually lives in. What has changed is not the farm but its foundation. Windows Server 2016 leaves extended support on 12 January 2027 per Microsoft's product lifecycle, and after that date the session hosts, the gateway and the broker stop receiving security updates unless you pay Microsoft for Extended Security Updates. Upgrading the farm in place to Windows Server 2025 is a legitimate answer, and we sell that too. This page is the other answer: retire the roles you run yourself and move the desktops and applications to Azure Virtual Desktop, where Microsoft operates the broker, gateway, web feed and connection plumbing as a service, and what you own is session hosts, images and profiles. The migration is a rebuild, not a lift-and-shift, and it is worth being precise about why. An RDS session host cannot be replicated into an AVD host pool and simply work: AVD session hosts register with Microsoft's control plane through an agent, reach users through reverse connect — no inbound 3389 or 443 on your firewall, which is what retires the RD Gateway — and, for pooled desktops, run Windows 11 Enterprise multi-session, a client operating system that hosts many interactive sessions, rather than Windows Server. That OS change is the part that needs discipline. Every application on the RemoteApp list is tested on Windows 11 multi-session before any user moves, because a minority of line-of-business and vertical-market applications are supported by their vendor only on a server OS, only on a single-session desktop, or not at all in multi-session. Those get a written disposition: a Windows Server 2022 or 2025 session host pool inside AVD, an AVD personal host pool or a Windows 365 Cloud PC for the users who need a machine of their own, or a vendor conversation we can help with but not promise. Where your applications are packaged, App Attach — Microsoft's current mechanism since MSIX app attach was retired in June 2025 — delivers them to session hosts without baking every one into the image. Profiles and licensing are where RDS migrations go wrong when they are treated as an afternoon's work. If your farm uses User Profile Disks or roaming profiles, people's settings, Outlook caches and application data live in those containers, and AVD uses FSLogix profile containers on Azure Files instead. We convert them — FSLogix's frx tool and scripted UPD conversion, validated on a sample of real profiles first, then run per wave the night before that wave moves — so users sign in to the new desktop and find their signature, their mapped printers and their pinned favorites, not a temporary profile. Licensing is mapped in writing, not assumed. The RDS CALs that licensed your farm do not carry into AVD. Access to Windows 11 multi-session desktops comes from per-user licenses most organizations already hold — Microsoft 365 E3, E5, F3 and Business Premium, Windows Enterprise E3 and E5, and Windows VDA per user — while Windows Server session hosts inside AVD still require RDS CALs with active Software Assurance or RDS user subscription licenses plus an RD Licensing server, external users need Microsoft's per-user access pricing enrolled on the subscription, and the Windows Server licenses on server-based hosts come from Azure's license-included pricing or Azure Hybrid Benefit. Identity follows the same map: Windows 11 multi-session hosts can be Microsoft Entra joined or hybrid joined, but Windows Server hosts must be joined to Active Directory Domain Services or hybrid joined, so your domain controllers' reachability from Azure — usually over the site-to-site VPN or ExpressRoute this page assumes — is a design input, not a cutover-night discovery. Cutover runs in waves by collection, with the RDS farm kept intact as the fallback until the last wave is signed off; users get Windows App on their existing endpoints, RD Web icons and the retired Remote Desktop clients stop being the front door, and the RD Gateway comes off the edge last. Two adjacent cases deserve straight answers. If your farm has Citrix Virtual Apps and Desktops or Omnissa (formerly VMware) Horizon layered on top of RDS, the same engagement applies — session hosts, applications, profiles and users move the same way — but there is extra work with no per-user list price: Citrix policies become Intune, Group Policy and RDP-property settings, Citrix Profile Management containers convert to FSLogix, App Layering is unpicked, and NetScaler or StoreFront authentication is redesigned around Microsoft Entra Conditional Access, so those estates are quoted per estate after we have seen them. And if a workload has a hard reason to keep its session hosts on your own hardware — latency to a plant-floor system, data residency, a GPU you already own — Azure Virtual Desktop Hybrid, which Microsoft took to general availability in September 2026, puts Azure Arc-connected on-premises hosts under the same AVD control plane; it supports Windows Server and single-session Windows 11 hosts but not multi-session, and it retires the same RDS roles, so it is a legitimate disposition for part of an estate and we scope it as one. What we do not do is promise that AVD will be cheaper than the farm you already paid for. The design includes a cost projection built from your observed session density, with autoscale schedules and Azure Hybrid Benefit applied where your licensing qualifies, set beside what the farm costs you today — decision-grade input, not a guarantee of your Azure bill.
Which one applies to you
Every collection and user group in the RDS estate gets one of four target dispositions in the design. This service delivers the first two end to end, designs the third and delivers it here or through our Windows 365 sibling, and scopes the fourth as an option.
| Pooled desktops and RemoteApps on Windows 11 multi-session (this service) | Windows Server session hosts in AVD (this service) | Dedicated desktops: AVD personal host pool or Windows 365 Cloud PC | Hosts that stay on-premises: Azure Virtual Desktop Hybrid (scoped as an option) | |
|---|---|---|---|---|
| Who it fits | The majority of an RDS estate: task workers and knowledge workers on session collections and RemoteApp collections whose applications run on a client OS. | User groups whose applications are supported by the vendor only on Windows Server, depend on server-only components, or are licensed in a way that ties them to a server OS. | Developers, power users, people with local-admin or per-user-licensed software, and anyone on an RDS personal (VDI) collection today. | Workloads with a hard reason to keep session hosts local — latency to on-site systems, data residency, hardware already owned — that still want the RDS roles retired. |
| What we build | Pooled host pools on Windows 11 Enterprise multi-session, sized from observed session density; FSLogix profile containers on Azure Files; App Attach for packaged applications; RemoteApp application groups mirroring your collections; autoscale; Windows App on endpoints. | A separate host pool on Windows Server 2022 or 2025 session hosts, AD DS or hybrid joined, with an RD Licensing server retained, FSLogix profiles and the same control plane, gateway and client as the pooled estate. | An AVD personal host pool with one VM per user and the profile moved with it, or — usually the simpler answer — Windows 365 Enterprise Cloud PCs through our Windows 365 implementation, sharing the application set and Conditional Access design. | Azure Arc-connected session hosts on your hypervisor or bare-metal Windows Server, registered to an AVD host pool; Windows Server or single-session Windows 11 only, since multi-session is not supported on hybrid hosts per Microsoft; quoted per estate. |
| Licensing that applies | Per-user AVD access rights included in Microsoft 365 E3, E5, F3 and Business Premium, Windows Enterprise E3 and E5, and Windows VDA per user; no RDS CALs; Azure compute and storage on Microsoft's meters. | RDS CALs with active Software Assurance or RDS user subscription licenses per user, plus Windows Server licensing on the hosts (license-included or Azure Hybrid Benefit); Azure compute and storage on Microsoft's meters. | AVD personal: the same per-user access rights as pooled. Windows 365: a Windows 365 license per user on Microsoft's price list, with no Azure subscription required on the Microsoft-hosted network. | Azure Virtual Desktop Hybrid per-user licensing on the Arc-connected hosts, RDS CALs with Software Assurance for Windows Server hosts, and your own hardware and hypervisor costs — confirmed against Microsoft's current terms at scoping. |
| Downtime shape | None until the user's wave: profile converted the night before, sign-in through Windows App the next morning, RDS collection kept as fallback until the wave signs off. | Same wave model; the server-OS applications are validated by their owners on the new hosts before the wave moves. | Per user: the Cloud PC or personal VM is provisioned and validated before the old desktop is retired. | Depends on host preparation on your side; planned as its own wave. |
| Our role | We deliver this end to end — this page. | We deliver this end to end — this page; the residual RDS CAL and RD Licensing server requirement is stated in writing so nobody is surprised at true-up. | We design the split and deliver the personal host pool here; Cloud PCs are provisioned through the Windows 365 Cloud PC Implementation, scoped alongside this engagement. | We identify the hosts that qualify and scope the hybrid deployment separately, with the RDS roles retiring on the same schedule. |
The disposition is made per collection and user group from your inventory, application test results and vendor support statements — not from a preference for the column with the simplest build.
Success criteria
What you receive
How the work unfolds
Confirm scope, stakeholders, the date driving the move, the Azure subscription and landing zone, and access. Inventory the farm from the Connection Broker and RD Licensing Manager, collect session-density and application-usage data, capture the Citrix or Horizon overlay where present, and segment users by collection and application need.
Assign every collection and user group to a target disposition, design the host pools, image approach, FSLogix storage, identity join, network, Conditional Access and autoscale, map RDS CALs to the entitlements AVD needs, and set the cost projection beside today's farm costs. You approve the target map and the wave plan before anything is built.
Verify the landing zone and hybrid network, build the host pools, image and FSLogix storage, publish the RemoteApp application groups, package suitable applications for App Attach, and test every application on its target OS with its owner. Anything that fails multi-session gets its disposition now, not on cutover night.
Convert a sample of real User Profile Disks or roaming profiles to FSLogix and validate what survives, deploy Windows App to the pilot endpoints, and run the pilot cohort on AVD for the agreed period. Findings — sign-in time, printers, peripherals, application quirks — are fixed in the runbook before wave one.
Convert each wave's profiles the night before, move the wave to Windows App and the AVD feed in the morning, keep the RDS collection as the fallback until the wave's owner signs off, and fold each wave's findings into the next. Later waves prepare while earlier ones settle.
Retire RD Web Access, the Connection Broker and the migrated session hosts, take the RD Gateway off the edge last, retain the RD Licensing server only if Windows Server hosts remain in AVD, hand over the design, runbooks and licensing map, and deliver the closeout report with exceptions and the decommission checklist.
Prerequisites
Who does what
IT Partner
- Inventory the RDS estate and any Citrix or Horizon overlay, segment users, and produce the target map, AVD design, licensing and entitlement map, cost projection and wave plan.
- Verify the landing zone, network and identity prerequisites and name any gap in writing before build.
- Build the host pools, image, FSLogix storage, App Attach packages, application groups, autoscale and Conditional Access within migration scope, and document what is built.
- Test every application on its target OS with its owner and record the disposition; refer eligible customers to Microsoft's App Assure program for failures.
- Convert profiles per wave, deploy Windows App to in-scope endpoints, run the pilot and the wave cutovers in the agreed windows, and fix migration-related issues within scope.
- Decommission the RDS roles in the agreed order, deliver the decommission checklist and the closeout report, and hand over the documentation.
- Say plainly when a user group should stay on a server OS, get a dedicated desktop, remain on-premises under AVD Hybrid or not move yet, and what should happen instead.
Your team
- Provide access, application media and licenses, vendor support statements and profile-store access, and own licensing compliance decisions.
- Sign off the target map, the AVD design, the wave plan and each wave's cutover, and make the stay-or-go call per collection.
- Provide application owners for testing, a pilot cohort, and staff on your side for cutover mornings and user communications.
- Own the Azure subscription and pay Microsoft (or your CSP) for Azure consumption, AVD access rights, RDS CALs, Windows 365 licenses and any per-user access pricing.
- Approve firewall, DNS and Group Policy changes we request, and coordinate third-party vendors whose products run inside the desktops.
- Execute the RDS decommission checklist items that stay with you — hardware disposal, CAL records, contracts with hosting or Citrix vendors.
What's not included
Limitations & technical notes
Frequently asked questions
Why move to Azure Virtual Desktop instead of upgrading the RDS farm to Windows Server 2025?
Both are legitimate, and we sell both. An in-place or side-by-side upgrade keeps everything you know — the broker, gateway, web feed, licensing server, your CALs — and buys you Microsoft's support window for Windows Server 2025. It also keeps you owning and patching all of those roles, running them on hardware you have to refresh, and exposing an RD Gateway on the edge. AVD retires the broker, gateway, web and connection roles into a Microsoft-operated service, moves pooled desktops to Windows 11 Enterprise multi-session with per-user licensing most organizations already hold, scales session hosts up and down with demand, and puts Conditional Access and MFA in front of every session without a gateway to maintain. The honest deciding factors are usually your application vendors' support statements, how much of the estate needs a server OS, and whether you want to keep owning that infrastructure. If you are not sure, our Windows Server 2016 End of Support Assessment and Roadmap prices the upgrade, the migration and the ESU bridge side by side before you commit.
What happens to our RDS CALs?
They do not transfer into AVD, and for most of your users they are no longer needed. Access to Windows 11 multi-session desktops in AVD comes from per-user licenses — Microsoft 365 E3, E5, F3 and Business Premium, Windows Enterprise E3 and E5, and Windows VDA per user — so the licensing map on this engagement usually shows the CAL count dropping to whatever still sits on Windows Server session hosts, where RDS CALs with active Software Assurance or RDS user subscription licenses are still required alongside an RD Licensing server. If you serve external users — customers or contractors without a license in your tenant — Microsoft's per-user access pricing is enrolled on the subscription and billed monthly to you. We put all of this in writing before build; what you do with retired CALs is a volume-licensing question our licensing consultants can answer.
What if an application will not run on Windows 11 multi-session?
It gets a disposition, not a workaround discovered by a user. Every application on the RemoteApp and collection list is tested on the target OS with its owner before the pilot. Applications that fail or lack vendor support in multi-session go to a Windows Server 2022 or 2025 host pool inside AVD, which runs the same control plane and client; applications that need a single-session desktop go to an AVD personal host pool or a Windows 365 Cloud PC; and applications that are genuinely stuck get a written recommendation and, for eligible customers, a referral to Microsoft's App Assure program. What we do not do is ship a wave and see what breaks.
How do you move user profiles from User Profile Disks to FSLogix?
By conversion, per wave, with a rollback. User Profile Disks and roaming profiles are converted into FSLogix profile containers on Azure Files — FSLogix's frx copy-profile tool and scripted UPD conversion — and we validate the process on a sample of your real profiles first, because Microsoft's FSLogix migration module is a preview and not everything survives an operating system change. On cutover night the wave's profiles are converted, and in the morning users sign in to Windows 11 and find their signature, pinned favorites, mapped printers and application settings. Oversized or corrupted profiles are flagged for cleanup rather than migrated blindly, and the original profile stays untouched until the wave signs off.
What happens to RD Gateway, RD Web Access and our VPN?
They retire. AVD session hosts connect outbound to Microsoft's control plane and users reach them through reverse connect, so there is no inbound 3389 or 443 to publish and no gateway to patch on the edge; the RD Gateway comes off last, after the final wave. RD Web Access is replaced by the Windows App feed, and Conditional Access with MFA sits in front of every session. Your VPN stays if people use it for other things, but nobody needs it to reach their desktop. The hybrid network between Azure and your sites — site-to-site VPN or ExpressRoute — is a different matter: the session hosts still need it to reach Active Directory, file servers, printers and any application back end that stays on-premises.
Will users be down during the migration?
Not the estate, and not for long per user. The RDS farm keeps serving until the last wave signs off. Each wave's profiles are converted the night before, and users sign in through Windows App the next morning; if something is wrong for a user, the RDS collection is still there and they go back to it while we fix the cause. The pilot cohort exists precisely so the first wave is boring.
Which users should get Windows 365 instead of AVD?
The ones who need a machine of their own: developers, people who install software or hold per-user licensed tools, anyone on an RDS personal (VDI) collection today, and users whose application is supported only on a single-session desktop. Windows 365 Enterprise gives each of them a persistent Cloud PC at a fixed per-user license price with no Azure subscription required on the Microsoft-hosted network; an AVD personal host pool does the same inside AVD with more control and a compute bill. We design the split in the target map, deliver the personal host pool here, and provision Cloud PCs through the Windows 365 Cloud PC Implementation, scoped alongside this engagement so the two do not collide.
Can some session hosts stay on our own hardware?
Yes, where there is a real reason. Azure Virtual Desktop Hybrid, generally available since Microsoft's September 2026 announcement, registers Azure Arc-connected session hosts on your own hypervisor or bare-metal Windows Server to an AVD host pool, so the broker, gateway and client are the same as for hosts in Azure while the desktops run next to a plant-floor system or inside a data-residency boundary. It supports Windows Server and single-session Windows 11 hosts, not multi-session, and carries its own per-user licensing alongside RDS CALs with Software Assurance for server hosts. We identify the workloads that qualify in the target map and scope the hybrid deployment separately; the RDS roles retire on the same schedule either way.
We run Citrix on top of RDS. Is that covered?
As a source, yes; at the per-user list price, no. Session hosts, applications, profiles and users move exactly as they do from a plain RDS farm, but a Citrix Virtual Apps and Desktops or Omnissa Horizon estate carries work that RDS does not: Citrix policies have to become Intune, Group Policy and RDP-property settings, Citrix Profile Management containers convert to FSLogix, App Layering has to be unpicked into images or App Attach packages, and NetScaler or StoreFront authentication and access policies are redesigned around Microsoft Entra Conditional Access, because AVD does not accept a third-party gateway in front of it. We quote those estates per estate after we have seen the farm, and your Citrix or Omnissa contracts and their termination stay between you and those vendors.
How much does it cost?
$35 per user plus a $3,950 tenant fee — an estimate for a typical single-region RDS estate of 50 to 1,000 users, confirmed as a written quote before work begins; you pay after you approve delivery. One hundred users, for example, come to $7,450, and 250 users to $12,700. Estates of 1,000 users and more, multi-region deployments and Citrix or Horizon sources are quoted per estate. Azure consumption, AVD access rights, RDS CALs for server-based hosts, Windows 365 licenses and any per-user access pricing for external users are Microsoft's charges to you, projected in the cost model so they are decisions rather than surprises.
Will AVD be cheaper than our RDS farm?
We will not promise it, because for some farms it is not. A fully depreciated set of hosts running Windows Server licenses you already own can be cheap to keep and expensive to replace with cloud compute, and a farm that runs 24 hours a day for a 9-to-5 workforce is the opposite. The design includes a cost projection built from your observed session density, with autoscale schedules and Azure Hybrid Benefit applied where your licensing qualifies, beside what the farm costs today in hardware, Windows Server, CALs, gateway and support. Every assumption is stated. Microsoft's meters are the bill of record after migration; if the monthly bill needs discipline afterwards, that is the Azure Cost Optimization and FinOps Assessment, not something we fold into a migration quote.
Our session hosts are Windows Server 2016. What is the real deadline?
12 January 2027 per Microsoft's product lifecycle: after that date the session hosts, gateway and broker receive no security updates unless you buy Extended Security Updates, and an RDS farm is an internet-facing, multi-user system, so running it unpatched is not a serious option. Four weeks of engagement fits comfortably before the date if scoping starts in time; if it cannot, the honest bridge is ESU — through Azure Arc for hosts that stay on-premises, or at no additional charge for Windows Server 2016 machines that run as Azure virtual machines, per Microsoft's current terms — while the migration finishes. Our Windows Server ESU Enrollment through Azure Arc and the Windows Server 2016 End of Support Assessment cover that bridge; this page covers getting off the farm.
What identity setup does AVD need?
It depends on the host OS. Windows 11 Enterprise multi-session hosts can be Microsoft Entra joined — no domain controllers in the picture — or hybrid joined through Active Directory and Microsoft Entra Connect. Windows Server session hosts must be joined to Active Directory Domain Services or hybrid joined, because the RD Licensing server dependency remains. Most RDS estates arrive with Active Directory and Entra Connect already in place, so hybrid join with the domain controllers reachable from Azure over the hybrid network is the usual design; an Entra-only design is possible for a pure Windows 11 estate and is what we recommend when nothing on the hosts needs Kerberos to on-premises resources. Retiring Active Directory altogether is a separate engagement.
What do users need on their devices?
Windows App — Microsoft's single client for Azure Virtual Desktop, Windows 365 and Remote Desktop Services on Windows, macOS, iOS, iPadOS, Android and the browser. The old Remote Desktop app from the Microsoft Store was removed in May 2025 and blocked from Azure Virtual Desktop in September 2025, and the MSI-based Remote Desktop client reached end of support for Azure Virtual Desktop in March 2026, so we deploy Windows App to each wave's endpoints through Intune or Group Policy as part of the cutover. Thin clients need a vendor build that supports Azure Virtual Desktop; we confirm per model during design and say plainly which ones need replacing.
How long does it take?
About 4 weeks for a typical estate: discovery and design in the first week and a half, build and application testing in the second, profile validation and pilot in the third, and waves through the fourth with decommission at the end. Large application catalogs, many collections, a Citrix or Horizon overlay, multiple regions or long change-freeze windows extend it, and the wave plan we agree with you states the real dates rather than the brochure figure.
What happens after the migration?
You own an AVD estate and the documentation to run it: the design, the licensing map, the runbooks and the decommission evidence. Most organizations of this size do not have a dedicated VDI engineer, which is what the Managed Azure Virtual Desktop Service is for — monthly image and update cycles, host pool health, autoscale tuning and FSLogix profile care at a per-user monthly fee, from the month users depend on AVD. It is deliberately a separate purchase: the migration stands on its own, and you choose who operates what follows.