How to Replace Legacy SharePoint Workflows with Power Automate

SharePoint Designer workflows — the click-to-configure automation tool that millions of organisations used from SharePoint 2007 through SharePoint Online — have been retired by Microsoft. The SharePoint 2010 workflow platform reached end-of-life in November 2020 and was disabled in SharePoint Online. The SharePoint 2013 workflow platform followed in April 2026. If your organisation still depends on SharePoint Designer workflows or Nintex on SharePoint Online, you need a migration plan. This guide gives you one.

📄 SharePoint 2010 workflows no longer supported — learn.microsoft.com

Step 1: Inventory Your Existing Workflows

Before you can migrate workflows, you need a complete picture of what exists across your tenant. Most organisations underestimate this — they know about their 5 "important" workflows but have forgotten the 40 others built over the years.

Automated inventory using PowerShell

The SharePoint Online Management Shell and PnP PowerShell can enumerate all workflow associations across all sites in your tenant:

• Use PnP PowerShell's Get-PnPWorkflowSubscription to list all workflow subscriptions (associations) on a site
• Use Get-PnPWorkflowDefinition to retrieve workflow templates
• Combine with Get-PnPTenantSite to iterate across all sites
• Export results to CSV: site URL, workflow name, list association, workflow platform version (2010 vs 2013), last run date

Classify workflows by priority

Not all discovered workflows need immediate migration. Classify each one:

Step 2: Map Legacy Workflow Features to Power Automate

SharePoint Designer workflows had their own set of actions and conditions. Most have direct Power Automate equivalents; some require a different approach.

Step 3: The Migration Process — Workflow by Workflow

• 1
  Document the existing workflow

  Open the workflow in SharePoint Designer (if still accessible) and screenshot or transcribe every step, condition, and action. Many older workflows have no other documentation. This is your specification for the Power Automate rebuild.

• 2
  Identify the business owner

  Find who owns the business process the workflow supports. They will need to validate the migrated flow before go-live and may have requirements or edge cases the original workflow handled incorrectly.

• 3
  Build in a development environment

  Create the Power Automate flow in a development/test environment pointing at a test SharePoint site. Never build and test against the production list — you cannot undo test approvals sent to real users.

• 4
  Test every path

  Test the happy path (expected input, approved outcome), the rejection path, the timeout/escalation path, and edge cases (null fields, special characters in text, very long text in comments). Run at least 5 full end-to-end tests before UAT.

• 5
  User acceptance testing

  Have the business owner and 2–3 regular users test the flow in the test environment. Their feedback often reveals undocumented edge cases the original workflow handled (or mishandled).

• 6
  Go live and monitor

  Enable the Power Automate flow in production. For the first 2 weeks, review the flow run history daily — check for failed runs and any unexpected error patterns. Keep the old workflow disabled (not deleted) for 30 days in case rollback is needed.

Common Migration Challenges

"Wait for Field Change" — the hardest pattern to migrate

SharePoint Designer's "Wait for field change" action allowed a single workflow to pause indefinitely until a column reached a specified value. Power Automate has no equivalent waiting pattern within a single flow. The solution is to split the logic into two flows: one that starts the initial process (triggered by item creation), and a second that continues the process (triggered by item modification with a condition checking the field value). This "two-flow" pattern is more reliable than the original waiting approach anyway — the old wait pattern was notoriously brittle under heavy load.

Workflow history and audit trail

SharePoint Designer wrote all workflow actions to a built-in History list. Power Automate has no equivalent. Design an explicit audit log list in SharePoint and write to it from the flow — this is actually better because you control what gets logged, the format, and the retention policy.

Impersonation steps

SharePoint Designer allowed "impersonation steps" that ran as the workflow administrator rather than the item submitter. Power Automate flows always run as the connection owner — typically a service account. Ensure your service account has the permissions needed (at minimum Contribute on the target lists) and document this in the flow description.

📄 Migrate SharePoint workflows to Power Automate — learn.microsoft.com