Skip to main content

In the support organization, there are frequently customer requests for how to properly refresh Test / Dev Environments with Production data.  The steps below can be used as an example for how to migrate content.  These steps are some basic guidelines around the process for migrating data from a Production Farm to a Test farm, but as all SharePoint farms are different, you may need to adjust these accordingly to meet your specific business needs. 

 

Production Farm Steps

Backup Your Databases

If you wish to preserve the current workflow history and state, it is recommended that you stop the target Web Application Pool(s) in IIS along with the SharePoint Timer Service in Services.MSC prior to performing backup operations

  • SharePoint
    • SharePoint Content Databases
  • Nintex Forms
    • Unless this is a straight migration where the old farm is no longer being used, it is recommended you generate a new database / new live ID for the farm, meaning that the Live / Mobile forms stored in the Nintex Forms database will need to be republished in your sites on the test Farm
  • Nintex Workflow
    • Workflow content databases
    • Workflow configuration database
      • If you are not using User Defined Actions, Workflow Constants, or Scheduled workflows, and there is no Workflow Progress data in the Nintex Configuration Database that needs to be retained on the target farm, you can create a new Nintex Configuration Database

 

Development Farm Steps 

Install / Verify Nintex Workflow and Forms Builds on Target Environment

 

Disable Jobs / Services on the farm

  • Disable the Nintex Workflow Scheduler Timer Job
    • Find the job under SharePoint Central Administration > Monitoring > Timer Jobs > Review Job Definitions
  • Disable the SharePoint Timer Service on all servers in the Farm
    • This can be found in Services.msc
  • Disable Target Web Application Pool(s) in IIS on all servers in the farm (leave SharePoint Central Administration in a ‘Started State’)

 

Restore and Attach Databases

  • Restore SharePoint and Nintex Databases in SQL Server Management Studio
  • Attach SharePoint Content DB(s) to the farm using Mount-spcontentdatabase PS
  • Execute "_PrepareForNewEnvironment" stored procedure on the Nintex Config Database
    This command will remove all existing connections to Nintex databases along with any Pending Nintex Live requests. This is a key step as this will prevent any connection strings from referencing production servers. 
    • Launch SSMS and expand the config database
    • Find Programmability and Expand the Stored Procedures folder
    • Right-Click on "_PrepareForNewEnvironment" and select the Execute Stored Procedure
  • Connect the Nintex Configuration Database in the Farm  Go to Central Administration > Nintex Workflow Management > Manage Databases
    • Click the Create button(edit button if a config database is already in place)
    • Enter the name of your server and the database
    • Select the "Connect to existing database option"
    • Click "Ok"
  • Connect the Nintex Content Databases to the farm

Additional Configuration Steps

  • Ensure All workflow actions have been enabled
    • In Nintex Workflow Management, go to Manage Allowed Actions
    • Select the check box at the top of the first column (ensure all items have been checked)
    • Click Ok
  • Temporarily disable outgoing email in the farm
    **This is 100% optional, but the workflows will be live when all of the services are brought back online, and the majority of customers we have worked with want to avoid confusion with emails coming from workflows in dev. This is recommended until you can confirm that all workflows have been stopped, or are not sending any further emails  
    • Go to Central Administration > Server Settings > Configure outgoing email settings
      • You can place a test server or a dummy relay in the outbound email
    • Go to Central Administration > Nintex Workflow Management > Global Settings
      • Place a test exchange server or a dummy relay in the outbound email.


Bring the sites and forms back online

  • Reactivate the Web Application Pools, the SharePoint Timer Service and the Nintex Workflow Scheduler timer job that were disabled during the ‘Disable Jobs / Services on the farm’ step
  • Republish any forms using Nintex Mobile / Live (if you did not bring over the live ID / Database)

 

Common Issues / Tips and Tricks

Explicit References

  • If you are using explicit links rather than the {Common:URL} token in your actions, these will need to be cleaned up prior to running your workflows.  The explicit links will still point at the production environment and could potentially alter production data if in use in a 'Call Web Service' or 'Web Request' action.  This could also extend to Workflow Constants if a URL is defined within a constant that is used across actions.
  • If you are using the 'Execute SQL' command to query or alter data within your production farm, you will need to update the connection string to reflect the proper location after moving your data.

Attention! Make sure you have no workflow constants or other configuration storage items where production URLs could be persisted for Web Service Call or Web Request actions for example. Scheduled workflows may run against production farm if you don't.

NB You may batch replace SharePoint users' email addresses with some junk mailbox on development farm with Set-SPUser cmdlet.

Alexey, great point on the Call Web Service and Web Request actions.  This also feeds in to the point that if links are input explicitly (not using the {Common: URL} token) then they will need to be updated prior to running any workflows. This will not impact just these two actions, but rather, will have a broader impact across the farm.  As a best practice, users should use the tokens wherever possible to increase the portability of their workflows, and to avoid situations when moving data. I've updated the post to include some tips around explicit references.

By the way, there are situations, where end users need URLs from one AAM zone, and background workflows need to call another AAM zone URLs of the same web application. It would be great if Nintex could somehow allow to specify the zone in {Common:URL}. Anybody willing to support this idea on uservoice?

‌ .Thanks for the post .I have a question and hoping for the suggestions  from you.

  1. We have 2 farms one in SharePoint 2010 and SharePoint 2013 and we want to move one site collection from SharePoint 2010 to SharePoint 2013 and we do have scheduled workflows and we need Workflow progress data for that we need to backup/restore configuration database also.
  2. How could we add configuration database of SharePoint 2010 to the SharePoint 2013 farm without affecting the configuration database of SharePoint 2013?

Are user defined actions stored in the Config DB?

That is correct. UDA's will be stored in the Config DB.

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings