Mainframe Modernization on AWS: What the Cutover Costs

Mainframe modernization on AWS doesn't usually go wrong in the planning sessions. It goes wrong in the weeks between the last test cycle and the morning your branches, claims desks, or plant floors start running on the new stack. That's when two platforms run side by side, release freezes hold the business back, and every reconciliation break waits on someone with the authority to sign it off, so that's when budgets swell.

We've been building regulated systems on AWS since 2008: payment platforms that answer to PCI DSS assessors, claims platforms that answer to HIPAA, and agent-driven workflows that have to explain every decision to an auditor. When we're asked to rescue or price a mainframe program, we nearly always find the same thing. The code conversion has been estimated down to the line, and the cutover has been ballparked, even though the cutover is where the money and the risk sit.

We'll use one made-up but typical company to keep the numbers honest: a US regional bank whose deposits, consumer loans, and general ledger still run on a z/OS mainframe. There are about 4 million lines of COBOL behind them, some 2,500 batch jobs every night, and data split between Db2 for z/OS and VSAM files. Keeping it all running costs $9.6 million a year, and the hardware lease and two big ISV contracts renew in 20 months, which makes that the real deadline. Debit cards bring PCI DSS into scope, and because the bank is listed, SOX applies too.

If you're the one taking that number to the board, the bank's case shows where it usually goes wrong and what to ask for instead.

What does mainframe modernization on AWS cost once cutover is included?

Four things drive the cost of mainframe modernization on AWS. Two are about size: MIPS and lines of code. Two are choices you make: the path for each application and how many cutover waves you run. Then there's the one budgets tend to guess at, which is how long both platforms run side by side. Get that guess wrong, or skimp on reconciliation and hypercare, and the program comes back with a change order.

The cutover ledger deserves this much attention because downtime is expensive. Splunk's 2026 study with Oxford Economics put unplanned downtime for Global 2000 companies at $15,000 per minute on average. Four extra hours on a cutover weekend would cost $3.6 million at that rate, which is more than most programs budget for hypercare.

When one firm prices the build and another inherits the go-live, the cutover tends to fall between the two contracts, and nobody owns the overrun. So our legacy software modernization engagements put the cutover and the legacy switch-off in the same fixed-fee scope as the build.

Which AWS mainframe modernization path fits your estate: rehost, replatform, refactor, or reimagine?

There isn't one path for the whole estate. You choose per application, based on how much its business logic has to change and how long you plan to keep it. In the estates we assess, that usually leaves a few workloads refactored, a few reimagined, some retired outright, and a small set replatformed to buy time.

At the bank, deposits and consumer loans would go to automated refactor, since the bank expects to run and change them for another decade. Loan origination, which the business wants to redesign anyway, would be reimagined. About 300 regulatory reports that nobody opens anymore would be retired, with their data archived to Amazon S3. The debit card system would stay put for now, behind APIs, because its processor contract runs another three years, and its data would stream to AWS through change data capture.

When you sort the portfolio, look at how often each application changes. If it changes often, refactoring or reimagining it starts to pay off. Code nobody has touched in ten years, with fewer users every year, rarely justifies a rewrite.

Ask two more questions now, or you'll be asking them in hindsight. First, which applications share data stores or batch chains, since they'll have to move in the same wave? (At the bank, that's the general ledger and the deposit system, which share a nightly batch chain.) Second, is anything tied to an exam, an audit, or a contract deadline that fixes the cutover window no matter what the engineers say?

What changed in the AWS mainframe toolchain, and how does it move your budget?

Until March 2026, refactoring a mainframe with AWS's tooling meant paying by the line of code. Now AWS Transform for mainframe refactor offers code transformation at no cost, and AI agents handle much of the analysis and planning that analysts used to bill for. That money hasn't vanished from the budget. It's moved to testing, data parity, the cutover, and the engineers who make the calls that hold it all together.

The practical takeaway for a CFO: a proposal that still carries a large, opaque line for "code conversion" deserves a hard second look. Ask what the tool costs, what the remediation costs, and what the validation costs, as three separate numbers.

Two smaller changes matter for the run budget. AWS's pricing page lists the refactor runtime at $0.31 per AWS CPU core per hour, so the converted code still has a running cost. And if an older plan relied on AWS's own runtime for a replatform, those AWS Mainframe Modernization options no longer accept new customers, so the runtime has to come from the vendor directly.

We see the same shift in database work. On our application and database modernization programs, the savings from automated conversion are only real when the freed-up budget goes into validation and a clean cutover. Programs that pocket the savings and trim the test phase tend to give it all back during hypercare.

How do you build a mainframe migration to AWS cost model that survives CFO review?

A mainframe migration to AWS cost model survives CFO review when it prices the cutover as explicitly as the build and shows what each month of delay costs. We call this the Cost-Plus-Cutover model. It is the same arithmetic we put in front of finance teams before any statement of work is signed.

Total program cost = Build + (D × m) + F + R + H + B

D is what AWS costs each month at production scale while the parallel run lasts, and m is how many months it lasts. The mainframe bill isn't in there, because you're paying it until the exit date anyway. F is the cost of the change freeze, R covers reconciliation and business sign-off, H is hypercare, and B is the rollback reserve.

Finance and engineering have to agree on the inputs before anyone fills it in:

• Peak and average MIPS or MSU consumption, plus the monthly license charges and ISV contracts tied to them
• Renewal and notice dates for every mainframe contract, since these set your real deadline (for the bank, the hardware lease and two ISV renewals 20 months out)
• Batch windows, scheduler dependencies, and the downstream files other systems expect
• Data volumes for every store, along with the retention and residency rules each one falls under
• Regulatory events and blackout dates: quarter-end close and exam dates for a bank, open enrollment for a health plan, peak weekends for a retailer

Here's how it works out for the bank, with its $9.6 million annual run cost, a $6.0 million build, and a three-month parallel run.

The ratio matters more than the absolute numbers. At the bank, the cutover ledger adds roughly 43% to the build, and the single largest cutover line is the rollback reserve, equal to one month of mainframe run cost.

Then run the sensitivity that most proposals skip. If the mainframe exit slips one month past the contract date, the bank pays another $0.8 million in mainframe run cost plus a month of team burn. Let it slip three months and the bank has paid $2.4 million before counting the team, which is 40% of the whole build budget. That's why we put the exit date in the contract as part of our delivery commitment, not as a target.

How should you plan a mainframe cutover strategy without taking the business offline?

The bank can't take its branches offline, so it would move in waves. Each wave keeps data in sync in both directions until it's accepted, and nothing switches over until it has cleared a go/no-go gate with measurable criteria. Whichever pattern you pick for a wave decides the cost, the downtime risk, and how much evidence you'll have for an auditor afterward.

At the bank, the reporting and inquiry workloads would go first, on a shadow run. Consumer loans would follow as their own wave. Deposits and the general ledger, which share that nightly batch chain, would move last and together, with a full parallel run across a quarter-end close.

Each wave runs through the same loop. A failed gate sends the wave back for fixes and another parallel cycle, and a breached rollback trigger during hypercare sends traffic back to the mainframe, which stays current through reverse change data capture until the wave is formally accepted.

We built our delivery model around gates like these. Agents do the repetitive analysis and a forward-deployed engineer makes the judgment calls. Nothing passes a phase exit without the customer's signature, so every go/no-go decision ends up written down with a name next to it.

Then there's the calendar. In the US, that means steering clear of quarter-end close, tax season if anything touches filings, open enrollment at health plans, and the run from Thanksgiving to Cyber Monday for retail and payments. European operations add year-end close and August, when a lot of people are on holiday. The worst week the bank could pick would be the one before a Call Report is due, since any reconciliation break that turned up late would leave it no time to recover.

How long should a parallel run last in a mainframe migration, and what should it prove?

A mainframe parallel run should go on until the workload has been through every business cycle it handles, at least once. For the bank's loan system, one month-end close would do. Its general ledger and regulatory reports need a quarter-end. A retailer or a tax processor would need its peak season too. We count the cycles first and turn them into weeks afterward.

Mainframe logic hides at the edges. Say the bank tested its deposit system for two weeks in the middle of a month and everything matched. Then month-end arrived. An interest accrual rule that only fires on the last business day ran on AWS for the first time, and 40,000 accounts came out a few cents off. Nobody had seen that rule in two weeks of testing, and the same goes for tax tables that change in January, leap-year paths, and the batch jobs that run once a quarter.

What the parallel run must prove, and the evidence your auditors and business owners will want to see:

This is where the cost trade-off comes in. A full dual run on live input gives you the strongest evidence, but both platforms run at production scale, so it's the most expensive option. Replaying production traffic in a shadow run costs less and suits read-heavy workloads. That's why many programs, the bank's included, use a full dual run for ledgers and payments and a shadow run for reporting and inquiry screens.

Ask about MAP early, too. AWS's Migration Acceleration Program runs a mainframe track that offers methodology guidance, investment incentives, and partner support. If you might qualify, it's far easier to fold into the parallel-run budget before the statement of work is signed.

What does a rollback plan look like when the mainframe is still your system of record?

For the bank's deposit wave, a rollback plan that works keeps the mainframe current through reverse data synchronization. It marks a point of no return, and it turns every trigger into a number with someone's name next to it. Leave one out and you end up arguing at 3 a.m. about whether to roll back, with the branches due to open at nine.

The criteria get agreed before the parallel run starts, so nobody can move the goalposts during the cutover window. For the bank's deposit wave, they'd look something like this:

We hold to four rules on every program. The rollback gets rehearsed with the same care as the cutover, run in full in a lower environment, with someone timing it against the real window. Reverse CDC keeps running through hypercare, so the mainframe stays a warm fallback until the wave is formally accepted. Everyone knows where the point of no return is: once downstream systems or customers depend on data that exists only on AWS, a rollback becomes a forward fix. And the reserve stays funded, with at least a month of mainframe run cost and enough contract flexibility to use it, until final acceptance.

That discipline is what made the difference for a branded-payments leader whose two earlier modernization attempts had stalled before cutover. Our write-up of that program sums up why the first two failed: "Discovery eats the budget; cutover gets de-funded." The third attempt delivered a PCI DSS-aligned, cloud-native AWS platform with no audit incident during cutover.

Which compliance requirements shape a mainframe cutover for US and European enterprises?

The bank's compliance team would ask three questions about the cutover. What evidence do we need before go-live? Which weeks are we allowed to switch in? And can we prove we'd get back if something broke? On both sides of the Atlantic, operational resilience and third-party oversight are now exam topics in their own right, so the bank's answers would go straight into its compliance file.

For US institutions, the hard part is usually timing, and that's what we see across our financial services programs. Exams, quarter-end SOX testing, and card network deadlines all fall on fixed dates. At the bank, a deposit cutover that slipped from March to May would land its new-platform evidence in the middle of an exam cycle planned around the old system. So we plan the freeze calendar backward from those dates and fit the parallel run inside it. The cost of getting it wrong is concrete: IBM's 2026 Cost of a Data Breach Report puts the average financial services breach at $6.29 million, second only to healthcare, against a global average of $4.99 million.

In Europe, DORA has made resilience something you report on. In 2025, EU financial entities reported 3,383 major ICT-related incidents, according to the first DORA report from the European Supervisory Authorities. Half of them came down to system failures or malfunctions, and a botched cutover is exactly that. So we treat a rehearsed rollback and a tested exit plan as compliance deliverables, not engineering extras. Since November 2025, AWS has also been on the ESAs' list of designated critical ICT third-party providers, as Amazon Web Services EMEA SARL, so your register of information and exit strategy should name it.

Healthcare and life sciences organizations face the same logic under HIPAA. PHI can't sit half-migrated without access controls and audit logging on both sides. Our healthcare data platform work retires legacy systems on schedule, with data movement and access events traceable to source for audit teams.

Can AI agents convert COBOL to Java on AWS accurately enough for production?

They can, if they don't work alone. On the programs we run, agents sit inside a deterministic pipeline, with regression tests checking every change and an engineer owning each judgment call. A general-purpose model left to do the whole job gets less accurate as programs get more complex, and the parallel run is where you'd find out.

The research points the same way. In a 2026 arXiv study, GPT-4o produced compilable COBOL on only 41.8% of COBOLEval tasks, and just 16.4% passed their tests on the first try, while a domain-adapted model, COBOL-Coder, reached 73.95% compilation success. Practitioners are cautious too. Of 61 surveyed for a paper at ESEM 2026, 62.3% were happy to use LLMs for single-file migration most of the time or almost always, but only 4.9% would say that about a whole project. And in BMC's 2026 mainframe survey, 40% of respondents would let AI recommend code-management actions, while only 23% would let it carry them out.

So agents are very good at the volume work, and what's left of the risk sits in a smaller set of complex programs, cross-program dependencies, and data edge cases. That's where you want your senior engineers, and it's where the cutover gets decided. For the bank, that means the interest calculations and a few hundred Assembler routines. The hundreds of CICS screens that just read and update records are the easy part.

Fixed fee, time and materials, or outcome-based: how should you buy mainframe modernization services?

Here's how the bank's contracts would change over the program. Discovery would be time and materials, because nobody could price a scope that moved every week. After that, each of the three waves would get a fixed date and a fixed fee that fit the 20-month exit. The contract would also need a clause naming who pays when a date slips, and how each phase gets signed off. Put simply, the risk sits with whoever controls it.

Whatever the model, read the scope line by line. Cutover, hypercare, rollback rehearsal, and the mainframe switch-off should all be inside the fee. A proposal that stops at "code delivered to UAT" leaves the most expensive weeks of the program outside the price, and that is where change orders tend to appear.

One more point for CFOs. A fixed fee only has teeth if the provider's delivery economics make it sustainable. A firm that bills by the hour has every reason to add people when a program runs long. If most of the delivery runs on agents, an extra validation cycle costs the provider very little, and that's what makes committing to a date possible.

What should you ask a mainframe modernization partner before you sign?

If the bank were choosing a partner, we'd tell its CFO to get three things proven before signing: that the people scoping the work will run the cutover, that the cutover is in the price, and that the partner has named customers running in production on AWS today. Here's how that test might play out.

Say the bank put three firms through that test. The first couldn't promise that the engineers in the pitch would still be there on the cutover weekend. The second firm's fee stopped at UAT, with hypercare, rollback rehearsal, and the mainframe switch-off marked "to be scoped." Only the third could say who'd write the test cases and sign off that the new system behaved like the old one, what would happen to its fee if it caused a slip, and when each wave's rollback would be rehearsed.

The bank would still have a few questions for that third firm: how much of the work agents would do and how many hours that saves against a traditional proposal, how an auditor could trace an automated decision back to source, and which AWS competencies and service validations the team holds for migration and modernization.

Last, and most important, it would ask to speak to a named customer whose cutover looked like its own, and find out where they started, what changed, and how long the value took to arrive.