A migration moves the ground under your commitments. Workloads shift shape, regions, and even providers, and the reservations you bought against the old baseline may no longer match anything. The discipline is to protect what you already hold, pause new buying until the picture clears, and rebuild coverage only when the new baseline is stable.
Handling commitments during a cloud migration is the practice of protecting, pausing, and rebuilding your reserved instances, savings plans, and committed use discounts while the underlying workloads are in motion. A migration is the one time when the usual advice to maximize coverage is wrong: usage is unstable, so any commitment you buy risks being stranded the moment a workload moves. The goal through a migration is not to optimize the rate but to avoid locking yourself into a baseline that is about to disappear, then to commit aggressively once the new shape settles.
This article is part of the complete guide to cloud commitment management. The pattern below comes from the migrations we have supported across the 500-plus environments we have optimized since 2019, where mishandled commitments are one of the most common sources of stranded spend.
A commitment is a bet on a stable baseline. You promise a provider a year or three of usage in a particular shape and they discount the rate. A migration deliberately destroys that stability: instance families change, workloads consolidate or split, some move to another region for latency or compliance, and some leave the provider entirely. Every one of those moves can orphan a reservation that was matching usage perfectly the week before. The same coverage and utilization numbers that signal health on a stable estate, explained in coverage and utilization, become misleading mid-migration because the denominator itself is moving.
Before anything moves, build a complete inventory of existing commitments: instrument type, scope, term, expiry date, and current utilization. Flag every commitment that expires during the migration window and every one tied to a workload on the move list. This inventory is the map you will use to decide what to protect and what to let run out naturally. A standard reserved instance tied to a workload leaving the cloud is a problem; a flexible spend-based commitment is far more likely to keep matching something.
The single most important move is to stop buying new commitments against the workloads in scope. During the unstable window, on-demand or pay-as-you-go pricing is the correct default even though it costs more per hour, because it carries no lock-in. Paying the on-demand premium for a few months is almost always cheaper than stranding a three-year commitment. This is the migration exception to the usual rule, and it connects directly to the logic in when to use on-demand instead of committing. Keep buying only for workloads that are demonstrably staying put and stable.
Protect existing commitments, pause new buying for anything in motion, run unstable workloads on-demand, and rebuild coverage only once the destination baseline has held steady for several billing cycles. Paying the on-demand premium briefly beats stranding a multi-year lock.
For commitments you already own, the lever is scope, not cancellation. Most commitments apply across an account family, so a reservation orphaned by one workload may still match another if you widen its scope, as described in how to manage commitments across multiple accounts. Where a commitment is genuinely stranded with no matching usage anywhere, your options are limited to exchange or sale, covered in selling and exchanging unused reservations, and those routes recover only partial value. Convertible instruments give you the most room to re-shape coverage onto whatever survives the migration.
If a one-year commitment expires three months into a six-month migration, the cleanest move is often to let it run out and not renew. You capture the discount for its remaining life and avoid making a fresh bet on a baseline you know is about to change. Sequencing the migration around commitment expiry dates, where you have the freedom to, turns the term structure from a liability into a natural off-ramp.
Once the destination estate has held steady for several billing cycles, the migration exception ends and normal discipline resumes. Rightsize first so you never reserve waste, as in why you should rightsize before you commit, then rebuild coverage with a laddered purchase, as in how to ladder cloud commitments to reduce risk. Rebuilding on a clean, rightsized baseline is the whole point of having paused: you commit to the estate you actually have, not the one you used to have.
Exit and exchange flexibility varies sharply by provider, and the rules change, so verify the current policy in each provider's documentation before planning around it. As a general shape, AWS Savings Plans and most Google Cloud and Oracle commitments are locked for the term, AWS convertible reserved instances can be exchanged, and Azure reservations have historically allowed exchanges and limited refunds. Those differences should inform which instruments you hold going into a migration: the more uncertain the future, the more you should favor flexible spend-based commitments over rigid resource-based ones, a trade-off explored in spend-based vs resource-based commitments.
We inventory your existing portfolio, protect and re-scope what we can, sequence the migration around expiry dates, and rebuild coverage on the stable new baseline. On the performance model, if we do not save you money, there is no fee.
Get a commitment audit →Migration handling is the high-risk window in the commitment cluster. Read the complete guide to cloud commitment management for the full discipline, and download The Commitment Strategy Playbook: RIs, Savings Plans, CUDs for the migration inventory and re-scoping worksheets. When you want the portfolio handled through a migration for you, see our commitment management service.
New commitment instruments, FOCUS changes, hyperscaler pricing shifts, and the plays that actually move a bill. No schedule, no filler.