Why You Must Migrate Your VSTO Add-Ins Before April 2026

Microsoft has set a hard deadline. By April 2026, the new Outlook for Windows will become the default mail client for enterprise Microsoft 365 subscribers, and the classic Outlook that your VSTO and COM add-ins depend on will enter a deprecation path with no further feature investment. If your organisation relies on custom VSTO add-ins for critical business workflows, the clock is ticking.

This is not a speculative change or a distant roadmap item. New Outlook became the default for small and medium business customers in January 2025. Enterprise organisations were given an extended timeline, but April 2026 is the line in the sand. After that date, new installations will default to new Outlook, and Microsoft has been explicit that VSTO and COM add-in models will not be supported in the new client.

For every organisation running legacy add-ins in Outlook, Word, Excel, or PowerPoint, the question is no longer whether to migrate but how to migrate without disrupting the business processes that depend on those add-ins.

What Is Actually Changing

To understand the urgency, it helps to understand what Microsoft is doing and why.

The End of Classic Outlook

Classic Outlook for Windows, the desktop application that has been the backbone of enterprise email for over two decades, is being replaced by new Outlook. The new client is built on web technologies and shares its codebase with Outlook on the web. It is faster, more consistent across platforms, and significantly easier for Microsoft to maintain and update.

Critically, new Outlook does not support VSTO (Visual Studio Tools for Office) add-ins or COM (Component Object Model) add-ins. These technologies rely on deep integration with the Windows desktop application runtime, a runtime that does not exist in the new web-based client.

VSTO and COM: Why They Cannot Be Carried Forward

VSTO add-ins are .NET assemblies that run inside the Office application process. They have full access to the Office object model and the Windows operating system. COM add-ins operate similarly, loading as native code within the Office process. Both technologies were designed for a world where Office was a desktop application running on Windows.

The new Outlook is fundamentally different. It runs in a web-based rendering engine. There is no .NET runtime to host VSTO assemblies. There is no COM infrastructure to load native add-in DLLs. Microsoft has stated explicitly that they will not port these technologies to the new platform. The statement from the Office product team is unambiguous: VSTO will not be updated for .NET Core or .NET 5+, and there are no plans to bring COM add-in support to new Outlook.

This is not a temporary gap that will be filled in a future update. It is an architectural decision that reflects the direction of the entire Microsoft 365 platform.

The Modern Web Add-In Model

The replacement is the Office Web Add-In model (sometimes called Office JS add-ins or simply modern add-ins). These add-ins are built using standard web technologies: HTML, CSS, and JavaScript. They run in a sandboxed browser context within the Office application and interact with Office through the office.js API.

The web add-in model works across all Office platforms: Windows (classic and new), Mac, web, and mobile. This cross-platform capability is one of the primary reasons Microsoft is pushing the transition. A single add-in built to the web model works everywhere, whereas VSTO add-ins only work on Windows desktop.

The Migration Timeline

Understanding the timeline is essential for planning a migration that does not disrupt your business.

January 2025. New Outlook became the default for new Microsoft 365 Business (SMB) subscriptions. SMB users opening Outlook for the first time on a new machine see new Outlook unless their administrator has configured a policy override.

Throughout 2025. Microsoft is progressively expanding the new Outlook rollout. Feature parity with classic Outlook continues to improve, and the toggle to switch back to classic Outlook remains available but is positioned as a temporary measure.

April 2026. New Outlook becomes the default for enterprise Microsoft 365 subscribers. This is the point at which most large organisations will feel the impact. New deployments and device refreshes will default to new Outlook. Existing classic Outlook installations will not be forcibly removed, but they will receive no new features and limited security updates.

Beyond April 2026. Microsoft has not published an end-of-support date for classic Outlook, but the trajectory is clear. Classic Outlook will receive security patches for a period after April 2026, but it is entering end-of-life. Organisations that have not migrated their add-ins will be running on a platform with a finite remaining lifespan.

The practical implication is this: if your organisation has custom VSTO or COM add-ins that are critical to business operations, you need to have a working web add-in replacement deployed before April 2026. Given that a typical migration project takes three to nine months depending on complexity, the window for starting that project is closing rapidly.

Key Architectural Differences Between VSTO and Web Add-Ins

Migration is not a straightforward port. The architectural differences between VSTO and web add-ins are significant, and understanding them is essential for planning a realistic migration project.

Execution Model

VSTO add-ins run as .NET assemblies inside the Office process with full access to the Office object model, the Windows API, and any .NET library. Web add-ins run in a sandboxed browser context and interact with Office exclusively through the office.js API. They cannot access the file system or run arbitrary .NET code.

Office API Surface

VSTO provides access to the complete Office object model via COM interop. Web add-ins use office.js, which provides a curated but increasingly comprehensive API. While office.js covers the most common scenarios, it does not replicate the full breadth of the COM object model. Some operations that were straightforward in VSTO may require server-side workarounds.

UI and Data Access

VSTO add-ins use Windows Forms or WPF for custom task panes, ribbon tabs, and form regions. Web add-ins render task panes as web pages using HTML/CSS, typically styled with the Fluent UI React component library.

For data access, VSTO can connect directly to local databases, the file system, and on-premises services. Web add-ins access data through web APIs over HTTPS, which means on-premises systems must be exposed through a secure API layer.

Authentication and Deployment

VSTO typically relies on Windows integrated authentication (Kerberos/NTLM). Web add-ins use OAuth 2.0 through Microsoft Identity Platform (Entra ID), with SSO available via the getAccessToken API.

VSTO deploys via MSI, ClickOnce, or Group Policy, requiring redeployment for updates. Web add-ins deploy through the Microsoft 365 Admin Center. Updates to the add-in’s functionality only require updating the hosted web application, with no changes needed on end-user machines.

Planning Your Migration: A Step-by-Step Checklist

A well-planned migration minimises disruption and delivers a modern add-in that is more maintainable, more secure, and works across all Office platforms. Here is a structured approach.

1. Inventory Your Add-Ins

Create a comprehensive inventory of every VSTO and COM add-in deployed in your organisation. For each add-in, document:

The Office application it extends (Outlook, Word, Excel, PowerPoint).
The business process it supports.
The number of users who depend on it.
The criticality to business operations (critical, important, or nice-to-have).
The specific Office APIs and Windows APIs it uses.
Any integrations with backend systems (databases, file shares, on-premises services).
Who developed and maintains it (internal team, vendor, or contractor).

2. Assess office.js API Coverage

For each add-in, map the VSTO/COM APIs it uses to their office.js equivalents. Identify any gaps where a VSTO capability does not have a direct office.js replacement.

Common areas where gaps may exist include:

Outlook form regions: Not available in web add-ins. The replacement is a task pane or contextual inline display using the on-message-read or on-message-compose events.
Low-level document manipulation: VSTO provides access to the full Open XML structure. office.js provides a higher-level API. For complex document manipulation, consider using the Open XML SDK on the server side, invoked by the add-in through a web API.
Windows API calls: Any add-in that calls Windows APIs directly (file system, registry, COM automation of other applications) will require architectural changes. These operations must move to a backend service.

3. Design the Target Architecture

Based on the API assessment, design the architecture for each web add-in:

Frontend: HTML/CSS/JavaScript running in the Office task pane. Use Fluent UI React for consistent Office styling. Consider TypeScript for maintainability.
Backend: A web API hosted in Azure (App Service, Azure Functions) or another cloud provider. This backend handles business logic that cannot run in the browser sandbox, including database access, file processing, and integration with on-premises systems.
Authentication: Implement SSO using the office.js getAccessToken API and Microsoft Identity Platform. For backend API calls, use the on-behalf-of flow to exchange the Office SSO token for tokens scoped to your backend.
Data layer: Replace direct database connections with RESTful or GraphQL API calls to your backend service.

4. Plan the Manifest

Web add-ins are defined by a manifest that describes the add-in’s entry points, permissions, and hosting details. Microsoft is transitioning to a unified manifest format (JSON-based) that supports both add-in and Copilot agent scenarios. For new development, use the unified manifest unless you have a specific reason to use the legacy XML manifest.

5. Build a Proof of Concept

Before committing to a full migration, build a proof of concept that demonstrates the most critical functionality of each add-in in the web model. Focus on the areas identified as highest risk in the API assessment. This proof of concept validates your architectural decisions and surfaces any unexpected limitations early.

6. Develop and Test

Develop the web add-in following Microsoft’s best practices:

Use the Yeoman generator for Office Add-ins (yo office) to scaffold the project.
Test across all target platforms: new Outlook, classic Outlook, Outlook on the web, and Outlook mobile if required.
Implement error handling for scenarios where office.js APIs behave differently across platforms.
Use the Office Add-in Debugger extension in Visual Studio Code for development and debugging.

7. Plan Deployment and Rollout

Sideload for development and internal testing.
Use Centralised Deployment through the Microsoft 365 Admin Center for organisational rollout.
Plan a parallel running period where both the legacy VSTO add-in and the new web add-in are available. This allows users to transition gradually and provides a fallback if issues are discovered.
Communicate the migration to end users with training materials and a clear timeline for removing the legacy add-in.

8. Decommission Legacy Add-Ins

Once the web add-in is validated in production and users have transitioned, decommission the VSTO/COM add-in. Remove it from deployment systems, archive the source code, and update your documentation.

What About Word, Excel, and PowerPoint?

While Outlook is driving the most immediate urgency due to the new Outlook timeline, the same architectural shift applies to Word, Excel, and PowerPoint. Microsoft’s investment is in the web add-in model across all Office applications. VSTO and COM add-ins in these applications will continue to work in the desktop versions for now, but the direction is clear: the web add-in model is the future.

Organisations that are migrating Outlook add-ins should consider migrating Word, Excel, and PowerPoint add-ins at the same time. The architectural patterns are the same, and a coordinated migration avoids having to run parallel add-in infrastructure for an extended period.

The Cost of Waiting

Delaying migration creates compounding risk:

Reduced migration window. Every month of delay shortens the available development and testing time before the April 2026 deadline. Complex add-ins with deep backend integrations require months of development and testing. Starting late means cutting corners or missing the deadline.

Talent availability. As the deadline approaches, demand for developers with VSTO to web add-in migration experience will increase. Engaging a specialist consultancy now ensures availability and competitive pricing.

Parallel running risk. A shorter migration timeline compresses or eliminates the parallel running period, increasing the risk of disruption when the legacy add-in is removed.

Technical debt. Every enhancement or bug fix applied to a VSTO add-in between now and migration is work that will be duplicated in the web add-in. Freezing VSTO development and focusing resources on the migration avoids this waste.

How McKenna Consultants Can Help

McKenna Consultants has been developing custom Microsoft Office add-ins for over a decade. Our team has deep expertise in both the legacy VSTO/COM model and the modern web add-in architecture, which makes us uniquely positioned to plan and execute migrations.

We specialise in custom Outlook add-in development for UK businesses, and we have guided multiple clients through the transition from VSTO to web add-ins. Our approach covers the full migration lifecycle:

Assessment and planning: We audit your existing add-ins, map API dependencies, identify risks, and produce a detailed migration plan with realistic timelines.
Architecture design: We design the target web add-in architecture, including backend services, authentication flows, and integration with your existing systems.
Development and testing: We build the web add-in, test across all Office platforms, and ensure feature parity with the legacy add-in.
Deployment and transition: We manage the rollout through centralised deployment, support the parallel running period, and help decommission the legacy add-in.

If your organisation has VSTO or COM add-ins and you have not yet started planning the migration, the time to act is now. Contact McKenna Consultants to discuss your migration requirements and timeline.

Conclusion

The new Outlook add-in migration 2026 deadline is not a theoretical future event. It is a concrete timeline backed by Microsoft’s strategic decision to unify Office around the web platform. VSTO and COM add-ins have served organisations well for two decades, but their architectural model is incompatible with where Office is going.

Migration from VSTO to web add-ins is achievable. The office.js API surface is mature, the development tooling is strong, and the resulting add-ins are more portable, more secure, and easier to deploy than their legacy predecessors. But it requires planning, development time, and testing across platforms.

With fewer than twelve months until the enterprise deadline, the window for a well-planned migration is closing. Organisations that start now will have time to build a proper proof of concept, run a parallel deployment period, and transition users smoothly. Those that wait risk a rushed migration, disrupted workflows, and the uncomfortable position of depending on a platform that Microsoft has stopped investing in.