SharePoint Add-ins Retirement: The April 2026 Migration Guide

On April 2, 2026, Microsoft permanently retires the SharePoint Add-in extensibility model and Azure Access Control Service (ACS) for SharePoint Online. This is a hard cutoff — not a deprecation warning. After this date, all legacy SharePoint Add-ins stop functioning across all tenants, breaking custom UIs, integrations, and business workflows with no degraded mode or grace period. (learn.microsoft.com)

The primary replacements are SharePoint Framework (SPFx) for UI components, Power Platform for workflows and forms, and Microsoft Entra ID (formerly Azure AD) for authentication. There is no automatic upgrade path between any of these and the old add-in model. Each affected solution must be rebuilt as a net-new application.

This guide covers exactly what breaks, how to audit your tenant, the real migration paths — including where each one fails — and how to execute the transition without losing data or disrupting production workflows.

For a broader view of Microsoft's 2026 end-of-support events — including SharePoint Server 2016/2019, Exchange 2016, and Office Online Server — see our Microsoft 2026 End-of-Support Timeline.

The April 2, 2026 Hard Stop: What Exactly Breaks

SharePoint Add-ins are the legacy extensibility model introduced with SharePoint 2013. Microsoft documents two major types: SharePoint-hosted add-ins, which run inside SharePoint using an isolated app web, and provider-hosted add-ins, which run on external servers and use Azure ACS to authenticate back into SharePoint. (learn.microsoft.com)

Here is what stops working on April 2, 2026:

• SharePoint-hosted add-ins no longer load. Add-in web parts fail to render. Any custom UI elements, pages, or lists stored in the add-in's isolated app web become inaccessible.
• Provider-hosted add-ins lose their authentication mechanism. Azure ACS, which these add-ins depend on to call back into SharePoint APIs, is retired on the same date.
• Azure ACS-based scripts and integrations — even those outside the add-in model — also stop working. Any custom application granted access via AppRegNew.aspx and AppInv.aspx using ACS-issued client IDs and secrets will fail.
• Remote Event Receivers registered via ACS stop firing. Events that your add-ins intercepted — item additions, deletions, updates — no longer trigger.
• The public marketplace no longer serves add-ins. Acquiring add-ins from AppSource has been impossible since July 2024.
• Project Online add-ins follow the same retirement path because Project Online sits on top of SharePoint Online.

The retirement was phased:

(learn.microsoft.com)

Two scope boundaries are worth noting. First, tenant and site app catalogs still exist — Microsoft continues to use them for SPFx deployment. What changes is add-in deployment through those catalogs. Second, this retirement is a SharePoint Online event. SharePoint on-premises add-ins are not retired by this change, though public marketplace acquisition is still affected. (learn.microsoft.com)

The Azure ACS Problem

Azure Access Control Service (ACS) is the authentication layer that provider-hosted add-ins use to communicate with SharePoint Online. It is also used independently by custom applications granted access via AppRegNew.aspx and AppInv.aspx.

The ACS retirement breaks two things at once:

1. Provider-hosted add-ins cannot authenticate to SharePoint — their API callbacks fail.
2. Standalone scripts and daemon jobs that used ACS-issued client IDs and secrets to access SharePoint data — even outside the add-in model — also stop working.

The replacement is Microsoft Entra ID (formerly Azure AD). All applications must be registered in Entra ID and use modern OAuth 2.0 flows. For applications that need granular, site-specific permissions rather than tenant-wide access, Microsoft recommends the Sites.Selected permission scope. (learn.microsoft.com)

For a detailed look at how this auth change affects your SharePoint security posture, see our SharePoint Permissions & Security Best Practices guide.

The App-Web Data Trap

When you uninstall a SharePoint-hosted add-in, its app web is deleted — all lists, libraries, documents, and configuration stored there are permanently removed. You must extract this data before uninstalling anything. If you accidentally uninstall, check the site's Recycle Bin — restoring the add-in from there will also restore its app web. But that is not how you want to run a production cutover. (learn.microsoft.com)

Remote Event Receivers

ACS-based Remote Event Receivers stop firing on April 2, 2026. Microsoft recommends moving to SharePoint Online webhooks, but webhooks are not a 1:1 replacement: they are asynchronous, list-item focused, and cannot cancel an in-flight change.

Microsoft documents a narrow bridge: Remote Event Receivers registered with an Entra ID application (using Sites.Selected) can continue functioning until July 1, 2027. This buys time for a proper redesign, but it is a temporary exception, not a reason to preserve the old architecture. (learn.microsoft.com)

How to Audit Your Tenant: Finding Hidden Add-ins and ACS Dependencies

Before you can migrate anything, you need a complete inventory. Many organizations discover add-ins they did not know existed — installed years ago by former employees, buried in subsites, or deployed by third-party vendors.

The Microsoft 365 Assessment Tool

Microsoft's recommended approach is the Microsoft 365 Assessment Tool, an open-source CLI maintained by Microsoft and the PnP community. It scans your SharePoint Online sites and generates CSV files plus a Power BI report showing all add-in and ACS usage. (learn.microsoft.com)

To run a SharePoint Add-in and Azure ACS assessment:

# Download from https://github.com/pnp/pnpassessment/releases
 
# Start the assessment
microsoft365-assessment.exe start --mode AddInsACS \
  --authmode application \
  --tenant yourtenant.sharepoint.com \
  --applicationid <entra-app-id> \
  --certpath My|CurrentUser|<thumbprint>
 
# Check status
microsoft365-assessment.exe status
 
# Generate the Power BI report
microsoft365-assessment.exe report --id <assessment-id>

One operational note: the scan can appear stuck at the start because it first retrieves Azure ACS principals before beginning per-site assessment. On larger tenants, let it run. That first phase is exactly the part you need for provider-hosted add-ins and old app-only usage. (pnp.github.io)

The generated report lets you:

• Identify every SharePoint Add-in across the tenant, per site
• See the source — marketplace, app catalog, or custom-deployed
• Inspect ACS principals — permission scopes, validity, app-only access, redirect URIs, app domains
• Identify who installed each add-in and when
• Classify add-in types — SharePoint-hosted, provider-hosted, or hybrid

The CSVs are what your engineers will actually sort, join, and work from. The Power BI report is useful for executive triage. (pnp.github.io)

Manual Checks

The assessment tool is comprehensive, but supplement it with:

• Site Contents pages: Navigate to /_layouts/15/viewlsts.aspx on each site. Add-ins appear with a distinct icon and often have an app web URL pattern like https://[app-prefix]-[app-hash].sharepoint.com.
• App Principals page: Visit /_layouts/15/appprincipals.aspx to see all application principals with site permissions. This page shows both ACS-based and Entra-based principals — an entry here does not automatically mean it uses ACS.
• PowerShell inventory: Use Get-PnPApp and Get-SPOAppInfo to enumerate deployed apps programmatically.
• Code and config search: Search for patterns like SPHostUrl, SPAppWebUrl, WCF-style IRemoteEventService, and legacy AppInv.aspx-style permission grants to find undocumented dependencies. (learn.microsoft.com)

The Audit Checklist

For each discovered add-in, record:

• Add-in name and type (SharePoint-hosted / provider-hosted / hybrid)
• Sites where installed (count and list)
• Business function (what workflow or UI does it power?)
• Data stored in app webs (lists, libraries, documents)
• ACS principal details (client ID, permission scopes, app-only access, expiration)
• Vendor/owner (internal dev team, ISV, former employee)
• Remote Event Receivers (any synchronous blocking events?)
• External dependencies (databases, APIs, Azure Functions, queues)
• Criticality rating (business-critical / nice-to-have / unused)

Why There Is No Automatic Upgrade to SPFx

This is the most misunderstood aspect of the retirement. You cannot replace a SharePoint Add-in package with an SPFx package and get an automatic upgrade. The two models are architecturally incompatible.

Microsoft's own add-in update documentation states that the update system cannot change add-in type, and migrating from an old add-in to a new one requires a new product ID with data migration logic provided by you. As Microsoft MVP Andrew Connell (Voitanos) puts it, these are "migration projects, not upgrades." (learn.microsoft.com)

Architectural Differences

Each add-in must be rebuilt as a new SPFx solution with its own GUIDs, its own deployment package, and its own permission model.

Two SPFx Migration Blockers With No Direct Replacement

There are two scenarios where the add-in model had capabilities that SPFx does not offer:

1. App deployment lifecycle events: In the add-in model, you could fire a remote endpoint when an app was installed or about to be uninstalled — useful for provisioning lists, libraries, or configuration on first run. SPFx has no equivalent. The recommended workaround is to implement a first-run check in your web part code that provisions resources when it detects they do not exist.

2. Synchronous event blocking: Remote Event Receivers could intercept an action (e.g., an item being added to a list) and cancel it based on custom logic. Webhooks are asynchronous only — they notify after the event has occurred. If you relied on synchronous blocking, you need to redesign: use SPFx list form customizers to validate input before submission, or restrict permissions on the target list so unauthorized changes cannot happen at all.

That architectural break is exactly why bad migrations drift into months of rework. Teams start by porting UI, then discover an app web with business data, an ACS principal with tenant-wide access, or a Remote Event Receiver that used to block invalid list changes. Those are not cosmetic details. They are the system.

Migration Paths: SPFx vs. Power Platform vs. Entra ID

The right migration target depends on what your add-in actually does. There is no single replacement — it is a mapping exercise.

Decision Framework

(learn.microsoft.com)

Path 1: SPFx — For UI Components and Page-Level Extensions

SharePoint Framework is the primary replacement for anything that rendered UI in SharePoint. SPFx web parts run client-side using TypeScript and modern JavaScript frameworks (React is the most common choice). They deploy to the app catalog as .sppkg packages instead of .app packages. (learn.microsoft.com)

The practical mapping: old App Parts become SPFx web parts. Old status bars and notifications become Application Customizers. Old list commands become Command Sets. Old field-level rendering moves to Field Customizers or list formatting JSON depending on complexity. SPFx works on both classic and modern pages.

Key steps:

1. Set up the SPFx dev environment: Node.js (LTS), Yeoman generator (@microsoft/generator-sharepoint), and your preferred editor.
2. Scaffold a new solution: yo @microsoft/sharepoint — choose web part, extension, or library component.
3. Rebuild the UI: Port your add-in's HTML/JS to React or vanilla TypeScript. Replace JSOM/CAML data access with SPHttpClient, PnPjs, or Microsoft Graph calls.
4. Handle permissions: If your add-in accessed data with elevated (app-only) permissions, register an Entra ID app and use the on-behalf-of flow or certificate-based app-only auth.
5. Deploy to app catalog: Upload the .sppkg to your tenant or site collection app catalog. Enable tenant-wide deployment if appropriate.
6. Replace add-in instances on pages: Add SPFx web parts via the Microsoft Graph Pages API or manually. Use the PnP Transformation Framework to convert classic pages to modern pages if needed.

Path 2: Power Platform — For Workflows and Forms

Not everything needs custom code.

Power Apps replaces custom list forms. If your add-in rendered a custom data entry form, a Power App embedded in a SharePoint list provides a similar experience without writing TypeScript. Microsoft documents SharePoint list form customization directly from the SharePoint UI. (learn.microsoft.com)

Watch for Power Apps edge cases: the SharePointIntegration control only exposes some properties when the form runs inside SharePoint, not during studio design time. Those properties may not be available in OnStart or OnVisible. Test RequestHide() in OnSuccess so SharePoint knows when to close the form. If your old add-in had hidden lifecycle assumptions, test these behaviors explicitly. (learn.microsoft.com)

Power Automate replaces event-driven background logic. Where your add-in used Remote Event Receivers to trigger actions on list changes, a Power Automate flow with a "When an item is created or modified" trigger achieves the same result — with a visual designer and built-in connectors.

Two migration gotchas with Power Automate:

1. Conditional Access alignment: When users run or view flows from SharePoint lists and libraries, SharePoint performs a token exchange with Power Automate. This requires consistent Conditional Access policies between SharePoint and Power Automate. (learn.microsoft.com)
2. Flow ownership: For critical or long-running flows, use service principal ownership instead of user ownership. Flows break silently when an employee leaves or loses access. Be cautious with the shortcut of adding a Microsoft List as a flow owner — users with edit permission on that list automatically get owner access to the flow, which is a problem for sensitive production replacements. (learn.microsoft.com)

The trade-off: Power Platform is easier to build but harder to govern at scale. Complex logic that previously ran in a single provider-hosted add-in may need to be split across multiple Power Automate flows, each with its own trigger and error handling.

Path 3: Entra ID — For Backend Integrations

If your provider-hosted add-in's backend is a standalone web application (ASP.NET, Node.js, Python) that calls SharePoint APIs, the backend code itself may be mostly reusable. The critical change is authentication:

1. Register the app in Microsoft Entra ID (Azure portal → App Registrations).
2. Assign Microsoft Graph permissions (Sites.Selected for granular access, or Sites.ReadWrite.All for broader scope).
3. Replace ACS token acquisition with MSAL (Microsoft Authentication Library) using client_credentials flow with a certificate. Client secrets are still supported but certificates are recommended for production.
4. Update API calls: migrate from SharePoint REST (/_api/) to Microsoft Graph (/v1.0/sites/) where possible.
5. Remove the add-in manifest and any AppRegNew.aspx / AppInv.aspx registrations.

This is the right time to tighten security. ACS-style app-only permissions were effectively broad and not selective at the site level. Newer Entra-based patterns use scoped approaches like resource-specific consent or Sites.Selected. If the old add-in had tenant-wide reach but only touched three sites, fix that now. (learn.microsoft.com)

Replacing Remote Event Receivers

Webhooks are the default replacement, but they are not equivalent. SharePoint webhooks are list-item focused, asynchronous, subscription-based notifications. Key constraints:

• Webhook subscriptions must expire within 180 days and need renewal
• Notifications are async only — no blocking
• The payload does not contain the changed item data; you must call back using GetChanges() for reconciliation
• Failed deliveries are retried up to five times at five-minute intervals before being dropped

(learn.microsoft.com)

If you need synchronous blocking and cannot redesign immediately, the temporary bridge is an Entra-registered Remote Event Receiver using Sites.Selected, which Microsoft supports until July 1, 2027. Use this only to buy time for a proper redesign.

The Risks of DIY Rebuilds and Open-Source Scripts

The PnP community has built excellent tools — the Transformation Framework, PnPjs, PnP PowerShell — and they are a legitimate part of any migration toolkit. But there are real risks to treating them as your entire strategy.

No SLA on PnP Components

Microsoft's own documentation is explicit: PnP components are "open-source assets backed by an active community providing support for them" and "there is no SLA for open-source tool support from official Microsoft support channels." If a PnP script breaks during your migration weekend, your support ticket goes to a GitHub issues list, not to a Microsoft engineer with an SLA. (learn.microsoft.com)

The Internal Rebuild Timeline Problem

Organizations that plan to rebuild add-ins internally often underestimate the scope. Each add-in is a full migration project: audit, data extraction, UI rebuild, permission redesign, testing, deployment, and user communication. Multiply that by 10–50 add-ins across a mid-size tenant, and internal teams commonly face 6–18 month timelines.

The pattern we see repeatedly: the IT team starts strong on the first two add-ins, then gets pulled into other priorities. The remaining add-ins sit in a backlog until the deadline forces a crisis response.

What DIY Approaches Miss

• App web data: The PnP Transformation Framework helps convert classic pages to modern pages, but it does not extract data trapped in add-in app webs. That requires separate scripting.
• Business logic mapping: An add-in is not just UI. It is often a tangle of Remote Event Receivers, custom forms, list-level permissions, and backend API calls. Automated tools convert the page; they do not reverse-engineer the logic.
• Regression testing: After rebuild, every workflow that touched the old add-in needs validation. There is no automated way to verify that a rebuilt SPFx web part behaves identically to the add-in it replaces.
• Page transformation is not migration: Microsoft's own migration docs state that when you replace an old add-in with a new one and the storage or schema changes, you must supply the migration code. UI transformation without data migration is how quiet data loss happens. (learn.microsoft.com)

Step-by-Step Migration Plan

1. Freeze the Legacy Estate

Stop new add-in deployments, freeze classic page edits on affected sites, and get business owners to sign off on a controlled migration window. This is about freezing legacy change, not blocking modern deployment. App catalogs still matter — you will use them to deploy the SPFx replacements.

2. Classify Each Add-in

For each add-in, document five things: UX surface, data store, auth model, event model, and external dependencies. Then classify into one of four buckets:

1. Retire — No one uses it. Uninstall after extracting any data.
2. Replace with no-code — List formatting, Power Apps, or Power Automate can cover it.
3. Rebuild in SPFx — Custom UI or logic that needs full development.
4. Re-auth only — Provider-hosted backend that just needs ACS → Entra ID auth migration.

That one-page classification sheet is what turns a vague migration backlog into an executable runbook.

3. Extract App-Web Data Before Touching Anything

For every add-in with data in its app web, extract before uninstalling:

# Connect to the app web
Connect-PnPOnline -Url "https://[tenant]-[app-hash].sharepoint.com/[app-web-path]" -Interactive
 
# Get all lists in the app web
$lists = Get-PnPList
 
foreach ($list in $lists) {
    # Export list items to CSV
    $items = Get-PnPListItem -List $list.Title -PageSize 500
    $items | Select-Object -ExpandProperty FieldValues |
        Export-Csv -Path "./export/$($list.Title).csv" -NoTypeInformation
}
 
# Export document libraries separately
$docs = Get-PnPListItem -List "Documents" -PageSize 500
foreach ($doc in $docs) {
    Get-PnPFile -Url $doc.FieldValues.FileRef -Path "./export/docs/" -AsFile
}

Depending on the target architecture, the extracted data might go into a host-site list, a hidden operational list, Dataverse, or an external store. Microsoft's FAQ is clear: when the new solution uses a different storage model, you must provide the data migration logic yourself. (learn.microsoft.com)

4. Build and Deploy Replacements

For each add-in in the "Rebuild" bucket, create a new SPFx solution. For "Re-auth" items, update the backend code to use MSAL and Entra ID. For "Replace" items, build Power Automate flows or Power Apps as appropriate.

The critical detail: deploy the new solution alongside the old add-in first. Run both in parallel for a testing window. Validate that the new solution produces identical results before removing the old one.

5. Modernize Authentication and Harden Permissions

Use Entra ID for all SharePoint Online app-only access. Prefer the narrowest scope you can justify — Sites.Selected or resource-specific consent where possible. Do not recreate an ACS-era tenant-wide permission footprint unless the workload truly requires it.

After you have verified there is no remaining business-relevant ACS app-only usage:

Set-SPOTenant -DisableCustomAppAuthentication $true

This is a hardening step after migration, not the migration plan itself. Microsoft's retirement guidance notes this switch does not affect provider-hosted add-ins directly. (learn.microsoft.com)

6. Test the Edge Cases

Validate page placement, deep links, CRUD behavior, permissions, notification timing, and audit outcomes. If you replaced Remote Event Receivers with webhooks, explicitly test delayed processing, subscription renewal, and retry logic — webhook subscriptions expire and failed deliveries are retried on a limited schedule. (learn.microsoft.com)

7. Cut Over and Retire

• Remove old add-in web parts from pages
• Add new SPFx web parts
• Uninstall legacy add-ins from sites (app webs should now be empty of critical data)
• Disable add-in support at the tenant level
• Update documentation and notify end users

For a deeper look at how we structure migration projects, see How We Run Migrations at ClonePartner.

Your Action Plan

This week:

• Run the Microsoft 365 Assessment Tool against your tenant
• Generate the Power BI report and review the add-in inventory
• Identify business-critical add-ins that are actively affected

This month:

• Extract all data from app webs before any uninstalls
• Contact third-party add-in vendors — ask for their SPFx replacement
• Classify every add-in: Retire / Replace / Rebuild / Re-auth
• Scope the rebuild effort for SPFx items

Within 60 days:

• Complete all SPFx rebuilds and Power Platform replacements
• Migrate all ACS-based integrations to Entra ID
• Disable add-in support at the tenant level
• Document the new architecture

This retirement is also an opportunity to modernize your broader SharePoint architecture. If you are still running classic subsites, consider moving to modern hub sites as part of the same project.

When a Migration Partner Makes Sense

If the add-in is a thin UI wrapper and your team owns the code, you can usually rebuild it internally. If it mixes app-web data, ACS principals with broad permissions, external services, Remote Event Receivers, and business-critical workflows, the hard part is no longer React or Power Apps. The hard part is reverse-engineering behavior and moving trapped data without breaking production.

At ClonePartner, we handle this exact class of work: inventory, data extraction, logic mapping, rebuild, validation, and controlled cutover. We work in days, not months.