Modernize Software Logo
Modernize COBOL COBOL to Java COBOL to C# Natural/ADABAS to Java Natural/ADABAS to C# Jovial to C# Tandem Modernization ColdFusion to Java
DMS
About
Blog FAQ's
Contact Us
Financial services August 4  •  13 min read

Modernize Now: Why Legacy Costs Are Breaking the Bank Budget

Mainframe, NonStop, COBOL, and core and payments package costs rise every year for banks. Here's the full cost picture and how to move off them safely.
← All posts

The short version

For most banks, the legacy run-cost goes up every year on its own. Mainframe software charges rise even when the hardware doesn’t change, MIPS pricing has climbed since 2022, NonStop and Tandem support and skills get pricier as the pool shrinks, and core and payments package maintenance keeps escalating while vendors steer you toward buying their newer platforms.

You can optimize the bill, and that buys time without removing the dependence. The durable move is to convert the code you own off these platforms and languages, with the behavior preserved exactly, because in banking a migration error isn’t a bug you patch later. It’s a financial misstatement, a regulatory issue, or a customer-facing outage.

That’s where deterministic transformation fits. DMS, the engine Modernize Software is built on, uses symbolic AI and enhanced compiler technology to convert your code deterministically, with Gen AI capturing the business rules buried in decades of customizations along the way.

The economics have flipped

For years the case for staying on legacy was simple: it works, it’s reliable, and modernizing is risky. That hasn’t changed. What’s changed is the other side of the ledger. The cost of staying now rises on a schedule you don’t control, while the cost of moving has fallen as automated conversion has matured. The lines have crossed for a growing number of banks.

Put a number on it. Large mainframes commonly cost somewhere between $840 and $2,000 per MIPS per year once software is included, so a 5,000 MIPS workload runs on the order of $7,000,000 to $8,000,000 a year before you touch the packages on top. Monthly license charges are tied to peak usage, calculated on a rolling four-hour average, so a single busy window sets the bill for the month. The cost of standing still, by several estimates, rises 15 to 20 percent a year on the mainframe alone. Nothing about your business has to grow for the invoice to.

Where the costs are climbing, layer by layer

The legacy run-cost isn’t one line item. It’s stacked, and every layer is moving in the same direction. Banks running card and payments workloads feel this across two platforms at once: the IBM mainframe for the core, and HP NonStop, the platform formerly known as Tandem, for the switches.

The mainframe layer

IBM z/OS and the core subsystems around it, Db2, CICS, IMS, and MQ, are licensed under monthly charges tied to peak MSU consumption. Software can be 30 to 40 percent of the platform’s total cost, the ISV tools stacked on top add their own maintenance fees, and the whole thing rises 5 to 8 percent a year even when the hardware sits still. Most organizations also lack clear visibility into which workloads drive their peak, so they can’t easily tell a usage increase from a pricing increase.

The NonStop and Tandem layer

The payment switches that authorize card transactions, including ACI’s BASE24 and BASE24-eps and the FIS Connex switch, run on HP NonStop, the Tandem lineage. That means specialized hardware, specialized support contracts, and a developer pool that’s even smaller and older than the COBOL one. A current job posting for a Connex and BASE24 developer on NonStop asks for seven or more years of experience, which tells you how narrow the talent funnel has become for the systems that move the money.

The language layer

Underneath both platforms sit COBOL and Assembler. The compilers and runtimes carry their own licensing, and the real premium is the people: experienced mainframe COBOL developers command well into six figures, and the pool is retiring. Assembler expertise is rarer still. Every year the language layer gets more expensive to staff, independent of how much code you actually change.

The package layer

On top of all that sit the packages that run the bank: core systems like Hogan, the long-running mainframe core now curated by Luxoft, and FIS Systematics, alongside the payment engines already named. Package maintenance and license fees escalate annually, customizations accumulate that only a few people understand, and vendors increasingly steer customers toward repurchasing their newer cloud-native platforms, which is a fresh migration and a fresh cost in its own right. ACI, for instance, is now moving payment customers toward its cloud-native Connetic platform. Whatever the path, the package layer rarely gets cheaper by waiting.

The multipliers that make it worse

The skills premium compounds the licensing cost. It isn’t only that the software bill rises. The people who can run these platforms are scarce and getting scarcer, which means contractor rates climb and key-person risk grows. In one IDC survey, 67 percent of CIOs named the mainframe skills shortage as their top infrastructure risk for 2025 and 2026. For NonStop, BASE24, Connex, and Hogan specialists, the pool is narrower still.

Lock-in limits your options. In a core banking survey, 17 percent of banks cited lock-in with their core vendor as a key challenge, and a similar share cited the talent shortage for maintaining legacy cores. When the platform, the language, the packages, and the few people who understand them are all controlled by someone else or aging out, your negotiating position weakens every year.

The opportunity cost is the largest number nobody invoices. Every dollar locked into rising run-cost is a dollar not spent on fraud detection, real-time payments, or customer experience. One Tier-1 US bank facing a 15 percent year-over-year jump in MIPS consumption cut its billable MIPS by 28 percent through workload offloading, microservices, and a revised pricing model, and redirected 12 million dollars in annual savings into an AI-driven fraud initiative. The run-cost wasn’t just expensive. It was holding back the work that grows the business.

Why optimizing the bill only buys time

There’s real money in cost optimization, and you should take it. Moving batch jobs out of peak windows, offloading eligible work to zIIP processors, consolidating the ISV stack, and renegotiating to a tailored fit pricing model can cut monthly license charges by 15 to 30 percent. Banks have done it: one global bank running three z15 mainframes cut MLC by 28 percent over 18 months and avoided a seven-figure annual increase.

That’s the right first move, and it has a ceiling. Optimization lowers the slope of the increase. It doesn’t remove the dependence, and it doesn’t stop the underlying escalation. You’re still on the platform, still paying the package, still hostage to a shrinking talent pool, and still watching the bill rise from a slightly lower base. To change the trajectory rather than the starting point, you have to move the code you own off the platform.

Why how you move matters more in banking than anywhere else

For a bank, a modernization mistake doesn’t show up as a slow page. It shows up as money in the wrong place. COBOL processes an estimated 3 trillion dollars in daily commerce, much of it in banking, and a logic error introduced during migration can become a financial misstatement, a regulatory breach, or an outage that locks customers out of their accounts.

The cautionary tale is well known. In 2018, TSB migrated off its legacy core to a new platform, and inadequate pre-migration mapping of the business logic contributed to a severe, prolonged outage that locked customers out, drew regulatory scrutiny, and cost the bank heavily. The lesson isn’t that modernization is dangerous. It’s that the conversion has to preserve behavior exactly, and you have to be able to prove it did, before you cut over.

The requirement this sets: for a regulated core or payment system, the new code has to be functionally equivalent to the old one, the same result for the same input, and that equivalence has to be demonstrable. Probabilistic conversion that’s usually right isn’t good enough when the output is somebody’s account balance.

The way off: deterministic conversion, with Gen AI capturing the knowledge

This is where deterministic transformation fits the banking problem precisely. Modernize Software is built on DMS, which uses symbolic AI and enhanced compiler technology to convert legacy code deterministically, with output built to be functionally equivalent to the original. The same construct converts the same way across the entire system, so a multi-million-line core becomes a coherent modern codebase rather than a pile of inconsistent translations, and the result is something you can validate against the original for equivalence before you trust it.

Applied across the layers, that means converting the COBOL and Assembler off the mainframe to a modern language that a far larger pool of developers can maintain, and converting the custom code on NonStop off the Tandem platform. Gen AI augments the work by capturing the institutional knowledge as the conversion proceeds: documenting the system, explaining the original code, and extracting the business rules buried in decades of Hogan, BASE24, and Connex customizations, so the logic that defines your bank is recorded in plain language rather than trapped in a few people’s memories.

An honest scope note. Packages like Hogan, FIS Systematics, and BASE24 include vendor code you don’t own, so modernization focuses on the parts that are yours: your customizations, your surrounding COBOL and Assembler, and the platform and language they run on. Replacing a packaged core outright is a larger build-versus-buy program. For the large body of bank-owned code that has to keep behaving exactly as it does today, deterministic transformation is the engine, and Gen AI alone is not the right tool for that conversion.

The economic case has improved sharply. Automated conversion now handles a large majority of the work, with reported automation rates of 70 to 85 percent in 2025, up from around 40 percent in 2020, and average modernization project costs have fallen as that automation has matured. A bounded, one-time investment ends a recurring, escalating cost. ING, for example, used an incremental approach to cut mainframe MIPS consumption by roughly 30 percent over three years without a production outage.

The principle: every layer of the legacy run-cost is a recurring charge that rises as the platforms age and the talent thins. Converting the code you own off those platforms is a one-time investment that ends the recurring charge and removes the lock-in. The sooner you start, the more business-rule knowledge you can still capture from the people who hold it.

A practical plan for the next 24 months

Sequence the work so the immediate savings fund the durable change, and the time-sensitive knowledge capture happens before the experts leave.

  1. Baseline the true legacy run-cost. Add up every layer: MLC and MSU charges, NonStop support, package maintenance and license fees, ISV tools, and contractor spend. Most banks underestimate the total because it’s spread across budgets.
  2. Optimize immediately to stop the bleeding. Offload eligible workloads to zIIP, move batch out of peak windows, consolidate the ISV stack, and move to tailored fit pricing. Use the savings to fund the modernization.
  3. Capture the knowledge now. While the COBOL, Assembler, NonStop, and package experts are still in their seats, use Gen AI to document the systems and extract the business rules embedded in your customizations, and have those experts confirm the output.
  4. Convert the highest-cost, highest-risk code deterministically. Move the bank-owned code off the mainframe and off NonStop with a transformation engine, and validate the result for functional equivalence against the original before anything goes live.
  5. Phase it, and verify correctness at each step. Move functionality across incrementally rather than attempting a single cutover, the mistake that hurt TSB. Each phase lowers the run-cost and the risk a little further.

Common mistakes, and how to avoid them

Where Modernize Software fits

Modernize Software is built on DMS, which uses symbolic AI and enhanced compiler technology to convert legacy code deterministically, with Gen AI capturing the documentation and business rules along the way. For a bank, that addresses the cost problem at its root: it moves the COBOL and Assembler off the mainframe and the custom code off NonStop, onto a modern language a far larger pool can maintain, with the behavior preserved and the equivalence demonstrable. The recurring, escalating run-cost becomes a bounded, one-time conversion, and the lock-in goes with it. If your legacy bill rises every year regardless of what your business does, that’s the conversation to have, and it’s better had while the experts who understand your customizations are still here to help.

Talk to Modernize Software

Tell us which platforms and packages drive your run-cost and which systems you can’t afford to get wrong, and we’ll map a conversion that preserves behavior and ends the escalation.

Frequently asked questions

Why do mainframe and legacy costs keep rising even when we change nothing?

Because the pricing is structured to. Mainframe monthly license charges are tied to peak MSU consumption rather than average use, software can be 30 to 40 percent of total cost, and a typical large financial institution sees software charges rise 5 to 8 percent a year with no hardware change. MIPS pricing has also climbed an estimated 15 to 20 percent since 2022. On top of that, package maintenance escalates and scarce skills get pricier, so the bill rises on its own.

What’s driving cost on the NonStop and Tandem platforms specifically?

The card and payment switches that many banks run, including ACI’s BASE24 and BASE24-eps and the FIS Connex switch, sit on HP NonStop, the Tandem lineage. That brings specialized hardware, specialized support contracts, and a developer pool that’s smaller and older than the COBOL one, so support and talent premiums keep rising for the systems that authorize transactions.

Can’t we just optimize our licensing instead of modernizing?

You should optimize, and it has a ceiling. Tactics like zIIP offloading, moving batch out of peak windows, ISV consolidation, and tailored fit pricing can cut monthly license charges by 15 to 30 percent, and banks have achieved around 28 percent. That lowers the base and leaves you on the platform, still paying the packages and still dependent on scarce skills. Optimization buys time; converting the code you own off the platform changes the trajectory.

Is automated conversion safe for a regulated core or payment system?

It is when it’s deterministic and validated. The risk in banking is that a logic error becomes a financial or regulatory problem, as the 2018 TSB migration showed. Deterministic transformation converts the same construct the same way every time and produces output built to be functionally equivalent, which can be validated against the original before cutover. Probabilistic conversion that’s usually right is not appropriate when the output is an account balance.

What about the packages themselves, like Hogan, FIS, and BASE24?

Those include vendor code you don’t own, so modernization focuses on the parts that are yours: your customizations and the surrounding COBOL and Assembler, plus the platform and language they run on. Replacing a packaged core outright is a larger build-versus-buy decision. For the large body of bank-owned code that has to keep behaving exactly as it does, deterministic transformation is the right engine, and Gen AI captures the business rules embedded in your customizations.

How long until modernization pays back?

It varies with scope, and the economics have improved. Automated conversion now handles 70 to 85 percent of the work, up from around 40 percent in 2020, and project costs have fallen as that automation matured. The recurring, escalating run-cost becomes a bounded one-time investment, and incremental programs commonly reach payback within a few years while lowering risk along the way.

Sources and further reading

Selected references behind the figures in this guide.

abstract-flow-shape-with-rainbow-reflections-refraction

Start with the code you thought could not move.

Send us a short note about your system. Rough line counts and target stack are enough to begin.

A Semantic Designs Company
Automated software modernization
powered by deep code understanding.
DMS, "Design Maintenance System" and Refactor++ are registered trademarks of Semantic Designs, Inc.
 The SD logo and "Semantic Designs" are registered service marks of Semantic Designs, Inc.
 The OMG logo is a registered trademark of the Object Management Group, Inc. in the United States and other countries.
 Software Reengineering Toolkit, CloneDR, PARLANSE, JOVIAL2C, Thicket, Smart Differencer, CheckPointer are trademarks of Semantic Designs, Inc.
Mail Icon info@semanticdesigns.com Mail Icon webmaster@semanticdesigns.com

© 2026 Semantic Designs All rights reserved | Privacy Policy