Azure VM resize: PowerShell lists Dv5 sizes, but Azure Portal only offers Dv4

Hello,

We recently migrated two production Azure virtual machines away from the retiring Bv1 family.

Initially, the VMs were running as:

Standard_B2ms

Standard_B4ms

Our goal was to move them to a newer supported VM family.

Environment

Region: France Central

Managed OS disks (one Standard SSD, one Standard HDD/Standard LRS)

SCSI disk controller

Windows Server virtual machines

What we observed

After stopping and deallocating the VM, we queried the available resize targets using PowerShell:

Get-AzVMSize ` -ResourceGroupName "<ResourceGroup>" ` -VMName "<VMName>"

For one VM, PowerShell returned, among others:

Standard_D2ads_v5 Standard_D2ds_v5 Standard_D2d_v5 Standard_D2as_v4 Standard_D2ds_v4

For the other VM, it returned:

Standard_D4ads_v5 Standard_D4ds_v5 Standard_D4d_v5 Standard_D4as_v4

However, when opening VM → Size in the Azure Portal, the v5 sizes were not available.

Only the following sizes appeared:

Standard_D2as_v4

Standard_D4as_v4

As a precaution, we resized both VMs using the sizes proposed by the Azure Portal:

Standard_B2ms → Standard_D2as_v4

Standard_B4ms → Standard_D4as_v4

The migration completed successfully and both VMs are running correctly.

Question

Can someone explain why there is a difference between:

the sizes returned by Get-AzVMSize, and

the sizes displayed by the Azure Portal?

More specifically:

Does Get-AzVMSize return VM sizes that are not actually valid resize targets?

Does the Azure Portal apply additional compatibility or capacity checks that PowerShell does not?

Is this related to:

regional capacity,

VM generation,

disk controller,

managed disk type,

host cluster,

or another compatibility requirement?

Would you recommend staying on Das_v4, or should we plan another migration to Dads_v5 if possible?

I am trying to understand the reason behind the different behavior rather than forcing the resize through PowerShell.

Thank you in advance for your insights.