Upgrading Geodatabase from 10.2.2 to 10.5

[AdamCrateau1]

We are upgrading an enterprise GDB from 10.2.2 to 10.5, and also migrating the db from SqlServer 2012 to 2016.  

What is the best workflow for upgrading And migrating an enterprise GDB?  Should we upgrade the GDB in place before migrating to a new SqlServer?

[JayantaPoddar]

Check the steps and prerequisites in Upgrade an enterprise geodatabase in SQL Server—Help | ArcGIS Desktop 

[AdamCrateau1]

Thanks Jayanta,  I have looked at that document which is great for the upgrade portion.  So, would you recommend upgrading the DB before or after migrating it to Sql2016?

[RebeccaStrauch__GISP]

We are in the testing phase for a similar move.  We are testing since there are other factors changing for us (i.e. physical location, virtual, etc) that we want to test with our editing workflow before update our production. Besides the official doc Jayanta Poddar mention, for what it is worth, I'll add our current experience.

We are using SQL's backup and restore to move/create the SDE database from our SQL2008 to our new SQL box (2012 or 2014?).  We are not jumping to 2016 since I have seen a few threads about < 10.5.x clients maybe having issues. 

The backup/restore process with keep the SDE name the same as the source SDE, but some of the user names and access needed to be tweaked (or maybe not for the restore version, but for the new??  we did this 2 weeks ago, and I was out last week). Unfortunately, that is now being done by our IT hidden from me, so I'm not 100% what they had to do.....but I have seen a couple threads in the past few weeks talking about SDE permissions that should help.

Anyway, I had them backup/restore the database as a 10.2.x SDE.   Before testing the "upgrading" in place, I created a couple more SDE databases (one as 10.3.1 and eventually one as 10.5.x) and did a copy and paste.  All seems to work.

The snag I ran into with authorizing the new SDE databases is locating the keycode file needed.  For us, this was located on our ArcGIS Server machine c:\Program Files\ESRI\License10.2\sysgen     That may save you some time.

EDIT: just saw your other question...my opinion.....move it as the current version....upgrade after.

[AdamCrateau1]

Excellent, thanks for the insight Rebecca.  

Our SDE is setup with the DBO schema, so sounds like we may end up troubleshooting some different things than what you're seeing.  We have a Dev Server we'll use to test restoring the DB to, and I'll do as you suggest by moving it first and then test upgrading.  I'll make a note to report back once we have some results.

[RebeccaStrauch__GISP]

Ours is also DBO schema.   Nice thing about SDE is you can spin up as many databases as you need and you SQL allows.  Always best to test this way, then when happy with the process, you can recreate a "clean" production version.  At least that is what I'm doing.

[ScottFierro2]

Agree with Rebecca Strauch, GISP‌ and that mirrors our workflow which we have finished with testing and moving to production. We took a 10.2.2 and a 10.3.1 DB both on SQL 2012 boxes and did backup/restore to SQL 2016 boxes that we have now gone to a high availability cluster on the SQL side with failover and DB side replication across the 2 VM's in the cluster and post restore we performed the upgrade to 10.5. The only caveat for anyone going this route do the restore to 1 VM perform the upgrade by direct connecting to the VM directly or you can use the clustered DNS connection but not have the DB replicated to the second server and once the upgrade is done to the first server then use SQL to replicate the DB to the next server because attempting to upgrade with active clustering in place doesn't work. We also have spun up an extra 10.5 DB in the new SQL environment from scratch as we had a need for pulling 1 schema out of the 10.2.2 DB into a DB of it's own. All DBO schema for us.

So can't guarantee our configs are the same and for most they won't be as we are constantly pushing and breaking ESRI limits or back dooring ESRI processes from the SQL side of things but can say it does work. Can read into some of this SQL clustering configs though for any interested here: https://msdn.microsoft.com/en-us/library/ms189910.aspx