Reconcile guest disk mappings before converting an Azure VM from SCSI to NVMe

Source facts

Changing an Azure VM from SCSI to NVMe changes how the guest uses its disks, not the remote OS or data storage. Device enumeration changes, and Windows data-disk assignments can shift without persistent identifiers. The conversion script stops and deallocates the VM. Microsoft excludes customized VMs whose third-party software can alter boot behavior, storage or filter drivers, or disk enumeration. On v6 sizes, temporary disks start RAW rather than preformatted NTFS. Microsoft Learn.

Applicability

Confirm that the target size, OS, and installed software fit the supported conversion path. Inventory boot configuration, persistent mounts or drive assignments, and temporary-disk initialization. Check the additional preview registration requirement if the selected sizes differ in temporary-disk support.

DSE recommendation

Record persistent disk identities and boot prerequisites before approving the controller conversion and VM deallocation. Have the application owner identify every path that depends on a disk’s current enumeration. Review the conversion script and the guest-readiness changes in a representative nonproduction VM. Treat temporary-disk formatting as a separately scoped operation with exact device identification; never apply a blanket formatting step to all newly enumerated disks.

Verification

After the authorized conversion, inspect both the Azure controller setting and the controller visible inside the guest. Reconcile OS, data, and temporary disks with the original map and test application access. Preserve the documented return command and original size in the change record. Stop on an unexpected disk identity or boot problem before attempting broad automated repairs.

Official references

Microsoft Learn: Convert Linux and Windows VMs from SCSI to NVMe. Source reviewed September 9, 2026.