Solving the real ROI question behind moving off US hyperscalers

The symptom: a migration business case that never quite closes

An engineering lead runs the numbers on moving off a US hyperscaler. Compute looks cheaper elsewhere. Storage looks cheaper elsewhere. But when the spreadsheet goes to finance, someone asks about egress fees, migration engineering hours, and the risk of downtime during cutover, and the business case stalls. Six months later the same conversation happens again, with the same result.

This is not a failure of the migration plan. It is a failure of the cost model. Most ROI calculations for leaving a hyperscaler only compare list prices for compute and storage. That comparison is incomplete, and it consistently underestimates the actual return.

The actual root cause: hyperscaler pricing is designed to hide the real unit cost

US hyperscalers do not compete primarily on compute price. AWS, Azure, and Google Cloud compete on making it expensive to leave. The mechanism is architectural, not just contractual.

Egress fees are the anchor, not the compute bill

Data transfer out of AWS typically runs $0.09 per GB after the first GB, with regional variation. For a SaaS platform serving 50TB of monthly egress (video, API responses, backups, CDN origin pulls), that is roughly $4,500 per month just to move data out, before you have optimized anything else. This fee does not exist to cover bandwidth cost; bandwidth is cheap. It exists to make multi-cloud and cloud-exit financially uncomfortable.

Managed service lock-in compounds the exit cost

Teams that build on RDS, DynamoDB, SQS, and Lambda are not just using compute, they are using proprietary APIs. Migrating off means re-architecting data access layers, not just moving VMs. This is real engineering time, and it is the line item most ROI spreadsheets underestimate by 3-5x.

Reserved instance and savings plan commitments distort the comparison

Finance teams often compare an EU provider's list price against a hyperscaler's 3-year reserved instance rate, and conclude the hyperscaler is cheaper. But that reserved rate assumes flat, predictable usage for 36 months. Most SaaS and e-commerce workloads do not have flat usage. They have seasonal spikes, growth curves, and product pivots that make long commitments a liability, not a discount.

Support cost is invisible until you need it

Hyperscaler support tiers that include a named technical account manager start around $15,000/month minimum, and still route you through a ticket queue for anything beyond account management. Compare that to a managed infrastructure partner where a senior engineer answers directly, and the "free" basic support tier on a hyperscaler starts looking a lot less free once you factor in engineering hours lost to self-service troubleshooting.

The fix: a complete cost model, with the line items that actually matter

A real ROI calculation for cloud cost optimization services needs five cost categories, not one. Here is the framework we use with clients.

1. Baseline the current total cost of ownership

Pull 12 months of billing data, not one month. Seasonal spikes and reserved instance renewals distort single-month snapshots.

# AWS Cost Explorer CLI example: pull 12 months grouped by servicenaws ce get-cost-and-usage \n  --time-period Start=2024-11-01,End=2025-11-01 \n  --granularity MONTHLY \n  --metrics 'UnblendedCost' \n  --group-by Type=DIMENSION,Key=SERVICE

Break this into: compute, storage, egress, managed services (RDS, ElastiCache, managed Kubernetes), support tier cost, and reserved instance amortization. Egress alone is usually 8-15% of total spend for content-heavy or API-heavy platforms, and it is almost always excluded from the first draft of a migration business case.

2. Model the true migration cost, not just the target infrastructure cost

This includes:

• Engineering hours for re-architecting managed-service dependencies (DynamoDB to PostgreSQL, Lambda to containerized workers, SQS to a self-hosted queue)
• Data transfer cost to move the dataset out, one time
• Parallel-run cost: running both environments during validation, typically 4-8 weeks
• Downtime risk cost, budgeted as a contingency line, even if the migration is designed for zero downtime

For a mid-sized SaaS platform with a 2TB database and 15 microservices, this typically lands between 200 and 450 engineering hours. At a loaded cost of 80 euros/hour, that is 16,000 to 36,000 euros in one-time migration cost. This number needs to be in the model, not treated as a rounding error.

3. Recalculate egress and data transfer under the new architecture

If the target environment is EU-based and colocated with your CDN's EU PoPs, egress costs typically drop 40-70% because you are no longer paying hyperscaler egress rates and you have shortened the network path for the bulk of your traffic.

# Example: comparing egress cost modelsn# AWS us-east-1 to internet: $0.09/GB after first 1GB freen# EU-based provider with peering to major EU IXPs: $0.01-0.02/GB typicalnn# 50TB/month egress comparison:n# AWS: 50,000GB * $0.09 = $4,500/monthn# EU provider: 50,000GB * $0.015 = $750/monthn# Annual difference: $45,000

4. Rebuild the architecture around open standards, not proprietary APIs

The single highest-leverage decision in a hyperscaler exit is replacing managed proprietary services with open-source equivalents that run anywhere. This is what actually enables cloud cost optimization services to deliver a durable return, rather than a one-time discount that erodes as you re-adopt vendor-specific tooling.

• DynamoDB to PostgreSQL or self-managed MongoDB, both portable
• Lambda to containerized workers on Kubernetes or Nomad
• SQS/SNS to self-hosted RabbitMQ or Kafka
• CloudWatch to Prometheus and Grafana

This step is also where a decision between an open-source sovereign stack and managed public cloud gets made concretely, service by service, rather than as an abstract policy choice.

5. Execute the cutover as a zero downtime migration

The migration itself should follow a staged pattern: replicate data continuously, run both environments in parallel, cut over DNS with a low TTL, and keep the old environment warm for rollback for at least one billing cycle.

# Example: lowering DNS TTL ahead of cutovern# Set 48-72 hours before the cutover windownexample.com.  300  IN  A  203.0.113.10nn# During cutover, monitor both originsncurl -s -o /dev/null -w '%{http_code} %{time_total}s\n' https://old-origin.example.com/healthncurl -s -o /dev/null -w '%{http_code} %{time_total}s\n' https://new-origin.example.com/health

For database-backed applications, this typically means logical replication running for days before cutover, not a single export/import window. We cover the mechanics of this in detail in our 6-phase zero downtime migration playbook.

How to validate the fix worked

ROI claims need to be measured against baseline, not assumed. Track these for at least two full billing cycles post-migration:

• Total infrastructure spend per month, compared against the 12-month hyperscaler baseline, normalized for traffic growth
• Egress cost as a percentage of total spend, expect this to drop from 8-15% to 2-4% if the new provider has favorable peering
• p95 and p99 latency for the top 10 API endpoints, measured before and after cutover, to confirm the new environment did not trade cost for performance
• Error rate and uptime during the 30 days following cutover, compared to the 30 days preceding it
• Engineering hours spent on infrastructure operations per month, this often drops significantly when proprietary managed services are replaced with standard tooling that the team already understands

A useful sanity check: if total spend dropped 30% but p99 latency also degraded 25%, that is not a win, it is a cost shift into a metric that eventually costs you conversions. Reference our guide on choosing the right performance metric if you are validating this on a customer-facing platform.

Build a simple monthly reconciliation dashboard

This kind of table, filled in with your actual numbers, is what converts an ROI argument from a projection into evidence, useful both internally and for board-level reporting.

How to prevent recurrence

The reason this ROI conversation repeats every quarter at many companies is that nobody owns the cost model after the migration decision is made. A few structural changes fix that.

Assign cost ownership to engineering, not just finance

Cost regressions creep back in through architectural decisions: a new feature that reintroduces a proprietary managed service, a data pipeline that reintroduces cross-region egress. Finance cannot catch these at the point they are introduced. Engineering can, if cost is part of the architecture review checklist.

Set egress and compute budgets per service, with alerting

# Example Prometheus alert rule for cost anomaly detectionn# (paired with a cost-exporter feeding billing data as metrics)n- alert: EgressCostSpiken  expr: increase(egress_cost_eur_total[24h]) > 150n  for: 1hn  labels:n    severity: warningn  annotations:n    summary: 'Daily egress cost increased by more than 150 EUR'

Re-run the full TCO model annually, not just at migration time

Hyperscaler pricing changes, your traffic patterns change, and new services get adopted. A cost model that was accurate at migration time will drift within 12-18 months if nobody revisits it.

Avoid re-introducing proprietary lock-in through convenience adoption

The most common way teams undo their own cost optimization is adopting a new proprietary managed service because it is fast to integrate, then discovering 18 months later that it is now load-bearing and expensive to remove. Every new managed service should be evaluated against one question: can we replace this without a re-architecture if pricing changes?

The bottom line, and what to do next

The real ROI of moving off a US hyperscaler is rarely visible in a one-line compute price comparison. It shows up in egress costs that quietly consume 8-15% of spend, in the engineering hours saved by avoiding proprietary re-architecture cycles, and in support costs that stop scaling with your headcount. A complete model, built on 12 months of actual billing data and validated post-migration with real metrics, turns this from a recurring debate into a decision you make once.

If you'd rather not debug this again next quarter, our managed platform handles it by default.