2

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:

Pre-Migration/Upgrade

Visual Studio 2015 --> C:\MyLocalWorkspace --> TFS 2015 via tfs.ourcompany.com

...to:

Post-Migration/Upgrade

Visual Studio 2015 --> C:\MyLocalWorkspace --> TFS 2017 via tfs.ourcompany.com

What's the least disruptive way to achieve this?

Jiveman
  • 1,022
  • 1
  • 13
  • 30

1 Answers1

1

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)

PatrickLu-MSFT
  • 49,478
  • 5
  • 35
  • 62
  • Hmm, what about the fact that the team collections are not only being migrated to another server, but also upgraded in the process? Would that cause Visual Studio to freak out or would it simply resume as if nothing happened? – Jiveman Apr 26 '17 at 14:43
  • On a related note, yesterday I tried a test by modifying my local machine's HOSTS file, and mapping `tfs.ourcompany.com` to the TFS2017 server's IP. When I closed and reopened VS, it automatically connected to the new TFS server just fine (based on the preexisting server connection that was there before), but my folder mappings were gone. – Jiveman Apr 26 '17 at 14:45
  • @Jiveman Upgrading a TFS with backup and restore preserves everything, migrated TFS instance still contains old workspaces. The mapping relationship is stored in TFS database. If the mapping is lost, you could just try to remap it. If remapping is not work, the worst-case scenario is deleting the old workspace and simply tell users to recreate workspaces pointing to the new server. Delete workspace will not lose any data, you can get them from server after create new workspace. – PatrickLu-MSFT Apr 27 '17 at 13:56
  • Not sure why changing local machine's HOSTS file will lose folder mappings. On the top of the source control explorer window, there should be a Workspace dropdown. Double check if you have select the right old workspace from that dropdown. Use [tf workspaces command](https://www.visualstudio.com/en-us/docs/tfvc/workspaces-command) to display information about workspaces on the current computer, try to remap or update workspace. – PatrickLu-MSFT Apr 27 '17 at 14:21
  • 1
    We just performed the actual migration this morning. Things worked as you described. The workspaces were fine. For some reason, the trail with the hosts file behaved differently from what actually happened in the end, so I guess it wasn't truly representative of the real migration. – Jiveman Apr 27 '17 at 16:39