What Is a SharePoint Add-In?
A SharePoint Add-In is a legacy extensibility package, formerly called an app for SharePoint, built with the SharePoint Add-In model. Add-Ins could be SharePoint-hosted or provider-hosted and use app identities, permissions, pages, remote services, and APIs. The model retired in SharePoint Online on April 2, 2026.
What SharePoint Add-In Means in SharePoint
The Add-In model allowed a solution to be installed from a public marketplace or organizational App Catalog and operate with declared permissions. SharePoint-hosted Add-Ins placed components inside SharePoint, while provider-hosted Add-Ins ran substantial application logic in an external web application and communicated with SharePoint. Older documentation may also call these solutions SharePoint Apps.
This model is now historical for SharePoint Online. Microsoft’s retirement means Add-Ins no longer function in SharePoint Online tenants after April 2, 2026; it is not merely a warning about future support. The tenant App Catalog itself remains because it is also used to deploy SharePoint Framework packages. On-premises SharePoint Add-Ins follow the support lifecycle of the applicable server product rather than this Online retirement date.
Why It Matters to the Business
A retired Add-In may have supported a visible web part, a background integration, a custom form, a workflow, a provisioning process, or an embedded business application. If that capability stopped, the problem cannot be solved by re-enabling a retired platform. Owners must decide whether the business process is still required and choose a supported replacement.
Modernization is an opportunity to remove low-value customization instead of rebuilding everything. For each Add-In, document users, frequency, data, compliance impact, integrations, support history, and the consequence of removal. A focused replacement can often use standard SharePoint, Power Platform, SPFx, Microsoft Graph, SharePoint APIs, and Azure services in a simpler architecture.
What SharePoint Administrators Need to Know
Administrators should inventory tenant and site collection App Catalog entries, installed apps, affected sites, owners, permission grants, remote endpoints, certificates or secrets, scheduled jobs, and data stores. An App Catalog package name alone may not reveal the whole solution; provider-hosted components can exist outside Microsoft 365 and need separate discovery and decommissioning.
Replacement design should split the legacy solution into capabilities. SPFx is Microsoft’s primary replacement for client-side SharePoint user experiences. Microsoft Graph and supported SharePoint APIs handle data access; Power Automate can replace suitable workflows; and Azure can host APIs, jobs, or application logic. Each replacement requires least-privilege authentication, testing, deployment, monitoring, and an explicit cutover plan.
What to Consider
Treat Online retirement as complete
SharePoint Online Add-Ins stopped working on April 2, 2026. Troubleshooting should focus on business continuity and replacement, not attempting to restore the retired service.
Choose replacements by capability
Use SPFx for supported client experiences, APIs for data, Power Platform for appropriate low-code processes, and Azure for hosted services. One legacy Add-In may become several governed components.
Decommission securely
After validation and cutover, remove obsolete packages and grants, rotate or revoke secrets, retire infrastructure, preserve required records, update support documentation, and monitor for residual calls.
Practical Takeaway
SharePoint Add-Ins are no longer a working SharePoint Online architecture; organizations should inventory remaining dependencies, restore business continuity with supported services, and securely retire the legacy components.
How This Shows Up in the Field
Legacy dashboard replacement
A retired SharePoint-hosted dashboard is rebuilt as an accessible SPFx web part using supported APIs, with telemetry, app catalog deployment, and a named product owner.
Provider-hosted request application
A team maps the old remote application into an SPFx interface, an Azure API with modern authentication, and a Power Automate approval flow, then removes obsolete app permissions and secrets.
Legacy SharePoint Add-Ins and modern replacements
| SharePoint Add-In model | A retired SharePoint Online model based on SharePoint-hosted or provider-hosted packages, add-in permissions, app identities, pages, and remote components. |
|---|---|
| SharePoint Framework | Microsoft’s primary supported client-side model for modern SharePoint web parts, extensions, and selected Microsoft 365 experiences. |
Related 6SC Services and Proof
Related SharePoint Glossary Terms
Frequently Asked Questions
Do SharePoint Add-Ins still work in SharePoint Online?
No. Microsoft retired the SharePoint Add-In model in SharePoint Online, and Add-Ins stopped working for all tenants on April 2, 2026. Any dependent process needs a supported replacement or formal retirement.
What replaces a SharePoint Add-In?
Microsoft points to SPFx as the primary replacement for client-side SharePoint customization. A full solution may also require Microsoft Graph, SharePoint APIs, Power Automate, Power Apps, Azure services, or standard features.
Are on-premises SharePoint Add-Ins also retired?
The April 2, 2026 retirement applies to SharePoint Online. Microsoft states that Add-Ins in supported on-premises SharePoint environments continue according to the relevant SharePoint Server product lifecycle and support boundaries.
Official Microsoft References
- SharePoint Add-In retirement announcement
- SharePoint Add-In and Azure ACS retirement FAQ
- SharePoint Framework overview
Editorial review date: July 13, 2026. Product status and licensing can change; confirm current Microsoft documentation before implementation.
Replace retired SharePoint Add-Ins now
6SC can identify failed or hidden dependencies, prioritize business continuity, design modern replacements, migrate users and data, and securely decommission legacy components.
Talk with 6SC