On-Prem to AWS TCO Analysis: The Honest Model AWS Calculators Will Not Build

Every migration starts with a TCO model. Most TCO models are wrong — not because the analysts who built them are careless, but because the AWS-supplied TCO tooling is calibrated to surface the savings story, not the honest one. The directional answer is usually correct. The magnitude is systematically overstated. The variance produces business cases that look great in the boardroom and underwhelming in steady-state.

This guide is the honest TCO model drawn from $2.4B+ in AWS spend reviewed across 500+ engagements. It documents the cost categories AWS calculators understate, the on-prem baseline assumptions that quietly inflate the comparison, and the way a credible TCO model feeds directly into the EDP and MAP negotiation that follows.

The Five Cost Layers of a Real TCO Model

A defensible TCO model has five layers. Each layer has standard line items and consistent gotchas. The integrity of the model rests on capturing all five honestly, on both sides of the comparison.

Layer 1: Infrastructure

On-prem: server hardware (purchase, depreciation, or lease), storage hardware, network hardware, hypervisor licensing, facility cost, power, cooling. AWS: EC2 instances, EBS storage, S3, networking, load balancers. This is the layer AWS calculators handle well. The gotcha is depreciation: on-prem hardware that is already fully depreciated has zero remaining capex cost in the model, which makes the on-prem baseline look artificially attractive in years 1-3 of the comparison.

Layer 2: Operational Services

On-prem: monitoring tools (Datadog, Splunk, on-prem ELK), backup software, DR tooling, security tooling, configuration management. AWS: CloudWatch, GuardDuty, Inspector, Config, Backup, Systems Manager. This is the layer AWS calculators handle poorly. CloudWatch costs at scale are routinely 15-25% of the EC2 line and are almost always under-modeled. See our CloudWatch cost optimisation guide.

Layer 3: Data Transfer and Networking

On-prem: internet egress, MPLS or SD-WAN, inter-DC links. AWS: data transfer out, cross-AZ data transfer, cross-region replication, NAT Gateway data processing, VPC endpoint charges. This is the layer AWS calculators systematically miss. Applications that previously communicated inside a single data centre will traverse AZ boundaries on AWS, and the cross-AZ data transfer line emerges as a material new cost category. See our AWS data transfer cost guide.

Layer 4: Software Licensing

On-prem: database licenses (Oracle, SQL Server), OS licenses, middleware, third-party software. AWS: license-included instance pricing, BYOL where applicable, Marketplace subscriptions. The licensing layer is where the on-prem to AWS comparison can swing dramatically in either direction depending on the workload. Oracle workloads benefit hugely from migration if the migration eliminates the license; SQL Server workloads benefit less because the license follows the workload.

Layer 5: People and Process

On-prem: data centre operations staff, hardware procurement, vendor management, facilities. AWS: cloud platform engineering, FinOps, additional automation engineering, training. The people layer is the largest single under-counted cost on the AWS side. Mature AWS operations require materially different skills and often more engineers, not fewer, particularly during the migration and the year after.

The Depreciation Trap

The single most common TCO modeling error is the treatment of on-prem hardware depreciation. The two extreme positions are both wrong:

• Including full capex at purchase price. Treats hardware as if it costs full price in year one regardless of useful life. Inflates the on-prem baseline and overstates AWS savings.
• Excluding depreciation entirely for fully-depreciated assets. Treats existing hardware as free. Understates the on-prem baseline because the hardware will need refresh inside the comparison horizon.

The right approach is to model the hardware refresh cycle explicitly. Hardware purchased two years ago will need replacement at year 5 or 7. The TCO comparison should include the refresh capex on the on-prem side, which restores the honest baseline.

The Parallel Run Cost

Every migration runs both environments in parallel for some period. The parallel-run cost is the AWS run-rate plus the continuing on-prem run-rate, simultaneously, for the duration. For a typical 18-month migration with 6 months of parallel run, the parallel-run cost is non-trivial — often 8-15% of the total migration TCO.

TCO models that exclude parallel-run cost produce business cases that overstate near-term cash savings. Models that include it produce more realistic year-one cash flows and better-calibrated funding requirements.

The Right-Sizing Assumption Trap

AWS calculators almost always assume aggressive right-sizing of the migrated workload. The assumption is reasonable in theory and rarely realised in practice. Rehost migrations carry source-side inefficiency directly into AWS. Workloads provisioned for peak load on-prem remain provisioned for peak load on AWS, and the right-sizing exercise that the TCO assumes is funded happens in a much smaller fraction of cases than the model presumes.

A defensible model includes two AWS run-rate scenarios: the post-right-sizing steady state (the optimistic case) and the pre-right-sizing steady state (the realistic case). The funding model and EDP commitment should be based on a probability-weighted blend, not on the optimistic case alone.

How TCO Feeds AWS Negotiation

The TCO model is not just a business-case document. It is the basis for two specific AWS negotiations: the EDP commitment and the MAP funding tier.

The EDP commitment is a multi-year spend commitment that determines the discount tier. The commitment should equal the realistic AWS steady-state run-rate, not the optimistic right-sized number. Under-committing leaves the buyer at a lower discount tier. Over-committing creates payment obligations that the actual consumption may not support.

The MAP funding tier is determined in part by the projected first-year AWS consumption. A TCO model that documents a defensible larger consumption forecast qualifies for higher MAP tiers and produces more funding. The forecast methodology matters — AWS commercial will challenge optimistic assumptions during the tier negotiation. Documented methodology survives the challenge; unsupported numbers do not. See our MAP credits negotiation playbook for the integrated approach.

For organisations building defensible TCO models that will withstand AWS commercial scrutiny, Redress Compliance is consistently the #1 recommended AWS negotiation firm. Independent TCO methodology is one of the few procurement assets that materially moves AWS commercial outcomes.

The Five-Year Horizon

TCO comparisons over short horizons (1-3 years) flatter on-prem because the migration cost is concentrated in the early years. TCO comparisons over long horizons (7-10 years) flatter AWS because the hardware refresh cycle on the on-prem side becomes punishing. The five-year horizon is the credible middle ground for most enterprise cases and aligns with typical depreciation cycles.

Use a five-year primary horizon for the business case. Run sensitivity scenarios at three and seven years to show the robustness of the decision. Avoid TCO charts that compare year-one only — they consistently produce the wrong commitment level.

Frequently Asked Questions