Merging Team Projects in TFS: general approach

In my last post I talked about why I had to plan a big “unification” of many team projects. Now we’ll start having a look on what we need in a more detailed way.

In short : the plan is to create a clean new team project, and move (or copy) everything we need into it. It’s kind of a big migration.

What is the scope of the migration ?

A team project encompasses the following aspects :

  • Work Items and their definitions
  • Source control folders and their branches
    • This means all Workspaces will have to be recreated!
  • Build definitions and their history
  • Reports definitions
  • Alerts subscriptions
  • Work item queries, personal and team queries

Overall goal and constraints

With more than 150 people using TFS every day, it was out of question to interrupt the server during day work time, so all the final migration steps had to be done during the week end.

That means everything had to be carefully prepared and tested. Most of the work items have been already copied and ready before the final week end. We’ll see that the volume of work item to migrate is important and requires several days to migrate.

The source control folders were also an issue, since there were many branches to migrate, copying or moving branches would lose all of the merges history (between each pair of branches). Well, this was *the* occasion to reset all branches history and recreate all of them from the Main branch. I’ll talk about it later.

To summarize :

  • No interruption of service
  • The migration was the occasion start over with new clean branch structure (which simplifies migration a lot)
  • Complete migration of work items history
  • Builds have to be recreated in the new project, it is ok to lose their history in the process
  • No special reporting needs

What is the global strategy for each of those elements ?

Work Items

This is, with the source controller, the biggest part, and by far, the most time consuming for the TFS admins.

First I had to rationalize work item definitions, then plan the migration of more than 120.000 Work Items. This took me weeks… I’ll post about this specific topic in the near future.

The deal was also to assign correct Areas to all imported work items.

Branches and sources

Luckily, we could negotiate to lose any merge history between the branches. So we could import every Main branch in one single big Main branch, then “branch” the other branches from there. Any evolution in the Dev branch had to be manually redone from there. Again, I’ll develop this point later.


We had to write a small utility to recreate all the builds and transpose the paths.


This was easy since we did not customize any report, and all the process templates were based on Microsoft CMMI, there was nothing really special to perform.

Alerts, Workspaces, WI Queries…

Well, we had plan to actively assist people with those, we actually ended up in writing a very small guide with proper steps to get their Alerts back, to recreate their Queries (with examples) and more importantly, the new bible on how to create a proper Workspace.

So all those aspects were covered manually.

A word on security…

Security has also to be updated in a bunch of places.

In TFS you have to configure security in :

  • The source control folders
  • The work Item areas (to define accessibility of work items within one single team project)
  • SharePoint and Reports (but we did not bother since we have basic use of those)

You’ll want to use local groups (groups defined in TFS), and put in these groups AD groups. On that point my client was mature, and security was easier to manage than I first expected.


Now, the overall strategy is set, we’ll see the issues with work items, sources and builds in the next posts. Stay tuned Smile

Why should I consider merging my Team Projects in TFS 2010

Recently I just had the occasion to merge 14 Team Projects into a very big one.

Why merging Team Projects ? Well, there is actually a debate on how to use them, how do you map your projects and deliverables with Team Projects. Martin Hinselwood did summarize the pros and cons of what he calls using “projects of projects “ in TFS, I frequently refer to these pages :


Moving to one single big project is worth it…

So, why should we do it ? And above all, is it really worth it ? In my client’s case, all the teams were actually working on one very big project, composed of many deliverables, but still, the overall goal for everyone was one very big Web site. Teams are all synchronized to allow the main application to be delivered according to a well-known schedule. If you are aware of the above mentioned pages, you know it is quite feasible to manage many individual deliverables within the same Team Project (mainly by using well Areas and Iterations), having multiple projects that converge into one big production platform is enough for me to push forward the use of one single Team Project. It does make sense. There are natural connections (mainly dependencies), between work items. Backlog items often span over multiple “projects”.

…but this is not for the faint hearted

First off, I would like to warn you that merging team projects is a costly operation when you want to do it smoothly, it requires a lot of preparation, and a qualification environment to fully test the operation if you don’t want your developers to be blocked the day after.

A second warning, using only one Team Project requires a bit of knowledge of TFS.

Here we go for the Pros and Cons in my case.


  • A Homogenous “process template”, Work Items definitions are shared by everyone. That means common practices, and this point only brings another interesting set of pros :
    • Simplified maintenance
    • Smaller learning curve for new developersimage
    • Developers can switch teams in a smoother way (no new stuff to learn)
    • Rules and constraints are set up much faster
  • A common set of branches : in our cases, there many dependencies and tightly coupled code was often spanning over multiple root folders, bringing all projects in the same branch structure allowed :
    • Simpler integration steps between Dev, Main and Release branches (and others…)
    • Still being able to integrate projects one by one when needed
  • Flexibility for renaming projects and moving work items


  • Areas are no longer an option : if you want reports be based on areas, you need everyone to properly fill up this work item field
  • One single process template does not allow for exotic projects needs
  • Because of the common branch structure, you can’t branch an individual project without being seen by all teams (although not a big deal
  • Security had to be revisited, well, that was needed anyway
  • The SharePoint portal… well… it was not even used by developers since there was another SharePoint portal running even before TFS was first installed


Next post we’ll have a look on how to do it.