New Outlook Add-Ins: The 2026 IT Migration Guide

By Amin Soltani, Founder of Professionally 11 min read

Migrating to the web-based client means leaving legacy extensions behind. Here is the exact framework IT teams need to audit new Outlook add-ins, replace broken COM tools, and navigate the October 2026 EWS retirement without disrupting daily workflows.

Mid-market IT teams managing 100 to 1,000 employees face mounting pressure in 2026 to evaluate the new Outlook. With Microsoft extending classic Outlook support to at least 2029, but new features flowing exclusively to the web-based client, administrators must determine which add-ins will continue functioning after migration.

The core issue is architectural. The new Outlook runs on a sandboxed webview model that rejects legacy extensions entirely. Only web-based add-ins built with JavaScript, HTML, and the Office JS API are supported. This shift eliminates the instability that plagued classic Outlook but demands a complete inventory of current extensions. Organizations ignoring this step encounter broken CRM logging, compliance failures, and frustrated sales teams who can no longer complete daily workflows inside their inbox.

Recent 2025-2026 developments have accelerated these decisions. Microsoft rolled out a classic-style theme for the new Outlook in August 2026 to ease visual transition, while confirming that legacy COM support will never return. Exchange Web Services (EWS) phased disablement begins October 1, 2026, with full retirement on April 1, 2027, directly affecting any add-in still making EWS calls. Teams that delay auditing now risk sudden workflow breakage within months.

This guide draws from real deployments across Outlook-heavy teams. It provides the exact checks, repeatable frameworks, and migration patterns that prevent the most common disruptions.

The architecture shift

New Outlook vs. Classic Outlook: Add-In Support

The difference is not incremental: classic Outlook supports the full legacy extensibility stack, while the new Outlook exclusively supports web add-ins. Microsoft states this is permanent due to the web-based architecture designed for stability, cross-platform consistency, and sandboxed execution.

Key distinctions IT admins track:

Offline capabilities also diverge. Classic Outlook offers a full local cache. The new client provides limited offline support with a maximum 180-day cache in many configurations. PST handling improved in 2026 but remains partial for import operations. Shared mailbox delegation and certain administrative scenarios still favor classic for complex environments.

For IT admins in mid-market M365 organizations, the practical implication is clear: treat the new Outlook as a greenfield environment for extensibility. Assume nothing from your current inventory transfers automatically.

Legacy limitations

Why COM Add-Ins in the New Outlook Fail

COM add-ins operate with high privileges inside the classic desktop client, which frequently caused crashes, performance degradation, and conflicts when multiple add-ins targeted the same mail item. They can manipulate any surface, inject UI elements, and directly access the Outlook object model.

Microsoft has placed these legacy extensions in maintenance mode. No new development occurs, and the new Outlook excludes them by design. Web add-ins run in a browser-like sandbox with strict permission models and fixed entry points. This eliminates the crash vectors that plagued enterprise deployments for years.

We've seen this firsthand across sales organizations using legacy Salesforce or DocuSign integrations. When they switch clients, they suddenly lose the ability to log emails or generate documents directly from messages. Customer service teams relying on compliance add-ins for archiving or redaction cannot complete their process. The result is shadow IT as users export emails to desktop tools or adopt disconnected workflows. (Sound familiar?)

The 14 most common legacy scenarios, representing approximately 95% of actual usage, now have viable web add-in or native Microsoft 365 equivalents according to Microsoft's migration analysis. The remaining long-tail solutions require vendor engagement or process redesign.

The modern standard

Outlook Web Add-Ins: The Foundation for Reliable Deployments

Outlook web add-ins use a manifest file to declare activation rules, commands, and task panes, running identically across all modern Outlook clients. This consistency reduces IT testing overhead significantly.

Current capabilities in the new Outlook include:

• Mailbox requirement sets up to version 1.16 (supporting message decryption, EWS token detection, and smart alerts).
• Seamless activation on mail items and appointments.
• Integration with Microsoft Graph for data operations (replacing EWS).
• Centralized deployment via Microsoft 365 admin center with group-based targeting.

Web add-ins cannot perform every action legacy solutions could. They lack direct access to certain local system resources and have more constrained UI patterns. However, they deliver superior reliability and security. Sandboxing prevents one faulty add-in from destabilizing the entire client.

For communication-heavy roles, this model proves particularly effective. Tools that analyze or enhance message content operate efficiently without loading the full desktop runtime. This is where modern solutions focused on tone, clarity, and grammar deliver immediate value without the overhead or risk of older extensions. While tools like Grammarly offer broad writing assistance, their enterprise deployment often requires extensive endpoint management and data privacy reviews.

Professionally, an AI-powered email rewriting tool that works natively inside Outlook, exemplifies this lightweight web-based approach. It processes messages for tone, clarity, and professionalism then discards the data immediately, aligning with the zero data retention best practices that IT teams demand in 2026. Across the 100+ companies using it daily, this architecture ensures zero endpoint drag.

The ticking clock

EWS Retirement for Outlook Add-Ins: The October 2026 Deadline

The EWS retirement timeline represents the most urgent forcing function for many organizations, with phased disablement beginning October 1, 2026. Full permanent retirement occurs April 1, 2027. Any add-in or integration still using EWS calls to Exchange Online will stop functioning unless explicitly allowed via the new EWSAllowedAppIDs mechanism.

This affects more than just add-ins. Custom applications, CRM sync tools, backup solutions, room booking systems, and voicemail integrations that relied on EWS must migrate to Microsoft Graph. For Outlook-specific add-ins, the makeEwsRequestAsync function becomes unusable after the deadline.

IT teams should run usage reports now to identify which AppIDs are making EWS calls. The allowlist provides breathing room but is not a long-term strategy. Microsoft recommends completing migrations before the October cutoff to avoid emergency support incidents.

The Graph API Migration Gap

While Microsoft Graph replaces EWS, it is not a 1:1 feature match. Certain administrative operations, particularly around archive mailboxes and public folders, still lack full Graph parity as of mid-2026. If you rely on third-party backup solutions or migration tools that touch these specific mailbox types, you must configure the EWS allowlist before October 1. Otherwise, your automated backups will simply fail silently.

The audit framework

What Are the Exact Checks for New Outlook Add-Ins?

Before any pilot or broad deployment, IT teams must inventory existing tools, verify web counterparts, test in isolated environments, and configure centralized deployment. Use this repeatable framework to prevent disruptions.

Step 1: Inventory (Week 1)
Export installed add-ins from classic Outlook via File > Options > Add-ins. Use PowerShell to collect organization-wide data through the Microsoft Graph PowerShell SDK or admin center reports. Categorize by usage frequency and business criticality. Pay special attention to industry-specific tools common in legal, finance, healthcare, and manufacturing.

Step 2: Classify and Research (Week 2)
For each legacy add-in, determine:

• Does a web counterpart exist in the Microsoft Store?
• Has the vendor published a migration guide for 2026?
• Can native Microsoft 365 functionality (Teams integration, SharePoint, Power Automate) replace it?
• Does it make EWS calls that require Graph migration?

Reference Microsoft's published list of legacy-to-web mappings, which includes solutions for Acrobat, HubSpot, Jira, Zoom, Webex, and several others. For unsupported tools, engage vendors immediately. Many released updates throughout 2025.

Step 3: Test in Isolated Environment (Weeks 3-4)
Deploy the new Outlook to a pilot group of 10-20 power users. Enable the "Import settings and install add-ins" option selectively using Group Policy: Disable web add-in installation on migration to new Outlook for Windows. Monitor for activation failures, permission issues, and performance impact. Test both online and limited offline scenarios.

Step 4: Governance and Deployment
Configure Centralized Deployment for approved web add-ins. Set up assignment groups by department. Document permission requirements since users must consent during first use. Create internal guidance on when to use the new client versus toggling back to classic.

Step 5: Monitor and Iterate
Use Microsoft 365 usage reports and add-in telemetry to track adoption and errors. Schedule quarterly reviews as new JS API requirement sets and native capabilities are added.

This process typically reveals that 60-80% of common add-ins have direct replacements, while the remainder require targeted vendor conversations or workflow changes.

Real-world patterns

How Do Mid-Market Teams Migrate New Outlook Add-Ins?

Successful organizations use the transition to simplify their environment, retiring low-usage add-ins and pushing logic to Microsoft Graph or Power Platform where possible. Teams that treat migration as a pure technical lift-and-shift struggle.

Sales teams often depend on CRM add-ins for activity capture. When the legacy version fails, the web equivalent or native Dynamics 365 App for Outlook frequently restores functionality with Graph-based sync. The transition requires updating app registrations and permissions but eliminates previous synchronization delays.

Customer service representatives using compliance or archiving tools face stricter requirements. Many organizations discovered that server-side journaling or Power Automate flows provided more reliable outcomes than client-side add-ins. This shift reduces the attack surface and simplifies endpoint management.

Handling Shared Mailbox Add-Ins

Shared mailboxes present a unique challenge in the new Outlook. In classic Outlook, COM add-ins could easily piggyback on the primary account's permissions to interact with shared folders. Web add-ins require explicit delegate access configurations and support for the SharedProperties API. If your customer support or accounts payable teams rely on add-ins to process shared emails, you must verify that the vendor has updated their manifest to support delegate access. We've seen teams grind to a halt because an archiving tool worked perfectly in a personal inbox but threw permission errors in the support mailbox. If you need to standardize shared mailbox tone, ensure the solution explicitly supports delegate scenarios.

For teams with heavy email volume, add-ins that improve composition quality become strategic. Non-native English speakers particularly benefit from tools that adjust formality and tone for different internal and external audiences. These web-based solutions activate cleanly in the new Outlook without the resource overhead of legacy components. By deploying AI tools that cut email overload directly via the M365 admin center, IT can standardize communication quality across the organization in minutes.

Validation steps

Testing Protocols That Prevent Production Surprises

Never rely solely on vendor statements; create a standardized test script covering activation on protected messages, shared mailbox behavior, and EWS-to-Graph call replacement validation.

Here's why that matters: a web add-in might work perfectly on a standard email but fail completely when a user tries to access a shared inbox. (And yes, that includes your own IT support inbox).

Include these checks in your script:

• Activation on protected (IRM) messages.
• Behavior with shared mailboxes and delegate access.
• Performance with large inbox volumes (10,000+ messages).
• Offline mode limitations.
• Coexistence with other approved web add-ins.
• EWS-to-Graph call replacement validation.

Use the new Outlook toggle in a controlled manner during testing. Document which add-ins trigger the auto-install of web counterparts and capture the exact permissions requested. This information feeds user training materials and approval workflows.

Monitor the Office Add-ins known issues page weekly during migration waves. Issues reported in early 2026 around discovery of certain default add-ins demonstrated that even Microsoft-published solutions can experience temporary regressions tied to backend authentication changes.

The transition to the new Outlook requires more than flipping a toggle. IT administrators who treat add-in compatibility as a strategic simplification opportunity deliver the most resilient outcomes for their organizations. The October 2026 EWS milestone makes proactive auditing non-negotiable. Teams that complete their inventories and vendor engagements now will avoid the reactive firefighting that defined earlier waves of Outlook client changes.

FAQ