Decide every workflow before the attach

A content database carries the workflows its sites use, and nothing that runs them. Neither destination supports both workflow platforms any more, and SharePoint Online runs neither. Chapter 2 counted the workflows; this chapter decides each one, while the old farm can still answer questions.

Which of your SharePoint 2010 and 2013 workflows still matter, and where can each of them run once its content has moved?

The decision this chapter leads to is a disposition for every workflow (kept on SharePoint Workflow Manager, rebuilt in Power Automate, or retired), recorded with its reason and its owner before its content database is attached or its site is copied.

Which workflows this chapter is for

Every workflow on a farm whose content goes to Subscription Edition by database attach, as Chapter 23 sets out, or into SharePoint Online by copy, as Chapters 8 and 9 do. Apart from Project Server's, each one, whoever built it, runs on one of two platforms: SharePoint 2010, which installs with SharePoint Server, or SharePoint 2013, which needs SharePoint Workflow Manager or Microsoft Workflow Manager, the second no longer installable (install and configure workflow, checked on 6 November 2026).

What each destination still runs

Sources for the table: workflows in SharePoint, what is deprecated or removed, the September 2026 update notes and the lifecycle pages for SharePoint Workflow Manager and Microsoft Workflow Manager 1.0, all checked on 6 November 2026. Subscription Edition itself is in support, under the Modern Lifecycle Policy (lifecycle, checked on 6 November 2026).

On a Subscription Edition farm at a current update, a SharePoint 2010 workflow that nobody decided arrives with its feature off, or runs unsupported because somebody turned it back on: the update notes name Get-SPLegacyWorkflowEnabledSites to list where it is on, and nothing in them restores support. We would allow Enable-SPLegacyWorkflow only as a dated exception for one site collection while its rebuild finishes, accepted in writing by the process owner.

A Microsoft developer page dates the on-premises deprecation of SharePoint 2010 workflows to 16 July 2026 (creating a workflow with SharePoint Designer 2013, checked on 6 November 2026); this chapter follows the Subscription Edition list, as the rest of this site does.

Inventory every workflow first

The site's workflow planner carries a read-only inventory script for SharePoint Server 2016, 2019 and Subscription Edition. Run on the old farm, outside business hours, as an account that can read every site collection, it is written to list every SharePoint 2010 association on sites, lists and content types, with its state, running instances and dates; every SharePoint 2013 subscription, or that no engine is registered; and to save a copy of each SharePoint 2013 definition and SharePoint Designer 2010 workflow file. It writes nothing to the farm. It has been checked for syntax, not yet run against a farm: run it on a test farm first, and treat its output as a starting inventory to confirm, not a complete one.

Three answers do not come from the script:

• The engine behind the SharePoint 2013 workflows, read from the installed programs on each Workflow Manager server.
• Use. The script counts running instances only for SharePoint 2010 associations. Moving online, the migration tool's scan adds each workflow's "latest execution or modification date" (workflow reports, checked on 6 November 2026); otherwise, use comes from the owner.
• The owner, who can say what the process needs and agrees its disposition.

Three dispositions, and where each is possible

Sources for the table: what is deprecated or removed, workflow in SharePoint Server and workflows in SharePoint, checked on 6 November 2026. Keeping holds for this destination only: a later move online rebuilds the workflow anyway. Every disposition also needs something read on the old farm before the attach: the inventory, the engine's records or the migration tool's scan.

Keep a SharePoint 2013 workflow only with its engine

Keeping means SharePoint Workflow Manager on the new farm. Microsoft documents an upgrade to it "from any version of Microsoft Workflow Manager", supports it on an odd number of hosts, and requires the App Management and Subscription Settings services in the farm (install and configure workflow, checked on 6 November 2026).

Microsoft's procedure for a new farm moves the App Management database with the content, because workflows "get their permission to SharePoint content through app principals stored" there, and the six Workflow Manager and Service Bus databases under their old names. It needs three records from the old farm: the Certificate Generation Key, or a reset of it; the scope name, registered again on the new farm; and the RunAs account and admin group. Every node leaves the old workflow farm before the backup. Then "workflows from the old farm should continue to work", which the procedure checks by starting one (SharePoint Workflow Manager on a new farm, checked on 6 November 2026). Chapter 23 places the engine and App Management in the attach sequence.

A kept workflow still needs an editor: SharePoint Designer 2013 was supported with Subscription Edition until 14 July 2026, and Microsoft states that Visual Studio can still create and edit SharePoint 2013 workflows (what is deprecated or removed, above). We would prove that on one kept workflow before any change depends on it.

Rebuild in Power Automate from a specification

Moving online, the SharePoint Migration Tool turns SharePoint 2010 out-of-the-box workflows and SharePoint Designer 2010 and 2013 workflows on lists, libraries and content types into flows: definitions and associations, not site workflows and not history (workflow migration). Among the actions it does not migrate are Call HTTP Web Service, the dictionary actions, both loops, parallel blocks and the Wait for actions; its scan lists them per workflow (workflow reports, above), and the migration stops on them by default, or turns them into Compose actions, Microsoft's placeholder (SharePoint Designer workflow migrations). Migrated flows stay off until their owner turns them on, and may not do exactly what the original did (activate migrated workflows; all three checked on 6 November 2026).

The rest is rebuilt by hand, and some of it redesigned. Microsoft's comparison lists site workflows, reusable workflows and elevated permissions through the App Step as not available in flows, and the generic HTTP action as a premium connector (classic workflows and Power Automate); a flow run, pending approvals included, times out after 30 days (limits; both checked on 6 November 2026).

On premises, a flow reaches the farm through the on-premises data gateway. Microsoft describes Power Automate with SharePoint Server as suited to non-interactive workflows and recommends the 2013 platform for interactive ones (workflow in SharePoint Server, above); its connector reference names "an on-premises SharePoint 2016 or 2019 farm" (SharePoint connector, checked on 6 November 2026). Whether it reaches Subscription Edition we do not know: test a connection on the rehearsal farm before choosing it.

We recommend a written specification for every rebuild, read from the saved definition and agreed with the owner: trigger, conditions, approvers, outcomes, notifications, and the identity each step acts as, chosen as Chapter 17 chooses one for elevated code. The rebuild is tested against it, not against memory.

Retire on the owner's word, and settle what is in flight

Retire a workflow when its process has ended, when only sites being retired use it, or when nobody claims it once asked. Its saved definition stays as a record, with any history its owner or the retention policy requires; the migration tool carries no history online, so we would export it first.

Instances in progress need a decision too. Moving online, a workflow in progress "appears as if the workflow was never started on the item" (running SharePoint 2013 workflows, checked on 6 November 2026). For an attach, Microsoft's procedure says existing workflows should remain intact, but not what becomes of an instance waiting when the databases were copied, and we do not know. We would let instances finish, or stop them deliberately and record what each was processing, before the source goes read-only.

Out of scope

InfoPath forms that workflows use are Chapter 20, and the site's InfoPath planner covers them; custom workflow actions and Visual Studio workflow packages are customisations too, inventoried in Chapter 15. The attach is Chapter 23, and verifying and cutting over a copy online are Chapters 8 and 9. Project Server workflows, third-party workflow products, Power Automate design and licensing are not covered.

Before you continue

• Every workflow is listed with its platform, attachment and use, and every definition the farm holds is saved
• The engine behind the 2013 workflows is named, and every process has an owner who confirmed it
• Each workflow is kept on SharePoint Workflow Manager, rebuilt in Power Automate or retired, with its reason and its owner's agreement
• Kept 2013 workflows have their Certificate Generation Key, scope name, RunAs account and admin group recorded, and move with App Management and the six workflow databases
• No SharePoint 2010 workflow runs on Subscription Edition except as a dated Enable-SPLegacyWorkflow exception its owner accepted
• Every rebuild has a specification its owner agreed, and the migration tool's scan names what it cannot carry
• Running instances are finished or stopped deliberately, and the history each owner needs is exported or kept

Download chapter 19 (PDF)Same text, same tables, same sources as this page.