Azure Virtual Desktop Migration Checklist for Multi-Site Companies

Moving users from several offices into Azure Virtual Desktop is harder than moving a single office because sites differ in network paths, applications, devices, identity dependencies, and support. A lab can pass while a branch still fails because of latency, a local printer workflow, or profile storage placed too far from session hosts. The Azure Virtual Desktop migration plan should treat each site as a distinct operating environment inside one controlled platform.

This Azure Virtual Desktop migration checklist is for companies with several offices, plants, clinics, warehouses, or regional hubs. It covers decisions before users move, pilot checks, and controls that remain after cutover. The focus is user-facing migration work: connectivity, identity, profiles, applications, host pools, security, rollback, and support.

TL;DR

Use the Azure Virtual Desktop migration checklist as a gate, not as a list to complete after the build. Start by grouping users by site, role, working hours, application set, and device needs. Choose Azure regions from measured latency and application dependencies rather than office geography alone. Finish AVD network planning for every site before pilot users are moved, then test the same routes, DNS behavior, firewall rules, and endpoint controls that production users will use.

For a multi-site AVD deployment, keep profile storage close to the session hosts, test application behavior on the chosen Windows image, and size host pools from measured concurrency instead of employee count. Run pilots with users from different sites and job types, record pass or fail criteria, and keep the old desktop path available until each migration wave is accepted. The final Azure Virtual Desktop migration should close only after monitoring, support ownership, recovery tests, and site-level rollback steps are in place.

What Multi-Site Companies Need to Decide Before Migration

A multi-site move starts with architecture decisions that affect every later step. You need to know whether users at different offices will share host pools, whether some sites need a different Azure region, where profile storage will sit, how session hosts will reach on-premises applications, and which users need pooled versus personal desktops. Microsoft’s Azure Virtual Desktop landing zone design guide places identity, networking, governance, security, and operations in the foundation for the workload, so these choices should be settled before production hosts are built. A site that needs private access to a local ERP system may require a different network path from a sales office that mainly uses SaaS applications.

Define the migration boundary before design work expands. Decide whether the project changes only desktop delivery or also identity join type, device management, file storage, print services, VPN design, and back-end hosting. Too many simultaneous changes make failures harder to isolate, so each wave needs a known set of moving parts and a tested rollback path.

For the multi-site AVD deployment, write down 5 items before design work goes further: which users are in scope, which sites are in scope, which applications must work on day 1, which data paths must remain reachable, and which service levels matter during business hours. These aren’t project slogans. They become acceptance tests later. If a warehouse scanner must open a line-of-business app within an agreed time, that requirement belongs in the pilot test plan now.

The primary Azure Virtual Desktop migration decision is whether the target design will be common across sites or regional by design. A common pattern may reduce operating effort, but it can create poor user experience when branches are far from the chosen Azure region or depend on local systems. A regional pattern can reduce latency but adds image, storage, monitoring, and recovery work. The right choice depends on measured traffic paths and user needs.

Build a Current-State Inventory by Site

Inventory work should be done per site, then rolled up into a company view. A company-wide spreadsheet that lists 2,000 users but hides where they work will miss the issues that matter during cutover. For each office, record user count, peak concurrent users, business hours, local internet capacity, WAN design, identity path, printers, scanners, USB devices, applications, file shares, mapped drives, authentication methods, and known support constraints. The goal is to make site differences visible before they become migration incidents.

Use observed data where possible. Microsoft lists Azure Virtual Desktop prerequisites that include connectivity to required service URLs and recommends keeping client-to-host-pool round-trip latency below 150 ms for the best experience. That makes latency testing part of discovery, not a final performance check. Run tests from each major office and from remote-user locations that represent real working conditions. Record the route, time of day, packet loss, and latency instead of keeping only a single average number.

Application inventory needs more than product names. Record version, install method, licensing, back-end location, authentication, add-ins, browser dependencies, local device needs, and support for a multi-user Windows session. If an app reaches a database across a slow WAN path, the desktop can feel poor even when the AVD session is responsive. That dependency should influence region placement.

Profile inventory should also start early because FSLogix profile migration can take longer than expected when users have old local profiles, redirected folders, large Outlook caches, OneDrive state, or legacy VDI containers. Record profile source, average and upper-end profile size, current exclusions, storage location, permissions, and the method used to create a clean target. This information helps decide whether users will receive new profiles or whether existing state must be copied and tested.

A useful inventory output is a site readiness table. Keep it simple enough to update during the project.

Choose Azure Regions and Map Users to Them

Region selection should follow users and application dependencies. A headquarters-first design often places the Azure region close to the largest office and assumes smaller sites will be fine. That can work when all sites have good paths to the same region, but it should be proven. Microsoft’s current guidance says session hosts should be placed in a region close to users and gives a target of under 150 ms round-trip time from the client network to the host-pool region. Azure Migrate can also help teams identify infrastructure dependencies when the desktop project is part of a broader Azure move.

Create a site-to-region matrix. Test the preferred region and at least 1 practical alternative for each site. Record latency during normal and busy periods, then check where applications and profile data will live. A desktop close to the user can still feel slow when the application server is far away.

For a multi-site AVD deployment, user assignment should be deliberate. Don’t let a user bounce between regions without a profile and data design that supports that behavior. Microsoft guidance for regional AVD architecture favors keeping users and their profile data aligned with the session-host region. That reduces sign-in delays and avoids competing profile copies. Users who travel can still connect to their assigned environment, but the design should make the home region clear.

This step also affects FSLogix profile migration because the target profile store should be chosen after the user-to-region map is known. Moving profile data into a central store first and splitting regions later can create another data move. Decide the home region, profile location, application path, and recovery region together so those choices support the same operating model.

Validate Landing Zone, Identity, and Access

The landing zone should be ready before production session hosts are created. Confirm subscriptions, resource groups, naming, role assignments, policy scope, DNS, logging, network peering, private connectivity, and security controls. Multi-site companies often already have Azure resources built by different teams, so inherited policies and route tables need special attention. A session host that passes a basic build can still fail later if an existing policy blocks an agent, storage path, or required service endpoint.

Identity design should answer how session hosts join the directory, how users sign in, how administrators receive access, and how service accounts are handled. The Azure Virtual Desktop migration should also separate administrative access from user access. Microsoft’s Zero Trust guidance for Azure Virtual Desktop recommends explicit verification, least-privilege access, segmentation, and visibility across the environment. Translate those principles into named controls such as Azure RBAC assignments, Conditional Access policies, privileged-role handling, and endpoint compliance rules.

Test identity from every site involved in the first wave. This matters when offices use local domain controllers, custom DNS, identity proxies, or different egress paths. Confirm that users can authenticate, tokens are issued as expected, group-based application assignments work, and sign-in logs show the expected controls. AVD network planning and identity testing should be done together because DNS or route problems can look like authentication failures.

Create a small access matrix for each user persona. List the host pool, desktop or RemoteApp group, file shares, profile permissions, printer access, and privileged resources. This stops broad group assignments from becoming the default fix when a pilot user can’t open something and gives support a known access baseline after cutover.

Complete AVD Network Planning for Every Site

Network work is the part of a multi-site move that most often exposes hidden differences between offices. AVD network planning should cover the client path to the Azure Virtual Desktop service, the session-host path to Microsoft service endpoints, the path from session hosts to applications and data, DNS resolution, security inspection, and any route back to on-premises networks. Each site should have a diagram that shows where traffic exits and what devices can inspect or alter it.

Start with service reachability. Microsoft publishes the required FQDNs and endpoints for Azure Virtual Desktop, including outbound service traffic and platform addresses that shouldn’t be blocked or redirected. Compare those requirements with firewalls, secure web gateways, proxies, and egress rules used at every site. A policy that works at headquarters may not exist at a branch, and a branch may use a managed firewall with a separate change process.

Then test the user path. RDP traffic can take different paths depending on network conditions and settings. Microsoft documents RDP Shortpath configuration for managed and public networks, with UDP-based options that can improve the connection path when the network permits them. Don’t treat protocol support as assumed. Validate it from representative site networks and capture the actual transport used during pilot sessions.

AVD network planning must also include application traffic that originates from the session host. If users open file shares, databases, print servers, license servers, or APIs in a datacenter, record the route from the Azure virtual network to those systems. Check DNS suffixes, firewall rules, asymmetric routing, MTU issues, and any inspection devices between Azure and the destination. These tests should use application ports and real authentication paths rather than ping alone or a generic connectivity test.

For sites with strict private-access requirements, decide whether Azure Private Link fits the design. Microsoft’s Azure Virtual Desktop Private Link guidance explains how private endpoints can keep certain service traffic on the Microsoft network. Private Link changes DNS and connectivity behavior, so it should be designed early rather than added during cutover week.

Finally, document capacity. Measure internet and WAN use during busy periods, then test AVD alongside other site traffic such as video meetings, backups, software distribution, or large file transfers. The production rollout should have a site-level network baseline and a way to compare post-migration traffic with it. If the first pilot makes the site circuit run near capacity, adding the rest of the office won’t fix the problem.

Prepare FSLogix Profiles and User Data

Profile design determines whether users see a familiar desktop and whether sign-in remains consistent across pooled hosts. Microsoft recommends FSLogix profile containers for Azure Virtual Desktop and advises keeping the storage account in the same region as the session hosts. That is especially important in a multi-region design because cross-region profile access adds delay to a path that is touched during sign-in and throughout the session.

Choose the target storage based on expected user count, profile behavior, performance needs, permissions, recovery needs, and regional placement. Microsoft’s FSLogix storage guidance compares Azure storage options and recommends Azure Files for many AVD environments. Whatever service is chosen, test SMB connectivity, identity-based permissions, NTFS permissions, storage limits, backup or recovery method, and access from every host pool that will use it.

FSLogix profile migration needs a user-state decision. Some organizations should move existing profile containers. Others will get a cleaner result by creating a new profile and migrating only needed user data. The decision depends on the source platform, profile health, app settings that must be retained, and the risk of carrying old corruption into the new environment. Define the rule per persona rather than choosing one method for every user.

For users receiving migrated state, test more than whether the VHDX mounts. Validate Start menu state, application settings, browser data, Outlook behavior, OneDrive, mapped drives, certificates, line-of-business app preferences, and sign-out. Check profile size growth after several days. A profile that works once but grows rapidly can become a storage and sign-in issue after broad rollout.

Keep rollback simple. During a migration wave, don’t delete the old profile source as soon as the user signs in to AVD. Maintain a defined retention period and record which profile copy is authoritative. This avoids confusion if a user returns to the old desktop for a business reason and creates newer files or settings there.

Validate Applications, Images, and Endpoint Dependencies

Application readiness has 2 separate questions: will the application run on the selected Windows session-host image, and will it work from the Azure network path with the required devices and services? Test both. Applications that appear simple may depend on local COM components, drivers, browser extensions, Office add-ins, hard-coded paths, machine certificates, or licensing servers. Multi-user behavior also matters for pooled hosts.

Decide which applications belong in the base image and which should be delivered separately. Microsoft’s App Attach overview describes a method for attaching packaged applications to user sessions without installing them in the base image. This can reduce the number of image variants, but package support and operational fit still need testing. Applications with drivers or deep OS dependencies may still belong in the image or a separate host pool.

Image management should be repeatable. Microsoft’s custom image template guidance uses Azure Image Builder to produce images from defined templates and can place the result in Azure Compute Gallery. For a multi-site AVD deployment, this helps when the same approved image must be available in more than 1 region. Keep image version, patch level, installed applications, configuration changes, and validation results tied to a release record.

Include endpoint dependencies in user testing. List printers, scanners, smart cards, webcams, headsets, USB devices, and local drive or clipboard needs. Set the redirection policy that matches security requirements and test the exact device model where possible because hardware behavior can differ in a shared Windows session.

The Azure Virtual Desktop migration checklist should also include application ownership. Name the business owner and technical owner for every critical application. During pilot and cutover, the migration team needs someone who can decide whether a defect blocks the wave, can be worked around, or belongs in a later fix. Without named ownership, technical teams can spend hours debating issues that require a business decision.

Design Host Pools, Sizing, and Scaling

Host pool design should follow user personas and measured load. Don’t size from employee count alone because only concurrent sessions create host demand. Group users by application mix, performance needs, security requirements, working hours, and region. A task worker with browser and Office apps may fit a different pooled density from an engineer who runs memory-heavy software. Some users may require personal desktops if applications or security controls don’t fit a shared session.

For pooled host pools, choose a load-balancing approach that matches the operating goal. Microsoft documents breadth-first and depth-first host-pool load balancing. Breadth-first spreads sessions across available hosts, while depth-first fills hosts toward a defined session limit. Test the choice with real workloads because VM size, application load, profile activity, and logon storms can change the practical session density.

Scaling should use measured daily patterns. Microsoft’s Azure Virtual Desktop autoscale guidance describes schedules for ramp-up, peak, ramp-down, and off-peak periods, along with capacity thresholds. A company with sites in several time zones may need separate host pools or scaling schedules so one region doesn’t stay fully powered because another region is still working.

Cost planning should include more than VM hours. Add profile and image storage, monitoring ingestion, network services, private connectivity, backup, security services, and licensing changes. Model a normal day and a high-demand day so the team can see which settings make cost rise when user count, profile size, or logging volume changes.

In the Azure Virtual Desktop migration checklist, define a minimum production capacity for each wave. The pilot may run on a small host pool, but the first production wave needs enough headroom for login bursts, patching, one host being unavailable, and unexpected application load. Record the accepted maximum session limit and the metrics that trigger a sizing change after go-live.

Build Security, Monitoring, and Recovery Controls

Security controls should be tested in the same path users will use after migration. Conditional Access, multifactor authentication, session lock behavior, device compliance rules, clipboard or drive redirection policy, local administrator restrictions, and privileged access should all be part of the pilot. Security that is added after users move can change login behavior or break required workflows, which makes troubleshooting harder.

Monitoring needs to exist before the first production wave. Microsoft’s Azure Virtual Desktop Insights guidance uses Azure Monitor Workbooks and Log Analytics data from AVD resources and session hosts. Build dashboards and alerts for connection failures, host availability, session counts, CPU, memory, profile issues, and network quality before cutover so the support team has a baseline from the pilot.

Recovery planning must cover customer-managed parts of the service. Microsoft’s multiregion BCDR guidance for Azure Virtual Desktop separates the Microsoft-managed control plane from items such as session hosts, profiles, applications, user data, and identity that the customer must plan for. Decide what happens if a session-host region, profile store, network connection, or on-premises application becomes unavailable.

Site failure scenarios also need written answers. If an office loses internet access, can users work remotely or from another location? If a WAN path fails, is there another route to required systems? If an Azure region has an outage, which users receive recovery service first? Put those decisions in runbooks before an incident.

Keep recovery targets realistic. Some departments may need a short recovery time, while others can accept a longer outage. Record the recovery time objective and recovery point objective for the desktop service, profile data, and application data separately. Then test the parts you control, including profile restore, host recreation, image availability, DNS changes, and user reassignment.

Run a Pilot by Persona and Site

A pilot should represent the risks in the production rollout, not the easiest users. Select users from different sites, time zones, job roles, application sets, and device types. Include at least 1 user from a smaller branch with a different network path and at least 1 user who depends on a critical local or legacy application. This is where network design, profile design, and application assumptions are tested together.

Build a pilot scorecard with pass or fail criteria. Test sign-in time, session stability, app launch, print and scan workflows, audio and video, file access, profile persistence, reconnection, password or token changes, and sign-out. Record network transport and latency during the same tests. User comments matter, but the team also needs technical measurements so a vague complaint such as “it feels slow” can be traced to a host, profile, application, or network cause.

The Azure Virtual Desktop migration should stay reversible during the pilot. Keep the old access method available and document how a pilot user returns to it. For FSLogix profile migration, make sure support knows which profile path is active and how to avoid users making conflicting changes in 2 environments. If an application has a blocking defect, the rollback should take minutes of known steps rather than a new design decision.

Use the pilot to train support staff. Service desk teams should practice finding sessions, checking host health, reading AVD Insights, identifying profile problems, reviewing sign-in logs, and confirming network status. A pilot that only project engineers can support isn’t ready for broad rollout.

Don’t close the pilot on a calendar date alone. Close it when the agreed tests pass for the selected personas and sites, the open defects have owners, and the migration board accepts the remaining risk. This keeps later waves from repeating the same unresolved problem at a larger scale.

Execute Migration in Controlled Waves

Migration waves should be small enough to support but large enough to reveal real production behavior. Group users by site and persona where possible because that keeps network paths, support ownership, and application needs consistent inside the wave. Avoid mixing many small groups from unrelated sites just to reach a target user count. That makes failures harder to trace and increases the number of support teams involved at once.

Each wave should have a pre-cutover gate. Confirm user assignments, host capacity, image version, application availability, profile readiness, DNS, network paths, monitoring, support staffing, communications, and rollback steps. The Azure Virtual Desktop migration checklist should be signed off by named owners rather than treated as a shared document that everyone assumes someone else reviewed.

Run cutover during a window that matches the site’s business reality. A global company may have overlapping shifts, weekend operations, or month-end finance work that make a single standard change window unsuitable. For the multi-site AVD deployment, keep a site calendar that flags payroll, close, warehouse peaks, customer events, and other periods when desktop disruption carries extra business cost.

During cutover, move users in a controlled order. Start with a small validation group, confirm login and key applications, then release the rest of the wave. Watch connection failures, host load, profile attach time, storage latency, and service desk tickets. If a threshold is crossed, stop adding users until the cause is known. A pause is safer than turning a contained issue into a site-wide outage.

Continue post-cutover checks through the next normal business cycle for that site. Review peak-hour performance, login spikes, profile failures, repeated disconnects, support themes, and application defects. The first hour can look healthy while problems appear when the full user group returns.

Final Migration Readiness Check

Close the project only when normal operations can run without the migration team acting as the permanent support desk. The final Azure Virtual Desktop migration review should confirm host-pool ownership, image patching, scaling based on real usage, profile monitoring, access reviews, and escalation paths. Documentation must match the environment that was actually built.

Use this final Azure Virtual Desktop migration checklist before retiring old desktop infrastructure:

• Every site in scope has passed latency, connectivity, DNS, and required endpoint tests.

• Every production persona has an accepted host pool, image, application set, and access model.

• FSLogix profile migration is complete or the new-profile rule is documented for all users.

• Network planning records match the final firewall, proxy, VPN, ExpressRoute, and routing setup.

• Monitoring and alert ownership are active for connection, host, profile, storage, and network issues.

• Recovery runbooks cover session hosts, profile storage, applications, user data, identity, and site connectivity.

• Rollback periods have ended only after business owners accepted each wave.

• Old infrastructure is retired through change control after data retention and recovery needs are met.

A multi-site AVD deployment is ready when the platform behaves predictably across different offices and the operating team can detect, isolate, and recover from failures without rebuilding the migration plan. That is the point where the checklist has done its job and the environment can move into normal service management.

Frequently Asked Questions

What Is the First Step in an Azure Virtual Desktop Migration for Multiple Sites?

Start with a site-level inventory rather than building host pools immediately. Record users, concurrency, applications, profiles, devices, network paths, and support limits for each office. Then test latency to candidate Azure regions. This gives the Azure Virtual Desktop migration a factual base for region choice, host-pool design, profile storage, and wave planning.

How Many Azure Regions Should a Multi-Site Company Use for AVD?

There’s no fixed number. Use measured latency, application and data location, recovery needs, and operating effort to decide. Some companies can support several sites from 1 region. Others need regional host pools because users or back ends are spread across distant locations. Keep user assignments and profile storage aligned with the regional design.

What Latency Is Acceptable for Azure Virtual Desktop?

Microsoft recommends round-trip time below 150 ms from the client network to the Azure region containing the host pool for the best experience. Lower is better for interactive work. Test each major site during business hours because branch routing and congestion can differ from headquarters.

Should Every Office Have Its Own Host Pool?

No. A host pool should represent a technical and operating boundary, not automatically a physical office. Sites can share one when region, image, application set, security rules, performance needs, and working hours align. Separate pools make sense when those requirements differ enough to create exceptions or poor performance.

How Should We Handle FSLogix Profile Migration?

Decide whether each persona should receive migrated profiles or clean profiles with selected user data moved across. Keep target profile storage in the same region as the session hosts where possible. Test permissions, profile attach, sign-in time, OneDrive, Outlook, app settings, and profile growth. Keep the old source during the rollback period.

Can Azure Virtual Desktop Use On-Premises Applications and File Shares?

Yes, if session hosts have network connectivity, DNS resolution, required ports, authentication, and acceptable latency to those systems. Test from the Azure session host rather than the user’s physical PC. Applications that make many back-end calls may need the back end moved closer to the host pool.

What Should AVD Network Planning Include?

AVD network planning should cover Microsoft service endpoints, client paths, session-host egress, DNS, firewall and proxy behavior, routes to applications and data, private connectivity, and site bandwidth. Test the actual remote-session transport too. Each major office needs its own results because network policies and egress paths can differ.

Should We Use RDP Shortpath During Migration?

Use it when it fits the network and security design and testing shows a benefit. The required UDP paths must be available for the chosen mode. Validate each representative site because NAT, firewall, or proxy behavior can differ. Keep the supported fallback path working.

How Do We Size AVD Session Hosts Before Go-Live?

Start with user personas, peak concurrent sessions, application behavior, and pilot measurements. Choose a VM family and size, set a session limit, then observe CPU, memory, disk, profile activity, and user experience under realistic load. Keep spare capacity for login bursts, maintenance, and a host outage.

What Should Be Included in an AVD Pilot?

Include users from different sites and roles, plus applications and devices most likely to expose risk. Test authentication, profile persistence, app launches, file access, printers, scanners, audio, video, reconnection, and support workflows. Record technical measurements and user acceptance. Keep rollback available until exit criteria are met.

How Large Should Each Migration Wave Be?

Choose a wave size the support team can handle if several users need help at once. The number depends on site size, application risk, support coverage, and pilot results. Start smaller for complex sites or critical teams. Increase later waves only after earlier waves show stable patterns.

Do We Need a Rollback Plan for Every Site?

Yes. Network paths, applications, support hours, and business constraints can differ by site, so rollback should be defined at the same level. State how users return to the old desktop, how profile changes are handled, who approves rollback, and how long the old environment remains available.

When Can We Retire the Old VDI or Desktop Environment?

Retire it after production waves are accepted, rollback periods have ended, required data is retained, support is stable, and recovery procedures are tested. Removing the old platform too early can turn a fixable defect into an outage. Use formal change control and business-owner approval.

How Should We Monitor Azure Virtual Desktop After Migration?

Track connection failures, host health, session counts, CPU, memory, sign-in behavior, profile issues, storage health, and network quality. Keep a pilot baseline and compare later sites against it. Alerts need named owners and response steps so support knows what action follows.

What Is the Biggest Risk in a Multi-Site AVD Deployment?

The biggest risk is assuming all sites behave like the main office. Differences in latency, WAN routes, firewall policy, local devices, application dependencies, support coverage, and working hours can change the result. Treat each site as a testable environment while keeping shared standards where requirements match.