Full backup restore vs in-place retry after Azure DevOps Server schema upgrade failure

Azure DevOps Server on-premises upgrades proceed in two phases: application-tier binary update and collection database schema upgrade. Once the schema upgrade phase begins, the Tfs_Configuration schema version can become irreversible, and Microsoft documentation describes restoring a consistent pre-upgrade backup set of Tfs_Configuration and all Tfs_ databases as the supported recovery when phase 2 fails.

The upgrade wizard surfaces a Retry option for certain transient failures, but the boundary between a safe retry and a state requiring full restore is not clearly defined. The collection upgrade is single-threaded per collection and can leave the database in an intermediate state; an interrupted process may leave orphaned schema objects that are not cleaned up by retry logic.

For Azure DevOps Server 2019/2020/2022 on-premises, the decision point is whether to attempt an in-place retry or to revert the entire deployment to a point-in-time backup set, with implications for recovery time objective and data consistency.

Is there a documented checklist to determine post-failure whether the schema upgrade transaction has committed? Can the presence or absence of an entry in TfsConfig upgrade history reliably indicate a committed schema version bump? What conditions make an in-place retry unsafe for a partially completed collection schema upgrade?