I'm planning to upgrade our on-premises Azure DevOps Server 2020 installation 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 deployment runs on a fully virtualized Hyper-V machine, so we can create and restore VM snapshots. However, the environment still contains legacy XAML Builds for a business-critical application used by many customers. These builds are deeply tied to business logic and other dependencies, making migration difficult. We also rely on classic build pipelines and release pipelines.
I understand that XAML Builds are deprecated, but this setup was inherited and is not fully documented, so parts of it are effectively a black box. One option would be to take a snapshot before upgrading and restore it if something goes wrong, although I have never used that approach for a rollback.
Has anyone upgraded an on-premises Azure DevOps environment that still uses XAML Builds? Would cloning the virtual machine into an isolated network and testing the upgrade there be a reliable approach? What backups, validation steps, and rollback plan would you recommend?
2 Answers
A full isolated VM clone is probably the least risky option in your situation. It doesn’t have to become a permanent second environment; it only needs to be realistic enough to confirm that the upgrade completes and that the critical XAML builds can still be queued, triggered, and finished.
Before testing, document the existing build agents, service connections, schedules, deployment targets, integrations, and any credentials or network dependencies. Also disable outbound notifications and deployments in the clone so a test build cannot affect production. Afterward, perform a controlled production upgrade during a maintenance window, with database backups and a tested rollback procedure ready.
I wouldn’t upgrade production and treat a Hyper-V snapshot as the testing plan. It can be a useful additional safety net, but Azure DevOps depends heavily on its configuration and collection databases. Make sure you have consistent, verified backups and understand the supported restore process before starting.
Since you’re virtualized, create a temporary clone of the environment and place it on an isolated network. Upgrade that clone first and verify that the XAML builds still trigger, complete successfully, and interact correctly with their dependencies. It won’t replace a proper backup and recovery plan, but it gives you much more confidence than testing directly in production.
So the idea is to clone the Hyper-V machine, perform the upgrade on the clone, and then check how the system behaves. The main limitation is that I may not be able to test every pipeline and external dependency there.