Azure SQL Reservations Lose Exchange Rights on February 1, 2027. Here's What to Do Now.

What is changing on February 1, 2027?

Microsoft is removing exchange eligibility for Azure Reservations on services that are also covered by an Azure savings plan. Until this year, Azure SQL Database wasn't one of them.

That changed on March 18, 2026, when Microsoft launched savings plan for databases, a one-year, spend-based commitment that covers Azure SQL Database, Azure SQL Managed Instance, Azure Database for PostgreSQL, Azure Database for MySQL and Azure Cosmos DB. Because Azure SQL Database is now covered by a savings plan, its reserved capacity falls under the new exchange policy.

In practice:

• Reservations bought on or after February 1, 2027 can't be exchanged.
• Reservations bought before February 1, 2027 keep exactly one final exchange.

Why does this matter more for databases than for compute?

Because there's no flexible three-year option to fall back on.

For virtual machines, Azure savings plan for compute comes in one-year and three-year terms. Savings plan for databases is one year only. So the deepest discount available on Azure SQL Database is still three-year reserved capacity, and from February 1 that discount comes with no way to change course.

Until now, exchanges were how most FinOps teams fixed their own forecasting mistakes: a reservation in the wrong region, the wrong tier, or for a workload that moved. After the deadline, that safety net is gone for new Azure SQL purchases.

What should you do before February 1?

1. Inventory by purchasing model, not just by cost

Split your Azure SQL estate into DTU, vCore provisioned and vCore serverless. Cost tells you where to look. The purchasing model tells you what you can do when you get there. DTU databases can't use reserved capacity, savings plans or Azure Hybrid Benefit at all.

2. Fix known mismatches while exchanges still work

If you have reservations in the wrong region, tier or size, exchange them now, while you still can. Every reservation bought before the deadline keeps one final exchange, so decide deliberately where that last one goes.

3. Treat DTU-to-vCore migration as a rate project

Migration is usually filed under modernization and pushed down the list. It's actually the gate on every commitment discount. In one estate we priced in August 2026, moving DTU elastic pools to vCore cut monthly SQL compute cost by about 13% before any commitment, and about 49% after one. Price it pool by pool, because pools below roughly 180 to 200 DTUs can cost more on vCore.

4. Match the commitment to your confidence

• Stable production databases whose service, region and tier haven't changed in six months are candidates for reserved capacity, stacked with Azure Hybrid Benefit if you hold the licenses.
• Estates mid-migration or spread across engines fit savings plan for databases better.
• Unpredictable workloads shouldn't sit on any native one-year or three-year commitment.

5. Update your approval process

After February 1, a three-year Azure SQL reservation can't be undone. Approval workflows should treat it like any other three-year contract, with the same scrutiny on breakeven and on whether the architecture will still look the same in three years.

How Archera handles the Azure SQL commitment problem

The direction of Azure policy is clear: deeper discounts, less reversibility. Archera's approach is to separate the discount from the length of the commitment, instead of asking you to forecast three years out.

• 30-day Guaranteed Commitments buy native Azure Reservations directly into your tenant, with an obligation measured in weeks rather than years. Your relationship with Microsoft and your reseller doesn't change.
• One-year Guaranteed Commitments cover Azure Reservations and Azure savings plans, at deeper discounts than the equivalent native one-year commitments.
• If capacity goes unused, Archera covers the loss under the terms of its guarantee. That protection is a contract between Archera and you, so it doesn't depend on Microsoft's exchange rules or its $50,000 annual cancellation cap.

‍

When the native safety net goes away on February 1, the protection you rely on shouldn't have been built on top of it.

‍

See where your Azure SQL estate stands. Archera's platform is free and shows your coverage, utilization and missed savings across Azure, AWS and Google Cloud.

Get a free savings assessment.

‍

Frequently asked questions

When does the Azure SQL reservation exchange change take effect?

February 1, 2027. Azure SQL Database reserved capacity bought on or after that date can't be exchanged.

‍

What happens to reservations I already own?

Reservations bought before February 1, 2027 keep exactly one final exchange.

‍

Why is Azure SQL Database affected?

Microsoft's policy removes exchanges for reservations on services covered by a savings plan. Savings plan for databases, launched March 18, 2026, made Azure SQL Database one of those services.

‍

Is there a three-year savings plan for databases?

No. As of September 2026, savings plan for databases is one year only. Azure savings plan for compute offers both one-year and three-year terms.

‍

Can I still cancel an Azure reservation?

Azure cancellations are subject to a $50,000 annual cap. Exchanges, not cancellations, are what most teams used to correct mistakes.

‍