Upgrading your Process Template in Team Foundation Server regardless of the version is pretty hard to achieve. Think of it like changing your mind on the blueprints of a building after you have finished construction. If you are making a small change, like adding a field, then this will be easy. But if you want to fundamentally change the structure of your work items and their workflow then you are looking at a bigger and much more complicated solution.
Here are the 6 7 8 ways to change the Process Template that I have used and all of their pros and cons. Some are easy to implement but may not fit your needs while others have a massive time penalty that you may not be willing to accept. Take my advice and try to implement the simplest solution that you can. Most failed Process Template changes are due to the complexity of the restrictions put in place by folks that don’t actually understand what they are asking for. I will often use the above construction metaphor to help customers understand what we are talking about in lue of a solution from the product team that is currently Under Review: Allow for updating project templates on existing projects in TFS (add your vote if you have any left)
The complexity of the change will depend on the scale and scope of the changes that you have made to your process template and the instance that is used in the Team Project. I would always recommend consolidating your organisation to a single process template as the two evils of maintaining TFS are; Wildly divergent process instances regardless of the original template; what I like to call frankin-templates. Work Items that have been so heavily customised as to be practically unusable by those they are meant for.
There are specific changes, namely worflow and state changes, that will limit your choices severely and you should be aware of all of the ramifications before you make any changes. I would go so far as to say that if you are going to make changes other than just adding some simple fields that you create a set of CodedUI tests for all of your Users paths through the workflow and run a bank of those tests every time you make a change to make sure that you have not broken a necessary activity that folks already use.
If you are making incremental changes to the process that you are already using you can likely upgrade with no issues nor data loss by simply overwriting the new work item types over the old ones. 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:
Sticking with same template is not a good option as everyone wants to take advantage of the new features.
In this scenario you keep the same process template but you “inject” the new platform features. This was done in TFS 2010 with a batch file and in 2012 the Product Team built in a basic capability to the web UI for those that have not modified their process templates much.
Note Does not work if you have made modifications to the workflow
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.
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
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.
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.
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.
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
For me options #7 is the most appropriate for most circumstances and is 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.
If you've made it this far, it's worth connecting with our principal consultant and coach, Martin Hinshelwood, for a 30-minute 'ask me anything' call.
We partner with businesses across diverse industries, including finance, insurance, healthcare, pharmaceuticals, technology, engineering, transportation, hospitality, entertainment, legal, government, and military sectors.