Upgrade vs. Migration: Definitions

  • Article

Being the Migration PM for the TFS team, I get a lot of “migration” questions from users.  After a few rounds of questions, most of the time the conclusion is reached that the user wanted something other than migration, say, an upgrade.  With the RTM release of TFS 2010 just months away, I thought that it would be great to have a few blog posts out there to help people determine if they really want to migrate to 2010, or if they would be better served by an upgrade or other option.

Over the next few days, I’ll be posting some of the common scenarios that people often present when they talk about wanting to perform a migration.  Before getting into the scenarios, I wanted to clarify the definitions of Migration and Upgrade in the context of TFS. 

Upgrade

An upgrade refers to the process by which an existing TFS server is moved from one version to a newer version.  Upgrades are always fully supported and are tested in many configurations before being released. In an upgrade, data on the server is transformed at the database level, and all data and metadata are preserved.

There are also multiple flavors of upgrades: In-Place and Migration-Based.  An in-place upgrade is defined as an upgrade that when complete will use the same set of hardware that is running the current TFS version.  A migration-based upgrade is defined as an upgrade involving a second, duplicate set of hardware which will host the new version of TFS when the process is complete.  Note that despite having a similar name, a migration-based upgrade is NOT a Migration (see definition below).

For more information about the differences between in-place and migration-based upgrades, please Bryan Krieger’s blog post on Team Foundation Server 2010 Upgrade.

Migration

A migration refers to the process of replaying actions from one system into another system.  One of the key differences as compared to an upgrade is that a migration is a lower fidelity data transfer.  In TFS, only version control and work item tracking data can be migrated between servers – build data, reports, and numerous other pieces of metadata are not able to be migrated.  In general, available migration tools have significantly less testing than the upgrade process, and most available tools have limited support (as they are released out of band).

In the case of a migration, the data transformations are done using only the public APIs, which are limited in providing only certain pieces of information while moving data.  The result of these limitations is that some data is lost or distorted in the process of migration.  Examples of this are artifact IDs (changeset numbers, work item IDs), date-time stamps, area paths, and iteration paths.

Server Move

Another term included here is server move, which is used to describe the process changing the hardware associated with a server.  During a server move, the version of TFS is not changed.  While a server move is neither an upgrade nor a migration, they are often performed before or after an upgrade, and are often confused with migration.

Scenarios

Stay tuned for additional posts on common scenarios!