We have a small/medium size SP 2010 farm with 6 or 7 web applications. The size of the content dbs dictates that we will need to make the migration to SharePoint (and Nintex WF) 2013 over a couple/few weekends instead of all at once. I will be splitting up the NW2010 db into a 1:1 mapping to our web applications. My question is, if I need to bring over the Nintex configuration database, along with the first web application's content db and Nintex content db, how will I move forward with the subsequent web application upgrades? My assumption is that at that point I cannot again bring over the Nintex configuration db from the 2010 farm since the config db on the 2013 farm will already be holding information about that environment.
Solved! Go to Solution.
You can have a NW content database per site collection, like you can with SP Content Databases.
Then, it's easier to move one or a few site collections at a time from 2010 to 2013.
The steps to split a single NW content/configuration database, into multiple content database is quite straightforward and will make it easier to do bit by bit migration.
Thanks so much for your response, Vadim! I am pretty clear on splitting out the Nintex content by site collection and remapping the databases. Where I was a bit unsure was specifically with the Nintex configuration db. Rereading some of the linked articles which I've been working with, the situation seems a bit more clear. Maybe you can tell me if this is a true statement. When I first begin migrating to the Dev 2013 farm and bring over and upgrade the Nintex 2010 configuration database, that obviously becomes the new configuration database in 2013. The important bit I think, is that at that point, I am all set with my Nintex Workflow 2013 configuration database. Is that accurate? I can then move forward with bringing over the 1 to 1 matched SharePoint and Nintex content dbs over the following days or weeks without concern about the configuration database?
Thanks again for your help,
You are correct. The Nintex config DB is farm specific, not content db specific. Therefore you will have a config database for each farm both 2010 and 2013. You will also need a separate license for each farm as well so I would ensure that is planned out well.
I would first work to get that established and get Nintex working then migrate a web app, content database and nintex db. This should bring over and update all the proper mappings for that content. The content in this case will be mapped to the content database and the nintex database simply retains the workflow information pertinent to that content.
You can then repeat this for each content database and nintex database as you desire.
Hope that helps.
Thanks so much Ed; I appreciate you taking the time to respond and confirm. We do have a NIntex Development license for our development farm and will be sure to have our production licensing needs planned with Nintex well before our production migration.
Hi, I am looking for something like this solution, we also want to make the migration gradually, I checked the links you gave and found them very useful but I have another doubt, I think our Nintex configuration database is also the content database, but if we are going to migrate the configuration database just once because it is farm specific, it will also have the content data from the sites right? if so wouldn't it create a conflict with the GUIDs? and also we would have duplicate data.
Is there a way to separate and backup the Nintex configuration database?