Upgrading your Process Template in Team Foundation Server

There are 67 ways to change the Process Template that you are using on your team projects and they all have their pros and cons.

• Updated: 2012-05 – Added #7 to the list

If you have made small or even sometimes large changes to the process that you are already using you can likely upgrade with no issues nor data loss by simply overwriting a work item type. However, if you are making large fundamental changes to the way that the template works (e.g. SfTSv2 to MSF Agile 5.0) then you need another approach:

1. Do nothing (0 hours)
   Sticking with same template is not a good option as everyone wants to take advantage of the new features .
   • Pro: Little or no work to achieve
   • Cons: You have to use the old template
     note: this is not a con unless there is some feature that people want
2. Create a new Team Project (.5 hours)
   This is tantamount to doing nothing, but you are using the new process template. You just have to be willing to leave all of your data behind. The real problem here is that with TFS 2010 a “move” or “rename” of files actually results in a “branch” and then a “delete” action that breaks the history chain for folders. The history is still intact, but it only exists on the old Team Project and is deleted or if the permissions are changed then the history is lost.
   • Pro: Minimal commitment
   • Pro:Retain access to historical reporting
   • Cons: You are leaving your history behind on the old project
     note: reports may be different anyway so this may not be such a bad idea for WI
   • Cons: You have to do a move (“Branch” + “Delete”) operation and disconnect you history
     note: This really sucks for version control
3. Destroy all Work Items and Import new ones (2-3 hours)

   In this scenario you loose all existing Work Item data, but you have not moved your source code, so no nasty history chain.

   How-To: Process Template Upgrade #3 – Destroy all Work Items and Import new ones

   • Pro: New template with clean data
   • Pro: no disconnect of version control history
   • Cons: No history on work items (all existing data is lost)
4. Use the TFS Integration Platform to move Source and Work Item history to a new team project (1-2 days) (RECOMMENDED)
   This is an ideal solution, but it does result in “time dilation” on your source control. There is no way to fake a check-in date so all dates will be when the actual check-in happens. As the TFS Integration Platform does all of the check-ins concurrently it stores the original date in the comment.
   • Pro: Keeps all history for both Work Items and Version Control
   • Cons: Time dilation effect, rather like traveling to Alpha Centauri at Light speed; this affects both Work Item and Version Control
     note: there are ways to fix this for work items and reporting
     note: If you care about this for Version Control you are likely doing something wrong!
5. Do an in place manual migration (1-¥ days)
   This is just plane nasty and take a lot of time. It can take over 8 hours to complete the migration once it has been planned out, and that time depends on the process template you are moving from, the one you are moving to, and the customisations you have made along the way. If all of your Team Projects have different customisations, then this is probably a non-starter.
   • Pro: Keeps all of your data intact with renames of fields and work item types
   • Cons: Takes a really, really long time
     note: There are many circumstance where this is not possible
     note: Even our most technical TFS Consultant takes 1-2 days to do this (I have never done this)
6. Do an in-place export migration.
   This gives us the best of both worlds, with an export of Work Item data to another location, destroying all the existing work item types along with all of the data, then install the new Work Item Types and reload the data. This is still a horrible process, but it keeps the Source Code history intact, and allows for the process template to be completely upgraded.
• Pro: Keeps all of your data intact will a small modification to fix time dilation on work items
• Cons: Takes a really, really long time
  note: There are many circumstance where this is not possible
  note: Even our most technical TFS Consultant takes 1-2 days to do this (I have never done this)

7. Rename Work Items and Import new ones (4-5 hours)
   In this scenario you get to keep all of the history in tact and also get to start afresh with new work item types. It is almost the best of both worlds as you don’t need to move Source Control nor do you end up with new Work Item ID’s.

   How-To: Process Template Upgrade #7 – Overwrite retaining history with limited migration

   • Pro: New template with clean data
   • Pro: no disconnect of version control history
   • Pro: history on work items (all existing data accessible through history tab)
   • Con: leaves old legacy fields in the template

   
   

For me options #4 and #6 are the most appropriate for most circumstances and are part of my default arsenal. The rest I only use if I have to, but if a customer is happy with #1, #2 or #3 then I am unlikely to argue as they are easy to implement. That said the one for me that balances ease with functionality is #4 as you get all of your data in a clean format.

• How have you moved from one Process Template to another?

We want your stories…