Fix New Teams Migration Does Not Complete in Azure Virtual Desktop

When you deploy the new Microsoft Teams client in Azure Virtual Desktop, the migration from the classic Teams app can stall or fail to complete. You see the migration prompt, but the process never finishes, leaving users stuck on the old client. This happens because the Teams migration in AVD depends on specific registry keys, user profile permissions, and the order of installation steps. This article explains the root cause and provides a step-by-step fix to force the migration to complete reliably.

You will learn how to verify the migration status, correct the registry configuration, and apply the required policy settings. The fixes below work for both pooled and personal host pools in Azure Virtual Desktop. After applying them, the new Teams client will replace the classic app without user intervention.

Why the New Teams Migration Fails in Azure Virtual Desktop

The migration from classic Teams to the new Teams client relies on a bootstrapper that runs during user sign-in. In Azure Virtual Desktop, this bootstrapper often fails because the host pool image contains an older version of the Teams bootstrapper or because the user profile lacks write permissions to the Teams installation folder. Another common cause is the presence of the registry key that forces the classic Teams client to remain the default. When that key is set, the new Teams client cannot take over, and the migration appears to hang or never start.

The migration process checks several conditions before it proceeds. It verifies that the user has the correct licenses, that the network can reach the Teams download servers, and that the local policy allows the bootstrapper to run. In AVD, the default user profile may have the Teams app installed per machine, which complicates the migration because the new Teams client installs per user. This mismatch causes the migration to stop silently.

The Role of the Teams Bootstrapper

The Teams bootstrapper is a small executable that downloads and installs the new Teams client. It runs when a user signs in and checks the current Teams version. If the bootstrapper is outdated, it may not recognize the new Teams client and will keep trying to install the classic version. In AVD, the bootstrapper is often updated through the image, but if the image is not refreshed, the migration will fail.

User Profile Permissions and the Migration

The new Teams client installs into the user’s AppData folder. If the user profile is not writable or if the profile is a mandatory profile, the installation fails. In AVD, you must ensure that the user profile has full control over the AppData\Local\Microsoft\Teams folder. Otherwise, the migration process cannot copy the necessary files.

Steps to Force the New Teams Migration to Complete

The following steps apply to both Windows 10 and Windows 11 multi-session images used in Azure Virtual Desktop. Perform them on the golden image before you capture it, or on a live session if you are testing the fix.

1. Uninstall the classic Teams app from the image
   Sign in as a local administrator. Open Control Panel > Programs > Programs and Features. Select Microsoft Teams and click Uninstall. This removes the per-machine installation that blocks the migration.
2. Delete the Teams registry key that locks the classic client
   Open Registry Editor as administrator. Navigate to HKLM\SOFTWARE\Microsoft\Teams. If the value IsWAMDefault exists and is set to 1, change it to 0. If the key does not exist, create it as a DWORD value with a value of 0.
3. Install the latest Teams bootstrapper
   Download the Teams bootstrapper from the Microsoft 365 admin center or use the direct link https://go.microsoft.com/fwlink/?linkid=2196106. Run the installer with the command msiexec /i teamsbootstrapper.msi. This installs the bootstrapper that will trigger the migration on the next sign-in.
4. Set the Group Policy to allow automatic updates
   Open the Group Policy Management Console. Navigate to Computer Configuration > Administrative Templates > Microsoft Teams. Set the policy “Do Not Update Teams Automatically” to Disabled. This allows the bootstrapper to download the new Teams client without being blocked.
5. Verify the migration on a test user
   Sign in with a test user account. The new Teams client should start automatically. Check the version by selecting the profile picture and then About. The version should be 1.6.00 or higher. If the classic client still appears, repeat the registry check and confirm the bootstrapper installation.

If the Migration Still Does Not Complete

When the migration fails after the steps above, the issue is often related to the FSLogix profile container. The new Teams client stores data in the user profile, and if the profile container is not configured to support the new client, the migration cannot write the necessary files.

1. Check FSLogix profile container settings
   Open the Registry Editor on the host. Navigate to HKLM\SOFTWARE\FSLogix\Profiles. Ensure that the value VHDLocations is set to a valid storage path and that the value Enabled is set to 1.
2. Enable the Teams data in the profile container
   In the same registry key, create a new DWORD value named IncludeTeams and set it to 1. This tells FSLogix to include the Teams data folder in the profile container.
3. Restart the session and test again
   Sign out and sign back in. The migration should now complete because the profile container allows the new Teams client to write its data.

If Teams Still Has Issues After the Main Fix

Teams Shows a Blank Window After Migration

A blank window indicates that the new Teams client cannot render because the WebView2 runtime is missing or outdated. Install the latest Microsoft Edge WebView2 runtime from the Microsoft website. After installation, restart the Teams client.

The Migration Prompt Reappears Every Sign-In

If the migration prompt appears repeatedly, the bootstrapper is not detecting that the new Teams client is installed. Check the registry key HKLM\SOFTWARE\Microsoft\Teams\IsWAMDefault. If it is set to 1, change it to 0. Also verify that the new Teams client is installed under the user’s AppData folder, not the system folder.

Classic Teams Reinstalls After the Migration

This happens when the image provisioning process includes a script that reinstalls the classic Teams app. Remove that script from the image or modify it to skip the installation if the new Teams client is present. Also check the scheduled tasks in Task Scheduler that may run the Teams installer at logon.

New Teams Desktop vs Classic Teams in AVD: Key Differences

Item	New Teams Desktop	Classic Teams Desktop
Installation method	Per user, installed in AppData	Per machine, installed in Program Files
Resource usage	Lower memory and CPU usage	Higher resource consumption
Update frequency	Automatic updates via bootstrapper	Manual updates through the admin center
Profile compatibility	Requires FSLogix IncludeTeams setting	Works with standard profile containers
Migration trigger	Bootstrapper runs at sign-in	Not applicable

You now have the steps to force the new Teams migration to complete in Azure Virtual Desktop. Start by cleaning the image, fixing the registry, and installing the latest bootstrapper. Next, test the migration with a single user before rolling out to the entire host pool. For persistent issues, check the FSLogix profile container settings and the WebView2 runtime version.