Upgrading your Process Template in Team Foundation Server



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.

  • Update 2012-05 – Added #7 to the list
  • Update 2012-12 – Fixed layout and omissions noted by Jesse Houwing
  • Update 2012-12 – Updated for TFS 2012

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:

#1 Do nothing (0 hours)

Lazy the Smurph

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
  • Con You have to use the old template

    Note this is not a con unless there is some feature that people want

#1.1 Enable new features only (5 minutes)

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.

  • Pro Little or no work to achieve
  • Con Same old process in new clothing

Note Does not work if you have made modifications to the workflow

#2 Create a new Team Project (.5 hours)

Ripped scroll

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
  • Con 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

  • Con 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
  • Con 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)

a distorted clock

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
  • Con 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)

One way sign with a double ended arrow

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
  • Con 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.

One arrow going up and another going down

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
  • Con 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) (Recommended)

trophyIn 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 #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.

Upcoming Training Opportunities

These are the next five classes we have, and you can check out our full public schedule of classes.

Live Virtual Product Backlog Management Skills with Joanna on 14th December 2023
Virtual Traditional
14-15 Dec, 2023
09:00-13:00 CET
2 half-days
Immersive Professional Agile Leadership Essentials with Joanna on 12th January 2024
Virtual Immersive
12 Jan-1 Jan, 2024
13:00-17:00 GMT
8 weekly half-days
Immersive Professional Scrum Product Owner with Martin on 17th January 2024
Virtual Immersive
17 Jan-6 Jan, 2024
13:00-17:00 GMT
8 weekly half-days
Immersive Professional Scrum Master (PSM) with Dan on 17th January 2024
Virtual Immersive
17 Jan-28 Jan, 2024
13:00-17:00 GMT
7 weekly half-days

We can deliver any of our courses as private in-house training over Microsoft Teams & Mural. We also recommend training based on your accountabilities or role, you can go directly to recommended courses for Scrum MastersProduct OwnersDevelopers and Agile Leaders.

Create a conversation around this article

Share on Facebook
Share on Twitter
Share on Linkdin

Related Courses

No items found

Read more

Martin Hinshelwood NKDAgility.com
https://youtube.com/shorts/Ce5pFwG5IAY Scrum Masters: Unlocking the Power of Liberating Structures 🚀  In the dynamic world of Agile and Scrum, Scrum Masters are continuously seeking innovative ways to enhance collaboration and effectiveness within their teams.  Introduction: Embracing Liberating Structures in Scrum  One transformative approach that’s gaining traction is the use of liberating …
Martin Hinshelwood NKDAgility.com
Business Leaders face a key challenge when scaling their organisations effectively while maintaining the distinctiveness that made us successful in the first place. Many frameworks and methodologies, such as Scaled Agile Framework (SAFe) or the Spotify Model, promise a structured approach to scaling, but do they genuinely fit our unique …
Martin Hinshelwood NKDAgility.com
As we inch further into the dynamic landscape of the 21st century, our long-established Alpha organisations stand on shaky ground. The organisations whose DNA is infused with strict command and control, woven into the fabric of every process, are feeling the tremors of a rapidly evolving, technologically charged market. Not …
Martin Hinshelwood NKDAgility.com
Under the ruthless canopy of the red market, I find myself staring at the bloated behemoth of an Alpha organisation, huffing and puffing in a vain attempt to keep up with the frenzied pace of the modern world. The Alpha model, once a paragon of order and efficiency in the …


We believe that every company deserves high quality software delivered on a regular cadence that meets its customers needs. Our goal is to help you reduce your cycle time, improve your time to market, and minimise any organisational friction in achieving your goals.

naked Agility Limited is a professional company that offers training, coaching, mentoring, and facilitation to help people and teams evolve, integrate, and continuously improve.

We recognise the positive impact that a happy AND motivated workforce, that has purpose, has on client experience. We help change mindsets towards a people-first culture where everyone encourages others to learn and grow. The resulting divergent thinking leads to many different ideas and opportunities for the success of the organisation.