Skip to main content

Post-Migration Optimization and the FinOps Handoff (2026): The First 30 Days After Cutover Decide Your Run-Rate

Cost Optimization & FinOpsUpdated Kevin W.4 min read

Quick summary: A lift-and-shift migration copies on-prem specs sized for peak plus headroom, then the migration partner rolls off and nobody owns the bill. The waste is predictable: 30 to 60% of cost untagged, over-provisioned EC2/RDS, idle NAT Gateways and orphaned EBS, and commitments bought on top of all of it. This is the explicit migration-to-FinOps handoff: owner first, visibility second, right-size before you commit. It comes with a 30-day checklist and an optimization-backlog CSV.

Key Takeaways

  • The waste is predictable: 30 to 60% of cost untagged, over-provisioned EC2/RDS, idle NAT Gateways and orphaned EBS, and commitments bought on top of all of it
  • It comes with a 30-day checklist and an optimization-backlog CSV
  • The bill it created does not, and the first 30 days after cutover decide your run-rate for the next year
  • This post is the explicit handoff that prevents that, anchored to AWS Cost Optimization Hub (which consolidates 18 recommendation types priced with your discounts)
  • We ship a 30-day handoff checklist and an optimization-backlog CSV template
Post-Migration Optimization and the FinOps Handoff (2026): The First 30 Days After Cutover Decide Your Run-Rate
Table of Contents

A migration project ends at cutover. The bill it created does not, and the first 30 days after cutover decide your run-rate for the next year. The pattern is consistent: a lift-and-shift reproduces on-prem specs (sized for peak plus a hardware-refresh buffer), the migration partner is measured on cutover success rather than run-rate, and when they roll off, nobody owns the bill. By the time someone notices, 30 to 60% of cost is untagged, EC2 and RDS are over-provisioned, idle NAT Gateways and orphaned EBS are billing, and someone has “saved money” by buying Savings Plans on top of all of it. This post is the explicit handoff that prevents that, anchored to AWS Cost Optimization Hub (which consolidates 18 recommendation types priced with your discounts).

This is for the engineering lead, FinOps owner, or CTO inheriting a freshly-migrated estate. It is the bridge from a program like a data-center exit to a steady-state FinOps practice. We ship a 30-day handoff checklist and an optimization-backlog CSV template.

The order: owner, visibility, right-size, commit, guardrail

Most post-migration cost work fails because the team does the right things in the wrong order.

1. Assign the owner first

Before the migration team rolls off, name the FinOps owner in writing, put a monthly cost review on the calendar, and turn on Cost Anomaly Detection routed to a channel a human reads. Diffusion of responsibility is the root cause of post-migration cost drift (see the FinOps gap).

2. Get visibility

Activate cost allocation tags in the Billing console. They are inactive by default even if your resources are tagged. Measure tagging coverage, then close the gap with a tag policy as described in tagging, chargeback & FinOps ownership. Opt the org into Cost Optimization Hub: it dedupes and ranks recommendations across accounts/Regions and prices them with your RI/SP discounts. (Our Cost Optimization Hub guide walks the console.) For the first monthly review after cutover, open Cost Explorer filtered to the migrated accounts and use Analyze with Amazon Q (June 2026) to narrate top drivers, which is faster than teaching every stakeholder to pivot CE. Optionally enable FinOps Agent (preview) to route Cost Anomaly Detection events to Slack/Jira so post-migration spikes reach engineering without manual triage.

3. Right-size and kill the lift-and-shift waste

Drive right-sizing from Compute Optimizer (surfaced inside Cost Optimization Hub). Then the idle/orphaned sweep: unattached EBS, idle RDS, old snapshots, unused Elastic IPs, idle NAT Gateways (see NAT Gateway idle cost), zombie load balancers. Storage: S3 lifecycle/Intelligent-Tiering and gp2 to gp3. Schedule dev/test off nights and weekends.

4. Commit only now

With the baseline right-sized, layer Compute Savings Plans over the stable portion. Pick a coverage target (70 to 80% is a sane start), not 100%. The decision logic is in Reserved Instances vs Savings Plans.

What to do this week

  1. Name the bill owner in writing and put a recurring monthly cost review on the calendar. Do this before anyone from the migration team leaves.
  2. Activate cost allocation tags and measure coverage. If it’s under ~80%, that’s your first backlog item.
  3. Opt into Cost Optimization Hub (org-wide) and export the top recommendations into the optimization-backlog CSV.
  4. Do the idle sweep (EBS, NAT, snapshots, EIPs): fast, low-risk wins that fund the harder work.
  5. Freeze new commitments until right-sizing is done. Write it down so a well-meaning teammate doesn’t buy an SP early.
  6. Run the first post-cutover review with Analyze with Amazon Q in Cost Explorer (team/account filter). Consider FinOps Agent (preview) for anomaly routing if your on-call channel is already in Slack.

What this post doesn’t cover

  • The steady-state FinOps operating model: see FinOps on AWS complete guide.
  • The migration program that feeds this handoff: see data-center exit and choosing a migration strategy.
  • Modernization economics (monolith to containers/serverless ROI): a separate, longer-horizon track than the 30-day handoff.
  • Exact pricing and recommendation counts: confirm Cost Optimization Hub coverage and current rates in the AWS console; figures here are the mid-2026 model.

Related: FinOps complete guide · Tagging, chargeback & FinOps ownership · RI vs Savings Plans · Cost Optimization Hub guide · AWS FinOps Agent preview · FinOps consulting · Cost optimization services

If you only do one thing: Assign a named owner for the bill before the migration team rolls off, and freeze all Savings Plan / RI purchases until the right-sizing pass is complete.

Frequently asked questions

Why does cost go UP right after a successful migration?
Because a lift-and-shift faithfully reproduces on-premises sizing, which was chosen for peak load plus a hardware-refresh headroom buffer and a "we cannot easily add capacity later" mindset that does not apply in the cloud. You end up paying 24/7 for instances sized for a peak that happens 2% of the time, plus the migration leaves behind idle NAT Gateways, orphaned EBS volumes, old snapshots, and dev/test environments running around the clock. On top of that, the migration team is measured on cutover success and timeline, not run-rate, so optimization is explicitly out of their scope, and when they roll off, nobody owns the bill. Cost goes up because nobody has yet done the optimization pass that migration deliberately deferred.
Should we buy Savings Plans or Reserved Instances right after migrating?
Not first. Right-size before you commit. Buying a one- or three-year Compute Savings Plan or Reserved Instance on an over-provisioned, lifted-and-shifted instance locks in the waste for the full term: you are now committed to paying for capacity you should have eliminated. The correct order is: stabilize, measure real utilization for at least two weeks, right-size the over-provisioned and idle resources, and only then layer commitments over the stable baseline (a 70 to 80% coverage target is a common starting point, not 100%, so you retain flexibility for change). Cost Optimization Hub will surface Savings Plans recommendations priced with your own discounts, but treat those as the step that comes after right-sizing, not instead of it.
What is AWS Cost Optimization Hub and why use it for the handoff?
Cost Optimization Hub is a feature within AWS Billing and Cost Management that consolidates cost-optimization recommendations across all accounts and Regions in your organization into a single dashboard. It supports 18 recommendation types (rightsizing from AWS Compute Optimizer, idle-resource and Savings Plans suggestions, and more), deduplicates overlapping recommendations, and quantifies estimated savings using your organization-specific pricing and existing Reserved Instance / Savings Plans discounts rather than list price, which matters for prioritization. For a handoff it is the fastest way to turn "the bill is too high" into a ranked, deduplicated backlog with realistic dollar estimates. You opt in through the Billing console; data populates within about 24 hours and refreshes daily.
Who should own the AWS bill after the migration team leaves?
A named person or team, assigned in writing before the migration partner rolls off. That is the single most important line of the handoff. It does not have to be a dedicated FinOps team; in a smaller org it is often a platform engineer plus a finance partner meeting monthly. Someone must be accountable for the run-rate, owns the optimization backlog, receives the cost-anomaly alerts, and runs the monthly review with engineering and finance. The failure mode is diffusion of responsibility: engineering assumes finance watches the bill, finance assumes engineering optimizes it, and the run-rate drifts up for two quarters until someone escalates. Assign the owner first. With an owner, the other tasks on the checklist get done; without one, none of them do.
When is post-migration optimization NOT worth doing aggressively?
When the resource is about to be re-architected anyway, aggressive right-sizing is wasted effort. If a monolith is moving to containers or serverless next quarter, do not spend a sprint tuning its EC2 fleet; just stop the obvious bleeding (idle resources, dev/test scheduling) and let the modernization handle the rest. Likewise, do not buy commitments on anything slated for change, and do not chase a $40/month rightsizing recommendation that carries real workload risk. Optimization has a cost too: engineering time and change risk. Sequence by estimated saving versus effort and blast radius, which is what the optimization-backlog template is for, and accept that some line items should be marked "won't do" rather than pursued.
How is this different from a general FinOps program?
A general FinOps program is the ongoing operating model: continuous visibility, optimization, and governance over the cloud bill. This post is specifically about the handoff moment that connects a finishing migration to that program. It is time-boxed (the first 30 days post-cutover, while the migration team still has context), it has a defined "definition of done" (owner assigned, tags active, baseline right-sized, first backlog seeded), and it deliberately front-loads the actions that get harder once the migration team disperses. It is the bridge: the migration program (for example a data-center exit) feeds into it, and a steady-state FinOps practice picks up where it leaves off. Our FinOps complete guide covers the steady state; this covers the bridge.
Share:
Kevin W.
Kevin W.

Ecommerce Growth & Retail Marketplaces

Ecommerce growth leader working across ratings and reviews, Walmart review syndication, retail marketplaces, and email and SMS deliverability. Writes the FactualMinds guides on AWS cost optimization and FinOps for teams that need cloud spend to stay predictable.

Ecommerce GrowthRatings & ReviewsRetail MarketplacesEmail & SMSAWS Cost OptimizationFinOps

Recommended Reading

Explore All Articles »