We are upgrading from TFS2013 (current prod) to TFS2017. The new server will have the same name (via dns alias) as the original one.
1. We will create a test 2017 upgrade box with name and IDs different from the 2013 box but with the same project collections\projects. Both boxes will be running on the network. Devs will likely be accessing the same
projects on the test 2017 server as on the 2013 server. How do we avoid things getting corrupted/confused? Does each dev need to create a workspace just for the Test -- or is that not enough?
2. Should devs checkin (or shelveset) all code before the prod upgrade is started?
3. In fact, should we create special user accounts for testing to avoided devs using their own accounts?
4. Are there any client-side TFS caches that users should clear?
Before you do production upgrade, developers need to check-in their code to TFS 2013. When do the production upgrade, you need to back up the TFS 2013 database, then restore it to TFS 2017 database.
Pre-production upgrade is just used to test whether you could upgrade your earlier version TFS to a later version successfully. The test TFS 2017 is a different server from the 2017 production server. It doesn’t matter which accounts you need to test.
When you upgrade your pre-production environment using the same steps you will use to upgrade production. Make sure you remember to use a service account which has no permissions in your production environment.
For question 4,5, you don’t need to clear the browser cache.
MSDN Community Support
Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to
MSDN Support, feel free to contact MSDNFSF@microsoft.com.