Your workflows already stopped
This post is for the orgs that didn’t make it. The migration window closed, the calendar reminders got snoozed, and on April 2, 2026 Microsoft retired SharePoint 2013 workflows from SharePoint Online for good, with no extension. The approval and notification workflows you’d been running for years stopped that day.
If a document submitted last week never routed to its approver, or a status column that used to update itself has gone quiet, this is why. Six weeks on, you’re not planning a migration anymore. You’re doing recovery.
The good news, such as it is: nothing was wiped. Your workflow definitions are still sitting in their sites. They just don’t run, and you can’t edit them. This post is the recovery path: find what you had, decide what’s worth saving, and bring the survivors back.
First: what “retired” actually means
The word people reach for is “deleted.” It’s the wrong word, and getting it right changes how you recover.
Your SharePoint 2013 workflow definitions still exist. A SharePoint Designer 2013 workflow stores itself as a set of files inside the site, in a Workflows document library (one folder per workflow, holding the .xoml markup plus its config and rules files). Retirement didn’t touch those files. What stopped is the engine that reads them. So the definitions remain, viewable as raw XML, but they cannot run and cannot be edited.
That distinction is your recovery asset. The logic of every old workflow is still legible if you know where to look.
Step one: inventory what you lost
You can’t recover what you can’t see. Three sources, in order of usefulness.
The Microsoft 365 Assessment tool. This is Microsoft’s open-source PnP tool, and it still runs fine as a post-mortem. Point its “Workflow 2013” assessment at your tenant and it produces a Power BI report listing every workflow, the lists it was attached to, how recently and how often it ran, and a Power Automate upgradability score for each one. Treat that score as a planning hint, high score means a simple built-in workflow type that rebuilds fast, low score means custom logic, not a promise of automatic migration. Every rebuild here is manual.
PnP PowerShell. For a closer look, Get-PnPWorkflowSubscription and Get-PnPWorkflowDefinition enumerate the workflow definitions and which lists they were associated with. This is how you confirm the assessment report against the actual site.
The raw definition files. Browse to the Workflows library in each affected site and download the folders. Those .xoml and rules files are the source of truth for what each workflow did. Open them and you can reverse-engineer the branching, the approvers, the email steps. This beats hoping SharePoint Designer’s visual canvas still renders a retired workflow; download the files and you own the logic regardless.
Where the definitions live
Retirement didn't delete anything. Each old workflow's definition is still here as files. Download the folder and you can read exactly what it did.
One source to be careful with: the hidden Workflow History list. It exists, but it auto-purges entries older than 60 days. By mid-May 2026, six weeks past the retirement, it is an incomplete record. Use it to answer “what ran often recently,” not as a full census of everything you had.
Step two: triage, not everything deserves a rebuild
Here’s the mistake to avoid: treating the inventory as a to-do list and rebuilding all of it. Most orgs accumulate workflows nobody uses. A retirement is a free excuse to clear them out.
Run each workflow against four signals:
- Recent usage. No runs in the last year? It was almost certainly abandoned before April. Leave it dead.
- Where it lived. A workflow on an active, in-use library matters. One on an archive list nobody touches does not.
- Complexity. A high upgradability score means a simple, built-in workflow type that’s fast to rebuild. A low score means custom logic that needs a manual rebuild, and that’s the point to ask whether it’s worth it at all.
- Business criticality. Ask the list owners directly. If a workflow has been broken for six weeks and nobody has complained, that silence is your answer.
The recovery sequence
Inventory, then triage, then rebuild. Skipping the middle step is how you waste a week rebuilding workflows nobody missed.
Done honestly, triage usually shrinks the rebuild list to a handful of workflows that genuinely run the business. That’s the list you act on.
Step three: stopgaps for the approval that’s broken right now
Triage takes a little time. If a real business approval (invoices, contracts, time off) is dead and people are stuck today, you need an interim fix before the proper rebuild. Three options, fastest first:
- Built-in SharePoint approvals. On any list or library, the Automate → Configure approvals menu turns on a Microsoft-managed, no-code approval. It is a Power Automate flow under the hood, but you build nothing. You preset default approvers and you’re done. This is the fastest way to get a routed approval working again.
- A minimal cloud flow. If the built-in approval is too rigid, a three-step flow (SharePoint trigger, Start and wait for an approval, send an email) gets you a working approval in well under an hour.
- Library content approval. The bare minimum: in the library’s Versioning settings, turn on Require content approval. You get native Pending / Approved / Rejected states with no routing and no notifications. It’s a fallback, not a real workflow, but it stops uncontrolled content from going live while you sort out the rest.
A stopgap buys you time so you can plan the real rebuild behind it. Treat it as exactly that, and don’t let it quietly become permanent.
Step four: rebuild the survivors in Power Automate
For the workflows that survived triage, the rebuild is well-trodden. A classic SP2013 approval maps almost directly onto a Power Automate automated cloud flow:
| Old SPD 2013 workflow step | New Power Automate step |
|---|---|
| Starts when an item is created | Trigger: When an item is created (SharePoint) |
| Sends for approval, waits | Action: Start and wait for an approval (Approvals) |
| Branches on approved / rejected | Condition on the approval Outcome |
| Sets a status column | Update item (SharePoint) |
| Notifies the submitter | Send an email (V2) (Outlook) |
Every connector in that list (SharePoint, Approvals, Outlook) is a standard connector. That means base Microsoft 365 licensing covers it. No premium Power Automate license, no Dataverse. The licensing scare around rebuilding doesn’t apply to a straight approval.
If you want the full step-by-step on the rebuild itself, that’s the subject of the earlier post on rebuilding your approval workflow in Power Automate. This post’s job was getting you to the rebuild: finding what you lost and deciding what’s worth bringing back.
Bottom line
April 2 already happened, so this is cleanup rather than a warning. And cleanup is better than the panic suggests. Your definitions weren’t deleted. They’re still readable as files in each site. The recovery is methodical: inventory with the assessment tool and PnP, triage hard so you only rebuild what’s genuinely used, prop up anything urgent with built-in approvals, and rebuild the survivors as standard-connector cloud flows. Do it in that order and the dead workflows turn into a much shorter, much saner list than the one you started with.