Working today is not the same as safe
VSTO add-ins are in an awkward spot in 2026. They still run, they still do their job in classic Office on Windows, and for that reason a lot of teams have filed them under solved. They are not solved. VSTO is a Windows-only, locally installed technology that Microsoft has steered away from for years, and two deadlines in 2026 turn the slow drift into a hard problem for anyone with a VSTO Outlook add-in in particular. This is not a panic piece. It is a clear read on what is changing, what still works, how long you realistically have, and what a migration to the modern web add-in model actually involves so you can plan it on your terms instead of during a failure.
Key Takeaways
VSTO is Windows-only desktop code
Written in C# or VB.NET, a VSTO add-in installs on the machine and runs only in classic Office on Windows. It never ran on Mac or the web.
New Outlook does not run it at all
The new Outlook for Windows has no support for VSTO or COM add-ins. New Outlook became the enterprise default in April 2026, with classic Outlook on a deprecation path.
EWS is being switched off
Exchange Web Services stops accepting connections from add-ins on 1 October 2026, so mail-related VSTO logic must move to Microsoft Graph.
Web add-ins are the replacement
Office.js web add-ins run across Outlook (new and classic), Mac, web, and mobile from one codebase, which is why they are the supported path.
You can run both during the move
Equivalent-add-in markup lets a VSTO add-in and its web replacement coexist on classic Outlook without duplicate buttons during the cutover.
Migrations take months, not weeks
A typical VSTO-to-web migration runs three to nine months depending on complexity, so the comfortable window to start has already narrowed.
What is a VSTO add-in, and why was it popular?
VSTO (Visual Studio Tools for Office) add-ins are Office extensions written in managed .NET code, usually C# or VB.NET, that install on a Windows machine and run inside the classic desktop Office applications. They were popular because they offered deep access to Office and the Windows machine, with the comfort of the .NET framework.
VSTO gave developers a managed-code way to extend Office. Instead of the raw COM model, you wrote C# or VB.NET against a .NET layer, with Visual Studio tooling, designers, and the full framework behind you. For years it was the natural choice for serious business add-ins on Windows.
Its strength was depth. A VSTO add-in runs in-process on the desktop, so it can reach the local file system, drive other applications through automation, hold rich state, and do heavy processing fast. Teams built years of custom business logic on that foundation: compliance stamping in Outlook, document assembly in Word, model tooling in Excel.
That same strength is now the problem. Everything VSTO does well depends on running locally on Windows, and that is precisely the world Microsoft is moving Office away from. The capabilities did not get worse. The ground they stand on is being removed.
Why are VSTO add-ins being deprecated?
Because Office is moving to a web-based, cross-platform model, and VSTO does not fit it. The new Outlook for Windows is a web client that cannot load VSTO or COM add-ins at all. Microsoft's direction across Office is the web add-in platform, which works on Windows, Mac, web, and mobile, where VSTO only ever worked on Windows desktop.
The clearest signal is Outlook. The new Outlook for Windows is built on the same web codebase as Outlook on the web, wrapped in a desktop shell. It has no place to run desktop add-in code, so VSTO and COM add-ins are not slow or degraded there, they are simply absent. New Outlook became the default for small and medium business subscriptions in January 2025 and the enterprise default in April 2026, with classic Outlook positioned as the temporary fallback rather than the destination.
Behind that sits a second deadline. Exchange Web Services, the older API many Outlook integrations used to read and write mailbox data, stops accepting connections from add-ins on 1 October 2026. So a VSTO Outlook migration is often two pieces of work at once: move the user interface from VSTO to Office.js, and move the data access from EWS to Microsoft Graph.
Excel, Word, and PowerPoint VSTO add-ins are not under the same Outlook-specific pressure, but the strategic direction is identical. The web add-in platform is where new features land, and the classic desktop applications, while still supported for now, are not where Microsoft is investing. If your add-in needs to reach Mac users, browser users, or centrally managed cloud devices, VSTO already cannot get there.
What still works, and how long do I really have?
The reassuring part: VSTO and COM add-ins still work in classic Outlook on Windows, and classic Outlook continues to receive new web add-in features even as it winds down. Excel, Word, and PowerPoint VSTO add-ins still run in their classic desktop apps. Nothing breaks the day you read this.
The honest part: classic Outlook is on a deprecation path with no new feature investment, and Microsoft has not published a hard end-of-support date but has made the trajectory unmistakable. Once your organisation finishes its move to new Outlook, your VSTO mail add-in is gone for those users with no fallback. For the other apps the runway is longer, but it is still a runway, not a permanent home.
The practical timing question is not when VSTO dies, it is when your users get switched. For many enterprises that switch is happening now. Because a typical migration runs three to nine months, and because demand for developers who have actually done VSTO-to-web and EWS-to-Graph work has climbed as the deadlines approached, the safe move is to scope the migration before the cutover reaches you, not after.
If you have a business-critical VSTO add-in and you are not sure how exposed you are, that assessment is the cheapest first step, and it is one we do regularly. We map what the add-in does, what survives a move to the web, and what needs rethinking, then give you a real scope and timeline. See how we handle it on our page.Office Add-in development services
How do you migrate a VSTO add-in to a web add-in?
The destination is an Office.js web add-in: a web application that Office loads in a sandboxed task pane and that talks to the document or mailbox through the Office JavaScript API. The migration is less a port and more a faithful rebuild, because the two technologies do not share code or runtime.
The work breaks into a few streams. First, re-express the business logic. The hard part is rarely writing new code, it is reproducing years of accumulated rules that nobody fully documented, then proving the new add-in behaves the same. Second, rebuild the UI as a task pane and ribbon commands instead of Windows forms. Third, for Outlook add-ins, replace EWS calls with Microsoft Graph, which means learning a second API surface alongside Office.js and is the piece teams most often underestimate. Fourth, handle authentication properly with single sign-on and the Office Dialog API rather than a desktop login.
Some scenarios that were trivial in VSTO need a rethink, because the web add-in runs in a sandbox and cannot touch the local machine. Where a VSTO add-in read a local file or drove another desktop app, the web version routes that through a backend service or a different design. Microsoft maintains a table of which Outlook scenarios are fully supported in web add-ins, and checking your specific workflows against it early avoids surprises. We go deeper on the Outlook specifics in our guide to migrating a VSTO Outlook add-in to the web.
<!-- Mark the legacy VSTO add-in as equivalent so the two do not show duplicate buttons -->
<VersionOverrides>
<!-- ... -->
<EquivalentAddins>
<EquivalentAddin>
<ProgId>ContosoAddin</ProgId>
<Type>COM</Type> <!-- use "COM" for both COM and VSTO -->
</EquivalentAddin>
</EquivalentAddins>
</VersionOverrides>Can I run my VSTO add-in and the new web add-in side by side?
Yes, and during a migration you usually should. On classic Outlook you can have the VSTO add-in and its web replacement installed at once, and you tell Outlook which to prefer so users do not see duplicate buttons or get conflicting behaviour on the same mail item. You do this with the equivalent-add-in markup in the web add-in's manifest, naming the legacy add-in by its ProgId, or through a Group Policy setting that achieves the same thing centrally.
This matters because it lets you migrate without a hard switchover. You can roll the web add-in out to a pilot group, keep the VSTO add-in as the active one for everyone else, and flip preference as confidence grows. It also avoids the worst failure mode, where both add-ins try to act on the same email and step on each other.
Worth noting: running a COM or VSTO add-in alongside a web add-in is only sensible during transition, and it is not recommended as a permanent arrangement, since the two can interfere. The goal is a clean cutover with a safety net, not a long-term coexistence.
What does a VSTO migration cost, and how should I plan it?
A VSTO-to-web migration typically runs three to nine months and lands in the mid-to-high five figures for a complex, business-critical add-in, driven by how much custom logic and backend integration exists. Plan a pilot, a parallel-running period, and an EWS-to-Graph workstream for Outlook add-ins.
Cost is driven by complexity, not by Office. A thin add-in with a few features is a modest project. A deeply integrated add-in with years of rules, external system connections, and an EWS dependency is a serious one, because you are reproducing behaviour and adding a Graph migration on top.
Plan it in phases. Start with an assessment that maps features to supported web scenarios and flags anything that needs redesign. Build to a pilot group with the equivalent-add-in safety net in place. Run the two in parallel long enough to confirm parity, then cut over and retire the VSTO add-in. The single biggest risk is leaving it too late, because a compressed timeline eliminates the parallel-running period and forces shortcuts right when reliability matters most.
VSTO add-in vs Office.js web add-in
| Factor | VSTO add-in | Office.js web add-in |
|---|---|---|
| Language | C# / VB.NET (.NET) | JavaScript / TypeScript |
| Runs on Windows, Mac, web, mobile | Windows only | Yes, one codebase |
| Runs in new Outlook for Windows | No | Yes |
| Code installed on the machine | Yes | No (sandboxed) |
| Deep local / file-system access | Full | Limited by design |
| Mailbox data API (Outlook) | Often EWS (retiring) | Microsoft Graph |
| Microsoft's supported direction | Deprecating | Yes |
Frequently asked questions
Are VSTO add-ins being discontinued?
They are on a deprecation path. VSTO add-ins still work in classic Office on Windows, but they do not run in the new Outlook for Windows at all, and Microsoft's investment is in the cross-platform web add-in model. For mail add-ins in particular, the runway is short.
Will my VSTO Outlook add-in work in the new Outlook?
No. The new Outlook for Windows does not support VSTO or COM add-ins at any level, with no fallback. To keep working there, the add-in must be rebuilt as an Office.js web add-in. It continues to run in classic Outlook for now.
Do I have to replace EWS when I migrate?
For Outlook add-ins, yes. Exchange Web Services stops accepting connections from add-ins on 1 October 2026, so mailbox data access should move to Microsoft Graph as part of the migration. Add-ins for Excel, Word, and PowerPoint are not affected by EWS.
Can I keep my VSTO add-in running while I build the web version?
Yes. On classic Outlook you can run both and use equivalent-add-in markup or Group Policy to control which one is active, so users do not see duplicate buttons. This lets you pilot the web add-in and cut over gradually rather than all at once.
How long does a VSTO migration take?
Typically three to nine months, depending on how much custom logic and integration the add-in has. Outlook migrations take longer because of the EWS-to-Graph work. Starting before your organisation switches to new Outlook gives you room for a parallel-running period.
Is the web add-in as capable as my VSTO add-in?
For most scenarios, yes, and the gap keeps closing as Microsoft adds APIs. The exceptions are deep local-machine operations, which the sandboxed web model cannot do directly and which usually move to a backend service. Check your specific workflows against Microsoft's supported-scenarios list early.
Plan the migration before the cutover plans it for you
VSTO add-ins are not broken, but they are finite, and 2026 is the year that stops being theoretical for a lot of organisations. The new Outlook default and the EWS shutdown turn a someday migration into a this-year one, especially for mail add-ins. The good news is that the destination, an Office.js web add-in, is more capable and far more portable than what you are leaving behind, and a phased migration with a parallel-running safety net keeps the risk low. If you have a VSTO add-in you depend on, the cheapest time to scope its replacement is before your users get switched. Tell us what it does and we will give you a straight assessment. Reach out through our contact page when you are ready.