How TechCorp Saved 40% Storage Costs Using Thin Provisioning Strategy

A mid-sized manufacturing company reduced their VMware storage footprint from 50TB to 30TB of actual consumption while supporting the same number of VMs. Here’s exactly how they did it and what you can replicate.

Results at a Glance

Key metrics achieved:

• 40% reduction in physical storage consumption (50TB to 30TB)
• $85,000 saved in deferred storage expansion costs
• Zero performance degradation across production workloads
• 6-week implementation timeline from planning to completion

Timeline: March 2024 – April 2024
Investment: 120 hours of admin time, no additional software costs

The Starting Point

TechCorp operates a 500-employee manufacturing facility with a VMware environment running 180 VMs across production, development, and test workloads. Their storage infrastructure consisted of three Dell EMC Unity arrays totaling 50TB of usable capacity.

The problem: Storage capacity was hitting 85% utilization. The IT team faced a choice—purchase an additional $200,000 storage array or find a way to optimize existing capacity. Previous attempts at VM cleanup only recovered 2TB, nowhere near enough to delay the storage purchase.

Specific challenges:

• Over-provisioned VMs consuming more storage than necessary
• Development and test VMs allocated 100GB+ but using less than 30GB
• No visibility into actual storage consumption vs. allocated capacity
• All VMs provisioned as thick lazy zeroed by default

Goal: Reduce storage consumption by at least 30% without impacting production performance or requiring application changes.

The Strategy Implemented

The infrastructure team chose a phased approach focusing on non-production workloads first, then carefully selected production VMs running on all-flash storage where thin provisioning performance impact would be minimal.

Methodology:

1. Audit all VMs to identify actual disk usage vs. allocated capacity
2. Convert development and test VMs to thin provisioning first (low risk)
3. Migrate selected production VMs on all-flash arrays to thin provisioning
4. Implement monitoring to track provisioned vs. used capacity
5. Establish policies to prevent future over-provisioning

Tools used:

• VMware vCenter Storage Reports for capacity analysis
• PRTG Network Monitor for ongoing datastore monitoring
• PowerCLI scripts for bulk VM analysis and conversion tracking

Team: Two senior VMware administrators, one storage engineer
Budget: Internal labor only, no software purchases required

How It Was Done

Step 1: Comprehensive Storage Audit (Week 1)

The team ran PowerCLI scripts to analyze every VM’s provisioned capacity vs. actual disk usage. They discovered that 120 of 180 VMs were using less than 50% of their allocated storage. Development VMs were the worst offenders—provisioned at 100GB but averaging 25GB actual usage.

Step 2: Risk Assessment and Categorization (Week 1-2)

VMs were categorized into three groups:

• Low risk: Development and test VMs (80 VMs) – convert immediately
• Medium risk: Production VMs on all-flash arrays (60 VMs) – convert after testing
• High risk: Production databases on traditional SAN (40 VMs) – keep thick provisioned

Step 3: Development Environment Conversion (Week 2-3)

Using Storage vMotion during business hours, the team converted 80 development and test VMs from thick to thin provisioning. This immediately reclaimed 12TB of storage capacity with zero downtime.

Challenge encountered: Some VMs had large snapshots that needed deletion before conversion. The team implemented a snapshot cleanup policy requiring deletion within 72 hours.

Step 4: Production VM Testing and Conversion (Week 3-5)

The team selected 10 production VMs on all-flash storage for pilot testing. After monitoring performance for one week with no degradation, they converted the remaining 50 production VMs in the medium-risk category. This reclaimed an additional 8TB.

Key decision: Production SQL Server and Oracle databases remained thick eager zeroed. The performance risk wasn’t worth the potential 5TB savings from those workloads.

Step 5: Monitoring Implementation (Week 5-6)

PRTG sensors were configured to monitor both provisioned and used capacity on all datastores. Alerts were set at 80% actual usage to provide early warning before capacity issues could impact operations.

The Outcomes

Storage reduction achieved:

• Development/test environment: 12TB reclaimed (60% reduction)
• Production environment: 8TB reclaimed (25% reduction)
• Total: 20TB reclaimed from 50TB (40% overall reduction)

Financial impact:

• Deferred storage array purchase: $200,000
• Implementation cost (labor): $15,000
• Net savings: $185,000
• ROI: 1,233%

Performance metrics:

• Zero increase in storage latency across converted VMs
• No application complaints or performance tickets
• VM creation time reduced by 75% for thin-provisioned VMs

Timeline of improvements:

• Week 2: First 12TB reclaimed from dev/test
• Week 5: Additional 8TB reclaimed from production
• Week 6: Monitoring fully operational

Unexpected benefits:

• Faster VM provisioning for development teams
• Better visibility into actual storage consumption trends
• Identified 15 VMs that could be decommissioned entirely

What You Can Learn

Success factors identified:

1. Start with low-risk workloads. Converting development and test environments first built confidence and delivered quick wins without risking production.
2. Don’t convert everything. Keeping production databases on thick provisioning was the right call. The 5TB potential savings wasn’t worth the performance risk.
3. Monitoring is non-negotiable. Without tracking provisioned vs. used capacity, you’ll eventually fill your datastores and cause outages.
4. All-flash arrays handle thin provisioning well. The performance difference was unmeasurable on modern storage platforms.
5. Snapshot policies matter more with thin provisioning. Uncontrolled snapshots can fill datastores faster than expected.

What might not transfer:

• Results depend heavily on how over-provisioned your VMs are currently
• Storage array performance characteristics vary significantly
• Organizations with mostly database workloads will see smaller savings

How to Apply This

Step 1: Run a storage audit

Use PowerCLI or vCenter storage reports to identify VMs with large gaps between provisioned and used capacity. Focus on VMs using less than 50% of allocated space.

Step 2: Categorize by risk

Separate VMs into low-risk (dev/test), medium-risk (production on modern storage), and high-risk (databases, tier-1 apps). Start with low-risk only.

Step 3: Convert and monitor

Use Storage vMotion to convert VMs during maintenance windows or business hours (it’s non-disruptive). Implement monitoring before you convert production workloads.

Step 4: Establish policies

Create VM provisioning standards that default to thin provisioning for appropriate workloads. Set snapshot retention policies to prevent capacity issues.

Required resources:

• VMware admin with Storage vMotion experience
• Monitoring tool that tracks provisioned vs. used capacity
• 2-4 weeks for phased implementation
• Maintenance windows for high-priority VMs (optional)

Potential obstacles:

• Resistance from application teams worried about performance
• Lack of monitoring tools to track thin provisioning safely
• Storage arrays that don’t handle thin provisioning efficiently