The cost optimization window after migration is the few months following cutover when usage data is fresh, architecture is still malleable, and nothing has yet been committed. It is the single highest return period in a cloud estate's life, for two reasons. First, lift and shift deliberately recreates on premises sizing in the cloud, so workloads arrive overprovisioned and full of waste that was invisible on owned hardware. Second, no commitments have been bought yet, so you can shape the steady state before locking in a discount against it. The mistake that wastes the window is buying a three year Savings Plan against the migrated bill in month one, which freezes the inefficiency in place. The right move is to optimise first and commit last.
Here is the sequence, and why the order is the whole point.
Why does a migrated estate arrive inefficient?
Lift and shift is a rational choice during migration: it reduces risk and moves fast by recreating the existing footprint in the cloud. But on premises sizing was built for peak load on hardware you had already bought, so it carries headroom that costs nothing to keep when the box is owned and costs real money when it is rented by the hour. Add idle development environments that came along for the ride, oversized instances chosen to match old servers, and storage left on premium tiers, and the migrated bill is structurally high. This is not a failure of the migration; it is the expected starting point, and it is exactly what the post migration window exists to fix. Our cross cloud cost optimization guide covers the levers in depth.
What is the right sequence?
- Rightsize and remove waste. Use the first weeks of real cloud usage data to resize instances to actual demand, delete idle and orphaned resources, and tier storage. This shrinks the base before anything is committed.
- Modernise the obvious targets. Migrate to current generation and more efficient instance families, move to managed services where they cut operational cost, and adopt cheaper architecture choices that do not require a full redesign.
- Then buy commitments. Only after the estate reflects its true steady state do you size Savings Plans, Reserved Instances, Reservations, committed use discounts, or Universal Credits against a defensible forecast.
Reverse this order and you commit to waste. Buy a long commitment in month one and the discount applies to instances you are about to delete or resize, locking spend you could have removed for free.
Why must commitments come last?
A commitment is a bet on a level of usage. If you place that bet before optimising, you bet on the inflated migrated bill, and the discount becomes a reason not to remove the waste underneath it, because the commitment is already paying for it. Optimise first and the commitment is sized to the real, lean steady state, so the discount compounds the savings rather than freezing the bloat. The same logic explains why short commitments or a smaller initial coverage layer make sense early: they preserve flexibility while the estate is still settling. As the steady state firms up, coverage can be increased against a forecast you can actually defend.
Optimise first, commit last. Rightsizing and waste removal in the first 90 days are free and reversible. A three year commitment bought against the migrated bill freezes the waste in place for three years.
How long is the window and how do you not miss it?
The first 90 days are where most of the opportunity sits, because that is when usage data has accumulated, the architecture is still fresh in everyone's mind, and no long commitments have hardened. The window does not close abruptly, but it narrows as commitments are bought, teams move on, and the migrated shape calcifies into normal. Not missing it means treating optimization as part of the migration program rather than a later project: budget for it, assign owners, and set the rightsizing and modernisation work to start the week after cutover, with commitment purchasing explicitly held until the estate has settled.
A worked example
A European SaaS company completed a lift and shift migration and was about to buy a three year commitment against the new bill to capture the discount quickly. Read against the first weeks of usage data, a large share of the migrated instances were oversized copies of old servers, several environments were idle, and storage sat on premium tiers. We held the commitment, rightsized and removed waste, moved workloads to current generation instance families, and only then sized coverage against the leaner steady state. The commitment ended up smaller and applied to an efficient base, so the discount compounded the savings instead of preserving the bloat. The post migration work was the largest single contributor to a program that left the company materially lighter on cloud spend. Figures are verified against billing data and anonymised.
Frequently asked questions
When is the best time to optimise cloud cost after migration?
Should you buy Savings Plans right after migrating?
Why does a migrated cloud estate cost so much at first?
Capture your post migration window with us
We help enterprises capture the optimization window right after migration across AWS, Azure, GCP, and OCI, sequencing rightsizing and modernisation ahead of commitments so the discount lands on a lean estate. We take zero provider commissions and work on a Fixed Fee or a no risk Gainshare basis, guaranteed: we reduce your cloud spend or we reimburse our service fee. Book a strategy call before you commit.
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.