--- 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 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. url: https://www.joinhorizon.co/blog/aws-post-migration-optimization-finops-handoff-2026/ datePublished: 2026-06-10T00:00:00.000Z dateModified: 2026-10-28T00:00:00.000Z author: kevin-w 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 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. **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](https://www.joinhorizon.co/blog/data-center-exit-large-scale-aws-migration-program/) to a steady-state [FinOps practice](https://www.joinhorizon.co/blog/finops-on-aws-complete-guide-cloud-cost-governance/). We ship a [30-day handoff checklist](https://www.joinhorizon.co/examples/architecture-blog-2026/post-migration-finops-handoff/finops-handoff-checklist.md) and an [optimization-backlog CSV template](https://www.joinhorizon.co/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 to 25% utilization is typically a double-digit-percent compute cut. Sequencing matters here: 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: 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](https://www.joinhorizon.co/blog/how-to-use-aws-cost-anomaly-detection-catch-surprise-bills/) routed to a channel a human reads. Diffusion of responsibility is the root cause of post-migration cost drift (see [the FinOps gap](https://www.joinhorizon.co/blog/aws-finops-gap-engineering-cost-ownership/)). ### 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](https://www.joinhorizon.co/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](https://www.joinhorizon.co/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, 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](https://www.joinhorizon.co/blog/aws-nat-gateway-billing-idle-cost-alternatives/)), 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](https://www.joinhorizon.co/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 had 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. ## 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://www.joinhorizon.co/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](https://www.joinhorizon.co/blog/finops-on-aws-complete-guide-cloud-cost-governance/). - **The migration program that feeds this handoff:** see [data-center exit](https://www.joinhorizon.co/blog/data-center-exit-large-scale-aws-migration-program/) and [choosing a migration strategy](https://www.joinhorizon.co/blog/aws-migration-strategy-choose-right-approach/). - **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](https://www.joinhorizon.co/blog/finops-on-aws-complete-guide-cloud-cost-governance/) · [Tagging, chargeback & FinOps ownership](https://www.joinhorizon.co/blog/aws-tagging-chargeback-finops-ownership-2026/) · [RI vs Savings Plans](https://www.joinhorizon.co/blog/aws-reserved-instances-vs-savings-plans-decision-guide-2026/) · [Cost Optimization Hub guide](https://www.joinhorizon.co/blog/aws-cost-optimization-hub-guide/) · [AWS FinOps Agent preview](https://www.joinhorizon.co/blog/aws-finops-agent-preview-bedrock-cost-anomaly-2026/) · [FinOps consulting](https://www.joinhorizon.co/services/finops-consulting/) · [Cost optimization services](https://www.joinhorizon.co/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. ## 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. 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. --- *Source: https://www.joinhorizon.co/blog/aws-post-migration-optimization-finops-handoff-2026/*