Lessons from the April 2026 VSTO Migration Deadline: A Post-Mortem for Enterprise IT
The April 2026 VSTO migration deadline is now thirteen days behind us. The countdown content of late 2025 and early 2026 — including our own 60-Day Implementation Guide published in January — is no longer a planning resource. It is a historical artefact. The deadline arrived; some organisations met it; others did not.
This post-mortem captures what we have observed from the inside of multiple enterprise migration engagements through the run-up to and the immediate aftermath of the deadline. It is partly a debrief — what worked, what failed, and what the patterns tell us about modernising Office extensibility under deadline pressure — and partly a forward-looking piece. Microsoft’s deprecation of VSTO is not an isolated event. It is the template for a sequence of platform sunsets that will continue through 2026 and into 2027 (most immediately, the October 2026 Exchange Web Services deprecation). The patterns we saw in VSTO migration are the patterns enterprise IT will face again.
The article addresses three audiences. First, organisations that completed migration on time and want to validate the choices they made. Second, organisations that did not complete migration and are now operating with broken or partially broken add-ins, who need a recovery framework rather than a replanning exercise. Third, organisations preparing for the next wave of Microsoft platform deprecations, who can use the VSTO migration as a learning input.
What Actually Happened on April 1, 2026
Microsoft’s enforcement of the VSTO deprecation was not theatrical. There was no large public announcement, no widespread breakage that hit the technology press. The deprecation has been progressing in stages for years, and the April 2026 deadline simply marked the point at which the previously deprecated extensibility models — VSTO, COM add-ins, and certain VBA-driven scenarios — stopped being supported in current and future channels of Microsoft 365 Apps for Enterprise.
What this meant in practice varied by add-in. Some add-ins that ran fine on March 31 stopped loading on April 1, because they relied on a specific COM activation pathway that the post-deadline build no longer permits. Others continued to load but began producing intermittent errors as the runtime model around them shifted. A small number, particularly those targeting Office 2019 or LTSC channels with deferred update profiles, continued to function — for now — because those channels have their own deprecation timelines.
The headline observation: the deadline was not a binary cliff for every add-in, but it was a cliff for many of them, and every organisation now operates in a world where the platform model VSTO depends on is no longer supported. Even add-ins that still function are deprecated. Their continued operation is a transient grace period, not a sustainable position.
The Migration Patterns That Worked
Across the engagements we completed before the deadline, a small number of migration patterns produced consistently good outcomes.
Web Add-Ins With Shared Runtime
The highest-quality VSTO replacements used the modern Office Add-ins platform with the shared runtime feature enabled. The shared runtime allows a single JavaScript context to span ribbon commands, task panes, function commands, and (where appropriate) custom functions, which closely mirrors the architecture of the VSTO add-ins these teams were replacing. Without shared runtime, multi-surface VSTO add-ins typically fragment into two or three separate web add-ins that lose the shared state model that made the VSTO add-in coherent.
The teams that started their migration with a clear architectural decision to use shared runtime, and built their add-ins around that decision, ended up with cleaner code, fewer integration seams, and an end-user experience close enough to the old VSTO behaviour that user training requirements were minimal.
Microsoft Graph as the Backend Integration Surface
The other architectural choice that consistently paid off was routing all backend interactions through Microsoft Graph. VSTO add-ins frequently used a tangle of integration paths — direct EWS calls for Outlook scenarios, REST calls to internal services for business data, occasional COM interop into the Office object model for data the JavaScript API does not expose. Migrations that treated Graph as the canonical backend surface — and pushed business logic out of the add-in into a Graph-aware service tier — ended up with substantially less code in the add-in itself and a much simpler operational story.
The teams that took this approach also positioned themselves well for the EWS deprecation that lands in October 2026, since they had already removed the EWS dependency as part of the VSTO migration. The teams that did not are now running both migrations in parallel — a substantially worse situation that we cover later in Q2.
AppSource and Microsoft 365 Admin Centre Distribution
The deployment story for VSTO replacements turned out to matter as much as the build. Teams that planned distribution through the Microsoft 365 admin centre — using centralised deployment to push add-ins to user mailboxes — completed migration faster and with fewer support tickets than teams that tried to bolt the new add-ins onto their old MSI-based deployment infrastructure.
For organisations distributing add-ins to external customers, AppSource (now part of Microsoft Commercial Marketplace) similarly turned out to be the path of least resistance. The validation requirements are strict, but the resulting distribution model is dramatically simpler than the old VSTO ClickOnce or MSI mechanisms.
Parallel Deployment During Cutover
Almost every successful migration we worked on shipped the new web add-in alongside the existing VSTO add-in for a period of weeks. The dual-running window let users transition gradually, gave support teams time to learn the new behaviour, and provided a safety net when the inevitable surface-level issues emerged. Teams that tried to flip the switch in a single weekend deployment uniformly experienced more support pain than teams that allowed a controlled overlap.
The Migration Patterns That Failed
Several anti-patterns emerged consistently in projects that struggled.
Underestimating the Authentication Migration
The single biggest surprise across the engagements we observed was the cost of migrating authentication. VSTO add-ins typically run under the user’s Windows identity and inherit Kerberos or certificate-based authentication to backend services. Web add-ins run in a sandboxed JavaScript context and authenticate via OAuth 2.0, almost always against Microsoft Entra ID.
This is not a code change. It is an identity architecture change. Backend services that previously accepted Windows authentication need to be reconfigured to accept Entra ID-issued JWTs. Service accounts that were silently relied upon for backend work must be replaced by Entra ID workload identities or managed identities. The audit trail changes shape. The error handling changes shape. The places where a 401 manifests change shape.
Teams that scoped this as a “small change to the login flow” routinely overran. Teams that scoped it as a parallel workstream, with its own architect, its own test plan, and its own pilot cohort, did not. The lesson for future Microsoft platform migrations is unambiguous: if the migration changes the identity model, treat the identity migration as a first-class workstream.
Treating COM Interop as a Drop-In Equivalence Problem
A common failure mode was teams attempting to map their VSTO add-in’s COM interop, line by line, to Office.js equivalents. The Office.js API surface is not a one-to-one replacement for the COM object model. Some operations have direct equivalents (range manipulation in Excel, mailbox property access in Outlook). Some have approximate equivalents that require restructuring the add-in’s behaviour. Some have no equivalent at all and require a redesign.
Teams that treated migration as transcription invariably hit the third category late in the project, when redesign was no longer feasible. Teams that did the API surface audit at the start — and made explicit migrate / redesign / retire decisions per VSTO capability — avoided the late-project crisis.
Underestimating Test Surface
VSTO add-ins are typically tested in two places: developer machines and a small QA environment running Office in a configuration that approximates production. Web add-ins behave subtly differently across Office versions, channels, and surfaces. A web add-in that works in Outlook on the web does not necessarily work identically in Outlook for Windows, even though Office.js abstracts over both. Excel custom functions behave differently in older Excel builds. Compose-mode versus read-mode in Outlook produces meaningfully different runtime contexts.
Teams that built a multi-surface, multi-version, multi-channel test matrix early found and fixed these issues during development. Teams that did not encountered them in user acceptance testing and lost weeks rebuilding test infrastructure they should have had at the start.
“We Will Migrate When We Have to”
The most damaging pattern of all was organisational rather than technical. A non-trivial number of organisations explicitly decided in 2025 that they would not begin migration until late 2025 or early 2026, on the assumption that the deadline would slip or that more migration tooling would emerge in the interim. The deadline did not slip. The tooling did not emerge in any form materially better than what was available at the start of 2025.
These organisations are now operating with broken add-ins and a migration project that should have started a year ago.
What to Do Now if Your VSTO Add-Ins Are Broken
For organisations whose VSTO add-ins are no longer functioning correctly after April 1, the question is no longer how to migrate cleanly — it is how to recover with the constraints of a live operational issue.
The structured response is in three stages.
Stabilise. First, identify which add-ins are critical, which are inconvenient, and which are dispensable. For critical add-ins, determine whether a temporary workaround is available — for example, falling back to a read-only mode, replacing the add-in’s primary function with a manual process, or downgrading affected users to a deferred Office channel where the add-in still loads (where licensing permits). The objective is to stop the bleed, not to solve the migration.
Triage. With critical functions stabilised, audit the remaining add-ins and decide which ones must be migrated, which can be retired, and which should be redesigned. The decision matrix is the same one you would have used twelve months ago — but the time horizon is now compressed and the risk tolerance is necessarily different.
Recover. Execute the migration in the order dictated by the triage. Do not try to rebuild the original add-in surface in flight; ship a minimum viable replacement first, then iterate towards the full feature set. Resist the temptation to bundle additional product changes or feature work into the recovery; every additional change is risk in a project that already has more risk than it can afford.
For the recovery itself, McKenna Consultants offers a packaged engagement designed for exactly this situation. We work with customers whose VSTO add-ins are broken in production and need to be replaced under operational pressure. The model is intentionally narrow: identify the highest-priority add-in, ship a working web add-in replacement in a defined timeframe, and move to the next one.
What the VSTO Sunset Tells Us About the Next Wave
VSTO is not the only Microsoft extensibility model being retired. Three further deprecations are visible on the immediate horizon:
Exchange Web Services (EWS) — October 2026. EWS blocking enforcement begins on 1 October 2026. Outlook add-ins that still rely on EWS — and there are many — must migrate to Microsoft Graph. We will publish a dedicated Final Sprint article on EWS migration in early June.
Older Office.js APIs and runtime surfaces. Microsoft is gradually consolidating the Office.js runtime model around the shared runtime and a more uniform service worker-based execution. Older runtimes will be deprecated in turn. Add-ins built today on shared runtime will age well; older add-ins built on the legacy runtime will face their own migration eventually.
Selected SharePoint REST and CSOM endpoints. Microsoft has been signalling for several years that the long tail of SharePoint REST and Client-Side Object Model surfaces will narrow toward Microsoft Graph. Organisations whose Office add-ins call legacy SharePoint endpoints from add-in code will eventually face migration here too.
The lesson from VSTO is not that Microsoft platform migrations are unmanageable. The lesson is that they have a rhythm — multi-year deprecation announcements, mid-cycle warnings, then a hard cutoff — and that organisations who treat each migration as an isolated emergency repeat the same mistakes. The organisations that fared best in VSTO migration are the ones treating the next wave as a programme, not a project.
A Forward Plan: From VSTO Recovery to Sustainable Office Add-In Practice
A practical posture for enterprise IT post-April 2026:
- Treat shared runtime web add-ins on the modern Office Add-ins platform as the canonical extensibility model. Every new Office add-in your organisation builds should target this platform. Older add-ins still in operation should be on a tracked migration path.
- Treat Microsoft Graph as the canonical backend integration surface. Move existing EWS, SharePoint REST, and CSOM dependencies to Graph proactively, not reactively.
- Treat Microsoft Entra ID as the canonical identity boundary for add-in authentication. OAuth 2.0 with MSAL is now the default. Internal services that still rely on Windows authentication should be on an Entra ID migration path of their own.
- Treat AppSource or Microsoft 365 admin centre centralised deployment as the canonical distribution model. ClickOnce, MSI, and other legacy distribution mechanisms have no future for Office extensions.
- Maintain a deprecation horizon view. A simple register of every Microsoft technology your add-ins depend on, paired with the latest known deprecation status of each, is worth more than any single migration plan.
This posture is not theoretically novel. It is what a well-run Microsoft extensibility practice has looked like for the last three years. What VSTO migration has shown is that organisations who failed to adopt this posture earlier paid for it under pressure, while organisations who did adopt it earlier completed the migration as a managed change rather than a crisis.
How McKenna Can Help
McKenna Consultants has been delivering custom Office add-ins for two decades. Our team has built and migrated add-ins across Outlook, Word, Excel, and PowerPoint — including delivering complete VSTO-to-web migrations for enterprise customers under deadline pressure. We are equally experienced with the EWS-to-Microsoft-Graph migration that is the next operational priority for many of the same teams.
If your organisation is operating broken VSTO add-ins post-April 2026 and needs a recovery engagement, or is planning the next wave of Microsoft platform migrations and wants to do it as a managed programme rather than under pressure, we can help. Contact us to discuss your situation.
