How Banks Can Use Mainframe Modernization to Replace Old COBOL Systems Safely 

Mainframe modernization lets a bank replace old COBOL systems with one slice at a time while the old system keeps running as a safety net. You record what the COBOL does today, wrap it so new apps can call it, move one product or process across, and run old and new side by side until the numbers match the cent. Then you switch that slice over and start on the next one. 

That’s the short answer. It matters now because your COBOL experts are retiring, AI tools promise to rewrite the code in months, and regulators remember what happened when a UK bank moved its core in one go. 

This guide is for bank and credit union technology leaders who need a mainframe modernization plan that keeps payments, balances, and audit trails intact. 

Key takeaways 

• Move one slice at a time. A single product line or batch process is a safer unit of change than the whole core. 

• Record behavior before you touch the code. Rounding, batch order, date logic and sort order are where COBOL replacements break first. 

• Prove it in parallel. Run old and new on the same transactions, reconcile to the cent, and keep a tested way back. 

• Let AI read and let people sign off. AI speeds up discovery, but your teams still decide what “correct” means. 

• Some COBOL can stay. Stable, high-volume batch can sit behind APIs while you replace the parts that block change. 

What does mainframe modernization change for a bank? 

Mainframe modernization is the work of moving a bank’s core processing, usually written in COBOL, onto platforms and code that today’s teams can change safely. It can mean rehosting, converting, rewriting, replacing with a packaged core, retiring unused code, or wrapping old programs with APIs. For most banks, it ends up as a mix. 

COBOL still carries a large share of everyday banking. IBM figures quoted by CIO Dive in July 2026 put COBOL behind more than 40% of online banking systems, 80% of in-person card transactions, and 95% of ATM transactions. 

Finding people who can maintain that code is a real constraint. In Kyndryl’s 2025 State of Mainframe Modernization survey of 500 business and IT leaders, 70% said they struggle to find people with the right mix of skills for the work. 

Regulation shapes the work too. In that same survey, 94% said compliance requirements heavily shape their modernization plans, and 74% rely on outside providers to do part of the work. 

Here’s our view. In most banks, the hard part of leaving the mainframe is business logic that exists only inside COBOL programs, written by people who have since retired or moved on. Any plan for core banking modernization has to start by moving that logic out of people’s heads and into tests. 

What a bank gains from mainframe modernization 

Gains show one slice at a time, as each product or process leaves the old code. Here’s what changes once a slice has moved: 

• Rate and fee changes ship in a normal release, without waiting for a slot in the COBOL change queue. 

• Apps read live data through APIs, so mobile and partner apps see balances and payment status in real time. 

• Fewer rules depend on a few people, because the logic now sits in tests and documents. 

• Data reaches analytics and AI work sooner, without another nightly extract. 

• Run costs can fall, later, once workloads leave, and license terms allow for a smaller mainframe footprint. 

Why is a one-weekend COBOL switch so dangerous for a bank? 

A one-weekend switch, often called a big-bang cutover, moves every customer, account and process to the new system at once. If one hidden rule breaks, it breaks for every customer, and there’s no old system running to fall back on. A bank can’t pause payments while engineer’s debug. 

In April 2018, UK bank TSB moved customer accounts off systems hosted by Lloyds Banking Group onto a new core platform from its owner, Sabadell. Its data migrated, but customers faced months of disruption, and the bank didn’t return to normal operations until December 2018. 

UK regulators fined TSB £48.65 million in December 2022, on top of £32.7 million it had already paid customers in redress. Mark Steward of the FCA put it plainly: “The firm failed to plan for the IT migration properly.” Regulators also faulted how TSB managed risk from its IT outsourcing arrangements. 

Those planning and cutover risks are the same ones any COBOL modernization carries. Gartner warned in June 2026 that more than 70% of mainframe migrations started this year will fail, as CIO Dive reported, with teams overestimating what AI can do named as a cause. 

Which COBOL behaviors break first when the code moves? 

Behaviors nobody wrote down break first. COBOL programs carry decades of business rules inside data types, batch schedules, and old fixes. These five come up again in COBOL migration work. 

Rounding that lives in the data type 

COBOL stores money as fixed-point decimals, often in a packed format called COMP-3. Rounding rules sit in the field definition, where no one searching for the code for a rounding function will find them. 

Move that logic to Java or C# using floating-point numbers and a daily interest accrual can drift by a fraction of a cent per account. Across two million accounts, that’s a reconciliation break on day one. Use decimal types for money (BigDecimal in a COBOL to Java move) and test rounding against real ledger history. 

Batch jobs that depend on run order 

Most banks run overnight batch as a chain: interest before fees, fees before statements, statements before the general ledger feed. That order often lives in JCL (job control language, the scripts that start mainframe jobs), with dependencies no one has mapped in years. 

Change one link and a customer statement can show yesterday’s balance. Map the full batch chain before any mainframe modernization step touches a single job. 

Dates patched for the year 2000 

Plenty of banks handled Y2K with “windowing”: two-digit years below a pivot, say 50, were read as 20xx, and the rest as 19xx. Data stored in that way must be converted with the same pivot. A wrong pivot shifts birth dates or loan maturity dates by a century. 

Sort order that changes with the character set 

Mainframes use EBCDIC encoding, where lowercase letters sort before uppercase and letters sort before numbers. Most modern platforms use ASCII or Unicode, where numbers come first. 

Any report or file that depends on sort order can come out in a different sequence, and downstream systems may reject it or process it wrongly. 

Data files that need translating field by field 

Much of a bank’s mainframe data sits in VSAM files (the mainframe indexed file format) and DB2 tables, laid out by copybooks. Packed decimal amounts, signed fields and text in EBCDIC all sit side by side in one record. 

Copy those files across byte for byte, and the new system reads nonsense. Each field must be converted using its copybook layout, then checked with record counts and control totals, so every account and every cent arrives. 

These rules rarely appear in the requirements of documents. That’s why we treat the running system and its historical outputs as the specification for the new one. 

Can AI speed up mainframe modernization without adding risk? 

Yes, if AI does the reading and people do the approving. They’re less reliable as the final judge of whether converted code behaves exactly like the original. Proof that new code matches the old still comes from testing against real outputs. 

Markets noticed the shift this year. In February 2026, Anthropic said AI lets teams modernize a COBOL codebase “in quarters instead of years.” IBM’s shares fell about 13% that day; a one-day drop not seen since October 2000. 

Analysts who track mainframe migration are more measured. Gartner’s Matt Brasier described AI in this work as “just another automation tool at the end of the day.” Kyndryl’s survey, meanwhile, found nearly 90% of organizations have put generative AI on the mainframe or plan to. 

AI earns its place in COBOL modernization in four jobs: 

• Discovery: mapping which programs call which, and which copybooks (shared data layouts) feed which files. 

• Documentation: turning a 4,000-line program into a plain description a business analyst can check. 

• Test drafting: proposing test cases from real transaction patterns, including the odd ones. 

• First-pass conversion: drafting COBOL to Java code that engineers then review line by line. 

People still own the target architecture, the call on which rules to keep, and the go or no-go for each release. AI-assisted code review with a human approval step is part of how we scope custom AI solutions for regulated teams. 

Choosing a mainframe modernization route for each part of the bank 

No single route fits a whole bank. Most estates mix routes, picking one for each part of the estate based on how stable it is and how often it changes. 

Route	What it means	Where it fits in a bank	Main risk
Wrap with APIs	Keep COBOL and expose its functions as APIs	Balance and payment status for mobile apps	COBOL skills risk stays in place
Rehost	Move programs to new hardware or cloud with little code change	Stable batch with a high run cost	Old logic and old debt move across unchanged
Refactor	Convert COBOL to Java or C# with tools	Well-structured programs with good test data	Hard-to-read code, rounding and sort shifts
Rewrite	Rebuild the function in new code	Products that change often, such as lending rules	Losing rules nobody wrote down
Replace	Move to a packaged core banking platform	Standard deposit and loan products	Custom rules, data migration and vendor lock-in
Retire	Switch off programs and reports nobody uses	Old products with no open accounts, unused reports	Switching off a job a regulator report still needs

This route-by-route view is how we approach legacy application modernization for financial services. 

When keeping COBOL on the mainframe is the right call 

One opinion that doesn’t help us sell projects: some COBOL should stay where it is. If a batch suite runs reliably, its cost is predictable and nobody needs to change it often, wrapping and documenting it may be a better use of budget than rewriting it. 

Kyndryl’s respondents put their own returns between 288% and 362% whether they modernized the mainframe, connected it to cloud or moved workloads off it. A full mainframe migration isn’t the only path that pays, and plenty of banks will run hybrid for years. 

What drives the cost of mainframe modernization for a bank? 

Most of the cost sits around the conversion itself: understanding the code, moving the data, testing, and running two systems side by side. Per-line prices published online rarely include parallel running, so size these drivers before any quote: 

• Size and tangle of the code: programs, copybooks, batch jobs and how they connect. 

• Data volume and formats: VSAM files, DB2 tables and years of history to convert. 

• Parallel-run length: every extra month-end means another month of running both systems. 

• Mainframe software contracts: license terms, often priced on MIPS (million instructions per second, a measure of processing capacity), decide when savings start. 

• People overlap: COBOL experts and the new team work together until each slice is switched off. 

• Regulator evidence: test records, signoffs, and vendor files take real hours. 

Our advice: budget for the overlap. During a parallel run, you pay for both systems and teams. Plans that assume savings from day one tends to cut testing first, and testing is the step a bank needs to protect. 

A safe order for replacing COBOL, slice by slice 

Safe COBOL replacement follows a fixed order: understand, wrap, move a small slice, prove it in parallel, cut over with a way back, then retire the old code. Each slice should be small enough that a failure touches one product or one process, and the bank can return to the old path within hours. 

1. Record what the system does today. Inventory programs, copybooks, JCL and files, and capture months of real inputs and outputs. This becomes your test oracle, the answer key every new build is checked against. 

2. Wrap before you replace it. Put an API layer in front of the COBOL functions your channels call, so you can swap what sits behind it later without touching the apps. Engineers call this the strangler fig pattern, and it’s the core of system integration and modernization work in banking. 

3. Pick the first slice with a small blast radius. One product line, such as certificates of deposit, or one back-office process. Leave card authorization and payments for later. 

4. Build against recorded behavior. Every rule found in discovery needs its own test. Decimal types for money, the same date window, and the same sort of order wherever downstream files expect it. 

5. Run in parallel. Feed the same transactions to both systems for full cycles, including a month-end and, ideally, a quarter-end. 

6. Cut over with a rollback you’ve rehearsed. Agree go or no-go criteria in advance, rehearse the cutover, and keep the old path warm until the new one has run cleanly through a month-end. 

7. Retire the old code, then repeat it. Switch off the COBOL for that slice, update the documentation, and move to the next slice. 

What to reconcile during a mainframe modernization parallel run 

Reconcile every number a customer, auditor or regulator could see: 

• End-of-day balances for every account 

• Interest accrued and posted to the cent 

• Fees, and the day they post 

• Statement content and line order 

• General ledger postings 

• Regulatory and internal report files 

• Rejected transactions, which both systems should reject in the same way 

Set a tolerance of zero for money. Every mismatch needs an owner and a label: a new-system bug, an old-system bug, or an agreed change. Agreed changes need business sign-off, because customers will notice them. 

What will regulators expect to see during a COBOL replacement? 

Regulators expect a bank to show that it planned the change, tested it against real behavior, kept control of its vendors, and could recover if the cutover failed. Their questions center on evidence. 

In the US, joint guidance from the Federal Reserve, FDIC, and OCC (June 2023) says using a third party doesn’t reduce a bank’s responsibility for running the activity safely and within the law. In the EU, DORA (the Digital Operational Resilience Act) has applied since 17 January 2025 and covers ICT risk, resilience testing and third-party providers. UK firms have had to stay within set limits for disruption to key services since March 2025. 

For a mainframe modernization program, that usually means keeping these records ready: 

• Test evidence tying each recorded COBOL behavior to a passing test 

• Parallel-run results with each mismatch and its sign-off 

• Cutover and rollback rehearsals with go or no-go decisions 

• Vendor oversight files showing how outside teams were chosen and monitored 

• Change approvals for every behavior the bank chose to change 

Where ViitorCloud fits in a COBOL replacement 

ViitorCloud has built software for clients since 2011, with a talent pool of 250+ people. In a bank’s mainframe modernization program, we can take on the work around the core: API layers that wrap COBOL functions, new services that take over a slice, data migration and reconciliation tooling, and AI-assisted code discovery with human review. 

Our teams have taken over existing codes before. On KPMG’s State Family Database, the team restructured and optimized an existing codebase and built the platform’s data ingestion module. 

For the Klaviss real estate transaction platform, our team connected document data extraction, e-signatures and payments through APIs in one flow. 

We don’t sell a core banking product, so the route of choice for each part of your estate stays with you. You can see the wider set of systems we build for lenders and banks on our BFSI industry page. 

Do you know what your COBOL does at month-end? 

If the answer is “mostly,” that’s the place to start. A short review of one product batch cycle, rounding rules and downstream files will show whether a first slice is ready to move, before you commit to a mainframe modernization timeline. 

Talk to our modernization team and bring the one product you’d most like to move first.