Old TFS and Azure DevOps Server: preserving work item history

What history sits in an old TFS collection?#

An old TFS collection holds a company's engineering record in SQL Server: work items with every revision, TFVC changesets with check-in comments, shelvesets, branches and merges, build and test results, and the links between them. Each team project collection is its own database, alongside a configuration database that ties the deployment together.

Long-running software companies often find more than they expected. Collections from the early years may hold the only record of how core features were designed, which bugs customers reported before the current tracker existed, and which fixes shipped in which releases. Older versions often added a reporting warehouse and SharePoint project sites, which hold reports and documents rather than the source records.

Migrate or archive: what each option keeps#

Migrating keeps history only for what moves cleanly, while archiving keeps everything but requires a way to read it later. The right answer usually differs by collection: an active product line may justify a careful move, while a collection for a retired product is better archived and left alone.

Microsoft documents upgrade paths for TFS and Azure DevOps Server and a separate path for importing collections into the cloud service, each with version prerequisites that change over time. Check the current documentation for your exact version before committing to a plan, and assume a very old collection may need intermediate steps.

Why TFVC history is the hardest part to move#

TFVC history is hard to move because centralized version control does not map neatly onto Git. TFVC branches are folders with recorded merge relationships, changesets are numbered across the whole collection, and each check-in can carry comments, policy overrides and associated work items. A Git conversion has to translate all of that into commits and branches.

Conversion tools make different trade-offs. Some bring only recent history or the tip of each branch, some flatten branch structure, and some drop the links between changesets and work items. Before choosing one, convert a test branch and compare a handful of changesets, including a merge, against the original.

The safe rule: if you convert TFVC to Git for ongoing development, archive the original TFVC history anyway. Export changesets with their comments, authors, dates, file lists and associated work item IDs, plus the branch hierarchy, so the reasoning behind old code survives even when the converted repository is simplified.

How to archive a TFS collection step by step#

Archiving a TFS collection means producing two things: a restorable backup and a readable export that does not need a server. Do both while the server, its service accounts and the people who administer it are still available.

• 1Inventory each collection, team project, TFS or Azure DevOps Server version, SQL Server version, process template and any file shares used for build drops.
• 2Back up the configuration database and every collection database from the same point in time, then checksum each file.
• 3Restore onto an isolated server of the same version and open old work items, changesets and attachments to prove the backup reads.
• 4Export every work item with all revisions, comments, links and attachments into files keyed by work item ID, including closed and removed items.
• 5Export TFVC changesets with comments, authors, dates, file lists, associated work item IDs and the branch hierarchy; mirror-clone any Git repositories and save their pull request threads.
• 6Archive the process template definitions and an identity map from old domain accounts to names and roles.
• 7Scan the export for secrets and personal details, restrict access to a named group, and record sign-offs before the server is retired.

Identities and process templates: the quiet failure points#

Identities are usually the first thing to break. TFS records people as domain accounts, and after a domain migration or years of staff turnover many of those accounts no longer resolve, so history can show unknown users or raw security identifiers. Export an identity map while the directory still knows who everyone was, with name, role and team rather than login names alone.

Process templates are where meaning breaks. Many teams customized work item types with fields such as root cause, customer impact or release note text, and with states that matched their own workflow. Without the process definitions, an archive holds values whose meaning nobody remembers, so save the definitions with the export and note which fields were used in which years.

Illustrative: a labeling software firm retires two old collections#

Illustrative: a fictional company that builds warehouse labeling and compliance software still runs a TFS server in a closet. Active development moved to Git on a cloud platform years ago, but two collections remain: one for the original desktop product and one for an integration toolkit that customers still use.

The CTO decides not to migrate either collection. The team backs up the configuration and collection databases, proves the restore on an isolated machine, and exports every work item revision, TFVC changeset and branch relationship, with an identity map built before the old domain is shut down. Shelvesets from the last release cycle are exported too.

The server is retired, removing an unsupported machine from the network. When an integration customer later reports a label format regression, engineers find the original bug, its triage comments and the changeset that fixed it in the readable export, which also becomes the reference entry in the company's records inventory.

How SourceX looks at an old TFS archive#

SourceX looks at an old TFS archive as a linked record of software work: bugs reported, triaged, fixed in changesets and verified in builds. In the Supply step of the SourceX five-step transaction, the fit check asks for metadata only, such as versions, collections, years covered and whether changesets link to work items.

Under the SourceX Enterprise Data Value Framework, an old archive can rate well on domain expertise and human-generated signal while rating lower on recency, and data cleanliness depends heavily on whether revisions and links survived. Rights review then checks for customer-funded code, contractor work and acquired products before anything is prepared, approved or delivered.