Skip to main content

AI & assistant-friendly summary

This section provides structured content for AI assistants and search engines. You can cite or summarize it when referencing this page.

Summary

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 depressingly consistent: a lift-and-shift reproduces on-prem specs (sized for peak plus a hardware-refresh buffer), the migration partner ...

Key Facts

  • •The waste is predictable: 30–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→FinOps handoff — owner first, visibility second, right-size before you commit — 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

Entity Definitions

EC2
EC2 is an AWS service discussed in this article.
S3
S3 is an AWS service discussed in this article.
RDS
RDS is an AWS service discussed in this article.
serverless
serverless is a cloud computing concept discussed in this article.
cost optimization
cost optimization is a cloud computing concept discussed in this article.

Related Content

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

Cost Optimization & FinOpsPalaniappan P4 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–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→FinOps handoff — owner first, visibility second, right-size before you commit — with a 30-day checklist and an optimization-backlog CSV.

Key Takeaways

  • The waste is predictable: 30–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→FinOps handoff — owner first, visibility second, right-size before you commit — 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 depressingly 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–60% of cost is untagged, EC2 and RDS are over-provisioned, idle NAT Gateways and orphaned EBS are quietly billing, and — worst of all — 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 — 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.

Benchmark pattern (not a cited client) — A composite estate freshly lifted from a data center: instances sized at on-prem peak + ~30% headroom, ~50% of cost untagged at cutover, dev/test running 24×7. Representative arithmetic, not a billed result: dev/test scheduled to 12×5 instead of 24×7 removes roughly 65% of those environments’ runtime; right-sizing a fleet sized for peak that runs at 15–25% utilization is typically a double-digit-percent compute cut. The point is sequencing: every one of those numbers is negated if you buy a three-year Savings Plan before doing the right-sizing pass. Right-size, then commit.

The order is the whole game: owner → visibility → right-size → commit → guardrail

Most post-migration cost work fails not because the team picks the wrong instance type, but because it does the right things in the wrong order.

1. Assign the owner first (this is not optional)

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 actual root cause of post-migration cost drift — see the FinOps gap.

2. Get visibility (you can’t optimize what you can’t see)

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 — 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→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–80% is a sane start), not 100%. The decision logic is in Reserved Instances vs Savings Plans.

What broke — A team inherited a migrated estate and, eager to show savings in month one, bought a three-year Compute Savings Plan sized to the current run-rate. The next sprint they right-sized the over-provisioned fleet and decommissioned idle hosts as planned — and immediately fell below their committed spend, paying for a commitment they could no longer use. They’d inverted the order. The recovery was slow (you can’t easily unwind a three-year commitment); they had to backfill usage onto the plan and defer further right-sizing until the commitment amortized. Right-size first, commit second — in that order, every time.

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 → 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. Order beats effort here.

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. The cost does not go up because the cloud is expensive; it 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–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 — critically for prioritization — quantifies estimated savings using your organization-specific pricing and existing Reserved Instance / Savings Plans discounts rather than list price. 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. What matters is that someone is 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; every other task on the checklist gets done if an owner exists and none of them get done if one does not.
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 exactly 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. Think of it as 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:
Palaniappan P
Palaniappan P

AWS Cloud Architect & AI Expert

AWS-certified cloud architect and AI expert with deep expertise in cloud migrations, cost optimization, and generative AI on AWS.

AWS ArchitectureCloud MigrationGenAI on AWSCost OptimizationDevOps

Recommended Reading

Explore All Articles »