Azure In-Place Upgrade: Windows Server 2012–2025

Posted on by Shailesh Vaja
Azure In-Place Upgrade: Windows Server 2012–2025
Reading Time: 6 mins

Overview

Windows Server 2012 and 2012 R2 reached end of extended support back in October 2023. Windows Server 2016 mainstream support has also lapsed, with extended support winding down in the coming years. If any of your Azure VMs are still running these versions, they are no longer receiving security patches from Microsoft — which means every new vulnerability disclosed against these platforms is a permanent, unpatched exposure sitting inside your environment.

For many organizations, the instinctive response is “we’ll redeploy a new VM on a supported OS.” That’s a valid path, but it’s also slow, disruptive, and risky when the VM in question hosts legacy applications, custom configurations, or roles that are hard to reproduce from scratch. Azure’s in-place upgrade capability offers a faster, lower-risk alternative: it upgrades the Windows Server OS on an existing VM while keeping the server roles, settings, and data intact — no redeployment required.

This post explains why the upgrade matters, what versions are supported, and walks through the complete process end to end.

Why This Upgrade Is Business-Critical

1. Security exposure compounds over time. Every month an end-of-life OS stays in production, the gap between known vulnerabilities and available patches widens. Attackers actively scan for unsupported Windows Server versions because they’re predictable, well-documented targets.

2. Compliance and audit failures. Most compliance frameworks (ISO 27001, PCI-DSS, SOC 2, and regional regulations across the UAE and GCC) explicitly require supported, patchable software. Running EOL operating systems is a routine audit finding — and in regulated industries, it can block certifications outright.

3. Vendor and Azure support limitations. Microsoft support engineers can and will decline to troubleshoot issues tied to an unsupported OS. If a production incident hits a Windows Server 2012 VM, you may be on your own.

4. Rising operational risk. Legacy OS versions lack modern security baselines, updated TLS stacks, and current hardware/driver compatibility — increasing the chance of instability as surrounding infrastructure modernizes.

The business case is simple: upgrading is a controlled, scheduled project. Not upgrading is an open-ended incident waiting to happen.

What Is an In-Place Upgrade?

An in-place upgrade moves a VM from an older Windows Server release to a newer one while preserving server roles, application settings, and data. Unlike deploying a brand-new VM and migrating workloads over, this method upgrades the OS on the existing disk.

Azure currently supports in-place upgrades to:

  • Windows Server 2012
  • Windows Server 2016
  • Windows Server 2019
  • Windows Server 2022
  • Windows Server 2025

Important trade-off to understand first

Performing an in-place upgrade disconnects the data plane from the control plane of the VM. In practical terms, this means the following Azure-native capabilities stop working after an in-place upgrade:

  • Automatic VM guest patching
  • Auto OS image upgrades (for scale sets)
  • Hotpatching
  • Azure Update Manager

The VM’s source image metadata (publisher/offer/plan) also stays frozen at the original deployment values — only the OS binaries change. If you rely heavily on these platform-managed features, deploying a fresh VM on the target OS may be the better long-term option. In-place upgrade is best suited for VMs where redeployment is impractical and you’re comfortable managing patching manually going forward.

Supported Upgrade Paths

Target VersionSupported From
Windows Server 2012Windows Server 2008 (64-bit) or 2008 R2
Windows Server 2016Windows Server 2012 or 2012 R2
Windows Server 2019Windows Server 2012 R2 or 2016
Windows Server 2022Windows Server 2016 or 2019
Windows Server 2025Windows Server 2022, 2019, 2016, or 2012 R2

If you’re on 2012 or 2012 R2 today, you have two realistic routes: hop to 2016 or 2019 first, or in many cases jump straight to 2025 (2012 R2 can go directly to 2025). Map your exact path using the official Windows Server upgrade matrix before starting.

Before You Start: Prerequisites

  1. Validate the upgrade path for your specific source and target versions using the matrix above.
  2. Run the Azure VM Windows OS Upgrade Assessment Tool to catch known compatibility issues before you commit.
  3. Verify free disk space on the OS disk meets Windows Server’s hardware requirements. Expand the OS disk first if needed.
  4. Disable antivirus, anti-spyware, and firewall software temporarily — these commonly interfere with the upgrade process and should be re-enabled once the upgrade completes.
  5. Confirm volume licensing (KMS) activation. The Azure-provided upgrade media requires the VM to use Windows Server volume licensing — the default for any VM deployed from a generalized Azure image. VMs imported from on-premises may need their KMS client setup key reconfigured.
  6. Confirm the VM uses managed disks. Unmanaged disk support was retired in November 2022, and the in-place upgrade process requires managed disks. Migrate first if you’re still on unmanaged disks.
  7. Take a snapshot of the OS disk and any data disks. This is your rollback plan if anything goes wrong — treat it as non-optional.
  8. Set the system locale to English (United States). Upgrade media is only available in en-US; mismatched locale settings can cause failures.

Step-by-Step: Performing the Upgrade

Step 1 — Create the upgrade media disk

The upgrade media is delivered as a special managed disk image pulled from the Azure Marketplace. One upgrade media disk can service multiple VMs sequentially (one at a time), or you can create several in parallel for simultaneous upgrades.

Run this PowerShell script, adjusting the variables for your environment and target SKU (server2025Upgrade, server2022Upgrade, server2019Upgrade, server2016Upgrade, or server2012Upgrade):

# Customer specific parameters
$resourceGroup = "WindowsServerUpgrades"
$location = "Central India"
$zone = ""
$diskName = "WindowsServer2025UpgradeDisk"
$sku = "server2025Upgrade"

# Common parameters
$publisher = "MicrosoftWindowsServer"
$offer = "WindowsServerUpgrade"
$managedDiskSKU = "Standard_LRS"

# Get the latest version of the upgrade image from Azure Marketplace
$versions = Get-AzVMImage -PublisherName $publisher -Location $location -Offer $offer -Skus $sku | Sort-Object -Descending {[version] $_.Version}
$latestString = $versions[0].Version

$image = Get-AzVMImage -Location $location `
                        -PublisherName $publisher `
                        -Offer $offer `
                        -Skus $sku `
                        -Version $latestString

# Create the resource group if needed
if (-not (Get-AzResourceGroup -Name $resourceGroup -ErrorAction SilentlyContinue)) {
    New-AzResourceGroup -Name $resourceGroup -Location $location
}

# Create the managed disk from the upgrade image
if ($zone) {
    $diskConfig = New-AzDiskConfig -SkuName $managedDiskSKU -CreateOption FromImage -Zone $zone -Location $location
} else {
    $diskConfig = New-AzDiskConfig -SkuName $managedDiskSKU -CreateOption FromImage -Location $location
}

Set-AzDiskImageReference -Disk $diskConfig -Id $image.Id -Lun 0
New-AzDisk -ResourceGroupName $resourceGroup -DiskName $diskName -Disk $diskConfig

The location and zone must match the VM you’re upgrading. If your subscription context isn’t already correct, run Set-AzContext -Subscription '<subscription name or id>' first.

Step 2 — Attach the upgrade media to the target VM

This can be done whether the VM is running or stopped.

  1. Sign in to the Azure portal.
  2. Search for and open Virtual machines, then select the VM to upgrade.
  3. Go to Disks → Attach existing disks.
  4. Select the upgrade disk you created in Step 1.
  5. Click Save.

Step 3 — Run the upgrade (Windows Server 2016, 2019, 2022, or 2025)

The VM must be in the Running state.

  1. Connect via RDP or RDP over Bastion.
  2. Identify the drive letter of the upgrade disk (usually E: or F:).
  3. Open PowerShell and change directory to the upgrade disk.
  4. Run:
.\setup.exe /auto upgrade /dynamicupdate disable

To avoid the upgrade stalling on a manual EULA prompt, add the /eula accept switch:

.\setup.exe /auto upgrade /dynamicupdate disable /eula accept
  1. Choose the correct “Upgrade to” image matching your current version and edition, referencing the Windows Server upgrade matrix.

The VM will automatically disconnect your RDP session once the upgrade kicks off. From this point, monitor progress using Boot diagnostics → Screenshot in the Azure portal rather than trying to reconnect over RDP.

Step 3 (alternate) — Run the upgrade to Windows Server 2012 only

Windows Server 2012 uses a slightly different, GUI-driven process:

  1. Connect via RDP or RDP-Bastion.
  2. Identify the upgrade disk’s drive letter.
  3. Open PowerShell, navigate to the upgrade disk, and run:
.\setup.exe
  1. Select Install now.
  2. On Get important updates for Windows Setup, choose No thanks.
  3. Select the correct Windows Server 2012 “Upgrade to” image for your current version/edition.
  4. Accept the license terms and click Next.
  5. For installation type, choose Upgrade: Install Windows and keep files, settings, and applications.
  6. Review the Compatibility report — warnings can generally be ignored — and continue.
  7. The VM reboots and disconnects your RDP session automatically. Monitor progress via portal screenshots as above.

Post-Upgrade Cleanup

Once the upgrade completes successfully:

  • Delete the OS disk and data disk snapshots you created as a rollback safety net.
  • Delete the upgrade media managed disk.
  • Re-enable antivirus, anti-spyware, and firewall software you disabled before the upgrade.

Note that the VM’s image plan metadata does not change post-upgrade — this is expected behavior, not a failure.

If Something Goes Wrong: Rolling Back

This is exactly why the pre-upgrade snapshots matter:

  1. Create new managed disks from the OS disk snapshot and any data disk snapshots — in the same availability zone as the original VM.
  2. Stop the VM.
  3. Swap the OS disk back to the snapshot-based disk.
  4. Detach the data disks currently attached.
  5. Attach the data disks created from the snapshots.
  6. Restart the VM.

You’re back to a known-good state with minimal downtime.

Practical Recommendations for a Production Rollout

  • Never skip the Assessment Tool. Running the compatibility assessment before touching a production VM catches the majority of blocking issues in advance.
  • Batch by upgrade path, not by convenience. Group VMs by their current OS version so you can reuse the same upgrade media disk sequentially where possible.
  • Schedule a maintenance window. The VM disconnects from RDP mid-process — treat this like any other planned outage, with stakeholders informed.
  • Test on a non-production VM first, especially if you’re jumping multiple versions (e.g., 2012 R2 straight to 2025).
  • Re-evaluate Azure-native management features afterward. Since Auto Guest Patching, Hotpatching, and Update Manager are disabled by the process, decide how you’ll handle ongoing patching — manual WSUS/Update Manager re-enrollment, or a scheduled redeploy plan down the line.
  • Don’t treat in-place upgrade as a permanent strategy. It’s an excellent bridge to get off an unsupported OS quickly. For VMs where you want full platform-managed patching long-term, plan an eventual redeploy onto a fresh image.

Final Thoughts

If you’re managing Azure infrastructure anywhere in the region — from Dubai to the wider GCC — running end-of-life Windows Server versions is one of the most common and most fixable compliance and security gaps we see. The in-place upgrade path removes the usual excuse of “we can’t afford the downtime to rebuild,” letting you move from Windows Server 2012 or 2012 R2 all the way to 2025 without losing your existing configuration.

Plan it properly — snapshot first, assess the path, and schedule the window — and this becomes a routine maintenance task rather than a high-risk migration project.

Shailesh Vaja

P.S. Modern AI tool has been used for creating some of the content. Technical validation and proofing are done by the author.

Leave a Reply

Your email address will not be published. Required fields are marked *