Upgrading TFS 2008 to 2010 and run in parallel run on single SQL Server


The Team Foundation Server 2010 upgrade wizard and its documentation are sufficient for many differing upgrade scenarios and configurations. The standard upgrade paths are applicable in almost all cases where there is no limit on hardware resource and the aim is upgrade/replace rather than parallel running. During a recent in house upgrade where hardware resource was tight and the user requirements for the upgrade included minimal downtime and a parallel running phase the standard paths were a bad fit. This newsletter documents the way these limitations were tackled and brings together several elements that were required to complete this type of upgrade. It includes details of the procedure to move Team Foundation Server databases from one server to another and reconnect the application-tier and specifics on running both 2008 and 2010 using shared SQL database and SharePoint servers.

This information found here is not meant to be a detailed overview of Team Foundation Server upgrade process as a whole and some knowledge of the technical architecture of both Team Foundation Server 2008 and 2010 is assumed. The main focus of this article is to cover the specific scenario encountered during the subject upgrade and collect together the information required for anyone that may attempt this type of upgrade in the future.

Upgrading TFS 2008 to 2010 and run in parallel run on single SQL Server

We recently needed to upgrade our 2008 implementation of Team Foundation Server to 2010. Normally this would follow one of two standard patterns covered by the Microsoft upgrade documentation, either an in place upgrade or a migration upgrade.  But due to lack of hardware resource the eventual solution would be a mix of both options with a few undocumented steps thrown in.

In-Place upgrade

An in place upgrade involves upgrade Team Foundation Server on the same hardware that was running the earlier version.  This path requires the un-installation of old version, followed by the install of 2010. The upgrade wizard is then run. Post upgrade (if all goes well) you have a shiny new Team Foundation Server 2010 installation with new upgraded databases and your old Team Foundation Server 2008 implementation is no longer accessible.

Migration upgrade

You can also perform a migration upgrade by copying your data to different hardware running SQL server.  Then installing Team Foundation Server 2010 and running the upgrade wizard. By using separate hardware in this way you have the opportunity to parallel run both versions for a while to allow confirmation that the upgrade was successful before turning off the 2008 server.

Upgrade Requirements

The main requirements for live operations during the proposed upgrade were as follows;

  1. The new 2010 must have the same architecture as the existing system.  Separate data tier and an application tier servers.
  2. The live Team Foundation Server 2008 server must remain available throughout the upgrade.
  3. A period of at least two weeks parallel running is required to allow for any post upgrade migration from 2008 to 2010.
  4. Both 2008 and 2010 must run from a single SQL Server instance.
  5. The switch from 2008 to 2010 must be as seamless as possible.

Initially this looks like a migration upgrade as these requirements immediately rule out the first option of an ‘In-Place upgrade’. Mainly because 2008 must remain available throughout the process and post upgrade for a parallel run period. That leaves the ‘Migration upgrade’ option but the main requirement for that path, is separate hardware for the new servers. As this resource was not available a third solution was required to allow the upgrade to continue. The main problem posed by the requirements was the need to use the existing SQL server for 2010 as well as the already running 2008. The interesting part then was not going to be the actual upgrade but attempting to get both 2008 and 2010 running on the same database server in parallel. This configuration is not covered in any installation or upgrade documentation I have come across and extensive Googling came up with no real help or guidance. Before describing the solution that was used an understanding of both the existing and target production environments is required.

Existing Team Foundation Server Environment

A description of the Team Foundation Server 2008 implementation that existed prior to the upgrade taking place. The Team Foundation Server application tier is hosted by the (WAGNER). The data-tier and databases for Report Server and SharePoint are hosted by (BACH). The TFS 2008 build service is hosted by (BIZET). All Team Foundation Server SharePoint project portals are hosted on (TOCH) under MOSS 2007.

Microsoft TFS Upgrade


Proposed upgrade environment

In order to keep 2008 up and running and unaffected, the upgrade would have to take place in isolation so the following solution was proposed. Create three virtual machines one for the data-tier one for the application tier and another for the build server. The data-tier would only be temporary and used to host the 2008 databases for the upgrade only and then thrown away. The application-tier and build VM’s would eventually become production servers hosting the 2010 services. The virtual upgrade environment is shown below. Eventually the upgraded databases will be moved from the temporary server (DYSON) to the existing live data-tier (BACH) and the new application tier (TIPPET) will be re-pointed to the live data-tier server (BACH).

Proposed TFS Upgrade Environment

Target Team Foundation Server Environment

The diagram below shows the production environment hosting both Team Foundation Server 2008 (blue circle) and Team Foundation Server 2010 (green circle). Both TOCH the SharePoint server and BACH the database server are shared between 2008 and 2010. Note the addition to the existing live environment of the two virtual machines TIPPET and BINGEN.

Team Foundation Server Environment

The Upgrade

The actual upgrade run in the VM environment went without any problems. The databases were exported from BACH overnight and imported onto the temporary server DYSON. Team Foundation Server 2010 was installed on TIPPET along with SQL Server reporting services. The Team Foundation Server 2010 upgrade wizard was run against the databases on DYSON which resulted in a fresh set of 2010 databases. At this point we now have two sets of databases, the 2008 versions of the databases in use on the live server and the new 2010 databases ready for export/import.

The structure of the database in Team Foundation Server 2010 has been completely reworked due to the introduction of the Team Project Collection database type. Effectively, the Team Project Collection database now encompasses all of the data held in the 2008 databases with the exception of ‘TfsWarehouse’. This allows this multiple Team Project Collection’s to be hosted on the same server. The two sets of databases can be seen below side by side, these lists do not include databases used by SQL Report Server or SharePoint.

TFS 2008 Databases (BACH) TFS 2010 Databases (DYSON)
TfsActivityLogging Tfs_Configuration
TfsBuild Tfs_DefaultCollection
TfsIntegration Tfs_Warehouse
TFS 2008 Analysis Database TFS 2010 Analysis Database
TfsAnalysis Tfs_Analysis

Note the addition of the underscore character in the 2010 databases, this is important as the database names must not clash when hosted on the same server. Check there are no clashes with your database names at this point.

Moving the upgraded databases

Now comes the tricky part! Once the TFS 2010 upgrade is complete the upgraded databases need to be moved from the temporary database server DYSON to the production server BACH. This needed to be done with care as BACH also hosts the TFS 2008 databases and these must be available throughout the upgrade process and post upgrade for a period of parallel running.

An existing MSDN article covers the processes of moving the databases. However, the described move is to a new server instance and not an existing instance that already hosts another version of TFS. The steps below include a summary of the information on MSDN and extra or modified steps to allow the co-existence of the databases for both 2008 and 2010 on the same instance.

(1) Stop TFS 2010 Services

These commands need to be run on the 2010 application tier.

  1. Start a command prompt on app tier
  2. cd “%programfiles%\Microsoft Team Foundation Server 2010\Tools”
  3. TFSServiceControl quiesce

(2) Backup databases on DYSON

Backup the following databases on DYSON and move/copy the backups to your live database server i.e. BACH.

Database Engine

  • Tfs_Configuration
  • Tfs_DefaultCollection
  • Tfs_Warehouse

Analysis Services

  • Tfs_Analysis

 (3) Restore Databases to BACH

The restoration of the databases differs for the Database Engine and Analysis services.

Database Engine

  • Tfs_Configuration
  • Tfs_DefaultCollection
  • Tfs_Warehouse

Analysis Services

  • Tfs_Analysis
  1. Copy the TFS_Analysis.abf to (E:\SQL_Analysis_Data\MSAS10_50.MSSQLSERVER\OLAP\Backup\).
  2. Open up a connection to the Analysis Services in SQL Mgmt Studio.
  3. Run the following XMLA query

<Restore xmlns=”http://schemas.microsoft.com/analysisservices/2003/engine”>




(4) Prepare BACH for TFS 2010

Some preparation must be carried out on BACH to allow the TFS 2010 application tier to access the moved databases.

The following  commands need to be run on the 2010 application tier.

Open a command prompt and run the following commands;

cd “%programfiles%\Microsoft Team Foundation Server 2010\Tools”

TFSConfig PrepSQL /SQLInstance:BACH

TFSConfig Accounts /ResetOwner /SQLInstance:BACH /DatabaseName:Tfs_Configuration

TFSConfig RemapDBs /DatabaseName:BACH;TfS_Configuration /SQLInstances:BACH /AnalysisInstance:BACH

TfsConfig registerDB /SQLInstance:BACH /DatabaseName:Tfs_Configuration

(5) Restart TFS 2010 services

These commands need to be run on the 2010 application tier.

Start a command prompt on app tier

cd “%programfiles%\Microsoft Team Foundation Server 2010\Tools”

TFSServiceControl unquiesce

SQL Reporting Services and SharePoint

Luckily both reports and SharePoint portals were not in use under 2008, so these needed be recreated manually post upgrade. Reporting services was installed on TIPPET and new databases were created on BACH for use with Team Foundation Server 2010. These were named differently than those currently in use by 2008. The SharePoint server TOCH (MOSS 7) did host a site for 2008 web portals but was not currently used, a new SharePoint site was created for 2010. Post upgrade both project reports and web portals would need to be recreated using command line tools available in Team Foundation Server 2010 Power Tools. See the tools and documentation for more information if required

Deploy New Reports

The upgraded database schema no longer works with reports created in previous versions. A new set of Agile 5.0 based reports can be deployed with TFS 2010 power tools using the following command line;

tfpt.exe addprojectreports /collection:http://tippet:8080/tfs/DefaultCollection /teamproject:”ProjectName”
/processtemplate:”MSF for Agile Software Development v5.0″ /force

Possible error message and fix see; Cannot create project (TF30225: xp_sqlagent_notify)

Deploy new SharePoint Portal

To take advantage of the new dashboard features project portals need to be recreated. To achieve this;

  1. Archive document libraries from the original portals
  2. Create new portals using TFS power tools (see command line below)
  3. Import document libraries to new portals

tfpt.exe addprojectportal /collection:http://tippet:8080/tfs/DefaultCollection /teamproject:” ProjectName” /processtemplate:”MSF for Agile Software Development v5.0″

Parallel Running and Switchover

The final step of the upgrade was to start the Team Foundation Server 2010 services in parallel with the already running 2008 services. A period of verification testing followed and the version control and work item tracking of both the original and upgraded databases could be compared. Once all was ready clients where switched to the upgraded application tier and normal was resumed. At this point the temporary SQL Server (DYSON) could be decommissioned leaving the live server (BACH) to host both 2008 and 2010 databases.

During the entire upgrade process the original 2008 version remained available for operational work and can now continue to run alongside the 2010 upgraded clone of itself. The Build services on both BIZET(2008) and BINGEN(2010) are running on separate servers accessing separate application tiers that use the same SQL server database instance and share the same SharePoint server.


In this newsletter we have discussed the two standard upgrade paths documented by Microsoft for Team Foundation Server. A third undocumented path has been outlined that involves temporary upgrade environments and moving databases between servers. We have also shown that both Team Foundation Server 2008 and a cloned set of databases upgraded to 2010 can be run on the same server allowing parallel running of both versions with the same data.

Previous Next