Decide every add-in before its model is retired

SharePoint Online stopped running add-ins on 2 April 2026 (add-in retirement, checked on 6 November 2026), so an add-in whose sites move there is left behind, decided or not. Subscription Edition still runs them, but an attach delivers their sites to a farm without the domain, services or trust they relied on. Chapter 2 counted the add-ins; this chapter decides each one while the old farm can still show what it does.

Which add-ins do your sites still depend on, and what becomes of each one where its sites are going?

The decision this chapter leads to is a disposition for every add-in (rebuild, replace or retire, and on Subscription Edition also keep), with its reason, what becomes of its data and its owner's agreement, before its sites move.

Which add-ins this chapter is for

Add-ins installed in sites on a SharePoint Server 2016 or 2019 farm whose content moves to Subscription Edition by attach (Chapter 23) or into SharePoint Online by copy (Chapters 8 and 9). Microsoft names two kinds. SharePoint-hosted add-ins consist "almost entirely of SharePoint components in an add-in web", with their logic in JavaScript; provider-hosted ones include "at least one remote component, such as a web application, service, or database" outside the farm. Either generally keeps its SharePoint components in the add-in web, "a special child web of the host web" (SharePoint Add-ins, checked on 6 November 2026).

What each destination still runs

Sources: add-in retirement (above), ACS retirement, deprecated or removed, Version 23H1 and SPFx on SharePoint Server, all checked on 6 November 2026, when Subscription Edition itself was in support (lifecycle).

Online, nothing keeps an add-in alive: an app catalogue "does not provide a way to continue using SharePoint Add-Ins in SharePoint Online after retirement", and for a provider-hosted add-in "changing authentication alone does not restore them" (both retirement pages, above). On Subscription Edition the online retirement "must not be interpreted as retirement of the SharePoint Server Add-in model": keeping an add-in there is a real option.

Count what is installed, not what is offered

A package in a catalogue is only "available for installation", and an add-in bought from the store came from the store, not from a catalogue (SharePoint Add-ins, above). What is installed is read web by web, with Get-SPAppInstance (checked on 6 November 2026). Microsoft's scans will not do it for you: the Migration Assessment Tool left support on 1 October 2026 (SMAT), and the migration tool's scan documents no risk code for add-ins (SPMT scan codes, both checked on 6 November 2026).

From an elevated SharePoint Management Shell on the old farm, outside business hours:

# Reads only. Writes addin-instances.csv and addin-farm.txt; changes nothing on any farm.
Write-Host "Listing add-in instances on every web, then the app domain and token issuers"
$rows = foreach ($site in (Get-SPSite -Limit All)) {
    foreach ($web in $site.AllWebs) {
        Get-SPAppInstance -Web $web | Select-Object @{n='HostWeb'; e={$web.Url}}, *
        $web.Dispose() }
    $site.Dispose() }
$rows | Export-Csv .\addin-instances.csv -NoTypeInformation
"App domain: $(Get-SPAppDomain)" | Out-File .\addin-farm.txt
Get-SPTrustedSecurityTokenIssuer | Format-List * | Out-File .\addin-farm.txt -Append

Microsoft documents the output only as "the metadata for an instance of an app", so the script keeps every field. We have not run it against a farm: run it on a test farm first, and treat its output as a starting inventory. Three answers do not come from it:

• The kind, and what it asks for. Save every package from the catalogues: each .app manifest declares the start page and the permissions requested (manifest and package), and an add-in principal, where named, is RemoteWebApplication "for provider-hosted SharePoint Add-ins" or Internal "mainly for SharePoint-hosted" ones (AppPrincipal element, both checked on 6 November 2026). For a provider-hosted one, record its server and how the farm trusts it.
• Use. Where search analytics run, an add-in's details page charts launches and distinct users per day (monitor apps, checked on 6 November 2026); otherwise, ask the owner.
• The owner, and for anything bought, its supplier.

What an attach carries, and what a copy leaves

Sources: Apps scan, configure an environment for apps, services upgrade and high-trust add-ins, all checked on 6 November 2026.

Hybrid configured on the new farm can undo what the attach brought. The Hybrid Configuration Wizard sets the farm's authentication realm to the tenant's context ID, and Microsoft warns that afterwards "existing SharePoint in Microsoft 365 add-ins fail to authenticate"; the wizard attempts the repair, and otherwise points to a support article on provider-hosted add-ins, workflow and cross-farm trust (Hybrid Configuration Wizard, checked on 7 November 2026). We would test every kept add-in again after hybrid is configured (Chapter 25).

Microsoft's procedure for 2013 workflows moves the App Management database, because the workflows "get their permission to SharePoint content through app principals stored" there (SharePoint Workflow Manager on a new farm), and a high-trust add-in's principal is registered in the same service (Register-SPAppPrincipal, both checked on 6 November 2026). What a kept add-in loses without that database, the upgrade pages do not say, and we do not know. We would move it, as Chapter 19 does, and prove each kept add-in on the rehearsal farm.

Rebuild, replace, retire, or keep

Sources: add-in retirement (above) and modernisation guidance, checked on 6 November 2026.

Rebuild from a specification, not from the old code: for a provider-hosted add-in, "there is no conversion tool that you can use" (provider-hosted to Entra ID, checked on 6 November 2026). Some behaviour does not survive online: remote event receivers registered through ACS stopped on 2 April 2026, those registered with Entra ID retire on 1 July 2027, and webhooks, their replacement, cannot block or cancel a change (retirement FAQ, checked on 6 November 2026). We recommend a specification written from the manifest, agreed with the owner and naming what the new model cannot do. On Subscription Edition a rebuild keeps the plumbing: Microsoft's steps for deploying SPFx there start with App Management and the app catalogue (SPFx on SharePoint Server, above).

Replace a bought add-in through its supplier. Microsoft's advice is to "contact the provider for an updated version that does not depend on the SharePoint Add-In extensibility model" (add-in retirement, above).

Retire an add-in nobody uses or claims, but settle its data first: "the app web is deleted when you uninstall the Add-In", so copy out what it holds. One removed by mistake comes back from the recycle bin with its add-in web (retirement FAQ, above).

Keep, on Subscription Edition only, when the new farm has everything an attach does not carry, and a catalogue for each web application that hosts add-ins (plan for apps, checked on 6 November 2026). A high-trust add-in "is trusted to use any user identity that the add-in needs" (high-trust add-ins, above), so we would review it as Chapter 17 reviews elevated code. A licence bought through the store is bound to one SharePoint Server deployment and transferable three times (app licences, checked on 6 November 2026); whether that still works now that acquiring from the marketplace has ended for SharePoint Server, we do not know, so ask the supplier. Keeping holds for this destination only: a later move online decides the add-in again.

Out of scope

Farm solutions are Chapter 15, elevated code Chapter 17, SPFx packages Chapter 16, workflows an add-in deploys Chapter 19, sign-in Chapter 21, applications that call SharePoint without being installed in a site Chapter 22, and the attach Chapter 23. Office Add-ins, tutorials and marketplace publishing are not covered. The site's page on SharePoint Add-ins and Azure ACS sets out what the online retirement stopped.

Before you continue

• Every add-in instance on the old farm is listed with its host web, and every catalogue's packages are saved
• Each add-in names its kind and permissions, and a provider-hosted one its server and its trust
• Each add-in has an owner who confirmed its use, and a supplier where it was bought
• Data in each add-in web is copied out before any uninstall, or moves by attach with a kept add-in
• Each add-in is rebuilt, replaced, retired or, on Subscription Edition, kept, with its reason and its owner's agreement
• Every rebuild has a specification its owner agreed, naming what the new model cannot do
• Every kept add-in ran on the rehearsal farm, with its domain, services, catalogue and trust rebuilt

Download chapter 18 (PDF)Same text, same tables, same sources as this page.