Let an Azure reservation lapse when the covered workload is declining or moving, when utilisation has fallen below the level that justifies a fresh commitment, or when a planned rearchitecting will retire the reserved family before a renewal term would pay back. Renew only what you are confident you will run, exchange where the workload has shifted to a different family, and let the rest expire onto pay as you go rather than recommitting out of habit.
The instinct to renew everything at expiry is what strands spend. A reservation is a forecast you made one or three years ago. If the forecast no longer holds, the disciplined move is to let it lapse and resize around what you actually run now.
What does the utilisation number tell me?
Reservation utilisation is the first gate. Azure reports the percentage of reserved hours that matched eligible usage. If utilisation on the expiring reservation ran in the high nineties, the commitment is earning its keep and renewal is likely sound. If it drifted into the eighties or below, you were already paying for capacity you did not use, and renewing at the same size repeats the mistake.
Read utilisation alongside the trend. A reservation at full utilisation but on a workload that is visibly shrinking is still a poor renewal candidate, because the number that matters is forward usage, not the last twelve months. Standing utilisation monitoring makes this visible long before expiry, as we cover in reservation utilization monitoring.
Renew, exchange, or lapse?
Three outcomes, three triggers. Renew when the workload is stable and you are confident it will run through the next term at similar scale. Exchange when the workload persists but has moved to a different virtual machine family, region, or size; Azure lets you exchange a reservation for one that matches current usage rather than wasting the remaining value. Lapse when the workload is declining, migrating to a managed service, or scheduled for a redesign that changes the compute shape entirely.
A European SaaS company held three year reservations on a virtual machine family it was migrating off as it moved services to a managed platform. Renewing would have committed three more years to a family due to disappear within two quarters. The team let the reservations lapse as each expired, ran the residual workload on pay as you go through the transition, and recommitted only once the new steady state was clear. The result avoided a large stranded commitment. Figures are verified against billing data and anonymised.
What about the refund and exchange window?
Azure allows reservations to be exchanged for a different reservation and, within policy limits, refunded. That flexibility changes the lapse decision: you are rarely fully trapped. If a workload moves mid term, an exchange recovers the remaining value onto a family you do run, which is almost always better than letting a mismatched reservation bill against usage that no longer exists. Treat lapse as the choice for genuine decline and exchange as the choice for a workload that has simply moved.
The lapse decision at a glance
| Signal | Renew | Exchange | Lapse |
|---|---|---|---|
| Utilisation | High nineties | Mixed, family moved | Falling below justification |
| Workload trend | Stable | Persisting, reshaped | Declining or migrating |
| Forecast confidence | High | Medium, known target | Low or redesign pending |
| Best instrument | New reservation or Azure Savings Plan | Exchanged reservation | Pay as you go for now |
Where the workload is stable but you want flexibility across families, the Azure Savings Plan is often a better renewal instrument than a fresh reservation, because it applies more broadly. Set your renewal posture from a defensible forecast, as described in the Azure cost optimization guide.
Frequently asked questions
Should I let my Azure reservation expire?
Can I exchange an Azure reservation instead of letting it lapse?
What utilisation level justifies renewing an Azure reservation?
Make the renew, exchange, or lapse call with confidence
We review your Azure reservation portfolio against forward usage, recover value through exchanges, and recommit only where the forecast supports it across AWS, Azure, GCP, and OCI. Our guarantee: we reduce your cloud spend or we reimburse our service fee.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.