Move Your RDS Deployment to Azure Virtual Desktop

On-premises Remote Desktop Services still works for many organizations, but it often limits scalability, security modernization, and hybrid-work flexibility. In 2026, the better question is not simply “How do we move RDS to Azure?” but “Should we lift RDS to Azure IaaS, modernize with Azure Virtual Desktop, or use Windows 365 Cloud PCs?”

Why modernize RDS now

Remote Desktop Services has long been used to publish desktops and applications to employees. However, traditional on-premises RDS environments usually require you to maintain connection brokers, gateways, web access servers, certificates, capacity planning, patching, storage, backup, disaster recovery, and perimeter security. Azure Virtual Desktop reduces much of that infrastructure burden by providing a Microsoft-managed control plane while letting you run session hosts in Azure. You still manage the session host VMs, images, applications, profiles, identity integration, network design, monitoring, and governance, but you no longer need to operate the legacy RDS control-plane components in the same way. Azure Virtual Desktop also supports modern capabilities such as Windows 11 Enterprise multi-session, FSLogix profile containers, host pool autoscale, Start VM on Connect, Microsoft Teams optimization, Azure Monitor Insights for Azure Virtual Desktop, and integration with Microsoft Entra ID and Conditional Access.

Choose the right path: RDS on Azure IaaS, Azure Virtual Desktop, or Windows 365

There are three common modernization paths. First, you can lift and shift existing RDS servers to Azure Infrastructure as a Service. This can be useful when you need a fast datacenter exit or must keep a Windows Server-based RDS architecture for compatibility, but it usually preserves much of the operational complexity and may still require RDS CALs. Second, you can modernize to Azure Virtual Desktop, which is the preferred path for many shared desktop and published app scenarios because it provides a managed control plane, elastic host pools, Windows 11 Enterprise multi-session, and strong integration with Microsoft 365, Microsoft Entra ID, Microsoft Intune, and Microsoft Defender. Third, you can use Windows 365 Cloud PCs for users who need persistent personal desktops with simpler per-user management and predictable licensing. Many organizations use a mix: Azure Virtual Desktop for pooled desktops and app publishing, and Windows 365 for dedicated Cloud PCs.

Licensing and eligibility in 2026

Licensing should be reviewed before the migration design is finalized. Azure Virtual Desktop access rights are included with eligible Microsoft 365 and Windows subscriptions such as Microsoft 365 Business Premium, Microsoft 365 E3/E5, Microsoft 365 F3, Windows Enterprise E3/E5, and other qualifying licenses, subject to Microsoft’s current licensing terms. If you run Windows Server as the session host operating system, Remote Desktop Services CAL requirements may still apply. External user scenarios can use Azure Virtual Desktop per-user access pricing where appropriate. For customers buying through the Cloud Solution Provider program, subscription terms, seat changes, cancellation windows, and renewal behavior are governed by Microsoft’s New Commerce Experience terms, so licensing and migration timing should be planned carefully.

Step 1: Assess the current RDS environment

Start with discovery rather than migration. Inventory RD Session Host servers, applications, user groups, usage patterns, peak concurrency, profile sizes, file shares, line-of-business dependencies, printers, authentication methods, certificates, GPOs, and network flows. Azure Migrate can help discover servers, dependencies, sizing, and readiness when you are evaluating Azure VM placement or lifting workloads to Azure. However, for Azure Virtual Desktop, the best practice is often to build clean session hosts from a managed image rather than directly migrating aging RD Session Host servers. This avoids carrying forward years of configuration drift, outdated agents, legacy software, and security exceptions.

Step 2: Design identity, network, and security

A successful Azure Virtual Desktop migration depends on identity and network design. Use Microsoft Entra ID for access control, Conditional Access, and multifactor authentication. Decide whether session hosts will be Microsoft Entra joined, hybrid joined, or domain joined based on application, profile, and management requirements. Plan Azure virtual networks, DNS, routing, firewall rules, private connectivity, and access to file services or application back ends. Apply least-privilege role-based access control, separate administrative duties, and use privileged access controls where available. Security design should also include Microsoft Defender for Endpoint on session hosts, Microsoft Defender for Cloud recommendations, secure baselines, patching, logging, network segmentation, and a plan for protecting administrative access.

Step 3: Plan profiles, images, and applications

User profiles are usually one of the most important parts of the migration. Azure Virtual Desktop commonly uses FSLogix profile containers stored on Azure Files, Azure NetApp Files, or another supported SMB storage platform. Storage performance, resilience, permissions, backup, and cost must be designed carefully. For session hosts, create a clean image strategy using Windows 11 Enterprise multi-session where possible. Windows Server session hosts can still be used when application compatibility requires them. Windows 10 Enterprise multi-session may exist in older deployments, but organizations should consider Windows lifecycle dates and plan a move to Windows 11 where appropriate. Package and test applications before production migration; app attach and modern image-management approaches can help reduce image sprawl in larger environments.

Step 4: Build a pilot Azure Virtual Desktop host pool

Before migrating all users, build a pilot host pool with representative applications, profile storage, Conditional Access policies, monitoring, and security tooling. Test pooled and personal desktop models if both are candidates. Validate user sign-in, application launch times, Teams audio and video behavior, printing, file access, single sign-on, profile persistence, and performance from user locations. Use pilot feedback to right-size VM SKUs, session density, storage performance, and autoscale rules. A pilot also helps determine whether specific users should move to Azure Virtual Desktop, Windows 365, or a remaining RDS-on-Azure design.

Step 5: Migrate users in stages

Move users in controlled waves rather than with a single cutover. Prioritize groups with simpler application dependencies first, then move more complex workloads after validation. Keep rollback options available during each wave. If Azure Migrate is being used to move supporting servers or selected RDS workloads to Azure, test migrations should be performed before production cutover. For Azure Virtual Desktop host pools, a clean build, image-based deployment, and staged user assignment is usually safer than directly migrating legacy session hosts. User acceptance testing should confirm performance, app compatibility, profile behavior, and security policies before each wave is considered complete.

Step 6: Optimize cost, performance, and operations

After go-live, configure Azure Virtual Desktop autoscale for host pools where appropriate, use Start VM on Connect for selected scenarios, and monitor idle capacity. Review Azure Reserved VM Instances, Azure Savings Plans, and Azure Hybrid Benefit eligibility where applicable. Right-size VMs based on actual session metrics rather than assumptions. Use Azure Monitor Insights for Azure Virtual Desktop, Log Analytics, and Azure Advisor to track availability, connection quality, session host health, capacity, and recommendations. Operational planning should include image patching, application updates, Intune management where applicable, backup for profile and application data, disaster recovery planning, and clear ownership for incidents and changes.

Step 7: Decommission legacy RDS safely

When all users and applications have moved and the business has signed off, retire the old RDS environment carefully. Remove or shut down RD Connection Broker, RD Web Access, RD Gateway, and RD Session Host servers only after confirming that no users, applications, scheduled tasks, certificates, DNS records, firewall rules, monitoring alerts, or integrations still depend on them. Clean up Active Directory computer objects, obsolete GPOs, public DNS records, certificates, load balancer rules, backup jobs, and documentation. Keep an agreed retention period for backups and configuration exports so the organization can respond if a legacy dependency is discovered later.

Key takeaways

• Windows Virtual Desktop is now Azure Virtual Desktop; modern designs should use current AVD terminology and features.
• Azure Virtual Desktop provides a Microsoft-managed control plane, but customers or their IT partner still manage session hosts, images, profiles, applications, networking, security, and operations.
• A clean Azure Virtual Desktop build is often better than directly migrating old RD Session Host servers.
• Windows 11 Enterprise multi-session, FSLogix, autoscale, Microsoft Entra ID Conditional Access, Defender, and Azure Monitor are central to a current AVD deployment.
• Windows 365 may be a better fit than AVD for users who need persistent personal Cloud PCs with simpler per-user assignment.
• Licensing should be validated early, especially for CSP New Commerce Experience subscriptions, eligible Microsoft 365 or Windows licenses, Windows Server RDS CALs, and external-user access scenarios.

If you are planning to replace or modernize RDS, IT Partner can help assess your current environment, compare Azure Virtual Desktop and Windows 365 options, design the target architecture, validate licensing, and migrate users in controlled phases.