Migration from Windows Workflow Manager (classic) to SharePoint Workflow Manager

Question

Migration from Windows Workflow Manager (classic) to SharePoint Workflow Manager

Volodymyr Holovko 41

Hi everyone,

I have a single-server Classic Workflow Manager farm hosted on my SharePoint 2019 server, [Moderator note: Personally Identifiable Information removed]. I need to move it to [Moderator note: Personally Identifiable Information removed]

I am considering upgrading to SharePoint Workflow Manager (SPWFM) during this migration, but I am not sure I know the current Certificate Generation Key (CGK).

My existing WFM and Service Bus farms use custom certificates issued by our internal CA.

The current WFM endpoint is - [Moderator note: Personally Identifiable Information removed]

Ideally, I would like to use this endpoint after the migration - [Moderator note: Personally Identifiable Information removed]

My questions are:

If I reset the CGK, will it replace, regenerate, or invalidate my existing custom CA-issued WFM and Service Bus certificates?
What is the supported way to move the farm to sp19app2.contoso.com and change its endpoint to [Moderator note: Personally Identifiable Information removed]? Can I use a DNS alias for this purpose?
Maybe would it be better to stop using custom CA-issued certificates and use Workflow Manager's certificate auto-generation mechanism instead?

I do not have any critical long-running workflow instances, so losing workflow execution history would be acceptable. Therefore, I am also considering installing a completely new SPWFM farm on [Moderator note: Personally Identifiable Information removed] and re-registering SharePoint.

Which approach would you recommend?

Relocate the existing farm and upgrade it to SPWFM.
Relocate and upgrade it while changing the certificate configuration.
Install a fresh SPWFM farm and re-register SharePoint.

I would appreciate advice from anyone who has performed this migration with custom CA-issued certificates and a change of the Workflow Manager endpoint.

Thanks!

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Hi @Volodymyr Holovko

Since workflow history preservation is not a requirement in your environment, you may want to consider option 3, which is to deploy a fresh SPWFM farm on sp19app2 and re-register SharePoint. Based on my research, Workflow Manager 1.0 is no longer supported, while SharePoint Workflow Manager (SPWFM) follows the SharePoint Server support lifecycle. Additionally, recent guidance has recommended moving from classic Workflow Manager to SPWFM. A fresh deployment could also help avoid the challenges associated with an unknown CGK and changing the existing workflow endpoint configuration.

References:

Microsoft Workflow Manager 1.0

Trending Issue: Classic Workflow Manager Workflows fail after September 2025 CU for SharePoint

This link is shared by community members for your convenience. It points to a third-party site that is not managed or verified by Microsoft. I can’t guarantee the quality, safety, or suitability of any content or software found there. Please review carefully and make sure you understand any potential risks before using it.

For your concerns regarding the CGK and certificates:

As far as I know, the CGK works similarly to the SharePoint farm passphrase and is required when joining a workflow farm. If the key is lost, Microsoft provides a documented procedure to reset it. However, the documentation states that resetting the CGK causes new Workflow Manager and Service Bus certificates to be generated, and SharePoint must then be configured to trust those certificates. I found documentation describing the behavior for auto-generated certificates, but I could not find documentation explicitly confirming whether existing custom CA-issued certificates are replaced or preserved during that process. For that reason, if you decide to proceed with a reset on the existing farm, I would recommend backing up the databases and exporting the current certificates (including private keys) beforehand.

Reference: Reset the Certificate Generation Key for SharePoint Workflow Manager

For the supported approach for moving the farm and changing the endpoint:

From what I understand, a DNS alias might be an option, provided that spwfm.contoso.com resolves correctly to the new server and that the workflow endpoint certificate includes the appropriate Subject Alternative Name (SAN). However, I could not find official documentation that specifically addresses changing the endpoint hostname of an existing Workflow Manager farm. Since the endpoint details are stored within the farm configuration, deploying a new SPWFM farm and registering SharePoint against the new endpoint may be a simpler approach than migrating and renaming an existing farm.

Regarding whether you should continue using custom CA-issued certificates or switch to auto-generated ones, custom CA-issued certificates remain a valid option for production, as domain-joined servers typically already trust your internal CA. You could issue a certificate that includes both spwfm.contoso.com and the server FQDN in the SAN field. Auto-generated certificates are simpler to set up, but because they are self-signed, they may require additional trust configuration on the SharePoint servers, including importing the certificates, running the Refresh Trusted Security Token Services Metadata Feed timer job, and repeating the process when certificates are renewed or regenerated. Whichever option you choose, please record the new CGK in a safe place when creating the farm.

After the new farm is ready, you could register SharePoint against it by running the Register-SPWorkflowService cmdlet. Existing workflows may need to be validated and, depending on the scenario, republished. I would recommend testing thoroughly before decommissioning the old server.
I hope this helps address your concerns.