VM SKU Migration

Muhammad Sarib Qureshi 0 Reputation points
2026-10-12T20:38:31.6+00:00

Hi all, I’m migrating multiple VMs to different SKUs, and the resize fails with the error “the underlying cluster is not available in the region”. Here’s what I’ve already tried without success:

  • Resizing from the portal and with az vm resize, which gave the same error
  • Deallocating the VM first and then resizing, which still failed
  • Checking the available sizes for the VM in the portal, where the target SKU doesn’t show up or fails when selected
  • Checking az vm list-skus for the region, to see if there are any restrictions
  • Checking my vCPU quota for the target VM family
  • Trying again at a different time, in case it was a temporary capacity issue
Azure Migrate
Azure Migrate

A central hub of Azure cloud migration services and tools to discover, assess, and migrate workloads to the cloud.

0 comments
Answer accepted by question author
Muhammad Umair Gulfam 80 Reputation points
2026-10-12T21:06:10.08+00:00

Hi Sarib,

A new VM isn’t pinned to any cluster, so creating one first is a good way to test whether the target SKU can be allocated in your region. If that works, the disk swap should work too. Here’s the approach I’d use.

First, check that the SKU is offered to your subscription and that you have quota and look at the Restrictions column. If it shows NotAvailableForSubscription, you’ll need a support request for SKU access. Then confirm there’s enough free vCPU quota for that VM family.

Second, note the old OS disk’s details (OS type, generation, zone, security type). The new VM has to match on OS type and Gen1/Gen2, and on zone if you use zones. If the old VM uses Trusted Launch, the new one needs the same.

Third, create a new VM with the target SKU using a marketplace image of the same OS and generation. This is your cluster check. If it deploys and starts, capacity is fine. If it throws the same error, the problem is SKU capacity in that region or zone, and swapping disks won’t get around it. In that case try another zone or region, or open a support request.

Fourth, deallocate the old VM, snapshot its OS disk, and create a managed disk from the snapshot (in the same zone as the new VM if you use zones). Working on a copy keeps a rollback path.

Fifth, deallocate the new VM and swap its OS disk to the copy, in the portal under VM > Disks > Swap OS disk. Then start it.

Finally, re-attach the data disks, move the old NIC (or assign the same static IP) if you want to keep the private IP, and re-enable extensions, backup and monitoring, since none of those carry over.

If it doesn’t boot, the usual causes are a generation mismatch, an older OS without an NVMe driver on an NVMe-based SKU, or apps relying on a temp disk that the new SKU doesn’t have.

Once everything is verified, delete the throwaway OS disk from the new VM, and keep the old VM and disk for a while before retiring them.

Hope this helps.

Was this answer helpful?

1 person found this answer helpful.
0 comments

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-10-12T20:38:50.06+00:00

    That error indicates a capacity constraint on the cluster that must host the VM size, not a quota issue.

    Based on the steps already completed, the supported next actions are:

    1. Choose a different VM size in the same region Even if a size appears generally available in a region, deployment or resize can still fail because the specific cluster or destination scope doesn’t have capacity for that SKU.
    2. Move or migrate to a different region or availability zone If the required SKU isn’t available where the VM is currently hosted, changing the destination region or zone is a supported workaround.
    3. If the VM is in an availability set, deallocate all VMs in that availability set and start them together Deallocating only one or some VMs in an availability set is treated like adding VMs back to the existing cluster, which can fail if that cluster lacks capacity. In Azure portal:
      • Go to Virtual machines
      • Use Add filter to filter by the availability set
      • Select all VMs in that availability set
      • Select Stop and wait until all show Stopped (deallocated)
      • Select Start to allocate them again as a batch
    4. If this is a migration target, verify the destination region supports the target size before retrying Use Azure CLI: 
         az vm list-skus --location "<destination-region>" --size "<vm-size>" \
     --query "[].{Name:name, Zones:locationInfo[].zones}" --output table
      If the command returns no output, that size isn’t available in that region.
    5. If the resize is blocked after a move or migration, check whether the target size is in a compatible VM family Switching between resource-disk and non-resource-disk families can require OS-level changes and can block resize scenarios after a move.

    What is already ruled out from the described testing:

    • Portal resize vs. az vm resize does not change the outcome.
    • Deallocating a single VM is not sufficient when the VM is tied to an existing availability set.
    • vCPU quota being available does not guarantee cluster capacity.
    • Retry alone does not help when the target SKU or cluster capacity is still unavailable.

    If the VM is not in an availability set and the target SKU still doesn’t appear in portal or fails after CLI validation and retries, the practical supported options in the context are to use a different SKU or a different destination region/zone.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.