VSTO Add-ins vs Office Add-ins: Proven Guide to Avoid Risk

VSTO add-ins and Microsoft Office Add-ins both put your own buttons, panes and automation inside Word, Excel, PowerPoint and Outlook, but they are built on opposite foundations. A VSTO add-in is a .NET Framework assembly that Office loads on a Windows PC and trusts with the full desktop object model. An Office Add-in is a web application, described by a manifest and run in a sandboxed browser control, that works in Office on the web, Windows, Mac and iPad.

For years the choice came down to existing skills and taste. In 2026 it comes down to deadlines. The new Outlook for Windows does not load COM or VSTO add-ins at all, Microsoft plans to make it the default for Enterprise users from March 2027, and Exchange Online starts blocking Exchange Web Services (EWS) on 1 October 2026. Any VSTO add-in project that touches Outlook or EWS now has a clock running.

The two terms are often blurred, and our own earlier piece on VSTO web add-ins and Office 365 add-ins used that mixed label; this is the current, more detailed version. It compares architecture, deployment, security, performance limits and feature depth, then sets out when a VSTO add-in is still the right call and how to migrate when it is not. If you need people to build either kind, see our guide to hiring a Microsoft 365 add-in developer.

Table of contents

What a VSTO Add-in Actually Is in 2026
What Microsoft Office Add-ins Are, and What They Are Not
VSTO Add-in vs Office Add-in: Key Differences at a Glance
How a VSTO Add-in and an Office Add-in Reach Users
Security and Trust: VSTO Add-in Full Trust vs the Office Add-in Sandbox
Performance and Reliability Limits for VSTO Add-in and Office Add-in Code
Feature Depth: What Office.js Can Do for a VSTO Add-in Team in 2026
The New Outlook Problem for Every Outlook VSTO Add-in
EWS Retirement: The Deadline Hiding Inside Many VSTO Add-in Projects
Running a VSTO Add-in and an Office Add-in Side by Side
When a VSTO Add-in Is Still the Right Choice
A Practical Migration Plan From VSTO Add-in to Office Add-in
VSTO Add-in and Office Add-in FAQs
References

What a VSTO Add-in Actually Is in 2026

VSTO stands for Visual Studio Tools for Office, Microsoft’s .NET toolset for customising desktop Office on Windows. Microsoft’s documentation describes a VSTO add-in as a managed code assembly that an Office application loads, which can respond to application events, call into the object model and use any class in the .NET Framework.

A .NET Framework Assembly Loaded Into Office

Every VSTO add-in is tied to an application rather than a document, so its features are available whichever file is open. That separates it from the other VSTO project type, the document-level customisation, which runs only while one specific Word document or Excel workbook is open. VSTO add-in projects are available for Excel, Outlook, PowerPoint, Project, Visio and Word.

The assembly talks to Office through each application’s COM object model, using primary interop assemblies or interop type information embedded into the build. When several are installed for one application, each VSTO add-in loads in its own application domain, and Microsoft says one that behaves incorrectly cannot cause the others to fail.

The Visual Studio Tools for Office Runtime

End-user PCs need the Visual Studio 2010 Tools for Office runtime, which still carries that name. It has two halves: unmanaged loader DLLs, VSTOEE.dll and VSTOLoader.dll, that Office calls first, and managed assemblies that expose the object model your code uses. There are separate 32-bit and 64-bit versions, and the right one is installed along with Office.

At start-up the application checks the registry, loads VSTOEE.dll and VSTOLoader.dll, starts the .NET Framework, checks the deployment manifest for updates, runs a series of security checks, creates an application domain and only then calls ThisAddIn_Startup. All of that happens on the user’s machine before the first line of your VSTO add-in code runs.

Registry Entries and LoadBehavior

Office discovers a VSTO add-in through a registry key under Software\Microsoft\Office\application name\Addins, in either HKEY_CURRENT_USER or HKEY_LOCAL_MACHINE. Four values are required: Description, FriendlyName, LoadBehavior and Manifest. A LoadBehavior of 3, the Visual Studio default, loads at start-up; 9 loads on demand; 16 loads the first time and then on demand. If a VSTO add-in fails while loading, the value changes from 3 to 2 and stays there.

Still Shipping in Visual Studio 2026

VSTO is legacy in direction but not abandoned. Microsoft’s workload reference for Visual Studio 2026 (version 18.0) still lists a Visual Studio Tools for Office (VSTO) component in the Office workload, now named Microsoft 365 development and described as creating “Office and SharePoint add-ins, SharePoint solutions, and VSTO add-ins using C#, VB, and JavaScript”. The framework targets Microsoft documents for VSTO projects are all .NET Framework 4.x versions, not modern cross-platform .NET.

What Microsoft Office Add-ins Are, and What They Are Not

Office Add-ins, also called Office Web Add-ins, are Microsoft’s cross-platform extension model for Excel, Outlook, Word, PowerPoint, OneNote and Project. They are built with HTML, CSS and JavaScript, and Microsoft says the same solution can run in Office on Windows, Mac, iPad and in a browser. They are not a newer edition of the VSTO add-in: the two share no runtime, no language and no deployment path.

A Web App Plus a Manifest

An Office Add-in has two parts: an app package and your own web application. The app package is a zip file holding a manifest, two icons and optional localisation files. The manifest tells Office the add-in’s name, ID and version, which ribbon buttons, task panes and event handlers it adds, and what permissions it needs. The logic lives on a web server you host and is loaded over HTTPS.

Office.js and Requirement Sets

Code talks to Office through the Office JavaScript API, usually called Office.js. There is a common object model shared by every host, plus richer application-specific models for Excel, Word, PowerPoint and OneNote. New APIs ship in versioned requirement sets such as ExcelApi 1.21 or Mailbox 1.16, and an add-in either declares a minimum set in its manifest or checks for one at runtime with isSetSupported.

Where the Code Runs: Webviews and Runtimes

In Office on the web the add-in runs in an iframe. On desktop and mobile it runs in an embedded browser control: Microsoft Edge with WebView2 on Windows, Safari with WKWebView on Mac and iOS, and Chrome on Android. Task panes and dialogs use a full browser runtime, while Excel custom functions and event-based tasks in classic Outlook on Windows can use a lighter JavaScript-only runtime with no cookies or local storage.

Two Manifest Formats

An Office Add-in can use the older XML add-in only manifest or the JSON unified manifest for Microsoft 365, which Microsoft now recommends for most scenarios. The unified manifest lets one package combine an Office Add-in with Teams apps and Copilot agents. It is not yet universal: perpetual Office on Windows, Outlook on Mac and Office on mobile do not support it, so some vendors still ship two versions.

VSTO Add-in vs Office Add-in: Key Differences at a Glance

The table below condenses the differences a project team runs into first. Each row is drawn from Microsoft’s own documentation for the two platforms.

Factor	VSTO add-in	Office Add-in
Language	C# or Visual Basic on the .NET Framework	JavaScript or TypeScript, plus any server stack
Where it runs	Desktop Office on Windows only	Office on the web, Windows, Mac and iPad
New Outlook for Windows	Not supported	Supported
Access to Office	Full COM object model	Office.js APIs grouped into requirement sets
What gets installed	Assembly and registry keys on every PC	A manifest; code stays on your web server
Deployment	ClickOnce or Windows Installer	Integrated apps portal, Centralized Deployment or Microsoft Marketplace
Updates	ClickOnce update check or a new setup program	Change the web code; manifest changes need redeploying
Trust model	FullTrust after certificate and inclusion-list checks	Sandboxed webview with HTTPS-only content
Offline use	Installed locally and designed to work offline	Loads its pages from your web server
Copilot agents	No packaging route	Can be combined with Copilot agents (preview)

Language and Tooling

A VSTO add-in team writes C# or Visual Basic in Visual Studio and debugs against a local copy of Office. An Office Add-in team writes JavaScript or TypeScript using Visual Studio, Visual Studio Code with Microsoft 365 Agents Toolkit, or the Yeoman generator, and can test in Office on the web. Microsoft’s transition guide warns VSTO developers that moving means a new language, a new deployment model and learning how web apps are hosted.

Platform Reach

Reach decides most projects. A VSTO add-in exists only where desktop Office for Windows is installed. An Office Add-in reaches every Office surface that supports its requirement sets, including Office on the web. That matters for Mac and iPad users, and for collaboration: when a workbook uses Excel custom functions, a co-authoring colleague is prompted to load the same add-in.

Depth of Access to the Office Object Model

Depth is where the VSTO add-in still wins. It can call anything the COM object model exposes, host Windows Forms, add Outlook form regions and custom task panes, and use the whole .NET Framework. Office.js covers a growing but deliberately bounded surface, and some capabilities appear first, or only, in desktop-only or web-only requirement sets such as WordApiDesktop or ExcelApiOnline.

How a VSTO Add-in and an Office Add-in Reach Users

Deployment is where the two models feel most different day to day. A VSTO add-in must be installed on each PC; an Office Add-in is assigned to people and loads from a server.

ClickOnce and Windows Installer

Microsoft supports two ways to deploy a VSTO add-in. ClickOnce publishes to a central location, installs with little user interaction and can update itself, but it registers only for the current user, so a shared PC needs one installation per person. Windows Installer can register for all users under HKEY_LOCAL_MACHINE and show licence pages, but every update means distributing a new setup program.

An all-users installer on 64-bit Windows should write its registry entries under both the standard hive and the WOW6432Node hive, because either edition of Office may be present. None of that applies to an Office Add-in, which never touches the registry.

Integrated Apps and Centralized Deployment

For an Office Add-in, the normal production route inside an organisation is the integrated apps portal in the Microsoft 365 admin center. Microsoft says add-ins deployed there are available to users right away with no client configuration. Customers in sovereign or government clouds cannot use the integrated apps portal and use Centralized Deployment instead, which works similarly but does not show admins the connected apps.

Microsoft Marketplace

Commercial Office Add-ins can be published to Microsoft Marketplace, which is reachable from a browser and from inside Office. Listing requires certification, and changing the manifest of a published add-in means certification again, although the web code behind it can change at any time. Marketplace distribution can even bundle an Office Add-in with the installation of a Windows app or an existing COM or VSTO add-in.

Older Routes and Their Limits

SharePoint app catalogs and network shares still exist for the add-in only manifest, with heavy caveats. Neither supports Outlook add-ins, SharePoint catalogs do not work on Mac or with add-in commands, and network shares are for testing only. Microsoft 365 subscriptions sold by GoDaddy cannot use admin center deployment, Exchange deployment or Marketplace acquisition at all.

Method	Model	Scope	How updates arrive	Main limits
ClickOnce	VSTO add-in	Current user only	Update check against the publish location	One install per user of a PC
Windows Installer	VSTO add-in	Current user or all users	New setup program	Admin rights for Program Files installs
Integrated apps portal	Office Add-in	Users and groups in a tenant	Web code changes on next load	Not in sovereign or government clouds
Centralized Deployment	Office Add-in	Users and groups in a tenant	Web code changes on next load	No view of connected apps
Microsoft Marketplace	Office Add-in	Public	Web code any time; manifest recertified	Certification required
SharePoint app catalog	Office Add-in, XML manifest	On-premises organisations	Replace the manifest	No Outlook, no Mac, no add-in commands
Exchange server	Outlook add-in, XML manifest	Online or on-premises mailboxes	Replace the manifest	Outlook only

Security and Trust: VSTO Add-in Full Trust vs the Office Add-in Sandbox

The two security models are close to opposites, and that shapes what each can safely do in a regulated business. Treat the choice as part of your wider cybersecurity review rather than a developer preference.

FullTrust, Certificates and Inclusion Lists

A VSTO add-in must request FullTrust. Before it installs, the VSTO runtime and ClickOnce check that the deployment manifest is signed with a certificate that is not on the Untrusted Publishers list and does not come from the Internet Explorer restricted zone. A certificate on the Trusted Publishers list installs silently; otherwise the user may be asked to grant trust, which adds the add-in to their inclusion list. An installer that writes into Program Files bypasses the inclusion list entirely.

FullTrust means the .NET code is not sandboxed. Once a VSTO add-in is trusted, it can do whatever the signed-in user’s account can do on that PC, including reading local files and opening network connections, so a careless or compromised build has the same reach as any other desktop program.

Sandboxed Webviews and HTTPS-Only Hosting

An Office Add-in runs in a browser control or iframe inside a sandbox, and Microsoft requires every URL to code or content files to use HTTPS. The manifest declares the permissions the add-in needs and the domains it may navigate to, and an iframe from an unlisted domain gets a permission denied error if it calls Office.js. The trade-off is plain: the add-in can do only what Office.js and the browser allow.

Authentication: Nested App Authentication Replaces Legacy Tokens

Outlook web add-ins have already lost an old shortcut. Microsoft’s nested app authentication FAQ, last updated in November 2025, says legacy Exchange Online user identity tokens and callback tokens “are no longer supported and turned off across all Microsoft 365 tenants”, and calls such as getUserIdentityTokenAsync fail with errors like 9017 or 9018. The recommended replacement is MSAL with nested app authentication (NAA), which provides single sign-on inside Outlook and other Microsoft hosts. Exchange on-premises tokens still work.

Conditional Access and Mobile Caveats

Two identity caveats catch Office Add-in teams out. Conditional Access is not supported for Office Add-ins on iOS or Android, because those clients use WKWebView or the Android WebView instead of an Edge-based control. And the approved client app Conditional Access grant, which Microsoft scheduled to retire in March 2026, causes errors for NAA token requests, so admins must move to the application protection policy grant. For the policy basics, see our guide to Conditional Access policies.

Performance and Reliability Limits for VSTO Add-in and Office Add-in Code

Both platforms protect Office from slow extensions, but they do it differently, and the limits are worth designing for from the first sprint.

Outlook Disables Slow COM and VSTO Add-ins

Since Office 2013, Office applications disable add-ins that perform slowly. Outlook records why it switched one off, and the reasons it can log include slow boot or demand loading, handling FolderSwitch or BeforeFolderSwitch events, item open and shutdown, as well as crashes. Microsoft’s own advice for staying enabled notes that native COM add-ins avoid the cost of loading the .NET Framework during Outlook start-up, a cost every VSTO add-in pays.

Admins can manage this with the List of Managed Add-ins group policy, where 1 means always enabled, 0 always disabled and 2 configurable by the user. Nothing prevents Outlook from disabling an add-in that crashes it or cannot be loaded, so a VSTO add-in that fails at start-up still needs fixing at the source.

Resource Limits on Office Add-ins

Office Add-ins in Excel, PowerPoint, Word and classic Outlook on Mac face explicit runtime limits when they run in desktop Office on Windows or Mac. The table summarises Microsoft’s resource limits guidance, plus the Excel and Outlook-specific thresholds.

Limit	Default threshold	What happens
CPU core usage	90% of one core, observed three times in five-second intervals	Office asks whether to keep running the add-in
Memory	Monitoring starts above 80% device memory use; warning above 50% for the add-ins	Office warns the user
Crash tolerance	Four crashes in a document session	Office warns and offers a restart
Application blocking	Five seconds unresponsive	Office restarts the active add-ins; admins cannot change it
Excel on the web payload	5 MB per request or response	A RichAPI.Error is thrown
Excel range read	5,000,000 cells	The API returns null or throws an error
Outlook regular expressions	1,000 milliseconds, retried up to three times	After three failures the user must switch items

Designing for Both Platforms

The practical lessons overlap. Do slow work after start-up rather than during it, cache data instead of calling the network on every folder switch or item open, and break large Excel operations into batches. For Office Add-ins, Microsoft specifically recommends web workers for CPU-heavy tasks, paging large reads, and keeping context.sync calls and proxy objects to a minimum.

Feature Depth: What Office.js Can Do for a VSTO Add-in Team in 2026

Office.js is no longer the thin API it was when Office 2013 introduced the add-in model. Counting the numbered requirement sets Microsoft lists for each application shows how far the platform has moved, and where it is deepest.

Excel carries the deepest Office.js surface, with 21 numbered API versions, more than twice the 9 that Word has.

Numbered Office.js requirement sets per application, September 2026

Excel, ExcelApi 1.1 to 1.21 21

Outlook, Mailbox 1.1 to 1.16 16

PowerPoint, PowerPointApi 1.1 to 1.10 10

Word, WordApi 1.1 to 1.9 9

Bar widths are each count divided by Excel’s 21. Preview, online-only and desktop-only sets are excluded.

Excel, Word and PowerPoint

ExcelApi 1.21 needs Version 2606 of Microsoft 365 on Windows or 16.110.1 on Mac, and Excel also has a desktop-only ExcelApiDesktop set. Word adds WordApiDesktop 1.1 to 1.5 on top of WordApi 1.9. PowerPointApi 1.10, which brings accessibility, slide background and hyperlink APIs, needs Version 2601. Volume-licensed perpetual Office lags far behind: none of those latest numbered sets is available there.

Excel custom functions deserve a mention because they cover a job that used to mean a COM automation add-in or an XLL. They are written in JavaScript, behave like built-in functions such as SUM, and Microsoft documents how to make them compatible with existing XLL user-defined functions. They are not supported on iPad or in volume-licensed perpetual Office 2021 or earlier on Windows. Our Excel add-in guide covers the basics.

Outlook Scenario Parity

Outlook is where parity matters most, because the new Outlook leaves no desktop fallback for a VSTO add-in. Microsoft tracks key Outlook scenarios and their support status in web add-ins; the rows below come from that list.

Scenario	Status in Outlook web add-ins	Relevant capability
Spam reporting	Supported	Integrated spam-reporting button
Online meetings	Supported	Online-meeting provider add-ins
Meeting enhancements	Supported	Event-based activation and Smart Alerts
Signatures	Supported	setSignatureAsync and account-change events
CRM and tracking	Supported	Activation without a selected message; drag and drop
Mail item transformation	Supported	getAsFileAsync
Attachment management	Supported	Multi-select and event-based activation
Data loss prevention	Supported	Smart Alerts on send and sensitivity labels
Message encryption	Partially supported	Decryption events; essential features still missing

Event-based activation is the closest web equivalent to the Application.ItemSend handler many an Outlook VSTO add-in relies on. The OnMessageSend and OnAppointmentSend events behind Smart Alerts arrived in requirement set 1.12, and their handlers run in the background without the user opening a task pane.

Gaps That Still Favour a VSTO Add-in

Some jobs remain easier, or only possible, on the desktop. Message encryption is the gap Microsoft itself marks as partial. Outlook form regions, Windows Forms dialogs, unrestricted local file and network access, and fully offline operation are native to a VSTO add-in and have no direct Office.js equivalent. Office.js also imposes hard ceilings, such as 100 messages for item multi-select and 25 MB of attachments in the new Outlook.

The New Outlook Problem for Every Outlook VSTO Add-in

If your VSTO add-in targets Word, Excel or PowerPoint, you have time to plan. If it targets Outlook, the new Outlook for Windows changes the calculation.

No COM or VSTO Support in the New Outlook

Microsoft is explicit: “VSTO and COM add-ins aren’t supported in the new Outlook on Windows.” The new client unifies the Windows and web codebases and supports only Outlook web add-ins, so an Outlook VSTO add-in simply does not load there. Both still work in classic Outlook. When users switch for the first time they can import settings, and web versions of their COM add-ins are installed instead where Microsoft can match one.

The Opt-Out Stage Arrives in March 2027

Microsoft describes three migration stages: opt in, opt out and cutover. In the opt-out stage the new Outlook is on by default and users are brought into it automatically, although they can still switch back. Message center post MC949965, updated on 20 February 2026, moved the Enterprise opt-out start from April 2026 to March 2027. Users are not migrated if an admin policy opts them out or hides the toggle, if they use a perpetual licence, or if their account is on-premises.

Classic Outlook Support Until at Least 2029

Cutover is the stage where users can no longer switch back and new Microsoft 365 deployments come with the new Outlook. Microsoft promises at least 12 months of notice before cutover reaches production rings, and its stages page gives no cutover date. It also says existing classic Outlook installations “will continue to be supported until at least 2029”, which gives an Outlook VSTO add-in a long tail, but not a future.

EWS Retirement: The Deadline Hiding Inside Many VSTO Add-in Projects

Exchange Web Services is a separate problem from the new Outlook, but it lands on many of the same projects. Any Outlook VSTO add-in, sync tool or back-end service that calls EWS directly to read mailboxes, calendars or public folders in Exchange Online is in scope.

What Changes on 1 October 2026

Microsoft announced in 2023 that it would start blocking EWS requests to Exchange Online on 1 October 2026, and in February 2026 set out a phased, admin-controllable plan. Tenants whose EWSEnabled setting is still Null on 1 October will see it changed to False as the rollout proceeds, which blocks EWS for every application in the tenant. Admins who set EWSEnabled to True and configure an AppID allow list by the end of September 2026 are excluded from that automatic change.

Final Shutdown on 1 April 2027

From 1 April 2027, EWS is “fully and permanently disabled” in Exchange Online and admins lose control of the EWSEnabled setting. Microsoft’s FAQ is blunt: “There will be no exceptions past April 2027.” EWS in on-premises Exchange Server is unaffected, and Microsoft Graph is the replacement for Exchange Online data. Microsoft has also said it will not provide APIs to create, read, update or delete public folders after October 2026.

Date	Change	What it means for add-ins
14 Oct 2025	Office 2016 and Office 2019 reach end of support	No more security fixes for hosts older add-ins still target
By Nov 2025	Legacy Exchange Online identity and callback tokens turned off	Outlook web add-ins need nested app authentication
Mar 2026	Approved client app Conditional Access grant scheduled to retire	NAA token requests fail under the old grant
End of Sep 2026	Last point to set EWSEnabled to True with an AppID allow list	Avoids the automatic block on 1 October
1 Oct 2026	EWS blocking begins in Exchange Online	EWS calls fail unless the tenant kept access
Mar 2027	New Outlook opt-out stage for Enterprise	Users move to a client with no COM or VSTO support
1 Apr 2027	EWS fully and permanently disabled	Code still calling EWS against Exchange Online stops working
At least 2029	Classic Outlook support continues	Classic Outlook keeps a supported host for older add-ins

Counted from 14 September 2026, the first EWS block is 17 days away and the permanent shutdown is 199 days away.

Days from 14 September 2026 to each Microsoft milestone

EWS blocking begins, 1 October 2026 17 days

New Outlook opt-out stage, counted to 1 March 2027 168 days

EWS permanently disabled, 1 April 2027 199 days

Classic Outlook support floor, counted to 1 January 2029 840 days

Bar widths are each day count divided by 840. Microsoft gives only a month for the opt-out stage and a year for classic Outlook, so those bars count to the first day of that period.

Checking Whether Your Add-in Calls EWS

Start with the EWS usage reports in the Microsoft 365 admin center and the scripts Microsoft has published for finding EWS applications. Then search each VSTO add-in codebase for EWS Managed API references, ExchangeService objects and SOAP calls to the Exchange.asmx endpoint, and search Office.js code for makeEwsRequestAsync. Anything that reaches Exchange Online through EWS needs a Microsoft Graph path, or an allow-list entry to buy time until April 2027.

Running a VSTO Add-in and an Office Add-in Side by Side

You rarely have to switch every user on the same day. Microsoft supports declaring a VSTO add-in and an Office Add-in as equivalents, so Office on Windows can prefer one version while everyone else gets the web add-in.

Equivalent Add-ins in the Manifest

Microsoft treats two add-ins as equivalent when the same developer publishes both, they target the same applications and workload, and they share very similar names and UI. In the unified manifest, the alternates.prefer.comAddin.progId property names the Windows-only add-in; in the add-in only manifest, an EquivalentAddins element does the same, with Type set to COM even for a VSTO add-in. The name comes from the add-in’s registry key and is case-sensitive.

Hiding One Version

If the VSTO add-in is still the better tool, Office on Windows hides the Office Add-in’s ribbon buttons wherever the VSTO add-in is installed and restores them if it is removed. There is a catch in Excel, PowerPoint and Word: once an equivalent is declared, Office stops processing updates for the Office Add-in until the Windows-only add-in is uninstalled. If the web version is better, the hide.windowsExtensions setting with disableWithNotification switches the old add-in off instead.

For Outlook, admins can get the first behaviour without touching the manifest through the “Deactivate Outlook web add-ins whose equivalent COM or VSTO add-in is installed” Group Policy. None of these settings affect Office on the web or Mac, where only the Office Add-in exists.

Sharing Code Through a Web API

Microsoft’s recommended path for reuse is to move shared business logic out of the VSTO add-in into a library exposed as a web API, which both the desktop add-in and the Office Add-in call. That keeps tested C# logic in service, shrinks the JavaScript you have to write, and leaves one code path to maintain during what is often a long transition.

When a VSTO Add-in Is Still the Right Choice

Neither model is better in every case. The decision table reflects the constraints covered above.

Situation	Better fit	Why
Excel, Word or PowerPoint tool used only on managed Windows PCs	VSTO add-in, for now	Full object model, offline use, no web hosting
Anything that must run in the new Outlook	Office Add-in	The new Outlook does not load COM or VSTO add-ins
Users on Mac, iPad or Office on the web	Office Add-in	VSTO runs only on Windows
Heavy desktop automation, Windows Forms or Outlook form regions	VSTO add-in	No direct Office.js equivalent
Commercial product sold to many tenants	Office Add-in	Marketplace listing and admin center deployment
Outlook message encryption	VSTO add-in in classic Outlook, with an exit plan	Web add-in support is only partial
Large Windows estate mid-migration	Both, declared as equivalents	Windows prefers one version; other platforms get the web add-in

Keep a VSTO Add-in When

A VSTO add-in still earns its place for Windows-only line-of-business tools in Excel, Word or PowerPoint that lean on the COM object model, need to work offline, or use Windows Forms and local resources. The platform is still in Visual Studio 2026 and in classic Office, and a rewrite that loses capability is poor value. Avoid new Outlook dependencies and write the exit plan down now.

Choose an Office Add-in When

Choose an Office Add-in for anything new that touches Outlook, anything that must work for Mac, iPad or browser users, and anything you plan to sell. It is also the only route into newer Microsoft 365 surfaces: the unified manifest can package an Office Add-in with Teams apps and with Copilot agents that read and write open documents, a preview capability for bringing generative AI into an add-in’s workflow.

For lighter automations, check first whether you need an add-in at all. Our comparisons of custom business apps and Power Apps and of Microsoft Copilot and a custom AI assistant may point to a simpler option.

Run Both When

Run both when you have a large Windows estate on a mature VSTO add-in and a growing group of users on other platforms. Declare the equivalence, move shared logic behind an API, and let the web version catch up scenario by scenario until the VSTO add-in can be retired.

A Practical Migration Plan From VSTO Add-in to Office Add-in

Migration works best when it is treated as a product change rather than a code port. These five steps follow Microsoft’s transition guidance and the constraints above.

Step 1: Inventory Every VSTO Add-in and Its Dependencies

List each VSTO add-in, the Office applications it loads in, its LoadBehavior value, its deployment method and every external dependency. Flag Outlook, EWS, public folders, local file access and offline requirements, because those decide both urgency and feasibility.

Step 2: Map Scenarios to Requirement Sets

For each feature, find the Office.js API and the requirement set that contains it, then check the Office builds your users actually run. Older estates lag badly: Exchange Server Subscription Edition, 2019 and 2016 support Outlook requirement sets only up to 1.5, while Exchange Online supports up to 1.16.

Step 3: Move Business Logic Behind an API

Move calculations, validation and integrations into a web API that both versions can call. This is where Microsoft Graph replaces EWS and where nested app authentication comes in for the Office Add-in. Keep the add-in layer itself thin.

Step 4: Pilot With Equivalent Add-ins

Deploy the Office Add-in through the integrated apps portal to a pilot group, declare the equivalence so Windows users keep the VSTO add-in where needed, and test in Office on the web, on Mac and in the new Outlook. Microsoft’s Script Lab add-in is a quick way to try APIs before you build anything.

Step 5: Deploy Centrally and Retire the VSTO Add-in

Once the web version covers the critical scenarios, reverse the equivalence so the Office Add-in hides the old one with a notification, withdraw the ClickOnce or Windows Installer package, and clean up the registry entries. For Outlook, aim to finish before the March 2027 opt-out stage rather than relying on users switching back.

For application-specific build detail, our Outlook add-in development guide, Word add-ins overview and guide to Microsoft Office programming cover the basics.

VSTO Add-in and Office Add-in FAQs

Is VSTO being discontinued?

We found no announced end date for VSTO in Microsoft’s documentation. The VSTO component still ships in the Microsoft 365 development workload of Visual Studio 2026, and a VSTO add-in still runs in desktop Office on Windows, including classic Outlook. What has changed is direction: the new Outlook does not support VSTO, and Microsoft’s cross-platform investment goes into Office Add-ins.

Can a VSTO add-in run on a Mac or in Office on the web?

No. Microsoft describes COM and VSTO add-ins as earlier solutions that run only in Office on Windows. To reach Mac, iPad or browser users you need an Office Add-in.

Is a VSTO web add-in a real product?

Not as such. A VSTO add-in is a .NET desktop assembly, while an Office Add-in is a web add-in. The phrase usually describes an Office Add-in created with the Office Developer Tools in Visual Studio, which is where much of the confusion comes from.

Do Office Add-ins work offline?

An Office Add-in loads its pages and scripts from your web server over HTTPS, so it depends on that content being reachable. A VSTO add-in is installed locally, and Microsoft positions offline use as one of the strengths of VSTO solutions.

Will my Outlook VSTO add-in stop working in 2027?

Not in classic Outlook, which Microsoft says remains supported until at least 2029. It will not load for anyone using the new Outlook, which becomes the default for Enterprise users in the opt-out stage from March 2027. Separately, any EWS calls it makes to Exchange Online stop working by 1 April 2027 at the latest.

How long does a migration take?

It depends on how much of the VSTO add-in relies on capabilities Office.js lacks. A thin ribbon and task pane tool can move quickly. An Outlook add-in with encryption, EWS sync and form regions needs a longer, staged plan, with equivalent add-ins in place throughout the transition.