--- title: Post-Migration Optimization and the FinOps Handoff (2026): The First 30 Days After Cutover Decide Your Run-Rate description: 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. url: https://www.factualminds.com/blog/aws-post-migration-optimization-finops-handoff-2026/ datePublished: 2026-06-10T00:00:00.000Z dateModified: 2026-06-10T00:00:00.000Z author: Palaniappan P category: Cost Optimization & FinOps tags: aws, finops, cost-optimization, cloud-migration, cost-optimization-hub --- # Post-Migration Optimization and the FinOps Handoff (2026): The First 30 Days After Cutover Decide Your Run-Rate > 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. **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](/blog/data-center-exit-large-scale-aws-migration-program/) to a steady-state [FinOps practice](/blog/finops-on-aws-complete-guide-cloud-cost-governance/). We ship a [30-day handoff checklist](https://bitbucket.org/baymail/factualminds-astro/src/main/examples/architecture-blog-2026/post-migration-finops-handoff/finops-handoff-checklist.md) and an [optimization-backlog CSV template](https://bitbucket.org/baymail/factualminds-astro/src/main/examples/architecture-blog-2026/post-migration-finops-handoff/optimization-backlog-template.csv). > **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](/blog/how-to-use-aws-cost-anomaly-detection-catch-surprise-bills/) routed to a channel a human reads. Diffusion of responsibility is the actual root cause of post-migration cost drift — see [the FinOps gap](/blog/aws-finops-gap-engineering-cost-ownership/). ### 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](/blog/aws-tagging-chargeback-finops-ownership-2026/). 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](/blog/aws-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](/blog/aws-nat-gateway-billing-idle-cost-alternatives/)), 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](/blog/aws-reserved-instances-vs-savings-plans-decision-guide-2026/). > **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](https://bitbucket.org/baymail/factualminds-astro/src/main/examples/architecture-blog-2026/post-migration-finops-handoff/optimization-backlog-template.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](/blog/finops-on-aws-complete-guide-cloud-cost-governance/). - **The migration program that feeds this handoff** — see [data-center exit](/blog/data-center-exit-large-scale-aws-migration-program/) and [choosing a migration strategy](/blog/aws-migration-strategy-choose-right-approach/). - **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](/blog/finops-on-aws-complete-guide-cloud-cost-governance/) · [Tagging, chargeback & FinOps ownership](/blog/aws-tagging-chargeback-finops-ownership-2026/) · [RI vs Savings Plans](/blog/aws-reserved-instances-vs-savings-plans-decision-guide-2026/) · [Cost Optimization Hub guide](/blog/aws-cost-optimization-hub-guide/) · [AWS FinOps Agent preview](/blog/aws-finops-agent-preview-bedrock-cost-anomaly-2026/) · [FinOps consulting](/services/finops-consulting/) · [Cost optimization services](/services/aws-cloud-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. ## FAQ ### 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. --- *Source: https://www.factualminds.com/blog/aws-post-migration-optimization-finops-handoff-2026/*