Question

In our current project we have four different TFS2010 Team Projects in the same Team Project Collection. The reason for this is that different parts of the project wanted to use different team project templates (CMMI vs Agile).

All projects now use the same template. Therefore we have now reached the conclusion that it would be better to merge the projects into a single team project. This raises several questions:

1. Is it possible / feasible to use one of the existing projects as the target project for the other three?
2. How do we move our existing work items into the new project whilst maintaining our area tree? We hope to create one root area for each of our existing team projects, and move all work items / areas underneath this root node.
3. Today we have work item links from one team projects into another – how do we keep these links when merging?
4. What is the best practice when moving the source code? One clear approach is to simply copy it to the new location, and locking and keeping the old team projects in case we need to access older versions of the code. But is it feasible to use branching for this, e.g. branching all existing code to the new team project? What kind of problems might this approach cause?

Thanks for your help!

Answer 1

Unfortunately, TFS 2010 doesn’t allow you to merge team projects.

Stucturing Team Projects and Team Project Collections is one of the most important strategy decisions to make before starting to use TFS. Unfortunately, a lot of the customers we help don’t make the up-front planning necessary and don’t understand some of the limitations in TFS around merging, moving, splitting, etc. team projects before they start diving in to using TFS 🙁

When we have consulting engagements where customers want to consolidate their team projects, we end up having to do a lot of manual work to migrate the artifacts. We have built some tools to help us with this process for work items but for the most part it’s a lot of tedious consulting work. The migration utilities always end up needing to be customized for each customer as well since they usually have different business rules for how they want to migrate.

Ultimately, a “migration” doesn’t end up bringing over all of the information and you end up with some other problems like date/time stamps being different from what they were originally. (I have heard it referred to as a time compression issue with migrations.)

Some additional thoughts for each of your original questions:

1. Sure, you could theoretically use one of the existing team projects as the target for the migration of the other three. As long as you like the team project name and don’t want to rename the team project. 🙂
2. This is where we have built custom work item migration utilities to assist our consulting customers. You would likely need to do the same.
3. This is possible as well with a custom work item migration utility. You can just keep track of the mappings between old work item IDs and new work item IDs and then add the links later once all of the new work items are created in the target team project.
4. That’s ultimately up to you. I would do a “move” version control operation on the source code from the old team project to the new team project. This maintains everything. However, I would not delete any of the old team projects because that will cause the version control history to be destroyed as well.

It’s not the best story for you but hopefully it will help your planning out some!