Most VM modernization projects start with a performance conversation - faster processors, better throughput, lower latency. The financial dimension rarely gets the same attention, and that oversight can derail an otherwise well-planned migration. Andrew DeLave, Senior FinOps Specialist at ProsperOps, presented a practical framework that treats performance and cost as a single unified project, not two separate workstreams.

Main insights

• VM modernization decisions require evaluating private pricing, discount eligibility, and commitment timing - not just on-demand rates
• The timing of modernization against existing commitments can create up to 26% cost variance depending on your strategy
• Resource-based commitments often outperform spend-based commitments long-term, even when accounting for temporary on-demand costs during migration windows
• Capacity availability in target regions must be validated before finalizing any migration plan, especially as AI workloads compete for newer hardware

Andrew DeLave brings an infrastructure engineering background to his FinOps role, which gives him a grounded perspective on the coordination challenges between engineering and finance teams during modernization efforts. His session focused on a three-part decision framework that helps platform teams evaluate VM migrations with both scorecards in view.

You can watch the full discussion here if you missed it.

The two-scoreboard problem

VM modernization creates an inherent tension between engineering and FinOps teams because each group optimizes for different outcomes. Engineering focuses on latency, throughput, reliability, and developer productivity. FinOps tracks effective savings, cost avoidance, coverage, and lock-in risk.

The result is a familiar stalemate: FinOps wants to deploy commitments against stable usage to maximize discounts. Engineering says "wait, don't commit to that - we might want to modernize that workload." Nobody wants to be locked into old hardware for three years, but nobody can commit to new hardware without a clear migration plan.

As Andrew put it, a common customer reality is: "There's never a best time to finish modernizing and then commit. And there's 10 things on my list, but only capacity for three." Modernization consistently loses out to whatever is on fire that quarter.

The strongest modernization business cases resolve this tension by keeping score on both dimensions simultaneously.

The what-when-worth framework

Andrew introduced a three-part framework for structuring VM modernization decisions.

What: Mapping today's fleet to realistic targets

This starts with workload classification - identifying which workloads are on legacy families, which are stable enough to evaluate, and which are causing active performance or efficiency pain. Workloads causing pain are the best candidates because they deliver both engineering and cost wins simultaneously.

Most teams check two things when evaluating migration targets: whether the new VM family supports their workloads, and what the list price is. Andrew highlighted several critical factors that almost nobody checks:

• The actual committed run rate price, not list price
• Whether customer-negotiated pricing applies to new machine types
• Actual capacity availability in target regions and zones

"List price comparisons are almost always wrong as they do not actually match the invoiced reality that you're going to see reflective of PPAs, enterprise agreements, and enterprise discount programs," Andrew explained.

To illustrate this, Andrew walked through a pricing comparison using metrics like SPEC 2017 or CoreMark to normalize VM costs for performance. When comparing Google Cloud's N2 to N4 instances at list price, N4 appears more expensive per hour. But when normalized for benchmark performance, N4 delivers better cost per unit of work because you need fewer instances to achieve equivalent throughput. The per-hour comparison is misleading; the per-unit-of-work comparison is what matters.

When: Timing against commitments

The timing question breaks most modernization plans. Engineering picks migration windows based on testing and maintenance schedules. FinOps picks windows based on when existing commitments expire. These rarely align naturally.

Andrew presented two concrete strategies for an N2 to N4 upgrade on Google Cloud:

Option A: Spend-based commitments. As existing N2 commitments expire, immediately purchase compute-flexible CUDs or spend-based commitments to replace them. These float across usage even if you modernize later, so you don't need to know your migration window in advance.

The trade-offs with Option A:

• Teams tend to commit too conservatively because the usage impact of modernization is unclear, leaving savings on the table
• Spend-based commitments cap your long-term savings by forgoing the deeper discounts available with resource-based commitments

Option B: Resource-based commitments. Let usage run on-demand temporarily after N2 commitments expire, complete the modernization to N4 within a defined window (typically 3 - 6 months for enterprise workloads), then commit to N4 using resource-based commitments.

"This strategy is a math problem. It's not a leap of faith," Andrew emphasized. You can calculate the break-even point between Option A and Option B - specifically, how long workloads can run on-demand before the added savings from resource-based commitments outweigh the cost of that on-demand period. In most enterprise scenarios, the deeper discounts over the commitment lifetime more than cover the temporary on-demand exposure.

The trade-offs with Option B:

• Requires tighter coordination between engineering and FinOps teams
• Demands thorough testing of target machine types before committing, since resource-based commitments lock you in for 1 - 3 years
• Requires confirmed capacity availability from your cloud provider before finalizing the plan

Worth: Quantifying the full impact

To justify modernization effort to stakeholders, you must quantify both performance gains and financial impact. Andrew introduced three key metrics:

• ESR (Effective Savings Rate): Tracks overall ROI from commitments and discounts - are you paying more or less against list costs?
• EAR (Effective Avoidance Rate): Measures cost avoided by using less infrastructure through efficiency gains
• ECOR (Effective Cost Optimization Rate): Combines both dimensions - paying less and using less

The critical insight here: modernization's impact shows up in EAR, and that value disappears entirely if you only report against list price. Teams that skip this step systematically underreport the financial value of their modernization work.

Andrew also referenced a free pricing comparison tool, vmpricify.net.app, that helps teams evaluate source versus target VMs. The tool compares Google Cloud VM list prices across regions, machine types, and CPU vendors, then normalizes for performance - making it practical to run these comparisons before committing to a migration target.

Capacity availability: The constraint that kills well-planned migrations

One factor that deserves its own attention: capacity availability in target regions and zones. AI workload demand is making newer hardware increasingly scarce across major cloud providers. Even a technically sound and financially justified migration plan can stall if the target instance family isn't available where you need it.

Confirming capacity with your cloud provider's account team must happen before you finalize migration plans - not after. Discovering a capacity constraint mid-migration, after existing commitments have expired, puts you in the worst possible position financially.

​

If you enjoyed this, find here more great insights and events from our Platform Engineering Community.

If you want to dive deeper, explore our instructor-led Platform Engineering Certified Professional course and connect with peers from large-scale enterprises who are driving platform engineering initiatives.

​

Key takeaways

• Use the what-when-worth framework to unify performance and cost decisions. Map your current fleet to realistic targets using actual negotiated pricing, time migrations against commitment expirations, and quantify both performance and financial outcomes. Treating these as one project - not two - is what builds durable stakeholder support.
• List prices mislead - always evaluate using your negotiated rates. The gap between list price comparisons and actual committed costs with private pricing can swing modernization decisions by 20 - 30%. Normalize for performance to measure cost per unit of work, not cost per hour.
• Resource-based commitments often win long-term despite temporary on-demand costs. Calculate the break-even point between spend-based and resource-based commitment strategies. In most enterprise scenarios, the deeper discounts from resource-based commitments justify a 3 - 6 month on-demand window during migration.
• Validate capacity before you finalize any migration plan. AI demand is making newer hardware increasingly scarce. Discovering a capacity constraint after existing commitments have expired is an avoidable and costly mistake - confirm availability with your cloud provider's account team early in the planning process.