For years, a Reservation exchange has worked as a safety valve. If a commitment no longer matched the workload it was bought to cover, most teams could correct that decision later without giving up the value already committed. From February 1, 2027, that safety valve becomes much narrower for the services it has historically covered, and the real shift this creates is not procedural. It is a shift from correcting a commitment after purchase to making a better commitment decision before purchase. Workload stability needs to become a first-class input to that decision, sitting alongside discount, utilisation and forecast rather than an afterthought considered only once something has already gone wrong.
Why This Matters
Starting February 1, 2027, Reservations purchased after that date will no longer be eligible for exchange where the corresponding service is supported by a Savings Plan. The policy covers affected services including Azure Virtual Machines, Azure App Service, and applicable Azure database services. Reservations purchased before February 1, 2027 retain one final exchange after that date. Microsoft’s own guidance on the policy change sets out these mechanics directly, including worked examples of how the final exchange applies to partial quantities within a single Reservation.
It is worth being precise about scope, because this is not a blanket end to all Azure Reservation exchanges. The restriction applies specifically to compute and database Reservations where a corresponding Savings Plan exists, including Azure SQL Database. Reservations for services without a Savings Plan option, such as Azure VMware Solution, and Reservations for deprecated products, are excluded from the change entirely and continue under the existing exchange policy.
Two related policies are also not changing, and both are worth stating clearly since they are easy to conflate with the exchange restriction. Instance size flexibility for virtual machines is unaffected by this update. The Reservation cancellation policy still caps total cancelled commitment at fifty thousand US dollars in any twelve-month rolling window per billing profile or enrolment. For workloads that no longer fit their Reservation, cancellation remains a lever alongside exchange and trade-in, even after the exchange restriction takes effect.
What Changes for a Reservation Purchased on Either Side of the Date
The practical effect differs depending on which side of February 1, 2027 a Reservation falls on, and both scenarios deserve separate attention rather than being treated as the same problem. An eligible Reservation purchased before the date keeps one final exchange under the new rules, and that exchange should be used deliberately rather than treated as a permanent safety net that can be drawn on repeatedly. An eligible Reservation purchased after the date has no exchange right at all where the corresponding service is Savings Plan-supported, which means workload stability, region and instance series all need to be validated before the purchase happens, not after.
This also applies at the level of individual quantities within a single Reservation, not just to the Reservation as a whole. If two of ten quantities on a Reservation are exchanged after the date, the remaining eight quantities each retain one further exchange of their own. Quantities need to be managed independently rather than assuming the entire Reservation moves together as a single unit, which is a meaningful change to how a large Reservation with many quantities should be tracked and governed going forward.
The Reservation Versus Savings Plan Decision
With exchange flexibility narrowed, the choice between a Reservation and a Savings Plan becomes considerably clearer to reason about, even if the underlying decision is now more consequential. A Reservation suits highly stable, predictable workloads where the service, configuration and region are genuinely expected to remain consistent, and it commits to a more specific service or configuration in exchange for typically the stronger discount when fully utilised. A Savings Plan suits dynamic or evolving workloads, committing to a dollar-per-hour spend level across eligible usage rather than to a specific configuration, and offering meaningfully more flexibility across services, instance families and regions at a generally lower discount rate.
Term options differ between the two as well. Reservations often run one or three years depending on the service. Savings Plans run one or three years for compute, but only one year for database services currently, which is a gap worth flagging early rather than discovering midway through a database commitment decision.
The decision rule underneath all of this is straightforward to state even though applying it honestly takes real analysis. A stable workload with high confidence in its configuration points toward a Reservation as the stronger economic choice. A dynamic workload with meaningful change risk points toward a Savings Plan as the better risk-adjusted commitment. The FinOps question worth asking explicitly for every material workload is not simply how much can be committed, but how much of that spend can genuinely be predicted with confidence.
What Changes Operationally, and What Does Not
Reservations do not disappear, and it is worth being clear about that so the policy change does not get overstated internally. What changes is that the decision to purchase one becomes more consequential than it used to be. Reservations remain attractive for highly stable workloads where the service, configuration and region are expected to stay consistent for the life of the term. Savings Plans become more relevant wherever a workload is dynamic or expected to move across eligible compute services, instance families or regions during that same period.
From Discount Optimisation to Commitment Confidence
The more useful question to lead with is not how much an organisation can commit, but how much of that spend it can confidently predict. That distinction changes how the estate gets segmented, what data gets collected, and how much governance the whole process actually needs. A stronger approach segments the estate by workload stability rather than treating every eligible dollar of spend as one undifferentiated commitment pool, with the explicit goal of isolating the predictable baseline from the change-risk portion and selecting the commitment instrument to match each.
In practice, that segmentation tends to sort into a handful of recognisable categories. Stable demand paired with stable configuration is the clearest case for a Reservation-led posture, since a specific commitment delivers stronger savings when fully utilised and there is little reason to give that up for flexibility nobody needs. Stable spend paired with a configuration that is expected to change points toward a Savings Plan-led posture instead, since spend-based flexibility reduces dependence on any one configuration. A planned migration or modernisation effort argues for a flexible or deliberately delayed commitment, since locking into a configuration that is likely to change within the term defeats the purpose of committing at all. A workload with a stable core and a variable edge often calls for layering both instruments together, committing the predictable baseline while keeping the variable portion genuinely flexible. And an existing Reservation that is already underutilised is a signal to review exchange or trade-in options now, since unused commitment quietly erodes whatever headline discount rate first justified the purchase.
The Savings Gap Is Only Half the Decision
A Reservation can offer a deeper nominal discount than a Savings Plan, but the highest discount rate does not automatically produce the lowest realised cost. If a Reservation is underutilised because the workload changes shape, the organisation ends up carrying unused commitment while simultaneously paying pay-as-you-go rates for any usage that falls outside what the commitment actually covers, which is the worst of both outcomes rather than a partial win.
A simple illustration makes the point concrete. Consider a portfolio with a one hundred dollar hourly eligible baseline, where seventy dollars of that baseline is consistently tied to workloads expected to remain in the same configuration, and thirty dollars is exposed to migration, scaling or regional change. Committing the full hundred dollars to a Reservation may maximise the theoretical discount on paper today, but it also commits the organisation to the least flexible part of the strategy for the portion of spend that was never actually stable in the first place. The more defensible position is committing the seventy stable dollars and treating the remaining thirty with a Savings Plan or genuine flexibility, even though that produces a lower headline discount than committing the full amount would suggest.
Independent FinOps analysis of the policy change puts the scale of that trade-off in concrete terms. One detailed breakdown of the discount gap found that one-year compute Reservations typically offer around 43% more savings than Savings Plans, narrowing to roughly 26% more on three-year terms, while one-year database Reservations offer as much as 81% more savings than their Savings Plan equivalent, which is precisely the kind of category-specific gap that makes a blanket estate-wide decision the wrong instinct.
What a Commitment Review Should Actually Analyse
Microsoft’s own recommendation engines use historical hourly usage and simulate different commitment quantities, which is a useful way to establish an economic baseline. Microsoft’s guidance on trading in reservations for savings plans lays out the specific mechanics of how that trade-in process works, including how the new commitment’s total value must equal or exceed the remaining value of the Reservation being returned. But a genuine FinOps review needs to add business context on top of that baseline, since historical usage alone cannot tell you whether today’s configuration will remain valid through the rest of the commitment term.
A thorough review works through several distinct layers of data rather than relying on any single one in isolation: the stable hourly usage baseline that defines the economic starting point, how much of an existing commitment is actually being consumed, how much eligible usage is already discounted through prior purchases, whether family, SKU or region changes are expected on the roadmap, whether any migration or modernisation work is planned that would change the picture, who actually owns the workload and its forecast, and what the realised saving looks like once underutilisation is factored in rather than the headline discount rate alone.
Where a Structured Review Adds Real Value
The most useful role an outside or dedicated FinOps review plays here is connecting cost back to the workload that generated it, mapping commitment consumption to the specific application, product, team or business owner responsible for it rather than leaving it as an anonymous line on a cloud bill nobody can act on directly. Equally important is separating current usage from future confidence, overlaying raw usage history with migration plans, architecture changes, scaling expectations and business roadmaps that a usage dashboard alone will never surface.
From there, the review should quantify the risk of being wrong, comparing the expected savings from a given commitment against the financial exposure created if the underlying configuration changes or the workload turns out to be less stable than assumed. And it should establish an operating rhythm, turning commitment management into an ongoing FinOps process reviewed on a regular cadence rather than a once-a-year purchasing exercise that gets revisited only when a renewal deadline forces the issue.
A Practical Runway to February 2027
The work between now and the deadline breaks down into a natural sequence rather than a single event. The immediate task is building a clear exposure view: inventorying every affected Reservation and its expiry date so nothing is discovered for the first time close to the deadline. The next review cycle should segment workloads by stability and change risk, turning that inventory into a working list of Reservation and Savings Plan candidates. Ahead of using the final exchange, scenarios should be modelled and the savings gap quantified in dollar terms, producing a prioritised set of actions rather than a vague sense of what might be worth doing.
Before February 1, 2027 itself, the priority shifts to executing final exchanges and right-sizing commitments where the modelling supports it, aiming to leave the organisation with a cleaner starting portfolio rather than one still carrying legacy mismatches into the new policy regime. After the deadline, the work becomes continuous rather than periodic: operating ongoing commitment governance based on usage data and forward-looking stability signals together, not usage data alone. Microsoft’s own documentation on self-service exchanges and refunds confirms that the extended grace period exists specifically to let customers assess their commitment needs and plan for exactly this kind of transition before the rules tighten further.
Four Things FinOps Teams Should Change
Four specific practices are worth adjusting deliberately in response to this change, rather than assuming the existing process will continue to work adequately once exchanges are gone. Forecasting needs to treat future instance series, service and region changes as genuine commitment risk, distinguishing stable demand from demand that may move or be reconfigured rather than blending both into a single projection. Commitment sizing should commit the stable portion of a workload first, resisting the temptation to size a Reservation to the full current footprint simply because today’s usage happens to support that size.
Optimisation should move from large, periodic commitment decisions toward smaller, incremental ones informed by continuously updated usage, utilisation and workload-change signals, rather than a single annual purchasing event that has to get the whole year right in one attempt. And governance should make workload stability an explicit, named approval criterion before any new Reservation is purchased, renewed, or materially increased, rather than leaving that judgement implicit and undocumented in whoever happens to be making the purchasing decision that quarter.
Independent commentary on the change has been blunter about the stakes of getting this wrong. One FinOps platform’s analysis of the policy update frames the database term mismatch specifically, warning that the combination of losing exchange rights and the one-year cap on database Savings Plans creates a genuine price cliff for database-heavy estates that have historically relied on three-year Reservations, since no product currently on the market replicates that combination of term length and flexibility. Whatever view an organisation takes on the fairness of the change, that specific gap is worth treating as a governance priority rather than a detail to revisit later.
The Database Estate Deserves Its Own Review
Database commitments need particular attention because Database Savings Plans currently offer only a one-year term, while eligible database Reservations can run considerably longer depending on the service. For a genuinely stable database workload, a longer Reservation can therefore remain the more economically attractive option even without exchange rights, provided the stability assessment behind that choice is honest rather than hopeful. Where migration, an engine change, or regional movement is realistic within the commitment term, the value of retaining flexibility becomes proportionally more important, and the calculus shifts toward shorter terms even at a lower discount rate.
What to Do Before February 1, 2027
Turning all of the above into action comes down to five sequential questions worth answering in order. Which Reservations are affected, and when does each one expire. Will the service, instance series, region and demand behind each of those Reservations genuinely remain stable, producing a clear split between stable and change-risk workloads. What is the actual dollar savings difference between the Reservation and Savings Plan options for each workload once realistic utilisation is factored in, not just the headline discount rate. Where would the one remaining exchange materially improve the portfolio, producing a prioritised list of exchange decisions rather than a reactive one made at the last possible moment. And finally, how will commitments be reviewed on an ongoing basis once exchanges are no longer available as a correction mechanism, producing a genuine operating model rather than a one-time cleanup exercise that quietly lapses once the deadline has passed.
Conclusion
February 1, 2027 should not be treated as a Reservation deadline. It is a decision-quality deadline. Organisations that understand workload stability, quantify the savings-versus-flexibility trade-off in real dollar terms, and govern commitments continuously rather than periodically will be in a considerably stronger position than those that have relied on exchanges to correct imperfect decisions after the fact.
The practical question worth asking about any Azure Reservation from this point forward is not simply whether it is cheaper than the alternative. It is whether there is genuine confidence in the workload staying stable for the length of the commitment being made. That is the question that matters more from February 1, 2027 onward, and it is the question a proper commitment review needs to be built to answer before the purchase happens, not after.
