Splitting existing SharePoint and Nintex Content Databases

Document created by emily.billing@nintex.com Champion on Jun 4, 2014Last modified by pamela.denchfield on Jul 12, 2016
Version 6Show Document
  • View in full screen mode

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


If Nintex Workflow was installed using its default configuration of one all-inclusive database, this data can be divided and distributed to one or more new databases. If SharePoint content needs to be similarly subdivided, there is a SharePoint method to achieve this. This document describes a process using both methods in conjunction to achieve a 1-to-1 mapping of SharePoint and Nintex data.


NOTE: If you do not want a 1-to-1 mapping of SharePoint and Nintex content databases, the SharePoint Content can be left as is and only a dedicated Nintex database created and the Nintex data moved. With this mapping, whenever a backup and restore is done in the future, the entire SharePoint content database and all the Nintex Workflow content databases will need to be backed up at the same time and restored at the same time. For more information, see Nintex Workflow Backup and Restore.


For guidance on planning database mapping and maintenance, see Database Design Guide: Nintex Workflow.


Process Overview

Please read this entire article to familiarize yourself with the process and its requirements. As always, Nintex recommends testing this process on a non-Production environment first.


The SharePoint method for moving database content

The PowerShell Move-SPSite command is used to move the content of a SharePoint Site Collection from one database to another on the same SQL Server. This process can be done independently of Nintex – if a SharePoint site collection is given its own SharePoint content database, it will use its

existing Nintex content database until directed otherwise.


The Nintex method for moving database content

The NWADMIN movedata command is used to move the Nintex workflow progress data of a Site Collection into its own Nintex content database. The new database can be created using the Central Administration interface, but the data itself must be remapped using NWADMIN.


High Level Steps

To split a SharePoint Content database and a Nintex Content database to enable one to one content for each:

  1. Create a new SharePoint content database (use the Microsoft recommended methods).
  2. Create a new Nintex Workflow content database by navigating to Central Administration and open Nintex Workflow Management. Click on Database Setup and then Add content database.
  3. Login to the SQL Server and ensure that all necessary service accounts are added to the newly created Nintex Database. To add a service account:
    1. Open SQL Server Management Studio.
    2. Expand the new Nintex Content Database.
    3. Expand the “Security” folder.
    4. Right-click the “Users” folder and select “New user…”
    5. Enter a Display name for the user then the login name.
    6. Select from the Role Member section “WSS_Content_Application_Pool”.
    7. Save the changes and perform an IISRESET.
  4. Stop the Web Application that contains the content database being split, by stopping the IIS site mapped to the web application.
  5. Stop all instances of the SharePoint Timer Service wherever they exist for the entire farm.
  6. To move SharePoint content from an existing content database to another database, use PowerShell Move-SPSite. This will keep all GUIDs including SiteID. Notes and links on how to use this command are provided below.
  7. Run nwadmin -o movedata, the detail for which is below.
  8. Map the new SharePoint content database to the new Nintex Workflow content database in Central Administration; via the Database Setup and then Manage database mappings page.
  9. Restart the Web application, the IIS site and all instances of the SharePoint Timer service in the farm.


To test the process:

  1. Open your new site.
  2. Find a workflow that is either “In progress” or “Completed” and view the workflow history. The Full visual and detailed history should display.
  3. Start a new instance of an existing workflow, ensure it starts and enters an “In progress” status. Check the workflow history for progress. Similarly, the full visual and detailed history should display.


Using PowerShell Move-SPSite

To split out site collections to maintain a 1-to-1 mapping between SharePoint Content Database and Nintex Workflow Content Databases, use the PowerShell Move-SPSite, providing the ability to move a site collection to an another Content Database whilst preserving all SharePoint GUIDs (naturally

except the Content Database ID).


For these procedures to work, the following conditions must be true:

  • The destination content database must already exist.
  • The source content database and destination content database must be located on the same instance of SQL Server.
  • The source content database and destination content database must be attached to the same Web application.


The specific KB describing this command from Microsoft is available here:

http://technet.microsoft.com/en-us/library/cc825328(v=office.14).aspx and here:



Before performing the below steps, disable access to the farm using Microsoft’s standard methods


Using NWAdmin -movedata

Please note: The information provided below only caters for the example described above. However, the “movedata” command is capable of catering for other scenarios, for information in this regard, please refer to NWAdmin Operations - Nintex Workflow 2013 or NWAdmin Operations - Nintex Workflow 2010.


This operation is used to move all workflow progress data for a site collection to a selected workflow content database. This command should be run as the Farm Account, as this identity will have access to each workflow database.


The utility will begin by warning the user to pause all services that can run or interact with workflow. You will need to stop the Web Application that is to be restored. This includes stopping the IIS site mapped to the web application and stopping the SharePoint Timer Service and all servers in the farm. This is important: if the workflow data changes during the migration process it may become corrupted. Once the migration is complete, the tool will attempt to detect any changes to the data and handle this by warning the user and moving the changed data, but it is recommended to avoid this situation.


In a command prompt, type:


nwadmin.exe -o moveData –Url http://YourFullyQualifiedDomanName/sites/sitename


The tool will list the workflow content databases that are configured with numeric identifiers and prompt the user to choose which of these databases the site collection workflow data should be moved in to.


The data for each workflow instance is moved one by one. If any fails to move, the tool will display error details and prompts the user either to retry moving the instance, skip the instance or abort the process, rolling back any changes.


Once the operation is complete, restart all services to continue workflow operation. From this point on, workflows in the site collection will use the new database. If any services were not stopped during the migration process, they will contain cached references to use the old database so it is

critical they are restarted at this point (which will cause them to clear the cached database pointer and use the new database).



NWAdmin.exe -o MoveData [-Url <siteCollectionUrl>] [-SourceDatabase <connection string>] [-TargetDatabase <connection string>] [-RetainSourceData]


-UrlThe url to the top level site of the site collection that data will be moved for.
-SourceDatabaseA database connection string to the Nintex Workflow database to extract data from. Use when retrieving data from an external database not connected to the target environment.
-TargetDatabaseA database connection string to the Nintex Workflow database to move data from. If a value is not provided the console UI will prompt for the target database.
9 people found this helpful