How do you upgrade from TFS 2018/2019 to Azure DevOps Server 2020/2022?

Think of upgrading TFS to Azure DevOps Server like renovating a house while people are still living in it. You need to photograph every room beforehand (backup), verify the new appliances fit the existing plumbing and wiring (compatibility checks), schedule the renovation during a weekend when disruption is minimal (maintenance window), perform the work (installer), verify everything works (validation), and keep the original photos in case you need to restore something (rollback plan). Skipping a version is like jumping from a 1990s kitchen directly to a 2024 design: possible because the renovation contractor handles all intermediate structural changes, but the transformation is more dramatic and testing more critical.

The pre-upgrade phase is the most important and most frequently rushed. Begin by documenting your current environment: TFS version and update level, SQL Server version, Windows Server version, number of project collections, total database size, installed extensions, configured build agents, and any custom plugins or event handlers. Check the compatibility matrix: Azure DevOps Server 2022 requires SQL Server 2019 or 2022 and Windows Server 2019 or 2022. If your current SQL Server version is not supported, you must upgrade SQL Server first, which is a separate project with its own planning. Run the TFS upgrade readiness tool (included in the Azure DevOps Server installer) against your databases to identify any blocking issues like unsupported collation settings, deprecated features, or corrupted work item data.

The backup strategy must be comprehensive and tested. Back up all collection databases, the configuration database, the warehouse database (if used), the reporting databases, and the file system cache. Do not rely solely on SQL Server backups: also export your build definitions, release definitions, extension configurations, and agent pool settings using the Azure DevOps CLI or REST API. These exports serve as documentation even if the upgrade succeeds, because they provide a reference point for validating that everything migrated correctly. Most importantly, test your restore process in a separate environment before the real upgrade. A backup you have never restored is a backup you cannot trust.

The upgrade itself is surprisingly straightforward when prerequisites are met. Download the Azure DevOps Server 2022 installer, run it on the application tier server, and it detects the existing TFS installation. The wizard offers an upgrade path, validates the environment, and then performs the schema migration on each collection database. For large databases (500GB+), the schema migration can take several hours. The installer handles all intermediate version migrations: if you are upgrading from TFS 2018, it applies the schema changes for 2018→2019→2020→2022 sequentially. During this time, the server is offline. Plan your maintenance window based on database size: roughly 1 hour per 100GB is a conservative estimate, though actual times depend on SQL Server hardware.

Post-upgrade validation is where most teams cut corners and regret it later. Verify that all project collections are online and accessible. Check that build agents reconnect (agents from TFS 2018 may need updating). Validate that XAML build definitions were preserved as read-only references. Test that Git and TFVC repositories are accessible with full history. Verify that work item queries, dashboards, and extensions function correctly. Run a sample build pipeline to confirm agents execute properly. Check that notification subscriptions still deliver emails. If you use the reporting warehouse or SharePoint integration, verify those connections.

The production gotcha is the agents and extensions gap. Self-hosted build agents from TFS 2018 use an older agent version that may not be compatible with Azure DevOps Server 2022 features. You will likely need to deploy new agents or update existing ones. Extensions installed from the Visual Studio Marketplace may have version compatibility issues: some extensions that worked on TFS 2018 have been deprecated or replaced. Test all critical extensions in a pre-production upgrade before touching production. Another common issue is authentication: if you switch from NTLM to Kerberos or add Azure AD authentication during the upgrade, all existing PATs and service account connections need reconfiguration.