Why You Need to Migrate Now

Microsoft has been signalling the end of SharePoint 2013 workflows for years, and the deadline is here. SharePoint 2013 workflows are scheduled for full retirement in April 2026 for SharePoint Online tenants. After this date, existing 2013 workflows will stop running.

SharePoint 2010 workflows were already retired in November 2024. If you still have 2010 workflows somehow running, they are on borrowed time.

This is not a theoretical future risk. If your organisation relies on SharePoint Designer workflows for approvals, notifications, document processing, or any other business process, you need a migration plan today.

Step 1: Inventory Your Workflows

Before you can migrate, you need to know what you have. Most organisations are surprised by how many workflows exist across their tenant — shadow IT has been building SharePoint Designer workflows for over a decade.

Using the SharePoint Admin Centre

Go to the SharePoint Admin Centre
Navigate to Migration > Workflow assessment (if available in your tenant)
Review the report of all active SharePoint 2013 workflows

Using PowerShell

For a more complete inventory, use PnP PowerShell:

# Connect to your tenant
Connect-PnPOnline -Url "https://contoso.sharepoint.com" -Interactive

# Get all sites
$sites = Get-PnPTenantSite -Detailed

foreach ($site in $sites) {
    Connect-PnPOnline -Url $site.Url -Interactive

    # Get workflow subscriptions
    $workflows = Get-PnPWorkflowSubscription

    foreach ($wf in $workflows) {
        [PSCustomObject]@{
            SiteUrl      = $site.Url
            WorkflowName = $wf.Name
            ListName     = $wf.PropertyDefinitions["Microsoft.SharePoint.ActivationProperties.ListId"]
            Created      = $wf.Created
            Status       = $wf.StatusFieldName
            Platform     = "2013"
        }
    }
}

What to Capture in Your Inventory

For each workflow, document:

Site and list: Where does it run?
Trigger: On item created, on item modified, or manual start?
What it does: Approval, notification, field update, document generation?
Who owns it: Who built it? Who relies on it?
Frequency: How often does it run? Daily? Weekly? Rarely?
Business criticality: What happens if it stops working?
Complexity: Simple notification or multi-stage approval with branching?

Prioritisation Matrix

Categorise each workflow:

Priority	Criteria	Action
Critical	Runs daily, business-critical, no manual alternative	Migrate first
High	Runs regularly, important but has manual fallback	Migrate next
Medium	Runs occasionally, nice-to-have automation	Migrate when possible
Low / Retire	Rarely used, for retired processes, or duplicates	Decommission

In our experience, 20-30% of discovered workflows can be retired rather than migrated. Processes change, people leave, and workflows linger. Do not migrate something nobody uses.

Step 2: Understand the Mapping

SharePoint Designer actions map to Power Automate actions, but it is rarely a 1:1 translation. Here are the most common mappings:

Trigger Mapping

SharePoint Designer	Power Automate
When an item is created	When an item is created (SharePoint connector)
When an item is changed	When an item is created or modified (SharePoint connector)
Manual start	Manually trigger a flow / For a selected item

Gotcha: SharePoint Designer’s “When an item is changed” fires on any change. Power Automate’s equivalent also fires on any change, but you usually want to add a condition to check which column changed. Otherwise your flow fires on every metadata update, including system modifications.

Trigger: When an item is created or modified
Condition: triggerBody()?['Status'] ne triggerOutputs()?['body/Status']

Action Mapping

SharePoint Designer Action	Power Automate Equivalent
Send an email	Send an email (V2) — Outlook connector
Set field in current item	Update item — SharePoint connector
Create list item	Create item — SharePoint connector
Start an approval	Start and wait for an approval — Approvals connector
Log to history list	Compose action + Send email (no direct equivalent)
Wait for field change	When an item is created or modified (new flow) or Do Until loop
Call HTTP web service	HTTP action or HTTP with Microsoft Entra ID
Set workflow variable	Initialize variable / Set variable
If/Else condition	Condition action
Parallel block	Parallel branch
Loop	Apply to each / Do Until
Pause for duration	Delay action
Pause until date	Delay until action

Actions with No Direct Equivalent

Some SharePoint Designer capabilities require a different approach in Power Automate:

Dictionary operations: SharePoint Designer had dictionary actions for working with JSON-like data. In Power Automate, use the json(), parse() functions and the Parse JSON action.

Workflow history logging: SharePoint Designer workflows wrote to a history list. Power Automate does not have a built-in history list. Options:

Write to a dedicated SharePoint list (create a “Flow History” list)
Use the “Compose” action with run-after configuration for debugging
Rely on the flow run history in the Power Automate portal (retained for 28 days, or 90 days for premium)

Impersonation / Elevated permissions: SharePoint Designer workflows could run with elevated permissions (app-only). Power Automate flows run in the context of the connection owner. For scenarios requiring elevated permissions, use an HTTP action with an Azure AD app registration and certificate-based auth.

Step 3: Handle Approval Workflows

Approvals are the most common SharePoint Designer workflow type and deserve special attention because the migration pattern differs significantly.

SharePoint Designer Approval Pattern

The typical SP Designer approval used task list items, custom email notifications, and outcome tracking via list columns. It was tightly coupled to SharePoint’s task infrastructure.

Power Automate Approval Pattern

Power Automate has a dedicated Approvals connector that is much more capable:

1. Trigger: When an item is created or modified
2. Condition: Status equals "Submitted"
3. Start and wait for an approval
   - Type: Approve/Reject - First to respond
   - Title: "Please approve: [Item Title]"
   - Assigned to: manager@contoso.com
   - Details: "Submitted by [Created By] on [Created Date]"
   - Item link: [Link to item]
4. Condition: Outcome equals "Approve"
   - Yes: Update item (Status = "Approved")
   - No: Update item (Status = "Rejected"), Send rejection email

Key advantages over SP Designer approvals:

Approvers can respond from Teams, Outlook, or the Approvals app
Built-in mobile experience
Sequential and parallel approval patterns built in
Approval history is automatically maintained

Key gotcha: The Approvals connector stores data in Dataverse (provisioned automatically in the default environment). This means approval data is subject to Dataverse storage limits. For high-volume approval scenarios, monitor your Dataverse capacity.

Multi-Stage Approvals

For workflows that require manager approval then director approval then finance approval, use sequential approvals:

1. Start and wait for approval (Manager)
2. If approved → Start and wait for approval (Director)
3. If approved → Start and wait for approval (Finance)
4. If any stage rejected → Update item, notify submitter

Alternatively, use the “Custom Responses” approval type for more complex outcomes (Approve, Reject, Request Changes, Escalate).

Step 4: Address InfoPath Forms

Many SharePoint Designer workflows are paired with InfoPath forms. Since InfoPath is also deprecated, you will likely need to migrate forms simultaneously.

Replacement Options

InfoPath Feature	Power Apps Replacement
Simple data entry form	SharePoint list custom form (Power Apps)
Complex multi-page form	Canvas app with multiple screens
Forms with calculations	Canvas app with Power Fx formulas
Forms with rules/validation	Canvas app with validation logic
Forms with repeating tables	Canvas app with gallery + collection

Migration Approach

Document every field in the InfoPath form
Create corresponding SharePoint list columns (or Dataverse table)
Build the Power App form
Customise the SharePoint list form (List > Integrate > Power Apps > Customise forms)
Test with users before decommissioning InfoPath

Honest caveat: Complex InfoPath forms with dozens of fields, cascading dropdowns, and conditional sections can take significant effort to rebuild in Power Apps. Budget 2-5 days per complex form. Simple forms can be done in hours.

Step 5: Nintex Migration Considerations

If your organisation used Nintex Workflow for SharePoint Online, the migration path has its own considerations.

Nintex to Power Automate Mapping

Nintex offered actions that go beyond what SharePoint Designer provided:

Nintex Action	Power Automate Approach
Regular expression	Compose with `match()` or `replace()` expressions
Query list (CAML)	Get items with OData filter (SharePoint connector)
Document generation	Generate document (Word Online connector) or third-party connector
PDF conversion	Convert file (OneDrive connector) — limited formats
For each with batching	Apply to each with concurrency control
State machine	Multiple flows triggered by status changes
Lazy approval	Approvals connector with email response enabled

Nintex document generation is a common sticking point. Power Automate does not have a native equivalent with the same flexibility. Options:

Word Online connector’s “Populate a Microsoft Word template” action (basic)
Third-party connectors like Encodian or Plumsail Documents (advanced)
Custom Azure Function with a document library (most flexible)

Nintex Forms

Nintex Forms migrate similarly to InfoPath — rebuild in Power Apps. Nintex responsive forms are often easier to recreate in Power Apps than InfoPath forms because the layout concepts are more similar.

Step 6: Testing and Cutover

Testing Strategy

Build the Power Automate flow in a development environment
Test with sample data — create test items in the SharePoint list and verify the flow executes correctly
Parallel run: Run both the old workflow and new flow simultaneously for 1-2 weeks. Compare outcomes.
User acceptance testing: Have the business process owners verify the new flow produces correct results
Cutover: Disable the old workflow, enable the new flow

Parallel Run Approach

During the parallel run period:

Old workflow: Still active on the production list
New flow: Active on the same list, but with actions that LOG
         results instead of taking real actions

Compare: Review the flow run history against workflow history
         to verify matching behaviour

Once you are confident the flow matches the workflow’s behaviour, switch the flow to production mode (replace logging actions with real actions) and disable the old workflow.

Common Testing Gotchas

Trigger timing: SharePoint Designer workflows triggered almost instantly. Power Automate flows can have a delay of 1-15 minutes depending on the trigger type and your licence. The “When an item is created or modified” trigger polls at intervals — it is not real-time. For near-instant triggering, consider the “For a selected item” trigger for manual workflows.

Connection ownership: The flow runs under the connection owner’s permissions. If the original workflow ran under an app-only context with elevated permissions, the flow may fail on items the connection owner cannot access. Use a dedicated service account for the flow connections.

Throttling: Power Automate has API call limits. A workflow that processes 500 items in a loop may hit throttling limits. Use concurrency control and delay actions to stay within limits:

Apply to each:
  Settings:
    Concurrency Control: On
    Degree of Parallelism: 1  (sequential processing)

  Actions:
    [Your actions]
    Delay: 1 second  (helps avoid throttling)

Step 7: Governance During Migration

Documentation

For each migrated workflow, document:

Original workflow name and location
New flow name and URL
What changed in the migration (any behaviour differences)
Connection owner (service account or named user)
Business owner (who is responsible)
Migration date

Environment Strategy

Migrate to dedicated environments, not the default environment
Group related flows by department or business process
Apply DLP policies that match the data sensitivity of each environment

Licence Impact

SharePoint Designer workflows did not require any licence beyond SharePoint Online. Power Automate flows may require additional licences:

Standard connector flows: Covered by M365 seeded licence (if triggered from SharePoint context)
Premium connector flows: Require Power Automate Premium ($15/user/month)
Flows using HTTP connector to external services: Premium
Flows using Dataverse: Premium
Flows using the Approvals connector: Standard (but Dataverse capacity is consumed)

Budget accordingly. A migration of 50 workflows may surface 10-15 that require premium licences. Identify these early and get budget approval before migration, not after.

Decommissioning Old Workflows

After successful migration and a stabilisation period (we recommend 30 days):

Disable the old workflow (do not delete yet)
Add a note to the workflow description: “Migrated to Power Automate flow [name] on [date]. Disabled. Will be deleted on [date + 90 days].”
After 90 days with no issues, delete the old workflow
Update your inventory to mark the migration as complete

Timeline and Planning

With the April 2026 deadline, here is a realistic timeline:

Phase	Duration	Activities
Inventory	1-2 weeks	Discover all workflows, document, prioritise
Planning	1 week	Map actions, identify licence needs, allocate resources
Critical migrations	2-4 weeks	Migrate priority 1 workflows
High priority migrations	2-4 weeks	Migrate priority 2 workflows
Medium priority + cleanup	2-4 weeks	Migrate remaining, retire unused, decommission
Stabilisation	4 weeks	Monitor, fix issues, complete documentation

For a typical mid-sized organisation with 30-100 workflows, plan for 3-4 months of active migration work. Larger organisations or those with complex Nintex workflows should plan for 6+ months.

Do not leave this until the last month. Rushed migrations lead to broken business processes, angry users, and emergency workarounds that become permanent technical debt.

Key Takeaways

Start with a complete inventory — you cannot migrate what you do not know about
Expect to retire 20-30% of workflows rather than migrate them
Approval workflows are the most common and have the cleanest migration path
InfoPath forms must be migrated simultaneously (to Power Apps)
Test with parallel runs before cutting over
Budget for premium licences where required
Document everything — your future self will thank you