Migrating Nintex workflows and history from 2010 to 2016


 To migrate SharePoint 2010 Nintex workflows to SharePoint 2016 farm, you need first to migrate the SharePoint content DB and workflows to SharePoint 2013. There is no direct migration path between SharePoint 2010 to SharePoint 2016 version. You will need to double-hope through SharePoint 2013, upgrade the content DB, and only then, move it to the 2016 SharePoint farm.

Therefor you will first need to build the SharePoint 2013 and 2016 SharePoint farm, and create the web application that will host the migrated content DB’s

  1. Create the SharePoint 2013 farm
  2. Create the web application with the same security model as the source SP2010 farm
  3. Create the SharePoint 2016 farm
  4. Create the web application with the same security model as the source SP2013 farm supporting the claims security model

If you are using Nintex Live ID in your sp2010 environment, note the live ID using the following instructions: Get the existing 2013 Nintex Live ID

upgrade your SP2010 Nintex product to the latest patch including all the latest bug fixes for this version.

Preparation and Nintex installation

On the SharePoint 2013 and 2016 farm stop/disable all SharePoint workflow services and timer job following these steps: Prepare SharePoint 2016  for Workflow Migration

Install the most updated  Nintex product for your farm following these steps : Deploy Nintex 2016 on SharePoint 2016 farm.

Attaching SharePoint Content DB

Backup the SP 2010 site collection content DB’s following these steps:

  • Stop all workflows services
  • Switch site to read-only
  • Create a backup through SQL manager for the site collection Content DataBase (CDB)
  • Start all workflows services
  • Stay on read-only on the 2010 site collection during the upgrade
  • Move the CDB to SP2013
  • Test CDB and fix Log errors using test-spcontentdatabase
  • Attach CDB using Mount-spcontentdatabase

Migrating Nintex configuration Database

On the SharePoint 2010 farm backup the Nintex configuration  databases, following these steps :

  • Stop SharePoint timer service
  • Detach Nintex Configuration database using NWAdmin.exe –o DetachDatabase
  • Backup database using SQL server manager
  • Restart SharePoint timer service
on the SharePoint 2013 farm restore
  • Execute “_PrepareForNewEnvironment  using SQL Manager on the configuration DB
  • Navigate to Nintex workflow management in central admin and create and connect to an exiting database providing the name of the backed up database you migrated from 2010.
  • Enable workflow actions

Migrating Nintex Content Database

Note: If the content database you are migrating is the same physical database as the configuration database, start from step 6 below
On SharePoint 2010 environment
  1. Stop the “Windows SharePoint Services Timer” service.
  2. Run “NWAdmin.exe –o DetachDatabase
  3. Backup the database (using “Microsoft SQL Server Management Studio”).
  4. Start the “Windows SharePoint Services Timer”.

on the SharePoint 2013 farm restore

  1. Restore the database that was backed up from the 2010 farm using SQL Management.
  2. Run “NWAdmin.exe –o AttachDatabase
  3. Restart IIS
  4. Map or review mapping SharePoint contentDB to Nintex workflow


  1. Restart all services that were stopped pre-installation
  2. Upgrade a web application from Classic Authentication to Claims Authentication using

    Convert -SPWebApplication


Code Snippets to Remove exiting Nintex configuration DB:

#Remove WF Configuration Database$farm = Get-SPFarm;
$farm.properties["NW2007ConfigurationDatabase"] = “”; $farm.Update();

Important :

Note: Why do I have to run a detach command before backing up the database?
The detach command must be used to store some data from the
environment that is not initially present in the
content database. For example, when the DetachDatabase command is run, information on pending Nintex Live
service requests is stored in the co
ntent database. When the AttachDatabase command is run in the 201
environment, the data is extracted from the database into the environment. If these steps were not followed, the
workflows waiting at a Nintex Live service request would never continue.