SharePoint 2013 Workflows Retire April 2, 2026: What Breaks for Project Online Governance

Here is a pattern that has been appearing in Project Online tenants since early April. A PM submits a project proposal through the standard intake form. Nothing routes. No approval notification arrives. No rejection comes back. The request sits in queue, listed as active, with no forward progress. The PM escalates. The PMO director checks the workflow status. The workflow started on April 2 and never advanced past its first step.

The proposal is not stuck on a slow approver. The workflow engine that would route it has stopped running.

That is what the SharePoint 2013 workflows retirement looks like from inside a Project Online tenant: not a dramatic error screen but a quiet governance stall where requests go in and nothing comes out.

TL;DR SharePoint 2013 workflows retired on April 2, 2026. If your Project Online uses them for proposal approvals, demand-management gates, or EPM stage transitions, those processes stopped executing. The migration path is Power Automate. The rebuild is not technically complex, but it takes time you may have budgeted for your September 30 Project Online migration instead. Start with the workflow inventory below; it tells you which workflows to prioritize and which ones can wait.

What SharePoint 2013 Workflows Did in Project Online

SharePoint 2013 workflows are the governance engine inside most Project Online configurations built between 2013 and 2020. They are not a peripheral feature. For many PMOs, they are the process layer that separates a structured portfolio from a flat list of projects.

In Project Online, SharePoint 2013 workflows appeared in three main places.

Demand management and project intake. When a business unit submits a project request, a SharePoint 2013 workflow routes that request through the configured intake process: initial screening, scoring criteria, approval by a portfolio committee, and final project creation. Microsoft's own Project Online documentation describes this as the standard "Create, Select, and Manage" demand-management architecture. The workflow is what moves a request from submission to approved project.

EPM stage transitions. Enterprise Project Types define the stages a project moves through: Initiation, Planning, Execution, Closure. Each stage boundary can have a gate where a workflow verifies that required data is present, routes the project to an approver, and only advances the project when approval is granted. The workflow enforcing that gate is a SharePoint 2013 workflow in the vast majority of Project Online configurations.

Project Detail Page routing. Custom Project Detail Pages collect data at specific points in a project lifecycle. SharePoint 2013 workflows triggered actions when PDP submissions occurred: notifications, data validation, conditional routing based on custom field values.

All three integration points depended on the SharePoint 2013 workflow engine. According to Microsoft's SharePoint 2013 workflow retirement announcement, that engine stopped running for all existing Microsoft 365 tenants on April 2, 2026.

What the SharePoint 2013 Workflows Retirement Broke on April 2

The retirement is precise. Workflows that were in-flight on April 1 did not complete; they stalled at whatever step they had reached when the engine shut down. For Project Online specifically, this means:

Proposal approvals stopped routing. New project requests submitted through a demand-management workflow go nowhere. The workflow starts (because the submission triggers it) but never advances to the notification or approval step. Approvers receive no notifications. The requests accumulate in a queue that no one is reviewing because no one is being told to review it.

Stage gates stopped enforcing. A project that reaches the boundary between Planning and Execution may appear to advance without completing the gate, or may refuse to advance at all, depending on how the workflow was configured. In either case, the gate's enforcement logic is gone.

Project creation workflows stopped completing. For Enterprise Project Types that include a "create project" workflow step, new projects may not reach the Published state through the normal process.

The scope of impact depends entirely on how many active workflows your tenant had running and how deeply governance workflows were embedded in your PMO operating model. PMOs that built every process around staged workflows are now effectively operating without process controls.

How to Find Every Affected Workflow in Your Tenant

Before you can rebuild anything, you need to know what you are rebuilding. SharePoint provides a way to scan for 2013 workflows across a tenant, but it requires admin access and a few steps that are not obvious from the admin center UI.

1. Open the SharePoint admin center and navigate to the workflow migration report. This report lists all SharePoint 2013 workflows across site collections, including their status, associated list or library, and last run date.

2. Filter by your Project Online site collection. Your PWA site collection (typically at https://[tenant].sharepoint.com/sites/pwa) is where most governance workflows live. Some tenants have multiple PWA site collections for different business units; check each one.

3. Classify each workflow by function. For each workflow, note whether it is a demand-management workflow, a stage-gate workflow, a PDP routing workflow, or a custom automation. The classification determines rebuild priority.

4. Check the last run date. Workflows that last ran before January 2026 are lower priority. Workflows that last ran in March 2026 were actively used and are now broken.

5. Document the approval logic before the institutional knowledge walks. For each priority workflow, capture the steps: who approves at each stage, what conditions trigger branching, what notifications go out, what happens on rejection. This becomes the Power Automate rebuild specification.

The Project Online Inventory Checklist includes a workflow inventory section that structures this output into a format you can hand directly to whoever handles the rebuild.

Migrating to Power Automate: What the Rebuild Looks Like

Power Automate is Microsoft's supported path for organizations moving off SharePoint 2013 workflows. The good news: Power Automate can replicate almost everything a SharePoint 2013 workflow did in Project Online. The not-so-good news: it is a rebuild, not a migration. There is no tool that reads a SharePoint 2013 workflow definition and produces a Power Automate flow automatically.

The diagram below shows the component mapping between the two systems.

The rebuild sequence, in priority order:

1. Triage by impact on current work. Which broken workflows are blocking active projects or new proposals today? Demand-management approvals that prevent new projects from being created are Priority 1. Stage gates blocking in-flight projects mid-execution are Priority 2. Notification-only automations are Priority 3.

2. Rebuild demand-management approval flows first. A standard multi-approver project proposal flow takes two to three days to rebuild in Power Automate using the Approvals connector. Test with a real project request before marking it done.

3. Rebuild stage-gate flows using the Project Online REST API. Advancing a project between EPM stages in Power Automate requires calling the Project Online REST endpoint directly. This is where most rebuilds take longer than expected: the API call requires authentication setup and error handling that the SharePoint Designer visual editor handled implicitly.

4. Build in retry logic. SharePoint 2013 workflows had a built-in retry mechanism for transient failures. Power Automate flows require explicit retry scopes and failure branches. Add them from the start rather than after the first production incident.

What You Lose in the Move

Power Automate can replicate the function of SharePoint 2013 workflows for Project Online governance. It cannot replicate everything about the experience.

The workflow history view inside Project Online changes. SharePoint 2013 workflows logged their history inside the Project Online workflow status view, visible to PMs without leaving PWA. Power Automate runs log in the Power Automate run history, which is a different location and requires a different permission set to access. PMs used to checking workflow status inside PWA need to learn where to look.

The visual designer has a different learning curve. SharePoint Designer, used to build SharePoint 2013 workflows, had a step editor that Project Online admins learned to use without deep technical knowledge. Power Automate's designer is also visual, but the connector model and expression language (Power Fx) are different. Expect a learning curve for whoever maintains the flows, particularly for complex conditional branches.

Reading Enterprise Custom Fields is less direct. SharePoint 2013 workflows could reference Enterprise Custom Fields by display name. Power Automate reads them via the REST API, which requires knowing the field's internal name and parsing JSON responses. Document your ECF internal names as part of the workflow inventory pass.

None of these gaps are blockers. They are friction. Plan for the friction explicitly rather than discovering it mid-rebuild.

How the April 2 Retirement Changes Your September 30 Plan

Most Project Online migration plans treat September 30, 2026 as the single planning horizon. The SharePoint 2013 workflow retirement on April 2 added a second, earlier deadline that most plans did not account for. For any PMO now past April 2 without rebuilt workflows, the collision matters for two reasons.

Broken governance workflows disrupt the migration project itself. If your PMO uses demand-management workflows to approve new projects, and those workflows are broken, then the migration project may be operating outside normal governance controls. Project requests submitted since April 2 may not have been formally approved. Stage gates may not have advanced. The migration plan, if tracked as a project in Project Online, may be in an ambiguous governance state.

Workflow rebuild time competes directly with migration execution time. A migration plan that assumed the PMO would operate normally through September must now account for a parallel track: rebuild governance workflows in Power Automate while also executing the data migration. For PMOs with complex governance configurations, that parallel track is measured in weeks, not days.

The practical adjustment: run the Project Online migration checklist now, with the workflow inventory as the first section rather than an afterthought. Know what is broken before scheduling migration work. The full Project Online end-of-life timeline covers what happens between now and September 30 in more detail, including the data export window that closes before the service itself shuts down.

Run the free Project Online Inventory Checklist Map your workflows, custom fields, and project data in about 10 minutes and get a structured export plan you can hand to your migration team. No signup required. → Open the checklist

Microsoft Project Online™ is a trademark of Microsoft Corporation. Onplana is not affiliated with Microsoft.