Migrate SharePoint 2013 Workflows to Power Automate: What Enterprise IT Leaders Need to Know Before Starting

Migrate SharePoint 2013 workflows to Power Automate using a four-disposition triage method: each workflow resolves to migrate, rebuild, retire, or hold against a sequenced stabilization plan. For 30-to-200-workflow inventories under CMMC, HIPAA, or SOC 2, i3solutions delivers audit-ready control-family documentation through the change.

• Triage precedes rebuild. Inventories of 30 to 200 workflows do not respond to workflow-by-workflow inspection at scale; a structured method produces sequenced dispositions in days, not months.

• Every workflow resolves to one of four dispositions: migrate to Power Automate cloud flow, rebuild as Power Automate plus custom code, retire with business owner sign-off, or hold pending business review.

• SharePoint 2013 to Power Automate is not a one-to-one rebuild. Declarative approval workflows port relatively cleanly; SharePoint Designer workflows with custom logic and event receivers require platform-model redesign.

• Power Automate adds operating-model requirements SharePoint 2013 workflows did not have: environment strategy, premium connector licensing, Dataverse selection criteria, DLP and ALM governance, runtime monitoring.

• Regulated enterprises (CMMC, HIPAA, SOC 2) require control-family continuity documentation through any platform change. Tool vendors do not produce this artifact; it is partner-delivered work.

Migrating SharePoint 2013 workflows to Power Automate is a rebuild, not a lift-and-shift, because the two run on fundamentally different engines. The flows look alike on the surface, but the execution models differ enough that one-to-one conversion fails, which makes Microsoft’s April 2026 retirement a redesign deadline.

i3solutions has delivered Microsoft platform modernization for regulated enterprises since 1997, with 600+ Microsoft platform implementations across aerospace and defense (Pratt & Whitney, BAE Systems), financial services (Brown Advisory), healthcare (Kaiser Permanente), and government (Wisconsin National Guard, United States Army). Our practice is structured around borrowed expertise: senior consultants placed inside your migration program, accountable for on-time, in-scope, in-production delivery against the engagement plan we draft jointly at scoping.

SharePoint 2013 workflows and Power Automate flows look superficially similar. Both define automation as a sequence of conditions and actions. Both attach to SharePoint lists and libraries. Both run as background processes against business-process events. The architectural similarity ends there.

SharePoint 2013 workflows execute in Workflow Manager, a service hosted independently of the SharePoint farm or tenant. The workflow definition lives in SharePoint Designer or Visual Studio, the execution context lives in Workflow Manager, and the data context lives in SharePoint. Three runtime locations, one workflow. Power Automate execution lives in the Power Platform service: workflow definition, execution context, and connection management all live in a different infrastructure stack, with a different security model, a different licensing model, and a different governance model.

The architecture difference produces a migration reality that surprises internal IT teams. A SharePoint 2013 approval workflow that takes a request, routes it to a manager, captures approval or rejection, and updates a list field looks like a 20-minute rebuild in Power Automate. It is, when the workflow uses only built-in connectors and standard SharePoint actions. The 20-minute rebuild fails when the workflow uses any of the following patterns: custom code in Visual Studio workflow projects, event receivers triggered by workflow state changes, SharePoint Designer workflows with embedded JavaScript or REST calls, workflows that depend on SharePoint 2013 service applications (Business Connectivity Services, User Profile Service synchronization rules, Managed Metadata workflows), or workflows that integrate with line-of-business systems through SOAP endpoints that do not have a Power Automate connector equivalent.

The asymmetry is empirical, not theoretical. We have observed enterprises with 50 to 200 SharePoint 2013 workflows where the simple-rebuild proportion is 20 to 40 percent. The remaining 60 to 80 percent require platform-model decisions: rebuild against a different connector pattern, rebuild using Power Automate plus Azure Functions for custom logic, rebuild using a third-party workflow platform if the use case exceeds Power Automate connector capabilities, or retire the workflow entirely because the underlying business process has changed since the workflow was authored.

Organizations that approach the migration as a tool swap discover this proportion six weeks into the project, after their IT team has invested 40 to 80 hours rebuilding workflows that worked on first attempt and the remaining workflows are the hard ones. The schedule slips, the budget overruns, and the business processes the workflows support degrade in the interim. The Stabilization Protocol we use at i3solutions is designed to surface the rebuild proportion in the first week of engagement, not the eighth, so the budget and schedule decisions get made at the planning stage rather than the recovery stage. (For the broader picture of how this fits inside a multi-year SharePoint estate transition, see Legacy SharePoint Modernization.)

Triage is the first phase of the Stabilization Protocol. The objective is not to rebuild any workflow yet; the objective is to produce a sequenced disposition plan that names which workflows get rebuilt in what order, which workflows get retired, and which workflows get held pending business review.

The triage method has three components: inventory audit, dependency mapping, and disposition sequencing.

Inventory audit

The audit catalogs every active SharePoint 2013 workflow in the tenant or farm with named attributes: workflow name, host site collection and list, author of record, business owner of record, last successful execution date, average monthly execution count, failure rate over the past 90 days, integration points (other systems the workflow touches), and a one-sentence purpose statement written in business language. The audit uses Microsoft’s Workflow 2013 Assessment Tool (available via the Microsoft 365 Assessment Tool from PnP) as the technical scanner, supplemented by interviews with the business owners of record for each workflow.

The audit surfaces three categories of workflow the assessment tool alone does not identify: orphaned workflows (no business owner can be identified; the workflow has been running for years without a named owner), zombie workflows (a business owner exists but the workflow no longer reflects current business process; the workflow runs but its output is ignored), and shadow workflows (the workflow has multiple business owners who disagree on its purpose; no clean disposition is possible without business-side reconciliation). The audit is one component of i3’s broader SharePoint Migration Services practice, which spans content migration, customization remediation, and governance setup across SharePoint Online, GCC, and GCC High destinations.

Dependency mapping

Each workflow gets mapped against its inbound and outbound dependencies. Inbound: which lists or libraries trigger the workflow, which other workflows hand off into it, which user actions initiate it. Outbound: which lists or libraries the workflow updates, which downstream workflows it triggers, which external systems receive its outputs, which compliance evidence it produces.

The map is the artifact that prevents the most common migration failure mode: rebuilding a workflow in Power Automate without rebuilding its upstream and downstream dependencies, then discovering at production cutover that the rebuilt workflow runs but no business process actually consumes its output because the dependent system still expects the old workflow’s data shape.

Disposition sequencing

Sequencing prioritizes the order in which workflows get rebuilt against three criteria: business criticality (workflows tied to revenue, audit evidence, or regulatory reporting take precedence), technical complexity (simple rebuilds front-loaded to build momentum; complex rebuilds scheduled when the team has stabilized on Power Automate patterns), and migration risk (workflows whose failure would disrupt active business processes get migrated with stabilization windows that protect the business through the transition).

The sequenced plan is the deliverable a regulated-enterprise IT Director or SharePoint Architect needs to commit budget. It names which workflows get migrated in which order, what each rebuild requires (simple connector pattern vs custom code vs platform redesign), what each rebuild produces (audit evidence reconciliation, business owner sign-off, compliance documentation), and what the stabilization windows protect (business processes that cannot tolerate workflow downtime).

Every workflow in the audit resolves to one of four dispositions with named business owner concurrence. The disposition framework is the second phase of the Stabilization Protocol. Without an explicit framework, IT teams default to “migrate everything” and discover at week eight that 30 percent of the inventory should have been retired and 20 percent should have been held pending business reconciliation.

Migrate disposition

The workflow rebuilds in Power Automate as a cloud flow using built-in connectors and standard actions. No custom code, no premium-connector dependencies beyond what is licensed, no Azure Function calls. Typical examples: simple approval workflows, document-routing workflows, notification workflows, list-driven status-update workflows. The migrate disposition is the lowest-cost rebuild class; workflows in this class produce the early wins in a migration program and contribute the smallest per-workflow cost share to the engagement total.

Rebuild disposition

The workflow’s underlying business logic carries forward but the platform-model changes. Rebuild applies when the workflow contains custom code (SharePoint Designer with embedded JavaScript or REST, Visual Studio workflow projects, event receivers triggered by workflow state changes), or when the workflow integrates with line-of-business systems through endpoints lacking a Power Automate connector equivalent, or when the workflow exceeds Power Automate’s connector and licensing constraints at the volume required. Rebuild dispositions resolve to Power Automate plus Azure Functions for custom logic, Power Automate plus Logic Apps for premium integration patterns, or a third-party platform (Nintex, AgilePoint, FlowForma) when the business case supports it. Rebuild workflows carry the moderate-to-high per-workflow cost share within the engagement total.

Retire disposition

The business owner confirms the workflow’s underlying business process is no longer needed, has been replaced by a different system, or has degraded into pure noise (still running, no longer consumed). Retire dispositions are the highest-leverage findings of the audit: a workflow that gets retired removes both the migration cost and the ongoing operational burden. Expect 10 to 30 percent of a typical enterprise SharePoint 2013 inventory to resolve to retire after honest business-owner conversation.

Hold disposition

The workflow has multiple business owners who disagree on disposition, or the workflow has no identified owner and the audit cannot complete the business-side question. Hold dispositions stay on the inventory but do not enter the migration sequence until business-side reconciliation produces a single owner with a clear disposition. The hold queue is the artifact that prevents the audit from stalling on workflows that cannot be migrated cleanly because the underlying business question is unresolved.

Each disposition requires named owner concurrence before the workflow enters the migration plan. The concurrence step is what distinguishes the Stabilization Protocol from a tool-driven migration assessment: the business side commits to the disposition in writing before any rebuild work begins.

Workflows that pass the migrate or rebuild dispositions fall into three structural categories. The category determines the Power Automate approach and the rebuild effort estimate.

Category A: declarative approval and notification workflows

These workflows use built-in SharePoint Designer actions (start approval process, send email, set field, log to history list) without custom code. They represent the simplest migration class. Power Automate approach: rebuild as a cloud flow using the SharePoint trigger plus the Approvals connector plus built-in mail actions. Premium connector usage is typically minimal (built-in approvals and notifications run on standard licensing). Category A workflows are the lightest rebuild class within the engagement scope.

Category A typically represents 30 to 50 percent of an enterprise SharePoint 2013 inventory. These workflows produce the early wins in a migration program: visible progress, business-owner confidence, and a baseline operating model for the Power Platform environment before the harder workflows enter the rebuild queue.

Category B: list-driven business-process workflows with custom logic

These workflows combine declarative SharePoint Designer steps with custom logic (embedded JavaScript or REST calls in SharePoint Designer, parameterized service calls, conditional routing logic that exceeds built-in approval-process patterns). Power Automate approach: rebuild as a cloud flow plus Azure Functions for the custom logic, or rebuild as a cloud flow using Power Automate’s expression engine for logic the engine can handle, with documented decision rationale for why each piece of custom logic resolves to Azure Functions vs cloud flow expressions vs premium connector calls. Category B workflows are the moderate-effort class within the engagement scope.

Category B is where the operating model decisions matter most. Custom logic in Azure Functions requires environment selection (which Power Platform environment hosts the flows; how Azure subscription billing maps to Power Platform environment governance), Dataverse selection (does the workflow need a Dataverse table or can SharePoint list storage carry the state), and DLP policy alignment (which connectors can run together in production).

Category C: SharePoint Designer custom-code workflows and Visual Studio workflow projects

These workflows depend on infrastructure SharePoint 2013 provided that Power Automate does not provide directly: event receivers triggered by workflow state changes, Business Connectivity Services calls to line-of-business systems, custom workflow activities written in C# against the Workflow Foundation API, or SharePoint Designer workflows with embedded code that exceeds Power Automate’s expression engine capabilities. Power Automate approach: rebuild against a different platform model entirely. Options include Power Automate plus Logic Apps plus custom connectors (when the integration pattern is salvageable), Logic Apps Standard (when the workflow needs full custom hosting), or a third-party platform when the workflow’s business case justifies it.

Category C is the highest-effort rebuild class and where the migration plan’s risk concentration sits. We have seen enterprise inventories where Category C represents 15 to 30 percent of workflow count but a disproportionate share of total rebuild effort.

The most common migration failure mode is treating Power Automate as a drop-in replacement for the Workflow Manager runtime and discovering six weeks into the project that Power Automate’s operating-model requirements exceed the IT team’s initial scoping. SharePoint 2013 workflows ran on infrastructure SharePoint provided. Power Automate runs on Power Platform infrastructure that requires explicit operational decisions before the first production flow executes.

Environment strategy

Power Automate flows live in Power Platform environments. An environment is a security boundary plus a data-storage boundary plus a DLP-policy boundary. SharePoint 2013 had no equivalent abstraction; workflows ran wherever their host site collection ran. Power Platform environment selection is a doctrine decision: which flows live in the default environment, which flows live in custom production environments, which flows live in custom development or test environments, and how Azure subscription billing maps to environment governance. Enterprises with 50 to 200 workflows typically need three to five custom environments segmented by business function or compliance scope.

Connector and premium connector licensing

Power Automate distinguishes between standard connectors (included in Microsoft 365 licensing) and premium connectors (requiring per-user or per-flow Power Automate licensing on top of Microsoft 365). The licensing implications surface late in a migration when 60 percent of the inventory rebuilds in standard connectors and 40 percent triggers premium connector licensing the IT team did not budget for. Microsoft’s Power Automate licensing model includes per-user plans (suitable for workflows tied to specific named users) and per-flow plans (suitable for workflows that run on system events without a named user owner). Workflow inventory triage determines the licensing model; running the licensing assessment after the rebuild is the failure mode. The Microsoft Learn Power Platform environments overview covers the foundational environment and licensing model in detail.

Dataverse selection criteria

Some workflows benefit from Dataverse as the data layer; others run cleanly against SharePoint lists. The criteria: workflows with complex relational data (multiple parent-child relationships across entities), workflows requiring strong typing and validation rules, workflows that exceed SharePoint’s 5,000-item view threshold, and workflows that integrate with Dynamics 365 or Power BI as downstream consumers tend toward Dataverse. Workflows that update a single list with simple field types tend to stay on SharePoint lists. Dataverse selection is a per-workflow decision made during the rebuild phase; the migration plan should not commit to a Dataverse-everywhere or SharePoint-list-everywhere policy without per-workflow evaluation.

ALM and DLP governance

Power Automate flows require application lifecycle management discipline (solution packaging, environment promotion, version control) and Data Loss Prevention policy alignment (which connectors can communicate with which other connectors in production). SharePoint 2013 workflows had implicit ALM through SharePoint Designer’s site-collection scoping and implicit DLP through SharePoint farm permissions. Power Automate requires explicit ALM tooling (Power Platform solutions, Azure DevOps pipelines, Dataverse environment variables) and explicit DLP policies (block patterns that allow business-data connectors but prevent personal-data exfiltration). Migration plans that omit ALM and DLP at the operating-model stage discover the gap when the first production flow hits a compliance-audit finding.

Runtime monitoring

SharePoint 2013 workflows surfaced failure through the workflow history list visible to site administrators. Power Automate flows surface failure through the Power Platform Monitor service plus per-flow run history plus Azure Application Insights for premium logging. Runtime monitoring is a deliverable: who watches the Power Automate run history, what failure patterns trigger which response, and how failure detection ties back to the business owner who needs to know when their flow has not run today.

Our migration engagements run on the Stabilization Protocol three-phase structure with named exit criteria at each phase boundary. The structure exists because tool-driven migrations skip the disposition decisions and recovery-driven migrations skip the planning. The Stabilization Protocol is designed to make the planning explicit, the dispositions accountable, and the execution sequenced against business protection.

Phase 1: inventory audit and dependency mapping

Phase 1 produces the workflow inventory artifact, the dependency map artifact, and the orphaned-zombie-shadow workflow flag list. Phase 1 also produces the licensing impact analysis (how the inventory’s premium-connector profile maps to Power Automate licensing) and the environment strategy recommendation (how many custom Power Platform environments the rebuild requires and how Azure subscription billing maps to environment governance).

Phase 1 typical duration for a 50 to 200 workflow inventory: two to four weeks. Phase 1 exit criteria: every active workflow is named in the inventory with a one-sentence purpose statement; every workflow has an identified business owner of record or is flagged as orphaned; every workflow has been mapped against its inbound and outbound dependencies; the licensing impact analysis has been reviewed by the IT Director and CFO; the environment strategy recommendation has been approved by the IT Director.

Phase 2: disposition decisions and sequencing

Phase 2 takes the Phase 1 inventory and resolves every workflow to one of the four dispositions (migrate, rebuild, retire, hold) with named business owner concurrence. Phase 2 also produces the sequenced migration plan: which workflows get rebuilt in which order, what each rebuild requires, what stabilization windows protect during the transition.

Phase 2 typical duration: three to six weeks. Phase 2 exit criteria: every workflow has a written disposition with business owner sign-off; the sequenced plan has been reviewed by the CFO (cost), the CISO (compliance posture), the compliance officer (control-family coverage), the business unit owners (per-workflow disposition), and the IT Director (phase structure with exit criteria); the stabilization plan names which business processes get protected during which migration windows.

Phase 3: governance handoff with named exit criteria

Phase 3 covers the platform-handoff work that ensures the IT team can run the Power Platform environment after the migration completes. The work includes ALM tooling stand-up (solution packaging discipline, environment promotion pipelines, Dataverse environment variable management), DLP policy authoring and deployment, runtime monitoring deployment (who watches what, what failure patterns trigger what response), and compliance documentation continuity (control-family mappings updated from SharePoint 2013 workflow evidence to Power Automate flow evidence).

Phase 3 typical duration: two to four weeks. Phase 3 exit criteria: ALM tooling is operational and named owners can produce solution-packaging artifacts on demand; DLP policies are deployed and the Power Platform admin center reflects production state; runtime monitoring dashboards are live and the named monitors have signed off; compliance documentation has been reviewed by the compliance officer and the external auditor for the next scheduled audit.

Five enumerated migration engagement deliverables

Every Stabilization Protocol engagement produces the same five deliverables, regardless of inventory size:

• Workflow inventory artifact with named attributes per workflow plus orphaned-zombie-shadow flags.

• Sequenced migration plan with per-workflow disposition, rebuild category, effort estimate, stabilization window, and named owner.

• Workflow-by-workflow disposition register signed by named business owners.

• Power Platform environment and governance setup with environment topology, DLP policies, ALM tooling, and runtime monitoring.

• Audit-ready control-family continuity documentation mapping SharePoint 2013 workflow evidence to Power Automate flow evidence for every framework in scope (CMMC, HIPAA, SOC 2, NIST 800-171, or others as the environment requires).

The five deliverables together produce on-time, in-scope, in-production migration outcomes our regulated-enterprise clients can defend at the next audit.

Migration completion is not “the last workflow rebuilt.” Completion is the state where every workflow has been resolved to its disposition, every disposition has been executed against the sequenced plan, every rebuild has been validated by its business owner, every retired workflow has been formally decommissioned with evidence preserved, and every compliance framework in scope has documented control-family continuity through the platform change.

Production cutover validation

Each rebuilt workflow undergoes production cutover validation: the new Power Automate flow runs against production data, the business owner confirms output matches expected business outcome, the failure-handling paths get tested against simulated failure conditions, and the SharePoint 2013 workflow gets disabled (not deleted) with a 60 to 90 day shadow period during which both versions remain available in case rollback is needed. The shadow period is the artifact that distinguishes a controlled migration from a forced cutover; enterprises that skip the shadow period discover edge cases at the worst possible moment.

Compliance documentation continuity

For CMMC 2.0 Level 2 environments, every workflow that produced audit evidence under SharePoint 2013 gets remapped to its Power Automate flow equivalent with control-family citations updated. NIST 800-171 Rev 3 control families most commonly affected by workflow migrations: AC-2 Account Management (workflows that provision or deprovision access), AC-6 Least Privilege (workflows that grant or revoke specific permissions), AU-2 Event Logging (workflows that produce audit trail entries), AU-12 Audit Record Generation (workflows that aggregate audit evidence), SC-8 Transmission Confidentiality (workflows that move data between systems with encryption requirements).

For HIPAA-regulated workflows, the Security Rule administrative safeguards and technical safeguards both require documented control-family continuity through any platform change affecting PHI handling. For SOC 2 Type II environments, every workflow that produced trust-services-criteria evidence gets remapped with continuity documentation reviewable by the external auditor.

The CMMC Program Final Rule (32 CFR Part 170) became effective December 16, 2024. Defense contractors operating in DFARS 252.204-7012 scope cannot defer CMMC documentation for workflow migrations indefinitely; the audit cycle catches up. The DoD CIO CMMC Program documentation covers the program scope, assessment levels, and contractor responsibilities in detail. The audit gap that opens between SharePoint 2013 retirement and Power Automate cutover is the failure mode compliance officers miss most often; workflows operating without audit trail continuity fail at audit when the assessor cannot trace the evidence chain through the platform change.

Audit evidence reconciliation

The final validation step is audit evidence reconciliation: the compliance officer or external auditor reviews the documented control-family continuity, validates that every framework requirement that previously rested on SharePoint 2013 workflow evidence now rests on Power Automate flow evidence with equivalent rigor, and signs off on the migration as audit-ready. Reconciliation is the artifact that protects the IT Director and the compliance officer from audit findings six or twelve months after the migration, when the original migration team has rotated off and the audit cycle returns. (For the cost framing that accompanies this completion-state validation, see the SharePoint Workflow Migration Cost Guide, which details the four cost variables and the three hidden-cost categories that surface late in regulated-enterprise migrations.)

Partner selection is the highest-leverage decision in a SharePoint 2013 workflow migration. The wrong partner ships a tool-driven migration that scrapes the audit at year-end. The right partner ships a structured migration that produces audit-defensible evidence and a Power Platform operating model the IT team can run after the engagement closes. Three diagnostic questions surface partner depth at proposal stage.

Diagnostic 1: do they triage before rebuilding

Ask the partner to describe how they approach the first two weeks of a 100-workflow engagement. A tool-driven partner answers in terms of running SPMT or the Workflow 2013 Assessment Tool against the tenant and producing a migration roadmap document. A structured partner answers in terms of the triage method (inventory audit plus dependency mapping plus disposition sequencing) and names the artifacts the first two weeks produce. Borrowed expertise depth shows in the answer: structured partners can name the orphaned-zombie-shadow workflow categories without prompting because they have seen them across enterprise engagements.

Diagnostic 2: do they produce control-family continuity documentation

Ask the partner to walk through a CMMC, HIPAA, or SOC 2 workflow migration they have shipped and describe the compliance documentation they produced. A tool-driven partner answers in generalities (we deliver compliance-ready output) without naming specific control families or specific evidence patterns. A structured partner answers by naming specific NIST 800-171 control families affected (AC-2, AC-6, AU-2, AU-12, SC-8) and the evidence transformation they document for each (what SharePoint 2013 evidence pattern, what Power Automate equivalent, how the continuity gets verified). The depth of the answer is the depth of the practice.

Diagnostic 3: have they shipped at enterprise inventory scale

Ask the partner to name a regulated-enterprise client where they have completed a SharePoint 2013 workflow migration of 50 or more workflows with audit sign-off. A tool-driven partner cannot name the client or names a client below 20 workflows. A structured partner names the client (under appropriate confidentiality, with named-reference permission), names the inventory size, names the compliance framework scope, and can produce references for the IT Director, CISO, or compliance officer at that client to talk through the engagement outcome. Reference depth is the artifact that confirms the partner has done this before in environments comparable to yours. (The broader vendor-evaluation framework for SharePoint engagements in regulated environments is detailed in SharePoint Consulting for Regulated Enterprises, which covers the structural questions buyers should run against any SharePoint-anchored consulting partner.)

i3solutions has delivered Microsoft Consulting Services for regulated enterprises since 1997, with 600+ Microsoft platform implementations including SharePoint 2013 workflow migration engagements across aerospace and defense, financial services, healthcare, and government clients. Our Enterprise Delivery Assurance practice means senior consultants stay on the engagement through production cutover and audit reconciliation, not just through the planning phase.

• Governance-First SharePoint Modernization

• SharePoint Server to SharePoint Online Migration

• SharePoint Workflow Alternatives Comparison

• Microsoft Modernization Plan