Share via

TFS Upgrade - Long Lead Checklist

  • Article

This is a set of preparations where you plan, research and gather information so you are fully prepared to upgrade.

 

Step

Instructions

1 – Review current guide ꙱ - Done
  • Review the current upgrade documentation here.

2 - Schedule meetings ꙱ - Done
  • Schedule the migration planning meetings: Timing, Roles and Preparations.
  • You must plan these meetings between the stakeholders well in advance in order to encourage collaboration and stay on schedule.

3 - Plan server topology ꙱ - Done
  • Take some time to consider your current server topology and whether it is meeting your needs.
  • Draw up a detailed design of new infrastructure if you are planning a migration as well as an upgrade. Even though TFS can have a simple topology, when you factor in Reporting Services, SharePoint and build servers, a design is worth the investment in time.

4 - Update environments ꙱ - Done
  • Update the environment versions, service packs and appropriate hotfixes for Windows OS, SQL Server, TFS, SharePoint and Client software.
  • Verify that all environments, including legacy and third party components, are compatible with the new version of TFS you wish to upgrade to.

5 - Research and plan TPC ꙱ - Done
  • Each TFS instance can have one or more Team Project Collections, which are the basic unit of recovery and isolation for TFS. See TFS Planning and DR Avoidance Guide for more information.
  • Even though Team Project Collections were designed for internet-scale hosting facilities, if your databases are getting very large — to the point where backup and movement of data is getting risky - it might be a good time to break up the database into multiple collections.

6 - Validate accounts ꙱ - Done
  • For installing TFS 2015, TF Build or TFS Proxy, use service accounts:
  • As a best practice, TFS service accounts should not be members of the Windows Local Administrators group on the server where TFS is installed.

NOTE: By default, every component uses a built-in account (such as Network Service) as its service account. You can change this account to a user account when you install the component, but you must ensure that any user accounts that you use have the Log on as a service permission.

  • If you use domain accounts for your service accounts, you should use a different identity for the report reader account.
  • If you are installing a component in a workgroup, you must use local accounts for service accounts.
  • For more info, read the Accounts required for installation of Team Foundation Server MSDN article.

7 - Test builds ꙱ - Done
  • Your test plan should include everything that’s needed for a smooth migration to a new version of TFS. The upgrade tools can port existing build definitions, but you should consider other factors as well, such as:
    • Do you want to install additional components on build machines?
    • Would you ever re-configure using batch or PS scripts for post-build events?
    • What about security permissions for pre- or post-build execution, such as folder/cache cleanup, IIS deployment, IIS reset, SQL DB access, and so forth?
  • New build servers might be moving from 32-bit to 64-bit.  If there are Java builds involved, there might be new TF build extension targets that have new versions. References to them might require new references.

8 - Review ports ꙱ - Done
  • Review required ports and make sure the network team acknowledges that all are open in the target environment. You can find more information here.

Related Posts

Authored by Mike Abrahamson
clip_image002_thumb[1] Mike is a Principle Consultant, based in Minnesota focusing on Application Lifecycle Management. Mike has Enterprise level experience leading ALM projects that help customers use Team Foundation Server to enable their business and ALM processes. Mike focuses on defining and delivering software solutions with an emphasis on process maturity and quality throughout the software development lifecycle.