Not applicable

Claims based authentication Nintex Workflow 2010 > 2013 migration

Looking for Nintex for SharePoint 2016 guidance? See the following link.

When you upgrade from Nintex Workflow 2010 to Nintex Workflow 2013, you will also need to perform an upgrade to Claims, and test it is working before proceeding to the rest of the migration.

There are two main issues that can happen when you are upgrading from Nintex Workflow 2010 to Nintex Workflow 2013.

1. Workflows which contain actions with embedded credentials will fail.

2. Workflows which wake after a Delay action will fail to continue after the migration.

Issue 1: Workflows which contain actions with embedded credentials will fail.

If embedded credentials are stored in the workflow definition, the workflow can fail as the credentials no longer match the new domain.  Actions which may result in embedded credentials include Call Web Service, Execute SQL, Copy to SharePoint, etc.

Issue 2 - Workflows which wake after a Delay action fail to continue after the migration.

When a workflow is initiated, it is compiled, and that ‘snapshot’ of the workflow is stored within SharePoint until the workflow completes. Workflow instances that "sleep" as a result of a Delay or Task action are stored within the SharePoint content database. When the workflow wakes, SharePoint takes the stored credentials and attempts to execute the workflow in the context of the original initiator. If the migration is completed while the workflow was asleep, the (Compiled) credentials are invalid and the workflow will end in error.

Other issues you may see  

We have also noticed the following when migrating to a new domain, or to claims based authentication for 2010/2013:

  • Workflows becoming un-published
  • Workflow history is unavailable
  • Tasks associated with the workflow do not appear when viewing the workflow history
  • Workflow tasks cannot be approved
  • Workflows missing altogether from the SharePoint Workflows page
  • The workflow status column missing from the list on which the workflow ran

While this list isn't definitive, these are some of the issues that our customers see during their migrations. The key to most of these issues is to make sure you have your users complete as many outstanding workflows as they can before the migration and ensure that you perform the steps to migrate users inside of the Nintex database.

After upgrading to Nintex Workflow 2013 from Nintex Workflow 2010, please follow the steps below to update the domain of ALL users within the “Old_domain” to “New_domain:

Please note: Nintex Workflow 2013 v3.0.8 and Nintex Workflow 2010 v2.3.14 onwards contain the stored procedures required for this. We recommend you upgrade to the latest build Product Downloads (Product updates are only available to Software Assurance, or Premium Support customers, if you do not have access please submit a Support​ ticket​)

  1. Run the following SQL statement against the NW config database:
    exec dbo.MigrateDomainInConfigDB @OldDomain = 'domain\', @NewDomain = 'domain\'
  2. Run the following SQL statement against the NW Content database:

        exec dbo.MigrateDomainInContentDB @OldDomain = 'domain\', @NewDomain = 'domain\'

Note: The MigrateDomainInContentDB needs to be run against every Nintex Workflow database which is acting as a content database. If you have a single database acting as a config and content database, this script will need to be run.

Example of a Claims based migration:





Please note: You must specify both old and new domains in the format domain\ (including the trailing "\"), to ensure the script does not update a username and also remember to add the claims designation to the new domain name (“i:0#.w|domain” for example) if you are also moving to claims at the same time.

The “i:0#.w|domain” claims identifier is based off of windows authentication. If you are using another form of authentication (such as Kerberos, forms, ADFS, etc.) please confirm the claims identifier. (Example: “i:05t|adfs|username” adfs through claims)

As always we'd recommend thorough testing wherever possible before performing the migration.