New Outlook for Windows and Email Signatures: What IT Admins Need to Know Before Migrating

TL;DR: New Outlook for Windows is architecturally different from classic Outlook — and not in a cosmetic way. It uses an entirely different add-in framework. COM-based (VSTO) add-ins, which many email signature tools have historically relied on, do not work in new Outlook at all. If your current signature tool uses this model, migration will break it. This article explains what changed, what the timeline looks like, how to audit your current tool, and how to use this moment to make a better architectural decision.

Two Outlooks, two completely different add-in models

If your organisation uses Microsoft 365 and runs Outlook on Windows, you are likely in a period where some users are on classic Outlook and some have already moved — or been moved — to new Outlook. These are not the same application with a different interface. They are built on fundamentally different technology stacks.

Classic Outlook for Windows (sometimes called legacy Outlook) is a native Windows application that has existed in various forms since 1997. Its add-in model is based on COM (Component Object Model) and VSTO (Visual Studio Tools for Office) — compiled, Windows-specific code that runs in-process with the Outlook application.

New Outlook for Windows is built on a web-based architecture, using the same underlying engine as Outlook on the web (OWA). Its add-in model is the modern Office Add-ins framework — HTML, CSS, and JavaScript running in a sandboxed web view, the same model already used by Outlook on Mac, OWA, and Outlook Mobile.

These two models are not compatible. A COM add-in written for classic Outlook cannot run in new Outlook. An Office Add-in written for new Outlook cannot run in classic Outlook. They are different systems entirely.

Why this matters for email signatures specifically

Email signature management tools that are built on the COM add-in model will stop working when users move to new Outlook. The add-in simply will not load. Depending on the tool’s architecture, this may mean:

Signatures stop appearing in the compose window entirely
The tool’s client-side component fails silently, with no error visible to the user
Some functionality falls back to server-side signature injection — but only if the vendor offers that as an alternative

This is not a theoretical future problem. The opt-out phase for new Outlook began in early 2026, meaning some users are already switching — either deliberately or because Microsoft has defaulted them into it. Organisations that have not explicitly asked their IT team about this are likely discovering the gap reactively, when users report that signatures are missing or broken.

The migration timeline

Microsoft has been communicating this transition for several years, but the concrete dates have shifted more than once. The current picture as of early 2026:

New Outlook rollout: New Outlook for Windows has been available as an opt-in since 2023 and has been gradually enabled by default across Microsoft 365 tenants from late 2024 onward.
Opt-out period: Organisations can currently prevent the automatic switch by policy. This opt-out is expected to remain available until classic Outlook’s retirement timeline solidifies — Microsoft has extended deadlines previously, but the direction of travel is not in doubt.
Full retirement from M365 subscriptions: Expected around 2028, after which classic Outlook will no longer be available as part of a Microsoft 365 subscription.
End-of-life support: Extended through at least 2029 for organisations running perpetual licence versions (Office 2021, Office 2024).

The practical implication: if your organisation runs Microsoft 365, you will migrate to new Outlook. The question is when, and whether your signature management tool is ready.

How to audit your current signature tool

The first step is establishing which add-in model your current tool uses. This is not always obvious from vendor documentation — some vendors have rebuilt their products to support the modern framework, some support both, and some are still COM-only.

Questions to ask your vendor:

Is your Outlook integration built on COM/VSTO, or the modern Office Add-ins framework (Office.js)? A vendor that cannot answer this directly is a concern.
Does your product support new Outlook for Windows specifically? “We support Outlook” is not sufficient — classic and new Outlook are different applications. Ask about each by name.
Is the same add-in manifest used for both new Outlook and classic Outlook, or are they separate deployments? Tools built on the modern framework typically deploy via a single manifest through Microsoft 365 Centralised Deployment, which works across new Outlook, Outlook on Mac, and OWA without separate installation.
If your primary model is COM-based, do you have a server-side fallback? Some tools that historically used COM add-ins have pivoted to server-side signature injection as their new Outlook story — which means email is now routed through their infrastructure. That is a different architecture with different tradeoffs (including GDPR implications) that you should understand before accepting it as the migration path.
What is your roadmap for new Outlook support? If a vendor is still working on it, get a timeline and evaluate whether it fits your migration schedule.

Red flags to watch for:

Vague answers about “Outlook support” without distinguishing classic from new
A vendor that describes their new Outlook solution as “coming soon” with no firm date
A vendor that pivots to server-side routing as their new Outlook answer without explaining what that means for data processing
Documentation that describes an installation process involving a local installer or desktop agent — indicators of a COM-based approach

What “new Outlook compatible” actually means

A tool that genuinely supports new Outlook for Windows will be built on the modern Office Add-ins framework (sometimes called Office.js or the Web Add-ins model). The characteristics of this model:

Cross-platform by design. The same add-in works in new Outlook for Windows, Outlook for Mac, Outlook on the web, and Outlook Mobile. Organisations that have historically had gaps in Mac or OWA coverage will often find these close automatically when they move to a properly built modern add-in.

Centralised Deployment. The add-in is deployed from the Microsoft 365 admin centre — no per-device installation, no user action required. An admin publishes the manifest to all users (or specific groups), and Outlook loads the add-in automatically. Changes to the add-in configuration deploy centrally without touching individual machines.

Compose-time signature injection. The add-in runs inside Outlook’s compose window and injects the signature before the email is sent. Employees see the correct signature as they write. The email never passes through any external server on the way to the recipient.

Sandboxed by design. The modern add-in framework does not have access to the email body content — it can inject a pre-rendered signature into the compose window, but it cannot read or modify the email body at send time. This is an architectural constraint of Office.js, not a policy choice, and it is what makes the add-in model GDPR-friendly: there is no data processor relationship for email content, because the content is never accessed.

Using the migration as a review moment

The Outlook transition creates a forcing function. If your current tool will not survive the migration, you need a new one. That is a constraint — but it is also an opportunity to make a deliberate choice rather than inheriting whatever was set up years ago.

Two questions worth asking while you have the budget and attention:

Server-side or add-in? Server-side tools apply signatures after the email is sent, by routing email through the vendor’s infrastructure. This works in classic Outlook, new Outlook, mobile, and every other client — because it happens at the mail flow level, not the client level. But it makes the vendor a data processor of your email content, requires a Data Processing Agreement, and means every outbound email passes through a third party. The add-in model avoids all of this, at the cost of not covering non-Outlook clients. Which matters more for your organisation?

What does your compliance function think? If your DPO has not been asked about the email routing architecture of your signature tool, the Outlook migration is the right moment to surface that question. Understanding the difference between server-side and add-in architecture, and what each means for GDPR obligations, will inform both the tool choice and the vendor contract. For more on this, see Email Signature Management for Microsoft 365: Server-Side vs Add-In — What’s the Difference?.

For a broader overview of how signature management works across M365 — including how Centralised Deployment, transport rules, and add-ins compare — see the complete guide to centralised email signatures in Microsoft 365.

And if you are at the beginning of this process and want to understand the full landscape before talking to vendors, how to manage email signatures across a company maps the problem space without assuming any particular solution.

Frequently asked questions

Will my existing signatures break automatically when users switch to new Outlook?

It depends on how your current tool works. If it uses a COM add-in as its primary delivery mechanism, yes — the add-in will not load in new Outlook and signatures will stop appearing in the compose window. If your tool uses server-side injection (signatures applied after send via mail flow rules), those will continue to work regardless of what client the user is on. If your tool uses the modern Office Add-ins framework, it will continue to work. Check with your vendor before any migration begins.

Can I delay the migration to new Outlook until my signature tool is ready?

Yes, for now. Microsoft provides administrative controls to prevent automatic switching to new Outlook. Your Microsoft 365 admin can set policies to keep users on classic Outlook. However, this is a delay, not a permanent solution — classic Outlook will be retired from M365 subscriptions and the opt-out controls will eventually be removed. Use the delay to get your signature tooling in order, not to avoid the question indefinitely.

Does switching to new Outlook affect server-side signature tools?

No. Server-side tools apply signatures at the mail flow level, after the email is sent, regardless of which client the user sent from. A user on new Outlook sending through Exchange Online will still have their signature applied if a transport rule or server-side tool is in place. The Outlook client is irrelevant to server-side delivery.

What is Centralised Deployment and do I need it for add-in-based signature tools?

Centralised Deployment is Microsoft’s mechanism for distributing Office Add-ins to users in your organisation from the Microsoft 365 admin centre. Most modern add-in-based signature tools deploy this way — you publish the add-in manifest once, and it propagates to all licensed users automatically. It requires Exchange Online mailboxes and an admin with Global Admin or Exchange Admin permissions. The main consideration is propagation time: new users or policy changes can take up to 24 hours to apply across the tenant.

If my tool supports both classic Outlook and new Outlook, what does that mean architecturally?

It typically means the vendor has built two different integration layers — a COM add-in for classic Outlook and a modern Office Add-in for new Outlook — and manages the transition between them. In some cases, vendors have moved entirely to server-side delivery as their “works everywhere” solution. Ask your vendor explicitly which model applies in each client, and whether the two experiences are equivalent or whether one has fewer features than the other.