SharePoint 2013 workflow replacement: what SPMT carries, and what it leaves behind

The problem

SharePoint Server 2016 and 2019 both went out of support on July 14, 2026. If you’re still on one of them, you’re planning a move to SharePoint Online right now, and you’ve probably found the part of the project that doesn’t estimate cleanly: the SharePoint Designer workflows.

Everything else in the project has a known shape, since documents copy across, sites map to sites, and permissions take a cleanup pass. Workflows are the line item where someone says “we’ll figure that out during the migration.” That’s the line item that slips.

Microsoft does ship a tool that handles part of this for you. Knowing which part is what matters, because migration plans go wrong in the gap between what the SharePoint Migration Tool converts and what it quietly leaves for a person to rebuild.

First, clear up which direction SPMT works

This one confuses people, and it wastes real time.

The SharePoint Migration Tool migrates workflows from a SharePoint Server farm into Power Automate. It’s a source-to-destination tool, and the source is on-premises. You point it at your farm, it reads your workflow definitions, and it creates flows in your Microsoft 365 tenant.

What it cannot do is recover workflows that were already running in SharePoint Online. Microsoft retired the SharePoint 2013 workflow engine from SharePoint Online on April 2, 2026, and those workflows stopped that day. There’s no SPMT path back to them, because SPMT was never pointed at the cloud. If that’s your situation, the recovery post covers what to do instead.

So SPMT is useful to exactly one group: organizations whose workflows are still sitting on a farm they’re about to leave. If that’s you, your workflows still run today, and you have something to convert. That’s a better position than most people realize.

Click to zoom

Scan first, migrate second

The most useful thing about SPMT for planning has nothing to do with migrating.

On the Choose your settings page there’s an option called Only perform scanning. Select it and SPMT reads your farm without changing anything, then produces a report of your workflow inventory. That report is the artifact you build the rest of the plan on: what exists, where it lives, and what type each workflow is.

Run this early, before anyone has committed to a migration date. Most organizations genuinely don’t know how many workflows they’re running. Ones built by a contractor in 2015, or by someone who left in 2019, are normal. Nobody currently on staff can explain what they do, and the only way to find out is to look.

An inventory forces three questions per workflow, and you want them answered before a single hour goes into rebuilding anything:

• Is this still actually used, or did the underlying list get abandoned years ago?
• Who owns the business process behind it, and can they describe what it’s supposed to do?
• Does it depend on anything else, a specific list schema, a content type, another workflow that triggers it, that also has to survive the move?

Skip this and you’ll rebuild workflows nobody uses, while missing the one that quietly approves every vendor invoice over $10,000.

What SPMT carries, and what it doesn’t

Microsoft’s documentation is unusually blunt here, which helps. The supported list:

• SharePoint Server 2010 out-of-the-box workflows: Approval, Collect Feedback, Collect Signature, and Three-state.
• SharePoint Server 2010 and 2013 Designer workflows.
• List, library, and content-type workflows.
• Workflow definitions and associations.

And the two exclusions, both stated in the same breath as the inclusions:

• Not site workflows.
• Not workflow history data.

The history gap is the one that catches people out. If your compliance or audit position depends on showing who approved what and when, that record does not come across with the flow. You need a decision on it before the old farm is decommissioned, because after that the answer is gone for good. Export it, keep a read-only copy of the farm, or formally accept that the history isn’t needed. All three are defensible positions. Leaving it undecided until cutover week is how it turns into someone’s problem during an audit.

Why there’s no version of this that keeps the old engine

Worth having ready for the stakeholder who asks why you can’t just keep what works.

Both the 2010 and 2013 workflow platforms run on Windows Workflow Foundation, a technology that predates Microsoft’s cloud architecture and was never designed for Microsoft 365 scale. The limitation is structural, so no amount of licensing or escalation changes it. Microsoft stopped investing in that engine years ago, and SharePoint Online has already switched it off.

Say that plainly to whoever asks. Nobody is taking away working automation to sell you something newer. The plumbing underneath is going away on its own schedule, and your real choice is whether you replace it deliberately or find the gap the week after cutover.

What replacement actually costs

Licensing is usually the smallest line item. A straight approval rebuild uses the SharePoint, Approvals, and Outlook connectors, all standard, so base Microsoft 365 covers it. The cost is staff time, and it lands in three places.

Discovery. Someone goes farm by farm, site by site, list by list. SPMT’s scan does the mechanical part, but interpreting the report and tracking down owners is human work, and it’s slower than it sounds in a farm with years of sprawl.

Translation. Power Automate isn’t a drop-in replacement for SharePoint Designer’s logic. Conditions, loops, and approval steps behave differently, and 2013-era patterns that lean on deprecated SharePoint features don’t map cleanly. SPMT converting a workflow is not the same as that workflow being correct. Every converted flow needs a person to run it against real data and confirm the logic held.

Business sign-off. A workflow that routes approvals touches real money or real risk. The owner of that process needs to test the replacement against actual scenarios before it goes live, not trust that an automated conversion got it right.

None of that is optional for a workflow that matters. It is entirely optional for a workflow nobody has used since 2019, which is exactly why the inventory comes first.

The sequence

For most organizations the work falls out in this order:

1. Scan the farm with SPMT’s scan-only mode and get the workflow inventory report.
2. Classify each one: actively used, safe to retire, or unknown and needs an owner found.
3. Route each survivor. SPMT-assisted conversion for straightforward list, library, and content-type workflows. Manual rebuild for site workflows and anything with complex branching.
4. Decide on history before the farm is decommissioned, since SPMT won’t bring it.
5. Test each flow with the actual business owner, and retire the old workflow only once the new one has run cleanly through a full cycle.

Follow that order and you end up with a project that has a number attached to it. The failure mode is building flows first and inventorying later, which is how a migration arrives at cutover weekend with half the business processes still unaccounted for.

Bottom line

If your workflows are still on a farm, you’re in the good version of this problem. They run today, SPMT can read them, and a scan costs you an afternoon. Run the scan before you commit to dates, because the report is what turns “we’ll figure out workflows during the migration” into a list with owners and hours against it.

SPMT will not migrate site workflows, and it will not migrate run history. Neither has a workaround, so plan around them instead of discovering them. Everything past those two is a planning exercise, and planning is cheap compared to finding the gap after cutover.