Is there any data loss risk due to changing disk type?

No changing the managed disk SKU from Standard HDD to Premium SSD is a metadata-only operation and does not destroy data on the disk. The disk's contents (your Storage Spaces virtual disk / SQL data) are preserved across the conversion as long as the VM is stopped (deallocated) before the SKU change. [learn.microsoft.com] [learn.microsoft.com]

Why it's safe

• Azure managed disks support an in-place SKU switch between Standard HDD, Standard SSD, and Premium SSD without recreating the disk or copying data. [learn.microsoft.com]
• Microsoft's official guidance and Q&A both confirm: deallocate the VM → update the SKU → start the VM, with no loss of data. [learn.microsoft.com], [learn.microsoft.com]
• The conversion only changes the disk's performance tier (backend storage class); the blob/data blocks remain intact.

1. VM size must support Premium Storage

The VM SKU must be an "s" series (e.g., DSv2, ESv3, etc.). If it isn't, the disk SKU change will fail / VM won't start. Resize the VM to a Premium-capable size first if needed. [learn.microsoft.com]

2. Storage Spaces / virtual disk consideration

Since the 3 TB virtual disk is built inside the guest OS using Storage Spaces over 6 × 500 GB disks, you must:

• Upgrade ALL 6 disks in the same maintenance window mixing SKUs underneath one Storage Spaces pool will give you inconsistent performance and is not supported as a steady state.
• Do not resize the individual managed disks (keep them at 512 GiB / P20). Resizing underlying columns of a Storage Spaces pool is not supported from Azure side; only the SKU change is safe.

3. Take a backup / snapshot first (strongly recommended)

Even though the conversion itself is non-destructive, always take a snapshot of each of the 6 data disks (and the OS disk) before the change. This is your rollback path and is the standard support-defensible practice for any SQL data disk operation.

4. Windows Server 2012 R2 lifecycle note - WS 2012 R2 is out of mainstream/extended support (requires ESU). The disk conversion itself is unaffected, but flag this to the customer — Premium SSD won't fix the OS support boundary.
5. Operational limits

• Disk SKU can only be changed twice per day per disk. [learn.microsoft.com]
• VM must be Stopped (deallocated) in the portal — not just shut down from the guest OS — otherwise the SKU update will be rejected. [learn.microsoft.com]

6. Verify host caching after upgrade

For SQL data disks on Premium SSD, Microsoft recommends host caching = None for data/log disks (ReadOnly is fine only for read-heavy data). Re-validate this after the upgrade.

Recommended sequence

1. Snapshot all 6 data disks (and OS disk).
2. Inside the guest: ensure SQL Server is cleanly shut down; flush Storage Spaces if possible.
3. Stop-deallocate the VM from the Azure Portal.
4. Confirm VM size supports Premium Storage (resize if not).
5. Change each of the 6 data disks' SKU to Premium_LRS (P20). [learn.microsoft.com]
6. Start the VM, verify the Storage Spaces virtual disk mounts healthy, and confirm SQL Server starts cleanly.
7. Validate IOPS/throughput with DiskSpd or SQLIO before handing back to the customer.

Hi,

There's no specific statement in the documentation saying that there is additional risk of data loss when switching from one disk type to another, and doing so is a normal, expected and documented procedure. I've converted disk types many times over the years and have not experienced any data loss.

As always, you should perform regular backups and in cases like this it is good idea to perform snapshot or backup immediately beforehand, just in case.

Regardless of what disk type you use, redundancy setting, etc., there is always a chance of some sort of platform or OS failure causing data loss. The chance is relatively small but it is critical to remember data loss can happen at any time and you should prepare ahead of time. It is easy to get complacent.

Convert the disk type of an Azure managed disk

https://learn.microsoft.com/en-us/azure/virtual-machines/disks-convert-types

Please click Accept Answer and upvote if the above was helpful.

Thanks.

-TP

Hello Nagrath, Richa,

Greetings! Thanks for raising this question in Q&A forum.

There is no inherent data loss risk caused by the disk type itself when you go from Standard HDD to Premium SSD. The risk in your scenario comes purely from the process specifically from the disk swap/attach steps if not done carefully, since the data on the disk is what matters, not the underlying storage tier.

Here is the safe step-by-step approach for your in-place upgrade:

Step 1: Take a Backup First Before doing anything, take a full VM backup (Azure Backup) or at least a snapshot of each of the 6 managed disks. This gives you a rollback point in case anything goes wrong during the migration.

Step 2: Stop SQL Server Services Before shutting down the VM, gracefully stop the SQL Server services on the guest OS. This ensures SQL has flushed all data to disk and there are no pending writes.

Step 3: Stop and Deallocate the VM Fully stop and deallocate the VM (not just shut down the OS) from the Azure Portal. Disk type conversion can only be done while the VM is in a deallocated state.

Step 4: Convert Each Disk's SKU For each of the 6 disks, go to the disk resource in the Azure Portal → Disk SKU → change from Standard HDD to Premium SSD (P20). This is a metadata-level change Azure does not wipe or recreate the underlying data blocks, it simply changes the performance tier of the existing managed disk.

Step 5: Start the VM and Verify Once all 6 disks are converted, start the VM again. Verify that:

• All 6 disks are attached and visible in Disk Management
• The Storage Pool / Storage Spaces configuration (the 3TB virtual disk) is intact
• SQL Server starts cleanly and the databases come online without errors

Step 6: Run a Database Consistency Check After SQL Server is back online, run DBCC CHECKDB on your databases to confirm there is no corruption, just as a good practice after any storage-level change.

A few important notes:

• Since your 3TB volume is built using Storage Spaces across 6 disks, make sure all 6 disks are converted before restarting having a mix of SKUs won't cause data loss, but converting them together avoids confusion.
• The disk SKU change is a control-plane operation in Azure, not a data rewrite, so the actual bits on disk remain untouched.
• The main risk areas are application-level (SQL not shut down cleanly) rather than the disk type change itself so Steps 2 and 6 are the most important for protecting your data.

If this answer helps you kindly accept the answer which will help others who have similar questions

Best Regards,

Jerald Felix.