It’s 9 AM on cutover day. The DNS is flipped, content is in place, and you’re feeling good. Then the calls start. A manager in HR can’t get her leave requests approved. Procurement says their PO approval emails stopped arriving. The helpdesk queue is filling up fast. You dig in and find 47 SP 2013 workflows still associated with active lists across a dozen sites — workflows that were quietly broken the moment the migration completed. None of them showed up in the planning doc because no one had ever inventoried them.

This is not a rare scenario. Workflows are the silent risk in SharePoint migrations because there’s no single view in Central Administration that shows you everything. They accumulate over years — SharePoint Designer automations, Nintex approvals, out-of-the-box review chains — spread across hundreds of lists and libraries, and nobody keeps a master list.

This post shows you how to run a complete workflow audit before you migrate, using PowerShell scripts that work across your entire farm. By the end, you’ll have an HTML dashboard and a classified inventory telling you exactly what you have, which platform each workflow runs on, and what you need to do about it before cutover.

Why Workflows Are the #1 Silent Risk in SharePoint Migration

The core problem is this: SharePoint Subscription Edition (SPSE) changes the rules for every major workflow platform your farm is likely running, and none of those changes are automatic.

SP 2013 / SharePoint Designer workflows depend on the legacy Workflow Manager service. In a fresh SPSE installation, Workflow Manager is not present and is not automatically installed. Every workflow built with SharePoint Designer using the SP 2013 engine will be silently inactive after migration. Items will still flow through lists. Emails won’t fire. Tasks won’t get created. Nothing breaks loudly — it just stops working.

SP 2013 workflows do not run in SharePoint Subscription Edition by default. The SP 2013 Workflow component must be separately installed and configured, and Nintex on-premises workflows require their own service application migration. The table below summarises what each platform requires.

Nintex for SharePoint 2013 is a separate product installed on top of SharePoint. Migrating your content databases does not migrate your Nintex license, your Nintex database, or the Nintex service application. If Nintex for SPSE is not installed and configured before content arrives, Nintex workflows become broken associations pointing at a service that doesn’t exist.

OOB SP 2010-style workflows — the built-in Approval, Collect Feedback, and Collect Signatures workflows — are deprecated in SPSE. Microsoft’s position is clear: these are going away. They may run temporarily in some configurations, but they are not a supported path forward.

Here’s how each platform lands in SPSE:

Before you can plan any of this, you need to know what you have. A mid-size farm with 200 sites might carry 120 SP Designer workflows, 35 Nintex workflows, and 18 OOB workflows spread across 60 different lists and libraries. Three completely different remediation paths. Without an audit, you’re guessing at scope, effort, and risk.

Two Approaches to SharePoint Workflow Auditing: OM vs SQL

The toolkit provides two audit modes because SharePoint environments vary widely in what access you actually have during a migration project.

The Object Model (OM) approach uses the SharePoint server-side API directly. It gives you the most complete picture: workflow definitions, associations, running instances, health status, and platform signals. It requires access to the SharePoint server and farm or site collection admin permissions.

The SQL fallback approach queries content databases directly using System.Data.SqlClient. It’s useful when you’re working as a contractor with limited access, when the SharePoint snap-in isn’t available on the machine you’re working from, or when a DBA is running the audit independently. It gives you counts and associations — enough for a scoping conversation — but not the full picture.

Use this table to decide which approach fits your situation:

Approach 1 — The SharePoint Object Model Audit (Recommended)

Prerequisites

Before running the OM audit, confirm three things:

• You are running the script from the SharePoint server itself — the SharePoint snap-in (Microsoft.SharePoint.PowerShell) must be available on the machine
• Your account has farm administrator rights, or site collection administrator rights on all site collections in scope
• PowerShell 5.1 or later (which is standard on any machine running SharePoint 2019)

If you’re running from a jump box or admin workstation without the snap-in, switch to the SQL fallback.

Running the Audit

Load the SharePoint snap-in, then invoke the script against your farm. The -IncludeInstances flag is important — it captures running and suspended workflow instances, which tells you whether workflows are actively in flight before cutover.

# Load SharePoint snap-in if not already loaded
Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
# Run the full farm workflow audit
.\Get-SPWorkflowAudit.ps1 -OutputPath "C:\MigrationAudit\Workflows" -IncludeInstances -Verbose

The script walks every site collection and web in the farm, calling Get-WorkflowInventory and Get-WorkflowDefinitions on each, building up a complete picture before writing the HTML report via New-HtmlReport. Depending on farm size, expect this to run anywhere from five minutes on a small farm to thirty or more minutes on a large one. The -Verbose flag gives you progress output so you can see it moving.

The output lands in the folder you specify: a self-contained HTML file and a set of CSV exports.

What the HTML Report Contains

The report is designed to be handed to a project manager or business sponsor without explanation. It has five sections:

1. Executive Summary. A dashboard card showing total workflow associations found, number of active running instances, count of health issues detected, and the scope covered (number of site collections and webs audited). This is the one-page view for a leadership conversation.

2. Platform Distribution. A breakdown by workflow platform — how many associations are SP Designer, how many are Nintex, how many are OOB — per site collection. This is what drives your remediation roadmap. If you have 90 Nintex workflows and no Nintex SPSE license in the budget, that conversation needs to happen before you finalize migration dates.

3. Workflow Inventory. A per-site table listing every workflow association: the site URL, the list or library it’s attached to, the workflow name, the platform classification, the current status (active or inactive), and the last modified date. This is the detailed working view. Every workflow in your farm appears here.

4. Active Instances. Running and suspended workflow instances — the workflows that are actually in flight right now. This section is critical for cutover timing. An approval workflow that has been running for 87 days is a business process, not just a configuration artifact. You need to know it exists before you schedule your maintenance window.

5. Health Issues. Orphaned workflow associations (pointing to lists that no longer exist), associations with no reachable definition, and instances stuck in error state. The Get-WorkflowHealthIssues function surfaces these. On a farm that’s been running for six or more years, this section typically contains surprises — cleanup candidates that reduce migration noise before you even start.

Note: The full production version of the Workflow Audit Kit includes additional health checks, error recovery logic, and the complete report generator. The snippets in this post show the invocation pattern — the kit handles the edge cases.

Approach 2 — The SQL Fallback

When You Need It

Use the SQL approach when you’re working in a restricted access environment — contractor access without farm admin rights, a scenario where the SharePoint snap-in isn’t available, or when a DBA is running the audit on your behalf. It’s also useful for a quick pre-meeting count when you don’t have time to run the full OM audit.

Be clear on the trade-off: the SQL approach gives you workflow associations and counts. It does not surface active instance data, does not detect health issues, and cannot interrogate workflow definitions in the same depth as the OM approach. Use it for scoping; use the OM approach for production audit work when possible.

Fix Permissions First (if needed)

The SQL audit requires the account running the script to have read access to the SharePoint content databases. In many environments, the farm service account doesn’t have this by default. If you hit access denied errors, run the permissions helper first:

# Grant farm service account read access to content databases
.\Fix-SPContentDatabasePermissions.ps1 -DatabaseServer "SQL01" -ContentDatabases @("WSS_Content_Portal", "WSS_Content_Teams")

This grants db_datareader to the running account on the specified databases. It’s a read-only grant — no write permissions are involved. Confirm with your DBA before running, but it’s a safe and standard operation.

Running the SQL Audit

You can target a single database or loop across multiple. For a farm with several content databases, running them in a batch is the practical approach:

# Audit a specific content database
.\Get-SPWorkflowAudit-SQL.ps1 -DatabaseServer "SQL01" -DatabaseName "WSS_Content_Portal" -OutputPath "C:\MigrationAudit\SQL"
# Audit multiple databases
@("WSS_Content_Portal", "WSS_Content_Teams", "WSS_Content_Archive") | ForEach-Object {
    .\Get-SPWorkflowAudit-SQL.ps1 -DatabaseServer "SQL01" -DatabaseName $_ -OutputPath "C:\MigrationAudit\SQL\$_"
}

Each database produces two CSV files: WorkflowAssociations.csv and WorkflowInstances.csv. These become the input for the platform classification and report generation steps below.

Classifying Workflows by Platform: Nintex, SP Designer, and OOB

Whether you ran the OM audit or the SQL fallback, the raw CSV output has a limitation: it tells you a workflow exists and where it lives, but it doesn’t explicitly tell you whether it’s a Nintex workflow or a SharePoint Designer workflow. That distinction is everything in migration planning.

Add-WorkflowPlatformToCSV.ps1 post-processes the workflow association CSVs and adds a Platform column with one of three values: Nintex, SP Designer (2013), or OOB (2010).

# Add platform classification to all workflow association CSVs
Get-ChildItem "C:\MigrationAudit" -Filter "WorkflowAssociations.csv" -Recurse | ForEach-Object {
    .\Add-WorkflowPlatformToCSV.ps1 -InputFile $_.FullName -OutputFile $_.FullName
}

The script uses heuristics to make the classification. Nintex workflows carry a distinct feature ID pattern and their definitions reference Nintex-specific content type IDs. Their task list names follow Nintex conventions that differ from the standard SharePoint workflow task list naming. SP Designer SP 2013 workflows are identifiable by their association metadata and template namespace. OOB SP 2010 workflows use well-known built-in template IDs that the script matches against a reference list.

You don’t need to know the internals — the script handles the detection. What matters is the output: once you have the Platform column, you can filter and sort your entire workflow inventory by remediation category. Every Nintex workflow in one view. Every SP Designer workflow in another. That’s your migration scope, right there.

Regenerating Workflow Audit Reports from Existing CSV Data

Once your CSVs are classified, you have a choice: work directly in Excel, or regenerate a clean HTML and Excel report from the updated data. Generate-WorkflowReports.ps1 handles the latter.

This script is useful in several scenarios:

• You ran the SQL audit and want an HTML summary without re-running the full OM audit
• You’ve merged CSVs from multiple farms or content database runs into a single view
• You’ve made manual platform overrides in the CSV (for edge cases the heuristics didn’t catch) and want to refresh the report
• You need an Excel workbook for a PM sign-off meeting

# Regenerate HTML and Excel reports from classified CSV data
.\Generate-WorkflowReports.ps1 -CsvPath "C:\MigrationAudit\SQL" -OutputPath "C:\MigrationAudit\Reports" -GenerateExcel

The script uses Find-CsvFiles to discover all audit CSVs in the directory tree, Add-PlatformInfo to apply the classification, and then New-HtmlReportFromData and New-ExcelReportFromData to produce the final outputs.

The Excel workbook is particularly useful for migration scope planning. It generates one sheet per platform — a Nintex tab, an SP Designer tab, an OOB tab — with all workflow details in a pivot-ready format. Hand this to your project manager and they can build a remediation plan directly from it without needing to understand the audit scripts at all.

Using the Audit Results to Plan Your Migration

Data collected. Platforms classified. Reports generated. Now what?

The audit output is only valuable if it drives decisions. Here are the five decisions it should inform.

1. Identify your critical workflows first. Look for the intersection of three signals: workflows that had active instances in the last 90 days, workflows attached to business-critical lists (HR onboarding, procurement approvals, compliance reviews), and workflows with a high instance count over the past year. These are the ones that will cause immediate, visible business pain if they break. They go to the top of your remediation backlog before anything else is scheduled.

2. Make the Nintex call early. Every Nintex workflow in your audit is a licensing and architecture decision, not just a technical one. Do you have Nintex for SPSE licensed? If not, every one of those workflows goes to Power Automate — and that’s a rebuild effort, not a migration. This decision needs to happen at the project planning stage, not the week before cutover.

3. Schedule SP Designer workflow rebuilds. SP Designer (SP 2013 engine) workflows are not migratable to Power Automate in a one-click sense. Each one requires analysis, redesign, and rebuild. The audit gives you the list and the site context. Your Power Automate specialists need this list as their intake backlog. Feed it to them early.

4. Audit OOB 2010 workflows with a retirement mindset. The built-in Approval and Collect Feedback workflows are deprecated. They may have been the default choice on lists created years ago by users who didn’t know better. Inventory them, but default to retiring rather than rebuilding. Check instance history — if no one has run an approval workflow on a particular list in 18 months, there’s a good case for not rebuilding it at all.

5. Delete dead workflows before you migrate. One of the most practical things the audit enables is pre-migration cleanup. Look for workflow associations with zero instances in the last 12 months, associated with lists that have low activity. These are candidates for deletion before migration. Fewer workflows in the source farm means a cleaner content database, fewer associations to validate on the other side, and a reduced blast radius if something goes wrong.

A simple prioritization frame for your scope document: score each workflow by Business Impact (High / Medium / Low), Active Instance Count, and Platform Rebuild Effort (Power Automate rebuild for SP Designer is higher effort than a simple reassociation). The audit report is the direct input — you’re not estimating or guessing at scope. You have a complete, classified inventory.

Get the Complete Workflow Audit Kit

Don’t get surprised by 300 broken workflows on cutover day.

You won’t know how many SP 2013 workflows you have until you run the audit. Some farms have 50. Some have 500. The Workflow Audit Kit tells you exactly what you have — and what needs to move to Power Automate — before cutover forces the answer.

The kit includes five production-ready scripts:

• Get-SPWorkflowAudit.ps1 — Full OM-based farm audit with health issue detection, active instance enumeration, and stakeholder-ready HTML report
• Get-SPWorkflowAudit-SQL.ps1 — SQL fallback for restricted access environments, outputs per-database CSVs
• Add-WorkflowPlatformToCSV.ps1 — Post-processor that classifies every workflow as Nintex, SP Designer, or OOB
• Generate-WorkflowReports.ps1 — Regenerates HTML dashboards and Excel workbooks from existing CSV data
• Fix-SPContentDatabasePermissions.ps1 — Pre-flight helper that grants the read access the SQL audit requires

Three output formats are included: an HTML dashboard suitable for sharing with leadership or a project sponsor, CSV exports per content database for detailed analysis, and an Excel workbook with one sheet per platform — pivot-ready for migration scope planning in Excel or Project.

The HTML report is stakeholder-ready out of the box. You can open it in any browser, share it as a file, and it stands alone without any tooling dependencies.

→ Get the Workflow Audit scripts — contact sudharsan_1985@live.in

No subscription. One afternoon of audit work, and you’ll know exactly what you’re dealing with before you move a single site.

Already at an earlier stage of the migration? Start with Post #1 — The Complete SharePoint 2019 to Subscription Edition Migration Guide for the full 12-post roadmap.

What Comes Next

The workflow audit is the foundation for everything downstream in the migration. Your Power Automate rebuild backlog, your Nintex licensing conversation, your cutover timing — all of it depends on knowing what workflows are in your farm and which ones are in flight.

With your workflow inventory in hand, the next piece of the readiness puzzle is infrastructure: are your servers, ports, and firewalls ready for SPSE? Post #5 covers port connectivity and firewall readiness for SharePoint Subscription Edition — the network-level pre-migration checks that get skipped until they cause a deployment failure.

Run the audit this week. The farm will tell you things about itself that no one on your team knows.