If you’re running virtual servers in Azure, it’s a good idea to explore removing your servers in favor of PaaS/SaaS solutions. Running VMs is often more expensive, and you have more overhead and maintenance. With that said, VMs are still very common, and oftentimes, migrating existing VMs to Azure is one of the first steps in an Organization’s journey to the cloud. With Windows Servers comes support lifecycles, so it’s important that your servers are running a supported build of Windows Server. At the time of writing, the oldest supported build of Windows Server is 2016, and it’s final day of support is January 12, 2027. Earlier builds are no longer supported.
| Version | End of Mainstream Support | End of Extended Support |
|---|---|---|
| Windows Server 2025 | Not Available Yet | November 14, 2034 |
| Windows Server 2022 | October 13, 2026 | October 14, 2031 |
| Windows Server 2019 | January 9, 2024 | January 9, 2029 |
| Windows Server 2016 | January 11, 2022 | January 12, 2027 |
When doing a lift-n-shift migration to Azure, you have the option to upgrade the client OS while the server is migrated. However, this isn’t always desirable since in most cases, you want to lift-n-shift the server infrastructure as-is. After the servers have been migrated, are stable, and backed up, you can plan your in-place upgrade. Prior to performing the upgrade, you should review the two links and table belowthe to verify compatibility.
- Microsoft server applications compatibility for Windows Server | Microsoft Learn
- Upgrade and migrate roles and features in Windows Server | Microsoft Learn
Required Free disk space is not stated in the MS documentation. This depends on installed roles and other factors, but it seems the consensus online is to have at least 20 GB of free disk space on the system drive. When it comes to hardware requirements, Azure will support in-place upgrades of Windows 2022/2025 for most VM SKUs assuming they meet the minimum specs here.
After reviewing the requirements and verifying you can upgrade to your desired Windows Server version, we can start the process to upgrade the VM in Azure. Microsoft provides a well-written guide, but we will walk through the process and examine certain aspects in more detail in this post.
Once you’ve determined which OS you want to upgrade to, we can use the script supplied by Microsoft to generate the upgrade media. We need to create the upgrade media as a managed disk using PowerShell. To use this script, we need the az.compute, az.resources and az.accounts modules installed. You could also install the entire az module, but that will take much longer than only installing the required modules. Set your customer specific parameters for the script (shown below). The rest of the script (not shown below) uses common variables that don’t need to be changed.
# Customer specific parameters
# Resource group of the source VM
$resourceGroup = "WindowsServerUpgrades"
# Location of the source VM
$location = "WestUS2"
# Zone of the source VM, if any
$zone = ""
# Disk name for the that will be created
$diskName = "WindowsServer2025UpgradeDisk"
# Target version for the upgrade - must be one of these five strings: server2025Upgrade, server2022Upgrade, server2019Upgrade, server2016Upgrade or server2012Upgrade
$sku = "server2025Upgrade"If we break down the script and look at the expanded properties of the versions variable, we can see the specific versions and information on the upgrade media. When I started this blog, there was no mention in the Microsoft Documentation of Server 2025 upgrade media, but it existed if we searched for it (documentation has since been updated).
If we look at the version number, it can be matched to the image versions here. In this case, 26100.4656.250712 is the latest (July 8th) image of Server 2025. This blog was published in Late July 2025, so it’s the most up-to-date available image.
After creating the disks with the script, you’ll see the disks in the Azure dashboard as 10 GB HDD disks. If you’re upgrading more than one server at the same time, you’ll want to make more than one upgrade disk since the disk can only be mounted on a single VM at a time.
Next we want to take a snapshot of the OS disk for the server you’re upgrading. This gives us the ability to revert to the snapshot if the upgrade causes problems. Locate the OS disk. You can do this from the disks blade in Azure, or if you want to make sure you have the correct disk, select your VM and then select disks under settings. Click the OS Disk:
Select Create snapshot:
Name your snapshot and complete the required details. For temporary short-term snapshots, usually you won’t need any special network or advanced settings. Create the snapshot of the disk.
This usually takes less than a minute. We can see our snapshot under the snapshots blade:
Next go back to your VM and back to the disks blade. Attach an existing data disk and select one of the upgrade media disks we created earlier.
Connect to your server and you’ll see an upgrade drive. Note the drive letter.
The drive contents contains the upgrade media:
Open an admin PowerShell and change to the directory where your setup media is, and issue the command:
.\setup.exe /auto upgrade /dynamicupdate disable /eula accept
You’re more than likely using the desktop experience, so make sure to select the correct image version:
The upgrade should kick off. The upgrade time will vary, but shouldn’t take more than two hours.
When finished, you’ll see the new OS version displayed in the VM properties in Azure (these screenshots were taken from different machines, so they don’t all match what we selected earlier):
However, you’ll still see the original source image that the machine was built on. If this was a lift-n-shift, you’ll simply see the name of the OS disk, but if it was built using a gallery image, you will still see the original gallery image version.
Don’t forget to delete your snapshot a day or two after verifying that the upgrade was successful and everything is stable.