Read through the current installation guide from MSDN – Download the latest installation guide from the MSDN and go through the same.
Schedule Migration – Plan well in advance and also update all the people who will be affected by the upgrade about the schedule and progress of the upgrade.
Plan the new server topology – Depending on the upgrade mode you may end up using the same server or using a new server for running TFS. It is best to plan the new server after considering all the features that we are going to use – reporting, SharePoint etc.
Update source and target environment versions – Update the following to meet the version requirements for TFS 2012
1. Windows OS – http://msdn.microsoft.com/en-us/library/vstudio/dd578592.aspx
2. SQL Server – http://msdn.microsoft.com/en-us/library/vstudio/dd631889.aspx
3. SharePoint -http://msdn.microsoft.com/en-us/library/vstudio/hh667648.aspx
4. Clients – legacy Visual Studio versions could require an update to communicate with the new version of Team Foundation Server. Client compatibility matrix – http://msdn.microsoft.com/en-us/library/vstudio/dd997788.aspx
Also, you might have to update any homegrown tools so that they will work with the new APIs.
Best Practice Analyzer- Run the Best Practice Analyzer tool on the old and the new topologies. This will help in
· Verify that the deployment for Team Foundation Server is configured according to recommended best practices
· Identify the source of problems in an unhealthy deployment
User accounts needed – Generally the following accounts are needed, but all the accounts are optional (depends on the TFS environment used) –
· Reporting – TFSREPORTS
· Team Foundation Server – TFSSERVICE
· Team Foundation Build – TFSBUILD
· Team Foundation Server Proxy – TFSPROXY
· SharePoint Products – WSSSERVICE
· SQL Server – SQLSERVICE
Identify and document the needed accounts and their memberships. For more info on the accounts needed and their permissions click http://msdn.microsoft.com/en-us/library/ms253149.aspx
None of the accounts should belong to the Administrators security group. 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 user accounts.
Review required ports – Review required ports and make sure the network team acknowledges that all are open in the target environment. The list of ports are available in http://msdn.microsoft.com/en-us/library/dd578664.aspx
Research and plan any changes to security groups – Many times, the existing Team Foundation Server servers were not implemented with the recommended Complete Task Details AD security group guidelines and might have leveraged local server groups on the Team Foundation servers themselves. This isn’t possible when the new environment is load balanced.
Test and update builds – Even though the upgrade tools for Team Foundation Server can port existing build definitions to work with the new version of Team Foundation Server, there could be other factors that need to be addressed. New build servers might be moving from 32-bit to 64-bit. If there are Java builds involved there might be new Team Foundation Server build extension targets that have new versions. References to them might require new references.
Backup of the TFS, Reporting and SharePoint databases – Backup current data using one of the three supported methods
· Stopping Team Foundation Server Services and using standard SQL backup procedures The services are
o IIS on Application Tiers
o Team Foundation Server Build service
o Team Foundation Server Job Agent
· Use marked transactions
Refer to the link http://msdn.microsoft.com/en-us/library/ms253070(v=vs.100).aspx for more details about marked transactions, maintenance plans etc.
Back up Reporting Services encryption key – use either the Reporting Services Configuration tool or the RSKEYMGMT command-line tool, which SQL Server provides. For a multiple-server or clustered deployment, you must use RSKEYMGMT.
Do a trial upgrade if possible – If we do a test upgrade we will know how much time it takes for the upgrade to happen and some of the issues we might face during the actual upgrade.
The supported upgrade procedures are
1. Inplace upgrade
2. Migration upgrade
3. Import upgrade using tfsconfig import command
For more information about the steps involved in upgrade visit the Visual Studio ALM Ranger’s blog – http://vsarupgradeguide.codeplex.com/releases
Content Created By: Venkata Narasimhan A
Content Reviewed By: Romit Gulati