The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Migrating legacy virtual desktop infrastructure (VDI) to Azure Virtual Desktop (AVD) is a controlled rebuild and transition—not a direct conversion of the old platform. Microsoft says there is no direct migration path from other VDI platforms. Plan to provision new AVD host pools and session hosts, then migrate or rebuild images, applications, user profiles, and required dependencies. To limit disruption, move users in tested waves organized around their work and application needs; no migration plan can guarantee zero interruption.
What changes when you move from legacy VDI to AVD?
AVD has a Microsoft-managed platform control plane that differs from traditional VDI systems. The old environment’s management layer does not become an AVD deployment. Your target needs new host pools and session hosts, along with the applications, profile storage, identity connections, networking, and operational processes those hosts require. Microsoft describes this as a migration rather than a direct platform conversion in its Migrate end-user desktops to Azure Virtual Desktop guidance, updated October 1, 2026.
Some components may be reusable, but reuse is a design decision to test, not an assumption. Assess whether to migrate or rebuild a golden image, whether existing profile data needs remediation, and whether applications or back-end services must change. Azure Migrate can support discovery and assessment for appropriate scenarios; it does not convert a legacy VDI control plane into AVD or provision the new AVD target for you.
How do you plan a migration that limits disruption?
Organize the migration around user personas and move each persona through discovery, target design, testing, and onboarding as a distinct iteration. A persona should reflect actual work requirements—not just a department name—including applications, performance needs, location, security requirements, profile behavior, and whether pooled desktops are suitable. Microsoft recommends persona-driven iterations to reduce the impact of change velocity and focus testing and onboarding for each pool.
#1 Best Overall
Use a production readiness gate for every wave. A running session host is not proof that a user’s workflow is ready. If an application, profile, or dependency is not ready, pause that persona or remediate it separately rather than cutting over users into a known problem.
Step 1: Discover users, workloads, and dependencies
Build an inventory of the legacy service before sizing or creating AVD resources. Microsoft’s Assess Azure Virtual Desktop guidance, updated August 27, 2026, identifies desktops, users, workloads, and profiles as assessment inputs. Extend that baseline to cover the dependencies that determine whether a user’s complete workflow will work after cutover.
- Users and sessions: assigned users, peak concurrent sessions, work patterns, locations, and user groups with materially different requirements.
- Applications and data: required applications, versions, licensing dependencies, data locations, and connections to back-end services.
- Desktop behavior: personal or pooled use, customization needs, performance requirements, and suitability for Windows multi-session.
- Profiles: current profile technology, formats, sizes, persistence requirements, and any data that needs cleanup or remediation.
- Access and infrastructure: identity and authentication dependencies, network flows, printing, peripherals, and operational ownership.
Use Azure Migrate for infrastructure discovery and dependency assessment where appropriate, but verify current tool support and implementation details in its current product documentation. If the estate lacks usable inventory, third-party discovery may supplement it; assess any provider’s current suitability rather than treating discovery output as a finished AVD design.
Step 2: Define personas and size for observed demand
Group users by workload, required applications, performance, geography, security or compliance needs, and desktop model. Size for peak concurrent use rather than the total number of people assigned a desktop. Test latency from representative user locations to candidate Azure regions, and evaluate the location of application back ends as part of the end-to-end experience.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsMicrosoft Cloud Adoption Framework guidance includes sizing examples, not universal recommendations or performance guarantees:
| Example in Microsoft guidance | How to interpret it |
|---|---|
| 6 users per vCPU | A light-user density assumption example from Microsoft guidance (2026); validate against your own workload. |
| 2 users per vCPU | A heavier-density example from Microsoft guidance (2026); it is not a promised capacity. |
| 4 GB RAM per vCPU | A performance-sizing example from Microsoft guidance (2026); test memory needs with representative applications and sessions. |
Use these figures only as starting points for a proof of concept. Actual density and responsiveness depend on the workload, applications, session behavior, host configuration, and target design.
Rank #3
Step 3: Confirm the foundation and prove the design
Before scheduling a production cohort, review the landing zone and establish the required identity, network, security, monitoring, backup, and operational arrangements. Microsoft planning guidance calls for a proof of concept before first deployment. Use it to exercise representative users’ real workflows and confirm that the service can be supported, not just that a desktop can launch.
- Test application compatibility on the chosen operating system and desktop model.
- Measure user experience and session density with representative workloads.
- Validate profile creation, persistence, access permissions, capacity, and performance.
- Check printing and peripherals that users need, plus connectivity to back-end systems.
- Exercise monitoring, backup, support procedures, and incident escalation.
A Microsoft planning page referenced for this area is marked deprecated and scheduled for removal on October 30, 2026. Do not rely on its licensing statements as timeless guidance: verify AVD eligibility, user licensing, external-user pricing if relevant, and current Azure compute and storage prices for the actual deployment. Budget infrastructure consumption separately from any license entitlement.
Recommended Free Tools
Step 4: Build AVD for each persona
Provision the target components each persona needs: host pool or pools, desktop or RemoteApp application groups, session-host images, application delivery, and profile storage. Microsoft’s migration guidance allows for migrating or creating images; choose after reviewing application state, dependencies, supportability, security baselines, and test effort.
For profiles, Microsoft identifies Azure Files and Azure NetApp Files as possible hosting options with FSLogix configuration. Neither is a universal winner. Compare them against the existing architecture, identity integration, permissions, capacity, performance, resilience, backup, operational model, and cost. Profile data may require separate migration or remediation before a user cohort is ready.
Check applications against the target OS and pooled or personal model. Some legacy applications may not work with Windows Enterprise multi-session; those users may need a personal desktop or application remediation. Where a back-end dependency would make the workflow too slow, assess that dependency rather than assuming a successful session-host build means the application is ready.
Step 5: Pilot, then cut over in controlled waves
Start with representative pilot users, including people who expose edge cases in applications, profiles, locations, or peripherals. For each persona wave, agree on readiness criteria and a cutover plan before moving users.
Free tools Windows power users keep installed
One-click scans. No signup required.
- Set entry criteria: required applications and data are available; profile behavior has been tested; access, security, and support arrangements are in place.
- Define test cases and success measures: cover sign-in, the user’s essential work, expected performance, and any persona-specific requirements.
- Plan the cutover: schedule a window, communicate the change, staff support, and identify who can pause or proceed with the wave.
- Keep the prior access path available: retain it until the new desktop and required applications and data have been validated under your organization’s policy.
- Review results before expanding: record issues and acceptance results, fix blockers, and then move the next cohort.
Microsoft’s iterative guidance supports focused testing and onboarding, but it does not prescribe one rollback procedure for every legacy platform. Define rollback or recovery steps for your actual source environment, data flows, and cutover design. If discovery reveals an incompatible application, profile remediation, or back-end latency, adjust that persona’s plan without unnecessarily delaying cohorts that are ready.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Step 6: Validate operations and retire legacy components deliberately
For each cohort, record whether sign-in, profile persistence, application access, relevant printing and peripherals, latency, concurrency, security controls, monitoring, backup, and help-desk readiness meet the agreed acceptance criteria. Gather user feedback and track defects while the cohort is still supported through the transition.
Retire legacy infrastructure only after you have accounted for remaining dependencies, data-retention requirements, and rollback obligations. The retirement point should follow the organization’s acceptance and governance rules, not simply the date a new host pool was created.
Quick Recap
Which design choices need a decision for each persona?
| Decision | Compare | What the evidence supports |
|---|---|---|
| Pooled or personal desktops | Application compatibility, customization, security and compliance, performance isolation, and cost | Microsoft warns that some incompatible legacy applications may require dedicated desktops; assess each persona rather than choosing one model for everyone. |
| Azure Files or Azure NetApp Files for profiles | Existing architecture, performance, capacity, resilience, operations, and cost | Microsoft names both as profile-hosting options; the cited guidance does not establish a universal winner. |
| Rebuild an image or migrate and tailor an existing one | Application state, dependencies, supportability, security baseline, and test effort | Microsoft allows migrating or creating images; decide after assessment and testing. |
| Move a persona now or remediate first | User impact, application and profile readiness, dependency latency, and remediation effort | Microsoft identifies application and profile remediation as issues that can delay particular personas. |
What to keep in view during the migration
- AVD is a new target environment, not a conversion of the old VDI control plane.
- Discovery and assessment inform the design; they do not replace building and testing new AVD components.
- Use measured concurrency and representative workloads to guide sizing, then validate in a proof of concept.
- Move users only when their applications, profiles, and dependencies have passed the agreed readiness checks.
- Keep licensing, pricing, and tool details tied to current Microsoft documentation and the specific deployment.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
