Service start failure after Azure DevOps Server upgrade leaves instance in partially upgraded state

Context

An on-premises Azure DevOps Server upgrade fails after the Configuration Tool has applied database schema migrations but before all application-tier services start successfully. The instance is left in a partially upgraded state with no automatic rollback mechanism.

Constraints and uncertainty

Pre-upgrade backups of SQL databases, file shares, and configuration exports exist. However, custom extensions and modified IIS settings are present, and the documented repair option in the Configuration Tool is explicitly unsupported once schema changes have been committed. The upgrade logs indicate the failure occurred during service registration, but the exact stage is ambiguous.

Goal

Determine the safest recovery path that minimizes data loss and downtime while preserving customizations.

Which factors should decide between a forward re-run of the upgrade versus a full restore to the pre-upgrade state? How do custom extensions and IIS modifications affect the viability of each approach? Is there a supported method to validate database consistency before committing to either path?