If your organisation runs custom VSTO or COM add-ins, you have probably encountered a good deal of noise about deadlines. This guide sets out what Microsoft has actually published, what is genuinely time-bound, and how to plan and execute a migration to the Office Web Add-ins platform without working from a date that does not exist.
What Microsoft Has Actually Announced
It is worth being precise here, because the planning implications are very different from the version that circulates in a lot of third-party commentary.
VSTO and COM add-ins are not supported in new Outlook for Windows
This is the real constraint, and it is a client capability gap rather than a dated deadline. Microsoft’s guidance for developing add-ins for new Outlook states it plainly:
To provide a more reliable and stable add-in experience, VSTO and COM add-ins aren’t supported in the new Outlook on Windows.
The same page carries an explicit note: “VSTO and COM add-ins are still supported in classic Outlook on Windows.” So the question is not “when does VSTO stop working” but “when do my users end up on a client that cannot load it”.
The new Outlook rollout is staged, with 12 months’ notice
Microsoft describes three progressive stages of migration: opt-in, opt-out, and cutover.
| Stage | What it means | Can users switch back? |
|---|---|---|
| Opt-in | New Outlook is off by default; users see a “Try the new Outlook” toggle | Yes |
| Opt-out | New Outlook is on by default | Yes |
| Cutover | New deployments use new Outlook | No |
Two commitments in that document matter for planning. IT administrators get at least 12 months’ notice before either the opt-out or the cutover stage reaches managed Enterprise plans in production rings. And on the far end:
Existing installations of classic Outlook through perpetual and subscription licensing will continue to be supported until at least 2029.
At the time of writing, that Microsoft page describes new Outlook as being in the opt-in stage. Whatever date your organisation eventually faces, you will be told about it a year ahead through the standard “notice of disruptive change” channels — you are not going to be surprised by it.
There is no announced deprecation for Word, Excel, or PowerPoint
This is the point most often garbled. Microsoft has announced no end-of-support date for VSTO or COM add-ins in Word, Excel, or PowerPoint. The VSTO add-in developer’s guide is a transition resource, not a deprecation notice, and the long-running Microsoft Q&A thread asking when deprecation will happen for Word/Excel/PowerPoint remains unanswered.
Plan your Word, Excel, and PowerPoint add-in modernisation on architectural merit and your own roadmap. Do not plan it against a Microsoft deadline, because there isn’t one.
The One Deadline That Is Real: EWS, 1 October 2026
If you want a genuine date to organise around, this is it — and it affects Outlook add-ins specifically.
Microsoft is retiring Exchange Web Services in Exchange Online. Any tenant with EWSEnabled set to Null on 1 October 2026 will have that value changed to False as the deployment rolls out, blocking EWS for all applications in the tenant. A phased, admin-controllable disablement runs from that point, concluding with full shutdown in 2027.
Microsoft has provided an escape valve: the EWSAllowedAppIDs allow list lets administrators nominate specific application IDs that may continue to use EWS while it remains enabled. Treat that as a bridge for a migration already in flight, not as a way to defer the work.
Note the scope: this applies to Microsoft 365 and Exchange Online only. There are no changes to EWS in on-premises Exchange Server.
The replacement is Microsoft Graph. If your Outlook add-in calls EWS for mail, calendar, or contact operations, this migration has a date attached to it and the VSTO question does not.
Why Migrate Anyway
Given the absence of a VSTO cliff, why do this work at all? The honest answer is that the reasons are architectural rather than regulatory, and they are strong ones.
Reach. A VSTO add-in runs on Windows desktop Office and nowhere else. A web add-in runs on Windows (classic and new Outlook), Mac, the web, and mobile from a single codebase.
The runtime is frozen. VSTO targets .NET Framework. Microsoft has not brought it forward to .NET Core or .NET 5+, and there are no plans to. Your add-ins are pinned to a runtime that is no longer receiving investment, whatever the support status of the host application.
Deployment. Web add-ins update by updating your hosted web application. No MSI, no ClickOnce, no per-machine redeployment for a bug fix.
New Outlook is coming regardless. Even with 12 months’ notice and support to 2029, the direction is settled. Doing this as planned work is materially cheaper than doing it when a stage transition lands.
It converges with the EWS work. As set out below, the authentication you build for a web add-in is the same authentication Microsoft Graph needs. Sequenced properly, these are one project.
Architectural Differences You Need to Plan For
Migration is not a port. These are the differences that drive effort.
Execution model
VSTO add-ins are .NET assemblies loaded into 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 web view and reach Office exclusively through Office.js. They cannot touch the file system or execute arbitrary .NET.
Anything your add-in does against the local machine — registry, file shares, COM automation of other applications, local database connections — has to move to a backend service. Identify these early; they are where estimates go wrong.
The asynchronous API
This is the single largest conceptual shift for a VSTO team. In VSTO you worked synchronously:
// VSTO
var doc = Globals.ThisAddIn.Application.ActiveDocument;
var selection = doc.ActiveWindow.Selection;
selection.Text = "Hello from VSTO";
In Office.js every document interaction is asynchronous and batched through context.sync():
// Office.js (Word)
await Word.run(async (context) => {
const range = context.document.getSelection();
range.insertText("Hello from Office.js", Word.InsertLocation.replace);
await context.sync();
});
You load properties, sync, then read the returned values. Budget explicit training time for this before your team writes production code — teams that skip it write synchronous-shaped code that works in testing and stalls under load.
Common Excel mappings
| VSTO pattern | Office.js equivalent |
|---|---|
worksheet.Range["A1"].Value2 = data | range.values = [[data]] |
worksheet.Cells[row, col] | worksheet.getCell(row, col) |
worksheet.UsedRange | worksheet.getUsedRange() |
chart.SetSourceData(range) | chart.setData(range) |
Range.AutoFit() | range.format.autofitColumns() |
Where the API surface genuinely does not reach
Office.js is a curated API, not a mirror of the COM object model. Plan for these:
- Outlook form regions have no web equivalent. Redesign as a task pane or contextual inline display driven by the message read or compose events.
- Custom task panes are not equivalent. VSTO’s
CustomTaskPanecould dock anywhere and host Windows Forms or WPF. A web add-in task pane renders in a fixed side panel. If your UX depends on floating, dockable, or arbitrarily resizable panes, that is a redesign. - Low-level Open XML manipulation is better handled server-side with the Open XML SDK, invoked by the add-in over a web API.
Do this audit in week one and classify every capability as migrate, redesign, or retire. The failure mode we see repeatedly is teams treating migration as line-by-line transcription and discovering the redesign category late, when there is no room left to absorb it.
Authentication: The Part That Overruns
Authentication is where migrations most reliably stall, and it is worth stating why: this is an identity architecture change, not a login flow change.
VSTO add-ins typically run under the user’s Windows identity and inherit Kerberos or NTLM to backend services. Web add-ins run sandboxed and authenticate via OAuth 2.0 against Microsoft Entra ID. Everything downstream changes shape — backend services need to accept Entra ID-issued JWTs, service accounts become workload or managed identities, the audit trail changes, and the places a 401 surfaces change.
Two approaches:
- SSO via Office.js — the preferred path.
OfficeRuntime.auth.getAccessToken()returns a bootstrap token that your add-in exchanges server-side, on-behalf-of, for a Microsoft Graph or custom API token. The user signs in once to Microsoft 365 and the add-in inherits that session silently. - MSAL.js in the task pane — the fallback where SSO is unavailable. The user authenticates through a dialog.
The SSO flow requires an Entra ID app registration with openid, profile, and offline_access scopes; your add-in’s web app URL registered as a redirect URI; an App ID URI in the form api://{domain}/{clientId}; and the corresponding WebApplicationInfo block (XML manifest) or its unified manifest equivalent.
If you run on-premises Exchange or SharePoint without Entra ID Connect, this is your longest-lead dependency. Start it first, resource it as its own workstream with its own architect and test plan, and do not let it become a task inside the add-in development sprint.
Manifest, Deployment, and Rollout
Choosing a manifest format
- Add-in only manifest (XML). The established format, widest tooling and documentation support, works across all Office versions including Office 2019 and 2021 perpetual licences.
- Unified manifest (JSON). Positions the add-in for Copilot extensibility and deeper Microsoft 365 integration; targets Microsoft 365 Apps.
For most enterprise migrations the XML manifest remains the pragmatic choice unless you specifically need Copilot agent scenarios. Either way, treat the manifest as real engineering — it controls discovery, surface availability, command placement, and SSO configuration, and manifest errors are the most common cause of deployment failures in the Admin Centre.
Deployment
Deploy through Microsoft 365 Admin Centre → Settings → Integrated Apps, uploading your manifest or an AppSource link and assigning to users, groups, or the organisation. Set the deployment to Available for a pilot, then Mandatory for full rollout — mandatory deployment pushes the add-in to the ribbon without user action, and is the mechanism that replaces Group Policy-based VSTO deployment. For Intune-managed estates, add-in assignment can be configured through the Microsoft 365 Apps policy against Entra ID security groups.
For add-ins distributed to external customers, Microsoft Marketplace (AppSource) validation is strict but the resulting distribution model is far simpler than ClickOnce or MSI.
Run them in parallel
VSTO and web add-ins use entirely different deployment mechanisms and do not conflict at the registry level, so both can be installed simultaneously. Use that: deploy the web add-in to a pilot security group while VSTO remains in place for everyone else, run it for at least two weeks under normal workload, and give pilot users a real feedback channel.
Test across the matrix, not just one configuration — new Outlook, classic Outlook, Outlook on the web, and mobile if in scope; compose mode versus read mode; large and complex documents; token expiry and re-auth; and behaviour when the network drops. Web add-ins behave subtly differently across Office versions, channels, and surfaces, and a single-environment test plan will not surface it.
Only then decommission: remove the ClickOnce deployment, push an MSI removal via Intune or SCCM, or drop the installing GPO. Communicate the removal in advance and tell users where the replacement lives.
A Sensible Sequence
If you are starting from a standing position, this ordering front-loads the risk:
- Inventory and classify. Every VSTO and COM add-in, with its business criticality, user count, backend integrations, and owner. Decide migrate / redesign / retire for each. Retire aggressively — do not migrate what nobody uses.
- Start the identity workstream immediately. App registrations, backend token acceptance, and the on-behalf-of flow. This has the longest lead time.
- Audit the API surface for the add-ins you are keeping, and escalate anything landing in the redesign category now rather than later.
- Deal with EWS first if you have it. It is the one item with a real date on it. Moving to Graph also removes a dependency you would otherwise carry through the add-in migration.
- Build, then pilot in parallel for a controlled group before any cutover.
- Decommission once the replacement is validated in production.
How McKenna Consultants Can Help
McKenna Consultants has been building custom Microsoft Office add-ins for two decades, across Outlook, Word, Excel, and PowerPoint. We work in both the legacy VSTO and COM model and the modern Office Add-ins platform, which puts us in a good position to plan and deliver migrations — including the Entra ID identity work and the EWS-to-Graph migration that usually accompanies them.
We can help with a migration assessment and honest effort estimate, target architecture design, full development delivery, or deployment and cutover support — as a delivery team or alongside your own developers.
If you are planning Office extensibility modernisation, or working out what the EWS date means for your Outlook add-ins, contact us to discuss it.
Sources
- Develop Outlook add-ins for the new Outlook on Windows — Microsoft Learn
- Stages of migration to new Outlook for Windows — Microsoft Learn
- VSTO add-in developer’s guide to Office Web Add-ins — Microsoft Learn
- Deprecation of Exchange Web Services in Exchange Online — Microsoft Learn
- Introducing EWSAllowedAppIDs: Preparing for the Final Phase of EWS Retirement — Microsoft Community Hub
