title: Steps for changing process template for an existing project in TFS 2010
body: <p>I have an TFS server installation that through time has gone through upgrades from TFS 2005 to TFS 2008 and then to TFS 2010.
  During the lifetime of the installation a lot of projects have been created and different project templates have been used. MSF Agile 4.0, 4.1, 4.2 and 5.0. and a few MSF CMMI ones.</p>
  
  <p>What I would like to do is "replace" the project template used for all these projects to use a new one common one: Microsoft Visual Studio Scrum 1.0.</p>
  
  <p>I am aware that TFS project templates are used as <em>templates</em> for creating new projects and cannot modify the tfs projects definitions after creation.</p>
  
  <p>Uptil now only the version control and build server part of TFS have been used and there are no existing work item types.</p>
  
  <p>Additionally all projects and build scripts are depending on the source code paths stay the same.</p>
  
  <p>As I see it I have the following options:</p>
  
  <p><strong>Create new TFS projects using the correct project template and then move/branch the source code to the new project.</strong>  </p>
  
  <ol>
  <li>All code is moved to a temporary team project.  </li>
  <li>The old project is deleted  </li>
  <li>New project with the original name and correct process template is created  </li>
  <li>Code is moved to the new team project  </li>
  <li><p>Temporary team project is deleted</p>
  
  <ul>
  <li><p>All the build definitions needs to be to recreated which is not an option.</p></li>
  <li><p>The source code move/branch will "mess up" the versioning history</p></li>
  </ul></li>
  </ol>
  
  <p><img src="https://i.stack.imgur.com/SVezi.jpg" alt="alt text"><br>
  By messing up the versioning history I mean that when you move source code it will behind the scenes do a delete + source rename on the original location and the history will still be located in the old project. This will make searching in the history difficult and if I actually delete the old project I will loose all the history before the source code move.</p>
  
  <p>This is really not an option for me since there is years of code change history that is needed to for supporting the different applications being built.</p>
  
  <p><strong>Use the TFS migration tools to migrate to another TFS project</strong></p>
  
  <ul>
  <li>This has the same downsides as the first solution</li>
  </ul>
  
  <p><strong>Replace/import work item types, install new reports, create new SharePoint sites</strong></p>
  
  <p>For each tfs project</p>
  
  <ul>
  <li><p>Delete existing work item definitions using "witadmin deletewitd"</p></li>
  <li><p>Import each work item definition from the new process template using "witadmin importwitd"</p></li>
  <li><p>Import work item categories using "witadmin importcategories"</p></li>
  <li><p>Delete old reports in project folder in report server</p></li>
  <li><p>Upload the report definitions from the new process template</p></li>
  <li><p>Modify data sources used for the reports using the report manager to point to the correct shared data sources (TfsReportDS and TfsOlapReportsDS)</p></li>
  <li><p>Modify the report parameter ExplicitProject default value to "" (empty string) and disable prompt user option.</p></li>
  <li><p>Export the documents in the old SharePoint site using stsadm</p></li>
  <li><p>Delete the old SharePoint site</p></li>
  <li><p>Recreate the sharepoint site using the TFS2010 Agile Dashboard site template</p></li>
  <li><p>Activate site feature "Team Foundation Server Scrum dashboard"</p></li>
  <li><p>In TFS Project Settings -> Project Portal Settings: Enable "team project portal" and ensure the url is correct. Enable "reports and dashboards refer to data for this team project"</p></li>
  </ul>
  
  <p>And finally..</p>
  
  <ul>
  <li><p>Process the Warehouse</p></li>
  <li><p>Process the Analysis Database</p></li>
  </ul>
  
  <p>Even though that this involves a lot of small steps this looks more appealing because
  this option will not force me to move the source code and my existing build definitions will be intact.</p>
  
  <p><strong>My question:</strong></p>
  
  <p>Are there other ways to achieve the replacement of work item types that I haven't mentioned?</p>
  
  <p>And/or am I missing any steps in last solution?</p>