In many of the tenants I work with, the new Microsoft Teams client is now showing up, at least as an option. Microsoft released it for Windows and Mac in October 2023, and admins have been talking about it ever since. It no longer runs on Electron but on Edge WebView2. That brings faster startup and lower memory use, and, finally, proper support for multiple tenants and accounts. If you've ever had to work across several organisations or identities, you know how annoying the old limits were. Even so, I wouldn't rush the move from classic Teams to the new client. Microsoft plans to retire the classic version later this year, and more users see the new interface every day.

The new Microsoft Teams client is a real step forward for most users

Technically, the new client is a clear improvement. It opens faster and responds more quickly, and you notice the difference most on older hardware. The part I like best is the multi-tenant and multi-account support. Working across organisations no longer means signing out all the time or keeping extra browser tabs open. Feature parity isn't complete yet, though. In several projects I've seen third-party apps or custom add-ins (the Outlook meeting add-in in particular) with quirks or compatibility gaps. Not every tenant is affected, but if you run nonstandard integrations, test them carefully.

The Teams update policy controls how the rollout happens

For a rollout at scale, the Teams update policy in the Admin Center is the tool you need. With the "Use new Teams client" setting you decide whether users can switch on their own or whether the new client is enforced centrally. Large organisations and environments with a lot of VDI need that control, or you end up with confusion and a pile of support tickets. Microsoft documents the policy options well (here).

Many organisations begin by offering the new client as opt-in so they catch problems early, such as add-ins or settings that don't migrate the way they should. In my experience, a staged rollout with pilot groups always saves trouble later on. Don't neglect communication either. A short email or a Teams announcement before the interface changes goes a long way.

When testing your Teams update policy, always include a few users who rely on complex third-party apps or integrations. They’ll be the first to spot real-world issues.

Deployment needs some thought too. On managed devices and in VDI, the Teams Bootstrapper installs the new client automatically, so you need far fewer manual installs:

# Example: Silent install of the new Teams client
teamsbootstrapper.exe -p

The Bootstrapper looks for existing versions and updates them where needed, which helps a lot in big rollouts and shared environments.

Outlook add-ins and other integrations still need careful testing

The client itself is stable, but some integrations still have edge cases. Outlook add-ins can be fussy, the Teams meeting add-in especially, and mixed Office versions or legacy configurations make that worse. Most tenants run without trouble. In a handful of environments, though, I've seen calendar sync glitches or buttons that simply weren't there. If you rely on custom apps or heavily used third-party integrations, test them properly before you move everyone over.

This is the short checklist I use:

  • Which third-party apps and add-ins are widely used?
  • Any known issues with these in the new client?
  • Do pilot users cover those with special requirements?
  • Is the Outlook meeting add-in working as expected?

Tell users up front about possible compatibility gaps. In tenants with many power users or custom workflows, it has paid off for me to brief the support team on the likely problems and to write a short FAQ.

Users feel the switch more than admins tend to expect

For many people the change comes as a surprise, particularly if they've used classic Teams for years. Take their side of it seriously. The visuals are new, some workflows work a little differently and notification settings have changed. The "Switch to new Teams" toggle will become more prominent over time, and once classic Teams is retired, nobody can avoid it. Clear communication and support early on make the move a lot easier.

Before any full rollout I run a pilot with users from several departments. Their feedback shows blockers and training needs that I might otherwise miss. People often forget about notification and personal settings, which don't always carry over cleanly. A short how-to or FAQ helps a great deal here.

The switch to the new Teams client follows a clear sequence

The Mermaid flowchart below shows the main steps from classic Teams to the new client and how the update policy, the user's choice and the client installation fit together:

flowchart TD
    Start["Start" ] --> Policy["Set Teams update policy" ]
    Policy --> UserChoice["User sees switch option" ]
    UserChoice --> Switch["User switches client" ]
    Switch --> Install["New client installs" ]
    Install --> Test["Test app/add-in compatibility" ]
    Test --> Rollout["Continue use/ Rollout" ]

Figure: Flow for switching from classic to new Teams client.

I recommend testing early and moving at a steady pace

The new Microsoft Teams client can look like a routine update, but my project experience says it isn't. Careful testing, communication in stages and attention to how people actually work will spare your IT team a lot of trouble. There are still rough edges, mostly around app compatibility, yet the new client is already much better than the old one. With the end of availability for the classic client getting closer, you don't have much time left to wait.