We are about to upgrade our TFS 2015 environment to TFS 2017. However, in the process, we are also upgrading the hardware, so we stood up a separate new TFS environment (new app server + new database server). We have a public URL registered to something like http://tfs.ourcompany.com and want to continue using the same URL post migration.
My question is, how will this affect Visual Studio users who already have mapped local workspaces to TFS 2015 using tfs.ourcompany.com?
So, to be clear, the goal is to go from:
Visual Studio 2015 --> C:\MyLocalWorkspace --> TFS 2015 via tfs.ourcompany.com
...to:
Visual Studio 2015 --> C:\MyLocalWorkspace --> TFS 2017 via tfs.ourcompany.com
What's the least disruptive way to achieve this?
Each TFS server has a unique identifier(GUIDs) that is used to represent each collection and is not dependent on the server "name." The upgrade/migration does not modify the TFS GUIDs.
For that reason, all end-users have to do is connect to the TFS server via Visual Studio and can resume work, including any pending changes.
Besides, if you have problems with workspaces, TFS Sidekicks is a really useful tool because it gives you a nice GUI tool to list, check, delete and manage all workspaces defined in your TFS. (Need Administrative privilege)