Renaming a Team Project was the most asked feature for Team Foundation Server since 2005, with over six thousands votes on it. Microsoft finally delivered that feature in April, in Visual Studio Online first and then in Team Foundation Server 2015.
Why did it take so long?
Team Foundation Server relies on a set of SQL Server databases, with a quite…complex schema. It wasn’t just about detecting a certain name and replacing it, it is all about GUIDs and the likes. A lot of work was done on the architecture, and more of it client-side.
Client-side? Yes.
When you rename a Team Project in either Visual Studio Online or Team Foundation Server, what happens among the operations is that also you are also creating a redirect from the old Team Project to the same, renamed one.
Take a look:
this Foo Team Project has some work in it:
a query with an explicit value in it (Foo instead of the @Project macro):
and of course some code.
You can then rename it:
and what you’ll need to do is to care about code mappings (workspaces or remotes, this would be best handled by a client update – 2015, 2013.5 or 2012.5). Code is migrated, Builds are migrated, and all the Work Item Tracking migration is completely effortless.
So you say yes, and the Team Project is renamed. Teams with ‘Foo’ in their name are migrated too:
Areas and iterations are migrated too, as expected:
Even the explicit query is migrated!
So what happens if you go straight to Foo?
This:
This doesn’t mean you are going to lose the possibility of using the former name – if you will reuse it, you would just lose the URL redirect but all the renamed artefacts would be kept as-is..
There are a couple of things you need to manually address after this. As mentioned above, you need to sort out the Workspaces or the Git Remotes, depending on the Version Control System you are using.
If you are using a BDT Build Definition with Lab Management, you need to refresh the Build Definition by running the wizard again so it can be properly linked again with the right Team Project. This is actually a workaround which will be solved by the new TFS 2015 Legacy Build Controller, but if you need to use older Controllers that’s how to sort it out.
On-premises, run a ProcessWarehouse job and a ProcessAnalysisDatabase job as soon as possible, so you will avoid any stale data in SSRS and the Excel Services in SharePoint would be already updated with the current names. The jobs would run anyway in the time interval you set, but this will avoid any temporary inconsistency in the reporting data.
Eventually, clear the SharePoint cache and run a SharePoint timer job so the Excel Services are up and running on the right values.