Hey there, let’s tackle your two migration questions head-on—these are super common scenarios when moving from on-prem TFS to Azure DevOps (formerly VSTS), so I’ve got practical steps for both cases.

1. Migrating a Single Local TFS Project to VSTS #

This is straightforward with official tools and a bit of pre-planning:

• Pre-Migration Prep

  • First, confirm your local TFS version is compatible (TFS 2017 or newer works best with VSTS). Older versions might require intermediate upgrades.
  • Clean up your project: archive unused work items, delete obsolete build definitions, and remove redundant files from source control to keep the migration lean.
  • Take a full backup of your TFS project collection—better safe than sorry if something goes sideways.

• Use the Azure DevOps Migration Tool
  This official tool handles most of the heavy lifting:

  1. Download and configure the tool with your source (local TFS project collection + target project) and target (VSTS organization + new empty project) connection details.
  2. Select exactly what to migrate: work items, source code (TFVC or Git—note VSTS supports both, but Git is more cloud-friendly), full change history, and linked artifacts.
  3. Run a test migration first to verify data integrity, fix any errors, then execute the full migration.

• Build Definitions: Manual Touch-Up
  The migration tool might not capture 100% of build configuration nuances. Export your TFS build definitions as JSON files, import them into VSTS, then adjust:

  • Agent pool settings (VSTS uses cloud-hosted or self-hosted agents, which may differ from your local TFS)
  • File paths and service connections (update to point to VSTS source control and cloud services)
  • Trigger conditions and variables to match your new environment

2. Migrating a Single Project from a Collection with 30+ Projects (Full History, Builds, Changesets) #

This is trickier because TFS collections are designed as cohesive units, but you’ve got two solid options:

Option 1: Split the Collection First (Recommended for Full Integrity) #

If you’re on TFS 2018 or newer, use the tf split collection command to extract your target project into a temporary standalone collection, then migrate that collection to VSTS:

1. Backup the original collection—this is non-negotiable.
2. On your TFS application-tier server, run the command (as an admin):

   tf split collection /collection:http://your-tfs-server:8080/tfs/OriginalCollection /newCollection:http://your-tfs-server:8080/tfs/TempCollection /project:YourTargetProject
   

3. Validate the temporary collection: check that all changesets, work item history, and build definitions exist and are intact.
4. Use the Azure DevOps Migration Tool to migrate the temporary collection’s project to VSTS, following the steps from the first scenario.

Option 2: Selective Migration (No Collection Split) #

If splitting isn’t feasible, use the migration tool to target only your specific project:

1. Configure the tool to filter by your project’s source control path, work item queries, and changeset IDs (you can get the range of changesets specific to your project via TFS’s history view).
2. For build definitions, filter and export only those belonging to your target project from TFS, then import and adjust them in VSTS as outlined earlier.
3. Watch for cross-project dependencies: If your project’s changesets link to work items or files in other projects, you’ll need to either migrate those dependencies too or reconfigure them in VSTS post-migration.

• Post-Migration Validation
  Regardless of the option you choose, verify these critical points:
  • All changeset history (comments, linked work items, file versions) matches the original project.
  • Build definitions trigger successfully and produce the same outputs as in TFS.
  • Work items retain their full history, state transitions, and links.

内容的提问来源于stack exchange，提问作者Veer