You may want to change it to a question since they tend to get more activity...unless you are just looking for a discussion. (I can do that if it doesn't allow you to do it)
We have a very similar process that we hope to do next month (mid-July.) so I'm interested in the topic too . The differences are we are moving to 2014 (since I'm not sure 2016 is compatible ??), and we don't have active field crews. If you have the luxury of at least a few days to backup/restore a code of the database from you 2008 to 2016 machine, I highly recommend doing as much of that testing as possible before you do the real switch.
For the tests we have done with our "master" which includes versioning, topology, etc., we have done a full backup from the 2008 and then a restore on the new SQL 2014 machine. I believe that is the recommended process. That part was done by our IT folks so I can't offer any technical specifics. In prep, I did reconcile/post, remove versions, compress etc. and got the version state back to zero for a clean backup. That may not be possible if you have active field crews.
There is no harm though with going thru this process, with the restore on the new machine, for testing. Just keep in mind that it will not have all the current updates until you are ready to make the switch real, but it is a good way to be able to create/test you new connections, tests you processes and scripts, etc. without harming your master/active database. Keep in mind, the restore will come in with the same name as your old database, so this is all assuming that this is a separate machine.
For some smaller databases, a simple copy/paste between the connected databases using ArcCatalog worked. This would need to be done from ArcCatalog 10.3.1 since 10.5.x would not be able to connect to the older 2008 database. But once you have a copy of the database on the 2016 machine, you can repeat this using either version.
Because of the "same restore name" on restore, I actually did both methods, and left the restored as 10.3.1, and created several empty database to do a copy and paste. Using this method, if you are using ArcCatalog 10.5.x, for the copy, the paste will be a 10.5.x (i.e. auto upgraded), but if you use 10.3.1 (and I assume if the source is still 10.3.1), it will still be 10.3.1 until you upgrade it.
We haven't done anything real in the test database yet, but so far most things have worked well. Once we are ready to make the push we will delete all the test databases, do a clean backup/restore and switch over all the connections. If the .sde file name remains the same, I'm hoping that all out map docs, etc will smoothly transition.
We are also dealing with our server being moved from across the street to a different city with poor network speed, so we will have to deal with remote desktops for editing....no other "distributed" or check-out/check-in method was feasible with the topology rules, etc. we had in place. I'm assuming it was just the network speed and not anything with 10.5.
This isn't answering any of your specific questions, but trying to stress....test if you can...so you know what to expect. That will reduce any downtime when you do the switch. Might be obvious, but I know is helping me get things setup properly for us.
