Azure Reservation Exchanges End 1 February 2027: Rethinking Your Commitment Strategy

Reservations were a safe bet for years precisely because you could exchange them. You bought a three-year commitment on the D series, moved to the E series a year later, and the exchange squared it up. The cost of guessing wrong was close to zero.

From 1 February 2027 that no longer holds. Reservations purchased after that date are not exchangeable if a savings plan covers the service — which means virtual machines, App Service, SQL Database, MySQL, PostgreSQL and others. Reservations purchased before it are entitled to one final exchange.

Microsoft announced this on 30 July 2026. There is enough time left to forget about it — and that is exactly the problem, because one of the traps triggers itself.

The trap this article exists for

An auto-renewal after 1 February 2027 manufactures a non-exchangeable reservation. Silently.

Auto-renewal is not processed as a continuation of the original reservation. It is processed as a new purchase. A new purchase after the cutover date means a non-exchangeable reservation. No approval step, no alert, and on the invoice it looks identical to last year.

So the three-year reservation you bought in 2024, knowing it could be exchanged, renews itself in 2027 — and the renewed one cannot be exchanged. You find out the moment you try, which is a year later at the earliest.

The second trap is subtler: an exchange performed after 1 February 2027 is processed as cancel + refund + new purchase. Even when you spend your final coupon, the resulting reservation is new, and therefore non-exchangeable. It makes sense, but it surprises people.

Third: a partial exchange consumes the coupon for the entire remaining quantity. Exchange 10 of 50 instances and the other 40 no longer have one.

What does not change

So this does not read as the end of the world:

• Trading a reservation in for a savings plan stays possible at any time, unchanged
• The 50,000 USD per 12 months cancellation cap still applies
• Instance size flexibility within a SKU group remains
• Services outside savings plans — Azure VMware Solution being the typical case — are not affected at all

Microsoft is not removing flexibility, it is relocating it. The savings plan is meant to be the flexible instrument. The reservation moves into the role of "I know exactly what I will need, and I want a deeper discount for that certainty."

The decision matrix after February 2027

This is the part worth saving. After 1 February 2027 the choice between a reservation and a savings plan is considerably less reversible, so the decision has to be better the first time.

I went through the underlying two-layer strategy — reservations for the predictable core, savings plan for the rest — in the reservations and savings plans article. After February 2027 the boundary moves: when in doubt, reach for the savings plan sooner than you would today.

Audit: go through your auto-renewals

This is the concrete work, and it should take half an hour. First list every reservation order:

az reservations reservation-order list \
  --query "[].{order:name, term:term, state:provisioningState, expiry:expiryDate}" \
  -o table

Then, for each order, list the reservations including the renew state and expiry:

az reservations reservation list \
  --reservation-order-id "$ORDER_ID" \
  --query "[].{sku:sku.name, qty:properties.quantity, renew:properties.renew, expires:properties.expiryDate}" \
  -o table

The output looks like this:

Sku                Qty    Renew    Expires
-----------------  -----  -------  --------------------
Standard_D8s_v5    24     True     2027-05-14T00:00:00Z
Standard_E16s_v5   8      True     2027-03-02T00:00:00Z
Standard_D4s_v5    40     False    2028-11-30T00:00:00Z

The first two rows are exactly the problem: Renew: True and expiry after 1 February 2027. Both will renew themselves into a non-exchangeable reservation.

Auto-renew is switched off via REST:

az rest --method patch \
  --url "https://management.azure.com/providers/Microsoft.Capacity/reservationOrders/$ORDER_ID/reservations/$RESERVATION_ID?api-version=2022-11-01" \
  --body '{"properties":{"renew":false}}'

Do not switch this off across the board. Auto-renew disabled means the reservation simply lapses and you start paying pay-as-you-go — which is worse than a non-exchangeable reservation. The goal of the audit is to turn every row with Renew: True and an expiry after February 2027 into a deliberate decision, not to disable it automatically.

How to work out whether this actually hurts you

The question is not "is non-exchangeability bad" but "what does not being able to exchange cost me". That is calculable.

Take a commitment worth, for simplicity, €100,000 over three years, and assume the discount gap between a reservation and a savings plan is 8 percentage points — substitute your own rate card, the ratio holds.

• The reservation saves €8,000 more than the savings plan over the full term
• Estimate honestly the probability that you change SKU or region within two years — say 40%
• If that change happens and you cannot exchange, you are left holding an unused commitment. Changing halfway through the term leaves roughly half the value, so €50,000, though part of it is recoverable through cancellation (up to the 50,000 USD / 12 months cap)

Even on a very conservative estimate, a 40% chance of a five-figure loss is worse than a certain €8,000 of saving. That is why the boundary moves towards savings plans — not because savings plans got better, but because non-exchangeability changed the price of being wrong.

If your probability of change is under 10% — stable SKU, long-running production, no migration planned — the reservation still wins. This maths is not an argument against reservations. It is an argument against unexamined ones.

Checklist before the end of 2026

1. List every reservation and its renew state using the commands above.
2. Flag the ones expiring after 1 Feb 2027 with auto-renew on. That is your working list.
3. Decide on each: renew as a reservation (accepting non-exchangeability), move to a savings plan, or let it lapse.
4. If you are planning an exchange, do it before 1 February 2027, while the right is still unlimited.
5. Put a final check in the calendar for January 2027 so nothing lapses by accident.

The worst case here is not deciding wrong. It is not deciding at all and letting auto-renewal decide for you.

If you are working through commitment strategy for a larger estate and want an outside view, take a look at my cloud architecture services.

Sources

• Azure update 568514 — announcement, 30 July 2026
• Reservation exchange policy changes — docs, ms.date 27 August 2026