Azure DevOps Server rollback consistency using VM snapshots versus SQL backups

Rolling back Azure DevOps Server after a failed upgrade requires strict synchronization between the application tier and the SQL Server databases. Because the upgrade process does not support an in‑place downgrade, the only recovery path is restoring to a state captured prior to the upgrade attempt.

Risks of Using VM Snapshots

The primary risk of using VM snapshots in a multi‑server deployment is state drift. A VM snapshot captures the application tier (IIS configuration, file system, and registry), but it does not include the data stored on a separate SQL instance.

If you restore only the application‑tier VM while leaving the databases at the upgraded schema version:

• Schema mismatch: The application tier will expect the pre‑upgrade schema, potentially triggering the upgrade wizard or demanding a repair.
• Orphaned metadata: File system folders, build‑agent caches, and search indexes may reference database objects that no longer exist in the restored state, leading to 500 errors or missing work items.
• Transactional inconsistency: Without a coordinated point‑in‑time recovery, the application metadata and database state will fall out of sync.

Re‑configuration and Compatibility

Restoring a VM snapshot generally does not require manual re‑configuration of the application tier, provided the databases are also restored to the exact same point‑in‑time. The tier uses the connection strings from the restored configuration database to re‑establish connectivity automatically.

Recommended Rollback Steps

To ensure a consistent rollback, follow these scoped steps:

1. Coordination: If using snapshots, snapshot the application‑tier VM and the SQL Server VM simultaneously (or take coordinated SQL backups at the same moment).
2. SQL Restore: If using SQL backups, restore the configuration database and all collection databases to the state immediately before the upgrade began.
3. Verification: After restoration, access the Azure DevOps Server Administration Console to verify the reported version matches the restored database schema before allowing user traffic.
4. Cache Maintenance: If inconsistencies persist, manually clear the build‑agent caches and rebuild the search index to resolve orphaned metadata references.

Diagnostic Question: Is your SQL Server hosted on the same virtual machine as the application tier, or on a remote instance?