How We Cut SQL Server Licensing Costs by 75% With Azure Migration For a Client

Fear was Driving This Infrastructure Decisions

Our client was running SQL Server on 32 physical cores on-premises. 

They knew they were overspending on licensing. But they were terrified to scale down.

The reason? On-premises hardware locks you in. Need to add cores later? You’re looking at new hardware procurement, installation delays, and more licensing costs. So they played it safe with massive over-provisioning.

After analyzing their workload, we found something interesting. They were using maybe 25% of their compute capacity. Three-quarters of their licensing costs were funding cores that sat idle.

We recommended dropping from 32 cores to 8 vCores in Azure. The client was nervous about the 75% reduction. But Azure changed the risk equation completely.

Need more power? Click a button. Scale up in minutes, not months.

Want a full guide on SQL Server Migration? Check it out HERE. 

Why On-Premises Creates the Over-Provisioning Trap

Physical hardware forces you into a corner. 

Adding capacity later means weeks of procurement and vendor coordination. For production databases, that timeline is unacceptable.

So IT teams overestimate. They buy more cores than needed because the alternative feels risky. Better to waste money on unused capacity than risk downtime from insufficient resources.

This client had been through this before. When we suggested going with fewer cores during a previous hardware refresh, they asked “what if we start facing issues?” 

Purchasing new CPUs is expensive. So they decided to stick with the same core count and stay safe.

The problem? They were running SQL Server Standard Edition. At roughly $2,000 per core, those extra 24 unused cores were costing them about $48,000 annually in unnecessary licensing.

We’ve written a thorough blog on when  to downgrade to save $6000 per core. 

The Workload Analysis That Revealed the Waste

Before recommending any migration, we analyzed their actual SQL Server usage. 

Not theoretical peaks. Not what they thought they needed. What they were actually using.

The data was clear. Their workload wasn’t utilizing the full hardware. The original on-premises setup wasn’t even designed for OLTP workload. They had pushed new servers maybe six to nine months prior, but still overestimated because scaling up in the cloud seemed uncertain to them.

We were 90% confident that fewer vCores could handle the same workload. 

Azure’s newer generation CPUs and hardware architecture meant 8 modern vCores would match or exceed the performance of their 32 older physical cores.

The client ran all the pre-migration tests. No bottlenecks. Everything worked as expected. We weren’t seeing any performance issues.

The Migration: 3TB Database in 15 Minutes

The migration strategy focused on minimal downtime. With a 3TB database, you can’t just take the system offline for hours.

Here’s how we did it:

• Day before migration: We took a full backup of the production database and ran the restore with NORECOVERY on the Azure VM. This happened overnight while the system stayed online.
• During migration window: We turned off the application so no new connections hit the database. Then we took a differential backup. Since this was a weekend with minimal activity, the differential was fairly small.
• Final restore: We restored the differential backup and brought the database online in Azure.

Total downtime: 15 minutes. Maybe less.

The migration window was short because we did the heavy lifting beforehand. 

The full backup and restore happened overnight. During the actual migration, we only transferred the differential changes.

The Bonus Win: File Server to Blob Storage

The client had been running a file server on-premises and facing latency issues. 

Their internet connection to vendor systems where they pulled data was causing delays.

They asked if migrating to Azure would create huge latency to their file server. We recommended migrating the file server to Azure Blob Storage instead.

The result? Latency completely eliminated. Blob Storage is faster and more reliable than their local file server ever was. 

With SQL Server and file storage both in Azure, there’s basically no latency between them.

This solved a problem they had been fighting for years.

Migration Results: Same Performance, 75% Lower Costs

The numbers tell the story:

• Licensing costs: 24 fewer cores to license. Over $48,000 in annual savings on Standard Edition licensing alone.
• Performance: Zero issues after go-live. The 8 vCores handled everything their 32 physical cores did.
• Downtime: 15 minutes for a 3TB database migration.
• Reliability: Better than their old hardware. Azure infrastructure plus keeping the old hardware as a DR site improved their disaster recovery setup.
• Flexibility: Need more capacity? Scale up instantly. No procurement delays.

The client went from 32 cores they didn’t need to 8 cores that handle everything perfectly.

Why Cloud Flexibility Changes Everything

The real value wasn’t just cost savings. It was eliminating the fear that drives over-provisioning.

The client was confident starting with 8 cores because Azure isn’t precious new hardware. It’s a button click to scale up if needed.

On-premises, downsizing is scary. You’re committing to physical hardware that’s expensive to change. In the cloud, you can test aggressive sizing knowing you can adjust in minutes if performance suffers.

This changes your capacity planning completely:

• Start lean: Begin with what you actually need based on workload analysis, not worst-case scenarios.
• Test without risk: Nervous about downsizing? Try it. If it doesn’t work, scale back up instantly.
• Pay for what you use: Stop funding cores that sit idle. Adjust capacity as your needs change.

The client had been overspending for years because they were afraid of undersizing. Azure removed that fear by removing the adjustment cost.

How to Identify If You’re Over-Provisioned

Run this quick analysis on your SQL Server environment:

• Check average CPU utilization over 2-4 weeks. If you’re consistently below 30-40%, you’re over-provisioned. Track peaks too, but don’t let occasional spikes drive your baseline capacity.
• Calculate cost per utilized core. Take annual licensing costs divided by actual average cores used (not provisioned). If the number is painful, you’re wasting money.
• Review your hardware age. Older physical servers often have lower per-core performance than modern cloud vCores. You might need fewer cloud cores than physical cores for the same workload.
• Ask why you have your current core count. If the answer is “our previous DBA thought we needed it” or “we didn’t want to risk going lower,” you probably have waste.

Check out this success story how we saved 66+ minutes of daily processing in 6 weeks for a client. 

Conclusion

Fear-based infrastructure decisions cost you thousands monthly in unnecessary licensing. 

The solution isn’t reckless downsizing. It’s data-driven right-sizing enabled by cloud flexibility.

This client went from 32 cores to 8 vCores. Saved over $48,000 annually. Improved performance with Blob Storage integration. Reduced complexity. Zero regrets.

When you can scale up instantly, you can afford to start lean and add capacity only when usage patterns demand it.

Stop paying for cores you don’t need.