Scenario: Upgrading Team Foundation Server

  • Article

You can use this topic to plan and upgrade your existing deployment to Visual Studio Team Foundation Server 2010. Before you upgrade, you should understand the releases from which you can upgrade, other requirements, and any optional features of Team Foundation Server 2010 that might require your consideration before you upgrade.

After you complete the upgrade, you should follow the links at the end of this topic to understand post-upgrade tasks and considerations. For example, you may still have some manual steps to perform on your upgraded team projects so that you can use certain features of Team Foundation Server 2010. In addition, you may want to better understand certain compatibility issues between different versions of Team Foundation Server and clients for Team Foundation.

You can upgrade to Team Foundation Server 2010 from the following releases:

  • Release-candidate version of Team Foundation Server 2010

  • Beta 2 version of Team Foundation Server 2010

  • Visual Studio Team System 2008 Team Foundation Server with Service Pack 1 (SP1)

  • Team System 2008 Team Foundation Server

  • Visual Studio 2005 Team Foundation Server

  • Visual Studio 2005 Team Foundation Server with SP1 

You cannot upgrade an installation of Team Foundation Server that has open connections. Upgrade requires downtime.

In-Place or Migration Upgrade Paths

You can choose either of two upgrade paths. Descriptions and illustrations of both paths follow, together with examples and rationales for using one instead of the other.

In-Place Upgrade Path

You can perform an in-place upgrade by doing an upgrade on the same hardware that was running the earlier version of Team Foundation Server. When you use this path, you must uninstall the previous version of Team Foundation Server, install Team Foundation Server 2010, and then run the upgrade wizard. The following illustration shows an in-place upgrade. This illustration depicts a single Team Foundation Server 2010 environment after the upgrade. 

Illustration of an In-place Upgrade

In place upgrade

If you use an in-place upgrade, you will have a single Team Foundation Server 2010 environment after the upgrade. The environment that was previously on your system is gone. In this case, an environment refers to all servers that make up a single version of Team Foundation Server, whether it is Team Foundation Server 2010 or an earlier version of Team Foundation Server.

Migration Upgrade Path

You can also perform a migration upgrade by migrating your data to different hardware. When you use this path, you must copy your data to different hardware, install Team Foundation Server 2010, and then run the upgrade wizard. The following illustration shows a migration upgrade:

Illustration of a Migration Upgrade

Migration upgrade

If you want to run both the new Team Foundation Server environment and the old environment simultaneously, you should perform a migration upgrade to new hardware. You might run two environments simultaneously to test the upgrade on your data before you commit to running the new version. After you move and restore your existing data to the new hardware, that data is autonomous and can be upgraded to create a different environment, even as your clients continue to use the old environment. The illustration labeled "Migration Upgrade" shows a migration upgrade, which creates two environments simultaneously running side by side on different computers after the upgrade.

The upgrade wizard deletes your old data during the upgrade. Regardless of what type of upgrade you perform or how many environments you run, you must back up your data before you start.

Which Type of Upgrade to Use

You should use the type of upgrade that best supports your team goals. In-place upgrades are typically less complex, but migration upgrades offer possibilities to improve scalability and testing.

The following are some examples of the different types of upgrades and the best checklist to use. This is not meant as a comprehensive list but offers only a few examples of what is possible by using each type of upgrade.

In-place upgrade examples

Migration upgrade examples

New Prerequisite Requirements

Before you start your upgrade, you might have to upgrade SQL Server or SharePoint Products to meet new Team Foundation Server requirements.

You must use SQL Server 2008 to host any databases that Team Foundation Server requires. In earlier versions of Team Foundation Server, the term "data-tier server" described the server that hosts all the data for Team Foundation Server. In this version, you can distribute the data for an installation of Team Foundation Server across multiple instances of SQL Server, but each instance requires SQL Server 2008.

In this version of Team Foundation Server, reporting and portal server are optional features. To use either of these features, you must use specific versions of the prerequisite software.

  • Reporting: If you use reporting, you must use a SQL Server 2008 instance of SQL Server Reporting Services and SQL Server Analysis Services.

  • SharePoint Products: If you use a portal server, you should use Windows SharePoint Services 3.0, Microsoft Office SharePoint Server 2007, or Microsoft SharePoint Server 2010. Windows SharePoint Services 2.0 is no longer supported.

Portal Server and Reporting Upgrade Options

When you upgrade Team Foundation Server, you can use your existing portal site or point to a different site. You cannot install SharePoint Products during the upgrade. All your upgraded projects will use the site that you specify during the upgrade.

If you want to move your portal to different hardware, you should back up the data on your existing portal site and then migrate it to new hardware before you start the upgrade wizard for Team Foundation Server.

  • If your portal is on the same server as Team Foundation Server, the extensions are upgraded automatically during the upgrade.

  • If your portal is on a different server from Team Foundation Server, you must install the extensions on the portal before you run the upgrade.

If you want data from your upgraded projects to appear in a portal and reports, you should add these features when you upgrade so that upgraded projects are automatically linked to the portal and reporting features. If you add a portal or reporting after you upgrade, you cannot easily create links between all your upgraded projects and the portal.

Tip

You should not skip adding a report server or a portal when you upgrade because you cannot easily add these features to upgraded projects after you upgrade.

Reporting Upgrade

The report server must meet the new requirements that are listed earlier in this topic. If you run multiple Team Foundation Server environments, each requires its own report server. Unlike earlier versions of Team Foundation Server, the report server does not have to run on the server that is running Team Foundation Server.

The amount of time that is required to migrate your existing data depends on many variables, which include the initial size of the reporting warehouse database and the capabilities of the hardware on which the migration is running. After the migration finishes, your reports appear as they did in the earlier version of Team Foundation Server.

Post-Upgrade Considerations

After you upgrade to Team Foundation Server 2010, you can access some new features immediately, but you must perform additional tasks to access other new features. For more information, see the following page on the Microsoft website: Updating an Upgraded Team Project to Access New Features. 

With the addition of features in Team Foundation Server 2010, you will want to know the limitations or restrictions that occur when users use earlier versions of Team Explorer to connect to Team Foundation Server 2010. For more information, see the following page on the Microsoft Web site: Compatibility between Team Foundation Clients and Team Foundation Server.

See Also

Reference

Checklist: In-Place Upgrade of Team Foundation Server on a Single Server

Checklist: Upgrade Team Foundation Server By Using More Than One Server