Skip to main content

I found the article below. In my situation, however, I am not refreshing the entire farm. I have one web app with some associated workflows. I don't want to overwrite the entire Nintex db in test (since I have other workflows in use there). And my prod farm continues in active use, so I don't want to stop any services or break any connections. My goal is to copy over the SharePoint web app and associated workflows to test.

It isn't so much of a big deal if some workflows are in an odd state after moving. I just want the data and history there, and to be able to restart workflows once moved.

What is the best approach?

https://community.nintex.com/community/build-your-own/blog/2016/09/12/how-to-refresh-a-development-farm-with-production-data

I usually export the workflows from source and import into destination. I do not bring over history as it only relates to executed workflows, so in test farms, it doesn't assist to bring over production history. Without bringing over the database, it doesn't stay associated. But new workflows will work just fine with its own history, etc. You could change your architecture for the Nintex database though if you must at all costs bring over database information. You can create a new Nintex Content Database and associate an individual web app to this database. (But I discourage this because when you need to move the data, you must perform some actions on the content to prepare it to move. It is expecting a URL change, which it is, but this will affect production negatively.) But anyway, changing the database architecture will still have its advantages. 

Last note, you cannot restart any workflows that are copied/migrated that were in progress no matter the situation. They must start over. 

‌

‌ ‌

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings