I'm planning to upgrade our on-premises Azure DevOps Server 2020 environment to the latest supported version. The upgrade path follows Microsoft's documentation, but we don't have a separate test environment available.
Our Azure DevOps instance runs on a fully virtualized Hyper-V machine, so we can create and restore VM copies or snapshots. The main concern is that we still rely on XAML builds for a legacy, business-critical application used by many customers. Those builds are deeply tied to business logic and other dependencies, making them difficult and risky to migrate. We also use classic build pipelines and classic releases.
I understand that XAML builds are deprecated, but the environment was inherited from a former engineer and parts of it are effectively a black box. One option would be to take a Hyper-V snapshot before upgrading and restore it if something goes wrong, although I have never tested that rollback process.
Has anyone upgraded an on-premises Azure DevOps environment that still uses XAML builds? What would be the safest approach, and how reliable is a VM snapshot or clone for validating the upgrade?
2 Answers
I wouldn’t make a production upgrade and depend solely on a Hyper-V snapshot for testing. Azure DevOps is database-backed, so a snapshot may not provide a fully consistent recovery point unless all related services and databases are handled correctly. Microsoft’s supported recovery approach is based on consistent backups and restores of the configuration and collection databases.
Since the server is virtualized, create a clone of the environment and place it on an isolated network. Upgrade that copy first and verify that the XAML builds can still be queued, triggered, and completed. It doesn’t need to become a permanent test environment; it just gives you a realistic rehearsal before touching production.
Because XAML builds are business-critical and difficult to understand, an isolated clone is the least risky option. Keep it separated from production carefully so it cannot send notifications, publish artifacts, modify external systems, or accidentally trigger real deployments. Use representative build inputs and dependencies where possible, then test the important XAML, classic pipeline, and release paths.
Take verified database backups as well as the VM snapshot before the production upgrade. Treat the snapshot as an additional safety net, not as the complete rollback plan, and document how you would restore the databases and reconnect the services if recovery is required.
So the idea would be to clone the Hyper-V machine, upgrade the clone, and use it to see whether the upgrade succeeds. I’m not sure how much of the pipeline behavior I can validate without the surrounding systems, though.