VMSS manual upgrade (Uniform mode) — resizing D2s_v3 instances to D4ls_v5 via model update + Instance Upgrade: confirming behavior, RI implications, and precautions

Question

VMSS manual upgrade (Uniform mode) — resizing D2s_v3 instances to D4ls_v5 via model update + Instance Upgrade: confirming behavior, RI implications, and precautions

K Yogesh 0

Hi all,

We're running a Virtual Machine Scale Set (Uniform orchestration mode) with 3 instances. Originally 1 instance was on Standard_D4ls_v5 and 2 were on Standard_D2s_v3. Since D2s_v3 is being deprecated, However, checking individual instance details shows:

Latest model applied: No on all 3 instances

Instance SKU still shows Standard_D2s_v3 on the affected instances, despite the model now specifying D4ls_v5

We're planning to use the Upgrade option under Instances (per this doc)
https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-perform-manual-upgrades?tabs=portal
to bring instances in line with the new model, one at a time, starting with a single instance as a canary before doing the rest.

Questions:

Behavior confirmation: When we click "Upgrade" on an instance whose current SKU differs from the model's SKU, will Azure actually resize/redeploy the instance to match the new SKU (D4ls_v5), or does manual Upgrade only reapply image/extension config and not change VM size? Is a Reimage vs Upgrade distinction relevant here?

Data loss: Does this Upgrade operation reset the OS disk (reimage), or does it preserve the OS disk and simply resize the VM in place? We want to confirm what, if anything, on the OS disk survives.

Downtime: Roughly how long is an individual instance unavailable during this Upgrade/resize process, and does the load balancer automatically stop routing traffic to it during that window (assuming health probes are configured), or do we need to manually drain connections first?

Best practice for staged rollout: For a 3-instance Uniform-mode scale set behind a load balancer, is upgrading one instance at a time (canary-first) the recommended approach, or would you recommend Rolling upgrade policy instead of Manual for this kind of SKU migration?

Reserved Instance implications: We intend to purchase an RI for Standard_D4ls_v5 (not D4ls_v3) once all 3 instances are consistently on this SKU.

Can you confirm Dsv3/Dlsv3 and Dlsv5 fall into separate Instance Size Flexibility groups, i.e., an RI purchased for one series does not apply to the other?

Given we're mid-migration, would you recommend a 1-year vs 3-year RI term in this scenario, or is there a documented way to change/exchange RI term/SKU later without penalty if our sizing needs shift again?

Post-upgrade validation: What's the definitive way to confirm an instance is fully "on the latest model" beyond just the "Latest model applied" flag — should we also check Health state, extension status, and image version explicitly?

Any guidance, doc links, or gotchas from your experience with SKU migrations on Uniform-mode VMSS would be appreciated.

Vinodh247-1375 43,506 Reputation points Volunteer Moderator

2026-07-11T16:03:10.18+00:00
Please confirm if you had a chance to try any of the suggestions provided for your question.

Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful.

If in case you have any resolution please share the same here with the community as it can be helpful to others. Else, please respond with more details and we will try to see if we can help further.

1 answer

Your answer

Vinodh247-1375 43,506 Reputation points Volunteer Moderator

2026-07-11T16:03:10.18+00:00

Please confirm if you had a chance to try any of the suggestions provided for your question.

Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful.

If in case you have any resolution please share the same here with the community as it can be helpful to others. Else, please respond with more details and we will try to see if we can help further.

Answer 1

Hi ,

Thanks for reaching out to Microsoft Q&A.

Manual Upgrade on a Uniform VMSS will reconcile the instance with the model, including VM size changes, so yes, your D2s_v3 instances will be recreated to D4ls_v5, not just patched; this is not a simple inplace resize but effectively a redeploy using the updated model, and unlike Reimage (which explicitly wipes OS disk), Upgrade typically preserves the OS disk if compatible, but in practice for SKU change you should assume a recreate event and treat OS disk as non-persistent unless you are using managed data disks for state. Expect 1 to 5 minutes of downtime per instance (depends on image + extensions), and with a proper load balancer health probe, traffic is automatically drained and no manual step needed unless you want graceful applevel draining. Your canary-first, one-instance-at-a-time approach is exactly right for a 3-node setup; Rolling Upgrade policy is better for larger fleets but overkill here. On RI: Dsv3/Dlsv3 and Dlsv5 are different flexibility groups, so RIs do not cross-apply, and you should only purchase after full migration; go with 1-year RI given you are already in transition, azure does allow RI exchanges (SKU/region/series) but not term reduction (3->1), so 3 year locks you in more. Post-upgrade, validate via instanceView (PowerState + ProvisioningState), modelApplied=true, VM size, extension provisioning status, and optionally image version alignment, that combination is the real confirmation, not just the flag.

Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful. This will be benefitting other community members who face the same issue.