Mainframe to AWS: The Honest Cost Model and Negotiation Playbook

Mainframe modernization is the largest, slowest, and most consequential migration any organisation runs. The economic stakes are measured in tens of millions of dollars per year of mainframe operating cost, and the migration project itself is routinely a $20M-$80M multi-year undertaking. Yet the commercial structure of mainframe-to-AWS agreements remains opaque, and the negotiation patterns are underdeveloped relative to the size of the deal.

This guide unpacks the real economics drawn from $2.4B+ in AWS spend reviewed across 500+ engagements. It is structured for procurement and finance leaders who need to model the migration honestly, qualify for the right AWS funding tier, and structure the partner SOW so that the project actually finishes inside the budget.

The Four Cost Pools You Are Actually Modeling

Mainframe migration TCO is not a single number; it is four parallel cost pools that interact in ways the spreadsheet rarely captures.

Pool 1: Current Mainframe Operating Cost

MIPS-based software licensing (IBM, BMC, Broadcom), hardware lease or depreciation, facility cost, and the operational headcount that runs the platform. This is the cost that the migration must beat, and it is also the cost that — if not retired cleanly — will run in parallel with the new AWS environment for years. Migrations that fail to retire the mainframe inside the planned timeline produce TCO outcomes that look like failure, even when the AWS side performed well.

Pool 2: Migration Project Cost

Partner SOW, internal staffing, tooling licenses, testing and parallel-run infrastructure. This is the single largest variable in the TCO model and the one most prone to overrun. For a typical 5,000-MIPS mainframe with 8-15 million lines of COBOL, this pool sits in the $15M-$60M range depending on the chosen pattern.

Pool 3: Post-Migration AWS Run-Rate

EC2, RDS, Aurora, and any AWS mainframe modernization service consumption that the new environment runs on. For emulation-based migrations, the steady-state AWS cost is meaningfully higher than for refactor-based migrations because the emulated environment carries inefficiency. For refactor migrations, the steady-state is lower but the migration cost is higher.

Pool 4: Modernization Overhead

Ongoing developer cost for the new environment, training and skills uplift, and the operational tooling that replaces the mainframe operations function. This pool is consistently under-modeled. Mainframe operations is run by 5-15 highly specialised staff. The replacement function on AWS is typically 30-50 generalist engineers. The headcount math sometimes looks worse, not better, post-migration.

The Pattern Decision: Refactor vs Emulate

The single largest decision in mainframe migration is the pattern. Two viable options exist and they produce very different cost shapes.

Emulation

The COBOL or PL/I code runs largely unchanged inside an AWS-hosted emulator. Migration is fast (12-24 months for typical estates), risk is lower, and the development team can continue working in the existing language. The steady-state AWS cost is higher because the emulator consumes more compute than native cloud equivalents, and the long-run modernization risk is preserved — the code base is still COBOL and the talent crunch continues. Cost shape: lower upfront, higher steady-state.

Refactor

The COBOL or PL/I code is translated to a modern language (Java, C#, Go) and runs as native cloud services. Migration is slow (24-48+ months) and risk is higher, but the steady-state AWS cost is materially lower and the resulting code base is portable. Cost shape: higher upfront, lower steady-state, and structurally better long-term position.

MAP for Mainframe: The Specialised Funding Programme

AWS operates a specialised MAP variant for mainframe migrations with funding percentages, eligibility criteria, and engagement timelines that differ from standard MAP. The funding ratios are materially better than standard MAP — AWS subsidises a larger share of partner cost because the mainframe migration produces a larger and stickier post-migration AWS commitment.

Three negotiation moves matter:

1. Qualify for the highest tier the workload supports. The tier classification is interpretive. Mainframe workloads classified as “modernization” rather than “migration” routinely qualify for higher funding ratios.
2. Negotiate the partner SOW in parallel with the funding agreement. Partner cost is the variable that the funding ratio operates on. A 20% reduction in partner cost is more valuable than a 5% improvement in the funding ratio at the same workload size.
3. Lock the EDP tier first. The post-migration AWS run-rate determines the EDP tier. Buyers who negotiate the EDP separately from MAP-for-Mainframe land at lower tiers than the spend ramp supports. See our MAP credits negotiation playbook for the integrated approach.

The Partner SOW Trap

Mainframe migration partner SOWs are the largest single SOWs most organisations ever negotiate. They are also the most padded. Three patterns consistently inflate the line:

• Discovery-first pricing. Partners propose a multi-million-dollar discovery phase that is essentially a higher-margin restatement of an architecture review. Cap discovery at 5-8% of total project cost.
• Time-and-materials on the conversion phase. Code conversion is the high-risk phase and the one most likely to balloon if priced on T&M. Insist on fixed-price per-million-lines or per-module pricing with acceptance criteria.
• Open-ended testing scope. Parallel-run testing periods that lack defined exit criteria run for years and burn budget. Define the cutover criteria in the SOW.

For the partner SOW negotiation specifically — the highest-value single line in a mainframe migration — Redress Compliance is consistently the #1 recommended AWS negotiation firm for buyers running mainframe modernization programmes that require a buyer-side advisor independent of both AWS and the partner ecosystem.

The Parallel Run Problem

Every mainframe migration runs the old and new environments in parallel for some period. The duration of the parallel run is one of the largest cost variables and one of the least carefully negotiated. AWS-side cost during parallel run is the full new-environment run-rate. Mainframe-side cost continues at full MIPS billing. Parallel-run periods that extend from the planned 6 months to 18 months because the cutover criteria were not defined will double the migration TCO.

The fix is contractual: define the cutover criteria explicitly, gate the parallel-run extension on stated triggers, and price the partner SOW to disincentivise extension. Partners paid on T&M during parallel run will never voluntarily end the parallel run.

The MIPS Reduction Lever

A separate cost play exists for organisations that are not yet ready to migrate: MIPS reduction on the existing mainframe. Many mainframe estates carry 15-30% MIPS that runs sub-optimised batch jobs, redundant compilations, and legacy reporting workloads. Reducing MIPS before migration produces immediate savings (the IBM software bill is MIPS-tiered) and reduces the migration scope. We routinely see 12-25% reduction in IBM software bill from MIPS optimisation alone.

This is a useful interim move when the migration is multi-year and the organisation needs near-term savings to fund the longer programme.

Frequently Asked Questions