If you’ve ever managed an environment in Azure, you’ve likely noticed a frustrating limitation: the "Size + Performance" slider for Managed Disks only moves in one direction: up.

While Windows and Linux operating systems have matured significantly in their ability to shrink volumes, the Azure Disk layer remains rigid. If you  provision a 1TB P30 disk for a workload that only needs 128GB, you are effectively stuck paying for significantly more storage than you need until you find a workaround or data grows to meet the capacity. 

Let’s take a look at a few different approaches to shrinking a disk in Azure, and which ones work best for what scenarios.

Why Can’t We Just Click "Shrink"?

While some SAN (Storage Area Network) systems handle this via thin provisioning and sophisticated controllers, doing this at Azure's scale, where data is replicated three times across different hardware, presents a significant risk of data corruption. To keep the platform "Five Nines" stable, Microsoft simply disables the feature.

The Architecture of a Downsize

Since there is no "Shrink" button, we have to either perform a manual migration, or leverage third-party tooling like Lucidity to handle shrinking for us. With Lucidity AutoScaler, expands and shrinks are done autonomously with no downtime based on real-time data requirements. By leveraging concepts like thin provisioning and storage pools, Lucidity is able to ensure that Managed Disks remain at ideal utilization levels at all times with no changes to infrastructure or need to take VMs offline. This delivers up to 70% cost savings on Managed Disk spend and hundreds of hours of manual support and maintenance efforts reclaimed. 

Lucidity is ideal for enterprises that are spending >$50k a month on Managed Disk. However, if you’re not at that scale of Azure usage yet, the alternative is to manually migrate your data to a smaller disk.

The workflow for manual migration generally looks like this:

1. Shrink the Partition: Use Disk Management (diskmgmt.msc) inside the VM to shrink the volume so the "Unallocated Space" is at the end.
2. Create a New Disk: Provision a smaller Managed Disk and attach it to the VM.
3. Migrate Data: Move bits from Disk A to Disk B.
4. Swap: Change drive letters or swap the OS disk.

Now, there are three primary approaches to migrating data to consider.

Migration Strategy 1: The File-Level Copy (Robocopy)

The simplest way is to copy files from the old drive to the new one. However, if you are moving an active application or an OS, locked files will cause the process to fail.

Best for: Data drives with no active database handles.

PowerShell

# Using Robocopy for multi-threaded file migration
# /E: Copy subdirectories, including empty ones.
# /COPYALL: Copy all file info (ACLs, Attributes, etc.)
# /MT:32: Use 32 threads for faster performance.
# /XJ: Exclude Junction points (prevents infinite loops)

robocopy E:\ F:\ /E /COPYALL /MT:32 /XJ /R:3 /W:10 /LOG:C:\MigrationLog.txt

Migration Strategy 2: VSS Snapshots & Block-Level Copy

To bypass the "locked file" issue, we can use the Volume Shadow Copy Service (VSS). This creates a point-in-time snapshot of the volume. Then you can mount a VSS snapshot to a folder or mount point, and access it as if it was a filesystem volume.

The Optimization Trick:

If you shrink the volume within the Guest OS first, you ensure that all "valid" data blocks are at the beginning of the disk. You can then use a block-level tool (like dd for Linux or specialized PowerShell wrappers for Windows) to copy only the used portions. This is significantly faster than file-by-file copying because it ignores the file system overhead.

Migration Strategy 3: The VDS Mirroring Method (The "Pro" Choice)

The most powerful (and often overlooked) feature in Windows is the Virtual Disk Service (VDS) Mirroring. This allows you to create a RAID-1 mirror between your oversized disk and your new, smaller disk.

How it works: Windows ensures that every write hitting the old disk is simultaneously written to the new disk. Once the "Sync" status reaches 100%, the data is identical.

Warning: To use mirroring, both disks must be converted to Dynamic Disks.

The Workflow via Diskpart:

Plaintext

list disk
select disk 0 (The original large disk)
convert dynamic

select disk 1 (The new smaller disk)
convert dynamic

select volume 1 (The volume on the large disk)
add disk 1

‍

The Catch: While this ensures zero data loss and allows for a near-instant "break" (switchover), the performance is low. The synchronization process is throttled by the VM's IOPS limit because it has to read from one disk and write to another while still serving application traffic. Expect a significant "IOPS hit" during the mirroring phase.

What's the best approach to shrinking Managed Disks in Azure?

‍

There you have it, three methods for manually migrating data to shrink Managed Disks. As you can see, none of these are perfect, and manual shrinking requires downtime and significant complexity. As a result, most organizations tend to either swallow the excess budget wasted on overprovisioning as just the cost of doing business, or dedicate significant resources to shrinking at scale over a period of weeks and months. 

‍

The alternative is to use Lucidity AutoScaler to handle expands and shrinks for you. Enterprises of all sizes and industries rely on Lucidity to eliminate overprovisioning waste autonomously, saving up to 70% on their cloud block storage bill, hundreds of hours of engineering time, and avoiding unplanned downtime from overly-full disks. Get a personalized demo if you'd like to learn more.