How to deploy and update SharePoint Workflow Manager

Articles

SharePoint Workflow Manager replaces the original Microsoft Workflow Manager and Service Bus for running SharePoint 2013-platform workflows. It is installed separately from SharePoint Server, and moving from the original WFM requires its own procedure. Prepare both server and client components and connect the workflow farm to SharePoint correctly.

First, check which product you are using. Moving from the original Workflow Manager to SharePoint Workflow Manager is not a normal CU installation. And if you already have SharePoint Workflow Manager, you do not need to repeat the entire migration procedure for every update.

Microsoft announced the new product on 16 February 2023. This guide describes deployment and the transition from the original WFM. The general CU installation procedure and migration to new servers are marked as later additions.

Components and choosing a procedure

Before you begin, distinguish between the base server installation, the client, and any update. Find current package versions in the relevant CU announcement and its KB article, this guide is not tied to a particular release.

Component Purpose Location
SharePoint Workflow Manager Server components of the workflow infrastructure Workflow farm servers
SharePoint Workflow Manager Client Client components for communicating with the workflow farm Workflow farm and SharePoint farm servers
Server CU, later addition Updates an existing SPWFM installation Workflow farm servers, the KB specifies the required client

Check the server and client versions in Control Panel – Programs and Features. Distinguish between Microsoft Workflow Manager and SharePoint Workflow Manager. Service status alone does not tell you which product and update are installed.

Starting point Procedure
No workflow infrastructure New deployment
Original WFM, keeping the servers Transition on existing servers
Original WFM, replacing the servers Migration to new servers
Already using SharePoint Workflow Manager Installing a CU

Preparing for deployment or an update

Distinguish between the server and client

Install both SharePoint Workflow Manager and SharePoint Workflow Manager Client on every server in the workflow farm. Every server in the SharePoint farm needs the client. Installing a SharePoint CU does not replace these components. The base installers are available from the Microsoft Download Center, select the update and required client version using the relevant KB article.

For production, prepare HTTPS, a DNS name for the endpoint, and a trusted certificate. Check the supported operating system, SQL Server, required IIS components, and Azure Service Fabric against the installation documentation. Service Fabric must be installed before SPWFM. On a dedicated workflow server, remember to install IIS with Windows Authentication, .NET Extensibility, and ASP.NET.

Microsoft recommends dedicated workflow servers. The number of workflow farm nodes is independent of the number of SharePoint servers, odd numbers such as one or three are supported. Having multiple nodes is not a reason to promise an update without downtime. Prepare a maintenance window and check the procedure for every node.

Save the current configuration

Before changing an existing farm, record the SQL instances and database names, service account, AdminGroup, endpoint, certificates, and scope. Back up all Workflow Manager and Service Bus databases and agree on a consistent recovery point with the SharePoint databases. Configuration exports alone do not replace a database backup.

On the workflow server, run Workflow Manager PowerShell as an administrator. The following example saves the configuration to an existing folder:

Get-WFFarm | Format-List * | Out-File 'C:\Install\WFFarm.txt'
Get-SBFarm | Format-List * | Out-File 'C:\Install\SBFarm.txt'
Get-WFFarmStatus | Out-File 'C:\Install\WFFarmStatus.txt'
Get-SBFarmStatus | Out-File 'C:\Install\SBFarmStatus.txt'

To leave and rejoin an existing farm, you need the original Certificate Generation Key. This is not the service account password. If you do not know it, recover or reset it before removing the servers, following Microsoft’s instructions. Store the key and passwords securely outside ordinary configuration exports.

Determine the scope on a SharePoint server in SharePoint Management Shell. The following example assumes a single Workflow Service Application Proxy:

$site = (Get-SPWebApplication -IncludeCentralAdministration |
    Where-Object { $_.IsAdministrationWebApplication }).Sites[0]
$proxy = Get-SPServiceApplicationProxy |
    Where-Object { $_.TypeName -eq 'Workflow Service Application Proxy' }
$proxy.GetWorkflowServiceAddress($site)

In a result such as https://workflow.contoso.com:12290/SharePoint2013/, the scope is SharePoint2013. Preserve the value actually in use during migration, do not automatically create a new scope just because you are replacing a server.

New SharePoint Workflow Manager deployment

First server

  1. Prepare accounts, SQL, IIS, certificates, and the required connectivity. Install a supported Azure Service Fabric Runtime.
  2. Install the base SharePoint Workflow Manager RTM.
  3. Install SharePoint Workflow Manager Client. When replacing a client, uninstall its older version first.
  4. Later addition for CU releases: if you are installing an available CU, first check its required client, install the server package, and restart if required. Follow the new farm procedure in the relevant KB.
  5. Run the Workflow Manager Configuration Wizard and create a new farm. If you need custom database names, ports, or certificates, use Configure Workflow Manager with Custom Settings.
  6. Save the chosen Certificate Generation Key and configuration. Check that the wizard completed and verify the service status.

Later addition: if the selected CU’s KB requires installing the update before creating a new farm, follow that sequence. Creating the farm on an unpatched installation and then installing the CU is not automatically an equivalent procedure.

Additional servers and connecting SharePoint

  1. Prepare the same components, client, and CU on the additional workflow servers.
  2. Run the wizard and select Join an Existing Workflow Manager Farm. Use the existing farm configuration and its Certificate Generation Key.
  3. Install the required SPWFM client on every SharePoint server, first uninstalling any previous client.
  4. Check App Management and Subscription Settings in the SharePoint farm, including service applications and proxies. Configure them first if they are missing.
  5. Establish trust for the workflow endpoint certificate in SharePoint and on the SharePoint servers using the certificate documentation.
  6. On one SharePoint server, connect the farms using Register-SPWorkflowService and perform the checks in Verification after the change.

Find the correct workflow URL using Get-WFFarm | Select-Object Endpoints. The following example registers a new farm over HTTPS. Run it in SharePoint Management Shell as an administrator with the required workflow farm permissions:

Register-SPWorkflowService -SPSite 'https://sharepoint.contoso.com' -WorkflowHostUri 'https://workflow.contoso.com:12290'

Adjust the names to match your environment. The -SPSite parameter identifies a valid site collection, it does not restrict registration to that site collection alone. This example is for a new connection, re-registering during migration has additional requirements.

Transition from the original WFM on existing servers

Do not install SPWFM over the original Microsoft Workflow Manager. The transition requires removing the original components, while preserving the existing databases and workflows. See Upgrade existing Microsoft Workflow Manager for the detailed procedure.

  1. Complete the backups, configuration records, and Certificate Generation Key check. Schedule downtime.
  2. In the original Workflow Manager Configuration Wizard, select Leave Workflow Manager Farm. Complete removal on all original workflow servers.
  3. On those servers, uninstall the original Microsoft Workflow Manager, Workflow Manager Client, Service Bus for Windows Server, and Windows Fabric if present. If the server is shared with SharePoint, do not confuse Windows Fabric with AppFabric 1.1 for Distributed Cache.
  4. Remove the remaining original installation folders identified in Microsoft’s documentation, only after verifying the specific path and completing uninstallation. Do not delete databases or other components’ directories. Restart the server.
  5. Prepare Azure Service Fabric and install SharePoint Workflow Manager and its client.
  6. In the wizard, select Join an Existing Workflow Manager Farm. Use the original databases, service account, and Certificate Generation Key. Do not create a new empty farm.
  7. Run the wizard again and complete Upgrade Workflow Manager Farm. Complete the transition and upgrade on every workflow server.
  8. On every SharePoint server, uninstall the old client and install the SPWFM client.
  9. Later addition for CU releases: then complete installation of the selected CU using Installing a CU, including the client required by that CU, and test the original workflows.

This transition preserves the original databases, it is not a supported upgrade by installing over the old product. A normal transition that keeps the existing registration generally does not require deleting the Workflow Service Application Proxy and running Register-SPWorkflowService again. Handle any endpoint or certificate changes according to the actual configuration.

Migrating the original WFM to new servers

Later addition to the original release dated 20 March 2023: Josh Roark published the new server migration procedure on 24 March 2023. It was subsequently incorporated into Microsoft Learn. This section is therefore not presented as part of the original March release.

When replacing servers, preserve the databases and identity of the existing workflow farm. A clean installation with new databases does not migrate your original workflows. The following sequence follows the official migration procedure, which builds on Josh Roark’s article.

  1. Record the configuration, Certificate Generation Key, RunAsAccount, AdminGroup, and scope. Prepare the new servers and a cutover plan.
  2. Use Leave Workflow Manager Farm on all original nodes. Take the migration backup of the workflow and Service Bus databases only after removing all original hosts, otherwise their old records will be carried over.
  3. If you are replacing SQL Server, move all six Workflow Manager and Service Bus databases. Preserve the original database names and establish working connectivity from the new servers. For the procedure described in the documentation, also check the required SQL alias.
  4. On the new servers, prepare IIS, Service Fabric, base SPWFM, and the client. Connect to the original or restored databases using Join an Existing Workflow Manager Farm and complete Upgrade Workflow Manager Farm.
  5. Complete the selected CU using its KB article and align clients across both farms.
  6. Check the endpoint and certificate trust. If the scenario requires re-registration, use the original scope and the appropriate workflow URL.
  7. Switch SharePoint to the prepared environment and test actual original workflows.

The default database names are SbGatewayDatabase, SbManagementDB, SBMessageContainer01, WFInstanceManagementDB, WFManagementDB, and WFResourceManagementDB. Preserve your own names if you use custom ones. During cutover, prevent concurrent processing of production workflows in the old and new environments.

The following example re-registers the service during migration. Replace -ScopeName with the actual original scope, -Force is not part of a normal CU installation:

Register-SPWorkflowService -SPSite 'https://sharepoint.contoso.com' -WorkflowHostUri 'https://workflow.contoso.com:12290' -ScopeName 'SharePoint2013' -Force

If you are also migrating the SharePoint farm, move the corresponding content databases and the App Management database. It contains the app identities used by the original workflows. Omitting it can cause workflows to fail even when the SPWFM farm is running correctly. A detailed SharePoint upgrade is outside this guide, follow its own migration documentation and the supported path between versions.

Installing a CU on an existing SPWFM farm

Later addition after CU releases began in 2025. This procedure applies to a farm already running SharePoint Workflow Manager. Select the specific server package and required client using that CU’s announcement and the Prerequisites section of its KB article. The More information section describes completing installation separately for existing and new farms.

  1. Check prerequisites, known issues, and available backups. Prepare installation packages and a maintenance window for both farms.
  2. Uninstall the old SPWFM Client on every server in the Workflow Manager farm and the SharePoint farm.
  3. Install the client required by the selected CU on all those servers. Obtain the version from its KB, it may differ from the server package build.
  4. Install the selected server CU on every workflow farm server. The server package does not belong on SharePoint servers that only have the client.
  5. Restart servers if required by the installation.
  6. On the workflow servers, complete Upgrade Workflow Manager Farm in the Workflow Manager Configuration Wizard.
  7. Check versions, farm status, connectivity from SharePoint, and workflow functionality.

The normal CU procedure does not include Leave Workflow Manager Farm, uninstalling the server product, or creating new databases. Those steps belong to other scenarios. Installing binaries also does not replace completing the farm upgrade in the wizard.

Verification after the change

On the workflow servers, check the installed component versions and farm status. The following example runs in an administrator Workflow Manager PowerShell window:

Get-WFFarmStatus
Get-SBFarmStatus
Get-WFFarm | Select-Object Endpoints, RunAsAccount, AdminGroup

From a SharePoint server, open the actual workflow endpoint over HTTPS, for example https://workflow.contoso.com:12290/. For an administrative check, use an account with workflow farm permissions. Check DNS, the certificate, and service availability. Then check that the Workflow Service Application Proxy in Central Administration reports a connection.

Connected status alone is not enough. Start a new instance of an existing workflow and check actions, tasks, history, and completion. Depending on your scenarios, also check that a waiting workflow resumes and that a test workflow can be published. Do not test under the SharePoint System Account, use an ordinary test user with the necessary permissions and a profile in the User Profile Service.

If a failure occurs, first check View Log in the configuration wizard, Workflow Manager and Service Bus events, and SharePoint ULS. Compare the actual client versions on every server. Do not address scope or permission problems by creating a new empty workflow farm.

Later additions – verified as of 17 October 2026

The original article is set on 20 March 2023. Migration to new servers and the general CU installation procedure are later additions. Current KB numbers, server builds, and required client versions belong in individual CU announcements rather than this guide.

Updating the server and client

For every update, check that release’s prerequisites and known issues. The server and client have separate installation packages and their versions may differ. Do not derive the client version from the server build number. The default procedure replaces the client, retaining an installed version is appropriate only if the announcement explicitly permits it and the version meets the KB requirement.

Dependencies and environment changes

SQL connectivity and other library requirements can change between releases. Before migrating or updating, check the current documentation and the specific KB. Plan Service Fabric changes separately using its documentation, they are not automatically part of every SPWFM CU. A historical Service Fabric version example is not a recommendation for an installation today.

Support and testing tools

SPWFM follows the Component Lifecycle Policy and the support lifecycle of the relevant SharePoint Server. Moving to SPWFM alone does not extend support for an old SharePoint farm.

SharePoint Designer 2013 has been out of support since July 2026. Do not reuse its examples in older guides as a recommendation for new deployments. Microsoft identifies Visual Studio as a supported option for creating and editing SharePoint 2013 workflows after that date, see the support retirement information. Test existing workflows directly through SharePoint.