3

We're currently using TFS 2010 for both source control as well as task tracking however the structure of both our projects and project collections leaves quite a bit to be desired. That being said, we're looking to restructure everything in a more efficient way when we move to TFS 2012.

My question is this, is it possible to move our existing projects into a new TFS 2012 project collection (including work items, tasks, etc.) for legacy/historical purposes? I'd like to have the current project structure and history available for historical purposes with active development on-going in a different project collection using our new project structure.

Everything I've seen so far suggests that its difficult (or impossible) to move entire projects between collections due to work item numbering, etc. I've considered detaching our 2010 project collections and re-attaching them individually in 2012 but I really don't want a whole list of project collections (which is part of our current problem). That then brings me to the challenge of merging project collections or moving a project between collections.

Any suggestions, work-arounds or tips would be greatly appreciated! Thanks in advance!

Mark
  • 61
  • 1
  • 3

3 Answers3

5

This is very much possible with TFS Integration Toolkit but it is extremely tedious and time consuming process. There is a learning curve. Tool is buggy so you have to work around it. I recommend don't get into it unless it's a high priority for team/management. Here is the procedure, do clean TFS 2012 install and then migrate work items and source using this tool. Make sure you also install TFS 2010 team explorer along with toolkit (it uses 2010 object model to migrate). You should setup a test environment and try it multiple times to achieve desired results. This item was raised numerous times for TFS 2008->2010 and you can pretty much follow same guidelines. See my response here. You may not be able to migrate work item IDs but can add a field to show old work item ID: 

<FIELD name="BCIReflectedWorkItemId" refname="TfsMigrationTool.ReflectedWorkItemId" type="String" />

Tool Limitations from documentation:

  • Limited to migrating only Version Control items, Work Items, and the links between them. Other portions of Team Projects are not migrated by this tool, including Reports, Team Build data, and SharePoint content.
  • Work Item IDs and Changeset numbers are not preserved during migration and new IDs are assigned sequentially as items are migrated. This implies that any references to these IDs will be invalid after migration; however, the links between work items and changesets will be migrated correctly, despite the ID changes.
  • Timestamps on work item revisions and changesets will be updated to the time of migration. Any work item fields that store date time information will have their values correctly migrated, but the time of the revision will not be migrated. The most significant impact this has on a system is in reports that rely on a time dimension (i.e. Bug Trends, Code Churn). Because the migration typically occurs over a much shorter time span than the original operations, the time axis in such reports will effectively be compressed.
  • Work Items of type Test Case are not migrated completely. The Integration Tools are not designed to migrate Test Cases at this stage. They need to be identified as Test Cases and processed as such; including the special XML encoded data fields, which should be cracked open and edited to point to the newly migrated work items. You could review the Visual Studio 2010 Test Case Import Utilities at http://tcmimport.codeplex.com/ as an alternative.
Community
  • 1
  • 1
Manish Jain
  • 9,569
  • 5
  • 39
  • 44
1

There is unfortunately no built-in way to move projects between collections while maintaining all of the historical data. There are tools to migrate projects, but they drop check-in notes, shelvesets, workspaces, etc.

See Moving a Team Project from one Collection to another

Community
  • 1
  • 1
Russ Amos
  • 419
  • 3
  • 9
0

The safest, and simplest way is to simply back everything up from 2010, and start 2012 with a clean slate. Document where everything from before the migration can be found, put your projects where you need them and move forward. It seems strange, and people fight against doing something like this but usually when they do they are quite happy with it.

Also, a great way to avoid this problem in the future is to minimize (or eliminate entirely) the use of multiple collections and use areas instead.

Andrew Clear
  • 7,910
  • 5
  • 27
  • 35