The new Outlook for Windows is not ready for most enterprises yet

In many of the Microsoft 365 tenants I work with, classic Outlook for Windows now shows the "Try the new Outlook" toggle. Now that we're in February 2024, IT teams keep asking me what this new Outlook for Windows actually is and how they should handle the transition. Microsoft has been clear about where this is going. Over time, the new Outlook will replace classic Outlook as well as the Mail and Calendar apps in Windows. Commercial tenants can already use the preview, but it's opt-in and differs from classic Outlook in some significant ways.

The new Outlook for Windows runs on the Outlook on the web codebase

The new Outlook for Windows relies heavily on the Outlook on the web (OWA) codebase. That gives you a modern, consistent interface, but it also brings a number of functional differences. Plenty of scenarios from classic Outlook are missing or work differently. The most important one is that traditional COM and VSTO add-ins are not supported. Only modern web add-ins work (Microsoft documents the details here). PST handling is limited too. You can't import or export PST files the usual way, and local archives don't work. Offline support is partial at best. If you rely on shared mailboxes or several Exchange accounts, expect more limitations. All in all, the experience is much closer to OWA and shares many of its technical dependencies (see the OWA documentation).

An add-in inventory is the first real step

I regularly see users flip the new Outlook toggle out of curiosity and then quickly notice that important functions or add-ins are gone. Frustration follows soon after. In organizations that still depend on classic add-ins (COM/VSTO), this turns into a real headache. My strongest advice is to start with a thorough inventory of every Outlook add-in that is actually used in production. Only then will you get a realistic picture of the functional gaps you're facing. PowerShell on the affected machines is a quick way to collect the data:

Get-ItemProperty HKCU:\Software\Microsoft\Office\Outlook\Addins\*

Pro tip: Listing the installed add-ins isn't enough. Find out which ones people actually use, because some are installed and never touched.

With that as your basis, you can put together a sensible migration plan and won't be caught off guard when a business-critical add-in turns out to be unsupported.

Admins should control the toggle instead of leaving the switch to users

Microsoft gives organizations tools to manage the rollout. The main one is the registry or Group Policy value "HideNewOutlookToggle", which hides the toggle in classic Outlook (see the documentation).

Here is a sample registry entry:

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Options\General]
"HideNewOutlookToggle"=dword:00000001

This keeps users from switching on their own and possibly cutting themselves off from their workflows. To block the new standalone Outlook app (from the Microsoft Store), use Intune's app block list to do it centrally. Also keep in mind that many settings and restrictions from Outlook on the web, OWA mailbox policies for example, automatically apply to the new Outlook for Windows.

A pilot group should come before any wider migration

In my experience, rolling out the new Outlook for Windows is never just a matter of flipping a switch. Rather than moving everyone at once, I recommend a focused pilot with a handful of users from different departments and roles. That way the real blockers show up, and you get feedback before you enable the toggle for everyone. People tend to underestimate how much their workflows change once add-ins or offline features are missing. If you're still on classic Outlook, raise the topic with stakeholders early and fit it into your overall Microsoft 365 strategy.

To show how the different Outlook clients relate to each other and which ones will be replaced, I put together a Mermaid diagram of the current relationships in a typical organization:

flowchart TD
  ClassicOutlook["Classic Outlook"] -->|"Toggle"| NewOutlook["New Outlook for Windows"]
  NewOutlook -->|"Web-based"| OWA["Outlook on the web"]
  OWA -- "Mailbox policies" --> Policies["OWA policies"]
  ClassicOutlook -- "COM/VSTO add-ins" --> Addins["Add-in compatibility"]
  NewOutlook -- "Web add-ins" --> Addins
  NewOutlook -- "Limitations" --> Limits["Feature gaps"]

Figure: The current connections between classic Outlook, new Outlook, OWA and policies.

I see a new era for Outlook, but the move is not a sprint

From a technology standpoint, the new Outlook for Windows is exciting. For enterprise use in early 2024, though, a lot is still unresolved. A structured approach works best. Look at your add-ins, business processes and user groups, and run a pilot before you open the toggle to everyone. Across many tenants the pain points are surprisingly similar (missing add-ins, weak offline support and unclear policy handling). Dealing with them early saves you trouble later on. And if you're already working on other projects such as the migration to the new Teams client, this could be a good moment to think about Outlook's future as well.