TL;DR:

• Starting Feb 1, 2027, new Azure Reservations for savings-plan-eligible services (VMs, App Service, SQL Database) can't be exchanged, ever.
• Reservations bought before then get one last exchange. Use it after the deadline, and the replacement Reservation is locked too.
• Guaranteed Commitments from Archera sidestep the problem entirely: real Azure Reservations in your tenant, but a 30-day term on your side and a Moneyback Guarantee that pays you back directly if usage drops. No exchange needed when you were never on the hook for three years. 

What's actually changing

Azure Reservations have always come with a built-in safety net. If you committed to a VM size, a database tier, or a region and your needs shifted, you could exchange the Reservation for something that fit better. No penalty, no waiting for the term to end.

That safety net is going away for any Reservation covering a service that's also eligible for Savings Plans: Virtual Machines, App Service, SQL Database, and anything that joins that list going forward.

Here's the exact mechanic:

• Reservations purchased on or after February 1, 2027 cannot be exchanged at all, for the life of the term.
• Reservations purchased before that date get one last exchange. Use it before the deadline, and the new Reservation is fine. Use it after, and the replacement Reservation is treated as a new purchase under the new no-exchange rules.
• Cancellation policy is unchanged. You can still cancel up to $50,000 per rolling 12 months, per billing profile. This is specifically about exchanges, not cancellations.

Microsoft's own guidance points customers toward Savings Plans as the flexible alternative going forward. That's a reasonable suggestion, with one catch: Savings Plans discount meaningfully less than Reservations do. Depending on term and service, the gap runs anywhere from roughly a quarter to over three-quarters less savings.

Why this matters more than it sounds like it does

Put those two facts together and here's the position Azure customers are being pushed into: take the bigger discount and accept that you're now fully exposed if your usage changes for the next one to three years, or take the smaller discount to keep some flexibility.

That's not a hypothetical trade-off. Anyone who's managed Reservations at scale has a story about a workload that got re-architected, a team that migrated off a VM family, or a business unit that got sold — and the exchange was the thing that kept a good financial decision from turning into a bad one eighteen months later. Take that lever away, and every Reservation purchase becomes a bet on your own roadmap holding steady for the full term.

For finance and FinOps teams, that's a real forecasting problem. For anyone advising portfolio companies or managing cloud spend across multiple business units, it's worse. You're now underwriting commitment risk across variance you don't fully control.

The trade-off shouldn't exist in the first place

Here's the thing: the flexibility Microsoft is removing was never really about the Reservation itself. It was a workaround for a structural problem: that committing for one to three years is inherently risky when usage isn't guaranteed to stay flat for one to three years. Exchanges were a patch on that risk. Removing the patch doesn't remove the risk; it just makes it visible again.

The better fix is not committing long-term in the first place, while still capturing the discount that comes with committing. That's the model we've built Archera around: commitments in 30-day terms instead of one to three years, with the utilization risk insured rather than sitting on your books. You get Reservation-level pricing because the commitment is real, but if your usage drops next month, that's not your shortfall to absorb. The term is short enough that "what if things change" stops being a question you have to answer a year in advance.

Applied to this specific change, it means the February 2027 deadline is close to irrelevant for anyone running commitments this way. There's no exchange to use up, no multi-year exposure to plan around, and no forced choice between discount depth and flexibility, because the commitment was never long enough to need an exit ramp.

What this changes if you're running commitments through Archera

Nothing on your side. Worth explaining why, because the reason isn't "Archera doesn't use Reservations."

It does. When Archera places a Guaranteed Commitment, what lands in your tenant is a real, native Azure Reservation, subject to the same Microsoft terms as anything you'd buy directly. What's different is the term you hold: 30 days at the Archera contract layer, not one to three years on the Azure side. The Reservation is real. Your obligation to it isn't multi-year.

That distinction is exactly what the February 2027 change makes expensive for everyone else. Strip out exchanges and Microsoft's native exit ramps reduce to one: cancellation, capped at $50,000 per rolling 12 months per billing profile or enrollment, a cap that isn't moving. For a mid-market Azure estate, $50K is a workable cushion. For an enterprise running eight figures of Azure, it's a rounding error. The remaining flexibility story is Savings Plans, and Savings Plans buy that flexibility with discount depth.

The Moneyback Guarantee isn't one of those exits. It's a contractual obligation from Archera to you, not a Microsoft-provided mechanism, not drawn against your cancellation allowance, and not subject to whatever the reservation policy looks like in 2027 or 2029. Microsoft can change the terms of a Reservation. It can't change the terms of your agreement with us.

Which is the whole point of putting a counterparty between yourself and a long-term commitment. The commitment terms are Microsoft's to revise. The risk transfer isn't.

So: if you're evaluating this against an Archera portfolio, February 1, 2027 is a date you can note and move past. If you're evaluating it against a self-managed Reservation book, the checklist below is the work.

What to do before February 1, 2027

If you're holding Azure Reservations today, a few concrete steps are worth taking well ahead of the deadline:

1. Inventory your Reservation book and flag anything you'd realistically want to exchange in the next 12–18 months: a re-architecture, a planned migration, a workload you're not fully confident about.
2. Use your final exchange deliberately, not reactively. Once it's gone, it's gone for that Reservation's remaining term.
3. Separate the discount decision from the term-risk decision. They've been bundled together by default, but they don't have to be.

‍

See what running your Azure commitments this way actually looks like: https://www.archera.ai/compare/prosperops

‍