SharePoint Add-ins and 2013 Workflows Retired: Migration Guide to SPFx and Power Automate

The Retirement Announcement

On April 2, 2026, Microsoft retired SharePoint Add-ins and SharePoint 2013 Workflows in SharePoint Online. This was not a gradual deprecation — it was a hard retirement date that Microsoft had communicated in the Microsoft 365 Message Center since 2023 and repeated across multiple roadmap announcements. If you have not yet migrated, your affected customisations stopped functioning on that date.

The retirement covers a broad surface area of the SharePoint extensibility model that organisations built on throughout the 2013–2018 era. Understanding exactly what was retired — and what was not — is the first step in scoping your migration project.

What Actually Stopped Working

The retirement covers four distinct technology areas, each with different migration paths:

• Provider-Hosted Add-ins (PHAs): Add-ins that ran external web applications authenticated via SharePoint's add-in permission model (ACS — Access Control Service). The ACS token issuance service was shut down, so PHA authentication fails entirely.
• SharePoint-Hosted Add-ins: Add-ins that ran client-side code in an app web. These stop loading because the app web provisioning infrastructure was retired.
• SharePoint 2013 Workflows: Workflows built in SharePoint Designer 2013 or Visual Studio using the 2013 workflow engine (Windows Workflow Foundation 4 hosted by Azure Workflow Service). The workflow service endpoint that processed these was shut down.
• Business Connectivity Services (BCS) External Lists: BCS external content types and external lists that depended on the Add-in model for authentication were also impacted.

What was not retired: SharePoint 2010 workflow templates (already retired earlier in 2023), classic Web Parts (retirement scheduled separately), SharePoint Framework (SPFx) — the modern replacement — and Power Automate flows.

Migrating Add-ins to SPFx Equivalents

The SharePoint Framework (SPFx) is the modern, supported replacement for both Provider-Hosted and SharePoint-Hosted Add-ins. SPFx solutions run in the context of the current user (no separate add-in permission grants), use the Microsoft Graph and SharePoint REST APIs via the current user's token, and are deployed via the tenant app catalog — the same infrastructure Add-ins used, but with a fully supported forward path.

Pattern Mapping: Add-in to SPFx

• SharePoint-Hosted Add-in with UI: Migrate to an SPFx web part. The JavaScript/HTML logic is nearly identical; replace the add-in web context (SP.ClientContext) with this.context.spHttpClient or PnPjs.
• Provider-Hosted Add-in (full-page app): Migrate to an SPFx Application Customiser (for full-page overlays or header/footer injection) or an SPFx web part hosted in a modern page. The external web app backend can remain — just replace ACS authentication with Azure AD app registration using Microsoft Graph permissions.
• Add-in with custom list forms: Migrate to SPFx List View Command Set extensions or SPFx Field Customisers.
• Provider-Hosted Add-in acting as a backend service: Replace ACS with an Azure AD app registration. The backend logic stays on your server; only the authentication mechanism changes.

// Old: Add-in CSOM (no longer works)
// var ctx = new SP.ClientContext(appWebUrl);
// var list = ctx.get_web().get_lists().getByTitle('Requests');

// New: SPFx SPHttpClient
import { SPHttpClient, SPHttpClientResponse } from "@microsoft/sp-http";

const response: SPHttpClientResponse = await this.context.spHttpClient.get(
  `${this.context.pageContext.web.absoluteUrl}/_api/web/lists/getbytitle('Requests')/items?$top=100`,
  SPHttpClient.configurations.v1
);
const data = await response.json();
console.log(data.value); // Array of list items

Migrating 2013 Workflows to Power Automate

SharePoint Designer 2013 workflows mapped to a fixed set of actions (Send Email, Set Field Value, Create List Item, Start Approval Process, and about 40 others). Every one of these has a direct Power Automate equivalent, usually a built-in connector action.

Action Mapping: 2013 Workflow to Power Automate Connectors

• Send Email: Office 365 Outlook connector — "Send an email (V2)"
• Start Approval Process: Approvals connector — "Start and wait for an approval"
• Set Field Value in Current Item: SharePoint connector — "Update item"
• Create List Item: SharePoint connector — "Create item"
• Log to History List: SharePoint connector — "Create item" (write to a log list) or use a Compose action for variable tracking
• Call HTTP Web Service: HTTP action — "HTTP" (premium connector)
• Set Workflow Status: SharePoint connector — "Update item" (write to a status column)
• Wait for Field Change: Power Automate trigger — "When an item is modified" with filter conditions

// 2013 Workflow trigger: "When an item is created or modified in a list"
// Power Automate equivalent (flow definition excerpt):

{
  "triggers": {
    "When_an_item_is_created": {
      "type": "OpenApiConnection",
      "inputs": {
        "host": { "connectionName": "shared_sharepointonline" },
        "operationId": "GetOnNewItems",
        "parameters": {
          "dataset": "https://contoso.sharepoint.com/sites/Procurement",
          "table":   "Purchase Requests"
        }
      }
    }
  }
}

Migrating Event Receivers

SharePoint Event Receivers — server-side code that fired on list events (ItemAdded, ItemUpdating, ItemDeleted) — were a common pattern for data validation, field defaulting, and cascading updates. With the retirement, any event receivers bundled inside Add-ins are also non-functional.

The two modern replacements are:

• Remote Event Receivers (RERs) via Azure Functions: Register a webhook on a SharePoint list that calls an Azure Function. The function receives the change notification and performs the action. This is the closest 1:1 replacement for synchronous ItemAdding/ItemUpdating scenarios where you need to validate and potentially reject changes.
• Power Automate HTTP Trigger: For asynchronous post-event scenarios (send email after item created, update another list after item changed), a Power Automate flow with an "When an item is created or modified" trigger handles the same use case without any custom code.

import { HttpRequest, HttpResponseInit, InvocationContext } from "@azure/functions";
import { ClientSecretCredential } from "@azure/identity";
import { Client } from "@microsoft/microsoft-graph-client";

export async function spWebhookReceiver(
  req: HttpRequest, context: InvocationContext
): Promise<HttpResponseInit> {
  // SharePoint validates webhook by sending a validationToken query param
  const validationToken = req.query.get("validationtoken");
  if (validationToken) {
    return { status: 200, body: validationToken };
  }

  // Process the change notification payload
  const body = await req.json() as { value: Array<{ siteUrl: string; resource: string }> };
  for (const notification of body.value) {
    context.log(`Change on ${notification.resource} at ${notification.siteUrl}`);
    // Query the changed items and apply business logic via Graph
    await processChange(notification.siteUrl, notification.resource);
  }
  return { status: 202 };
}

Migrating Content Editor Web Part Content

The Content Editor Web Part (CEWP) was used extensively to embed arbitrary HTML, CSS, and JavaScript on classic SharePoint pages. While the CEWP itself was not retired in this wave, the classic pages it runs on are increasingly unsupported, and any CEWP content that relied on Add-in infrastructure (SP.RequestExecutor cross-domain calls, add-in web URLs) now fails.

The migration path depends on what the CEWP content was doing:

• Display-only HTML/CSS styling: Move to a modern page with an Embed web part, or encapsulate in a simple SPFx web part that renders the same HTML.
• JavaScript that read SharePoint data via JSOM: Replace with an SPFx web part using spHttpClient or PnPjs. Modern pages do not load SP.js by default, so JSOM-dependent scripts will fail even if the CEWP renders.
• Embedded forms or calculators: Build as an SPFx web part using React or plain HTML. The SPFx generator scaffolds this in under 5 minutes for simple scenarios.
• Analytics or tracking scripts: Use SPFx Application Customiser to inject scripts tenant-wide or on specific sites, replacing per-page CEWP script injection.

Prioritising Migration by Business Impact

Most tenants have more Add-ins and 2013 workflows than they can migrate simultaneously. Use this prioritisation framework to sequence your migration sprints:

# Connect to SharePoint Admin Center
Connect-PnPOnline -Url "https://contoso-admin.sharepoint.com" -Interactive

# Get all site collections
$sites = Get-PnPTenantSite -IncludeOneDriveSites:$false

$addInReport = foreach ($site in $sites) {
  try {
    Connect-PnPOnline -Url $site.Url -Interactive
    $addIns = Get-PnPApp -Scope Site 2>$null
    foreach ($addIn in $addIns) {
      [PSCustomObject]@{
        SiteUrl      = $site.Url
        AddInTitle   = $addIn.Title
        AddInId      = $addIn.Id
        InstalledVer = $addIn.InstalledVersion
        Status       = $addIn.Status
      }
    }
  } catch { # Skip sites with access errors }
}

$addInReport | Export-Csv -Path ".\tenant-addin-inventory.csv" -NoTypeInformation
Write-Host "Found $($addInReport.Count) Add-in installations across $($sites.Count) sites"

Once you have the inventory, score each Add-in and workflow using three dimensions:

• Business criticality: Is this on the critical path for a core business process (finance approvals, HR onboarding, compliance sign-off)? Score 1–3.
• User volume: How many people are blocked daily? A broken approval workflow affecting 200 employees scores higher than a reporting Add-in used monthly by 3 people.
• Migration complexity: Provider-Hosted Add-ins with complex backend logic score higher complexity than a SharePoint-Hosted Add-in with a simple JSOM list read.

Migrate in order of: high criticality + high user volume first, then high criticality + low user volume, then low criticality in batch. Low complexity migrations can be done in parallel as filler work between complex migrations.

Timeline and Official Migration Resources

Microsoft has published official migration guidance and tooling across several channels. Use these as your primary reference alongside this guide:

• SharePoint Migration Tool (SPMT): Now includes an Add-in inventory report feature. Run it against your tenant to produce a structured inventory without PowerShell scripting.
• Microsoft 365 Assessment Tool: The Microsoft365AssessmentTool PowerShell module scans for Add-ins, 2013 workflows, BCS external lists, and classic pages in a single pass. Output is a structured report with migration recommendations.
• Power Automate Migration Assistant: Available in the Power Automate portal under Solutions > Migration, this tool can import exported SharePoint Designer 2013 workflow definitions (.xoml files) and generate a starter Power Automate flow structure — not a perfect migration, but a significant head start on action mapping.
• SPFx Yeoman generator: yo @microsoft/sharepoint — the official scaffolding tool for SPFx solutions. Use version 1.19 or later for SharePoint Online targets.
• PnP Migration Guidance on GitHub: The PnP community maintains detailed migration playbooks at pnp.github.io/sp-dev-docs/migration/ with worked examples for each Add-in pattern.