Azure DevOps Server 26H2 Upgrade: What Breaks First

Microsoft shipped the Azure DevOps Server 26H2 release candidate on October 27, and the release notes are long. They cover a new Boards UI, swimlane rules, Markdown everywhere, a Test Run Hub and pipeline debugging. Buried between the features are the changes that will actually decide how your upgrade weekend goes: self-hosted agents that can no longer download updates, TFVC check-in policies that silently switch off, and pipeline runs that wait for an authorization that expires faster than before.

I build Azure DevOps extensions that have to keep working on servers like yours, so I read release notes looking for what breaks, not what shines. This post is that reading. You get the 26H2 breaking changes ranked by blast radius, a pre-flight audit you can run against your current server in an afternoon, an honest look at whether upgrading now could block a later move to the cloud, and a reusable checklist for the upgrade itself.

What Azure DevOps Server 26H2 is (and isn't yet)

Azure DevOps Server now ships on a half-year rhythm. 25H2 came out at the end of 2025, and 26H2 is the next on-premises release. It brings features from the hosted service to your own hardware, plus security and quality fixes.

The RC, the final release, and timing

The current build is a release candidate. Microsoft says a direct upgrade from the RC to the final release will be supported, but there is no date for that final release yet. Microsoft's own advice is to try the RC on a test deployment first, and I agree: treat the RC as your rehearsal, not your production target, unless you have a specific feature you need now.

There is one date that should push older shops to act. Extended support for Team Foundation Server 2017 ends on January 12, 2027. If you still run TFS 2017 or earlier, the 26H2 cycle is your window to get onto a supported version.

Supported upgrade paths

• TFS 2015 or newer, and any Azure DevOps Server version: upgrade directly to 26H2.
• TFS 2013 or older: upgrade to TFS 2015 first, then to 26H2.
• No downgrades: once your databases are upgraded, there is no way back except restoring a backup. That fact matters later in this post.

The full feature list and known issues are in the Azure DevOps Server 26H2 release notes. Below is the part that deserves your attention first.

Breaking changes ranked by blast radius

I rank these by how many people get hurt and how fast, not by how interesting they are.

1. The agent download domain is changing

The old agent package domain, vstsagentpackage.azureedge.net, is being retired because the CDN behind it is going away. Self-hosted agents download their packages from https://download.agent.dev.azure.com instead. If your firewall or proxy allowlist only knows the old domain, agent downloads and updates will fail once the old URL is removed.

This one ranks first because it hits every self-hosted agent at once, and the symptom (agents stuck offline or failing to update) looks like a network problem rather than an upgrade problem. Ask your network team to add the new domain before the upgrade weekend, not during it.

2. Obsolete TFVC check-in policies are disabled

If any of your collections still use TFVC, check your check-in policies. 26H2 disables the remaining old-format policies, and creating or modifying obsolete policies is disabled too. The standard Visual Studio policies already support the new format. Custom policies written against the old PolicyBase class do not, and they need code changes.

The risk here is quiet: a policy that used to enforce a work item link or a comment on every check-in simply stops enforcing anything. Nobody gets an error, and your audit trail gets a gap. Microsoft has a step-by-step guide to migrating custom check-in policies, and developers also need an updated client library and a Visual Studio version that understands the new policy format.

3. Node 16 is gone from the pipelines-* agent packages

The pipelines-* agent packages now ship with Node 20 only. The vsts-agent-* packages still include Node 6, 10, 16 and 20. Any pipeline task that still targets Node 16 will behave differently or fail when it lands on an agent without that runner. If you need a temporary bridge, the NodeTaskRunnerInstaller@0 task can install Node 16 on the agent.

I wrote a full walkthrough on finding these tasks for the hosted service in Find Every Node 16 Task in Azure DevOps Before Nov 24. The same search approach works on your server, and the in-house tasks your team built years ago are the usual suspects.

4. YAML pipeline authorizations expire after 7 days

When a YAML pipeline touches a protected resource such as a service connection or agent pool for the first time, the run pauses until someone authorizes it. In 26H2 that wait times out after 7 days instead of 30. Runs that are already waiting are not affected.

For most teams this is a good change, because it stops a pile of stale runs resuming at once. It will bite teams where approvals go through a slow change board. If your process regularly needs more than a week to authorize a new resource, fix the process or authorize ahead of time.

5. Clone Work Item is removed, plus smaller Test Plans changes

Clone Work Item is gone; Copy Work Item remains and lets you edit before saving. This breaks habits and documentation rather than systems, but update any internal how-to pages and training material.

Smaller changes in the same category:

• The Test Plans column "Tester" is renamed to "Current Tester", which affects saved queries, exports and reports that reference it by name.
• Action logging in the desktop Azure Test Runner may stop working because Problem Steps Recorder is deprecated. The Test & Feedback extension is the suggested replacement.

Audit your extensions before the upgrade

26H2 adds something I think every admin should welcome: the collection admin pages and the Marketplace install page now flag extensions with high-privilege scopes, pipeline decorators and unpublished extensions.

What the new flags mean

• High-privilege scopes are permissions such as reading and writing source code, managing identities and groups, or creating and deleting projects.
• Pipeline decorators inject steps into every pipeline in the collection, so they always count as high privilege.
• Unpublished means the publisher pulled the extension from the Marketplace, which usually means nobody maintains it anymore.

Microsoft's guidance on managing high-privilege extensions is blunt: keep only the ones you trust and actually need, and uninstall unpublished ones. On a server that has been running for years, expect a few surprises the first time you open that page.

Keep, replace or rebuild

For each flagged extension, ask three questions:

1. Does anyone still use it? Check with the teams before assuming. If nobody can name the use case, remove it in staging and see who complains.
2. Does the scope match the job? An extension that shows a widget on a dashboard has no business managing identities.
3. Is it maintained? An unpublished or abandoned extension is a risk on every future upgrade, not just this one.

In-house extensions deserve the same scrutiny. Many were built quickly, with broad scopes "to be safe", and against SDK versions nobody has touched since. This is the kind of work I do for clients: reviewing an existing extension, narrowing its scopes, and rebuilding it on the current SDK so it survives the next server release too.

The cloud migration trap: upgrade or migrate first?

This is the part the release notes do not cover. If your organization plans to move from Azure DevOps Server to the hosted service, the migration runs through Microsoft's data migration tool, and that tool only accepts specific server versions.

After 25H2 shipped, admins who had upgraded found the tool rejected their databases because 25H2 was newer than the latest supported import version. A Microsoft Q&A thread on migrating 25H2 describes the dead end: no way to downgrade, no supported import, and an unofficial target date months out. I expect the same gap can open again after 26H2.

My rule of thumb:

• Staying on-premises for at least another year? Upgrade to 26H2 once the final release is out and your rehearsal is clean.
• Migrating to the cloud within the next six months? Check which server versions the migration tool currently accepts before you upgrade anything, and consider migrating from the version you already run.
• Undecided? Make that decision before the upgrade, not after. The upgrade is the one step you cannot undo.

What your users will notice on day one

Not everything in 26H2 is risk. Some changes will generate questions on Monday morning, so prepare a short announcement:

• A redesigned Boards UI with better accessibility, plus Move to position on Kanban cards.
• Swimlane rules that move cards into lanes automatically, and swimlane colors.
• Markdown in comments and large text fields. Users choose Markdown or HTML per edit. HTML can be converted to Markdown, but a Markdown comment cannot be converted back to HTML. Markdown fields also support interactive checklists.
• Team automation rules that activate a parent when the first child becomes active, and close or resolve it when all children are closed.
• Higher limits, including 2,000 connected GitHub repositories and 1,500 Delivery Plans per project.

The automation rules are worth a team conversation first. Automatically closing a user story when its last task closes is convenient, but it also means "all tasks done" now equals "story done", whether or not your Definition of Done agrees. I wrote about keeping those two separate in Make "Done" Mean Done in Azure DevOps Boards.

A pre-flight checklist and test plan

Staging collection dry run

Restore a recent production backup into a staging environment and upgrade that first. Then test, in this order:

1. Agents: register a self-hosted agent and let it update, using your production firewall rules.
2. TFVC: check in to a path with each custom policy and confirm it still enforces.
3. Pipelines: run your ten most important pipelines, including one that touches a new protected resource.
4. Extensions: open every flagged extension and confirm it loads and works.
5. Reports and queries: check anything that references "Tester" or other renamed fields.

Upgrade weekend runbook

• Take a full, consistent backup of every Azure DevOps database and verify you can restore it.
• Confirm the new agent domain is reachable from every agent host.
• Freeze TFVC policy changes and extension installs for the week before.
• Announce the downtime window and the day-one changes listed above.
• Keep the staging environment until production has run a full sprint without issues.

Turn the checklist into a reusable work item template

You will do this again for the next release, so do not keep the checklist in someone's head or an old email. Put it on an upgrade work item and reuse it every cycle. On 26H2 you can do that natively with an interactive Markdown checklist in the description. On Azure DevOps Services, my Checklist Extension adds reusable checklist templates and can block the work item from moving to Done until every item is checked, which is exactly what you want for an upgrade sign-off.

Conclusion: upgrade in the order things break

The 26H2 upgrade is not hard, but it is uneven. A handful of changes carry almost all of the risk:

• Allowlist the new agent download domain before anything else.
• Migrate custom TFVC check-in policies, or accept that they stop enforcing.
• Find Node 16 tasks and check your 7-day authorization flow.
• Audit flagged extensions and remove what nobody can justify.
• Decide on cloud migration before upgrading, because there is no downgrade.

Rehearse on the RC now, so the final release becomes a routine Saturday rather than an incident. And if the extension audit turns up an in-house extension that needs narrower scopes or a rebuild on the current SDK, that is work I do every week. Start with the reusable upgrade checklist, and get in touch if an extension is the thing standing between you and 26H2.

Frequently asked questions