What a COBOL Modernisation Project Involves: A Buyer's Guide

Anyone who asks what a COBOL modernisation project involves tends to get a sales pitch in reply. This guide gives the plain version: the options, the phases of a real project, what AI has changed, what Indonesian banking rules add, and how to choose who does the work. According to IBM figures cited by CIO Dive in July, COBOL supports 40 per cent of online banking systems, 80 per cent of in-person credit card transactions and 95 per cent of ATM transactions.

Why organisations modernise COBOL at all

The code itself usually works. The pressure comes from people and from change. A guide for banking leaders published by Amazon Web Services on 22 May 2026 says 71 per cent of mainframe teams report being understaffed and that the pool of COBOL engineers is shrinking. It also cites FinTech Futures for the estimate that large financial institutions spend 70 to 85 per cent of their IT budgets maintaining older systems.

How widespread the dependence is varies by source. The same guide cites DXC for the figure that 45 of the world's top 50 banks still rely on mainframe applications; IBM, citing its own research institute, puts it at 43 of the top 50. The numbers differ, the direction does not.

The five options, from least to most change

Modernisation is not one thing. An overview published in July by the developer firm Mecanik Dev sets out the five approaches most of the industry uses.

• Rehost: move the application to new infrastructure with the COBOL largely unchanged. Lowest cost, shortest timeline and low risk, but the least benefit.
• Replatform: adjust the application for a new platform, for example recompiling COBOL for Linux or cloud, without rewriting the business logic.
• Refactor: restructure and convert the code to a modern language while keeping its external behaviour the same. Medium cost and risk, high benefit.
• Rearchitect or rewrite: rebuild the system with a new design on a modern stack. The highest benefit, and also the highest cost, the longest timeline and the highest risk.
• Replace or retire: substitute a packaged product, or switch off functions nobody needs.

The same overview ties the choice to the business driver: cost reduction favours rehosting, a skills shortage favours refactoring, a need for new capability favours a rewrite, and commodity functions favour replacement. In practice, a large estate rarely gets a single answer.

What the project actually looks like

Whatever the option, the stages are similar. The outline below is our synthesis of the sources, not a standard.

• Discovery: map the programs, the data flows and the business rules buried in the code. Much of what the system does was never written down.
• A decision per application: choose one of the five options for each part of the estate, with the reasons recorded.
• A bounded first slice: start with one contained business domain as a proof of concept, with success measures agreed in advance, as the AWS guide recommends.
• Build and prove equivalence: test the new component against the behaviour of the old one, usually by running both side by side and comparing results.
• Data migration and cut-over: move and reconcile the data, switch over in steps, and keep a way back.
• Retire: switch off the old component only when the new one has carried the load.

The case for working gradually is long established. The software author Martin Fowler describes it as the strangler fig pattern, in an article dated August 2024: new components grow alongside the old system and take over piece by piece. He argues that complete replacements tend to fail because the existing behaviour is hard to specify in full, and because users cannot wait years for a rewrite to deliver. The temporary code that lets old and new coexist looks wasteful, he notes, but it is what reduces the risk.

What AI changes, and what it does not

AI is the main reason the subject is back on board agendas. CIO Dive reported on 28 July 2026 that AI tools are shifting strategy away from rip-and-replace and towards modernising systems where they are. Morgan Stanley has modernised 17 million lines of legacy code with an in-house AI platform that it says saved developers more than a million hours. Vendor tooling now includes AWS Transform, IBM watsonx Code Assistant for Z and Microsoft's Azure Migrate.

The same report carries the warning. Gartner predicts that 70 per cent of mainframe migrations started this year will fail because organisations overestimate what generative AI can do. Mitch Ashley of The Futurum Group called one AI vendor's claim to modernise COBOL systems of any size laughable. Our reading: AI shortens discovery, documentation and code conversion. It does not remove testing, data migration or the business decisions about what the system should do.

What Indonesian banks must factor in

For commercial banks in Indonesia, the starting point is OJK Regulation 11/POJK.03/2022 on the use of information technology. OJK's published question-and-answer document says it covers, among other things, IT governance, IT architecture and the IT strategic plan, risk management, cyber resilience, the use of IT service providers and the placement of electronic systems.

Three points in that document bear directly on a modernisation plan. Banks may use cloud computing, and the cloud provider is then treated as an IT service provider under the regulation. The core banking system is not among the systems that may be placed abroad, so it must stay in a data centre and a disaster recovery centre in Indonesia. And placing any eligible system abroad requires OJK's permission, which OJK grants or refuses within three months of receiving a complete application. This is a description, not legal advice; a bank should confirm its own position with its supervisor.

Who does this work, and how to choose

Three kinds of provider are involved. Platform vendors such as AWS, IBM and Microsoft supply the tooling and the destination. Global services firms run large programmes, often alongside them; CIO Dive notes that Unisys works with AWS and Kyndryl with Microsoft. Local integrators and specialist engineering firms bring proximity, language and knowledge of local rules. For banks with standard operations where speed matters more than customisation, the AWS guide points to packaged cores from vendors such as Thought Machine, Mambu and Finxact. A very large estate with a hard deadline may need a global firm's scale; a bounded system, or a first slice, often suits a smaller team that stays close to the code. Whoever is on the shortlist, the same questions apply.

• How will you find out what the system really does before you change it?
• How will you show that the new component behaves like the old one, including the odd cases?
• What is the smallest first step, and how do we reverse it?
• Who checks what the AI tools produce?
• How is data reconciled at cut-over?
• What will our own team be able to maintain when you leave?

What to watch next

• Whether Gartner's failure prediction is borne out as this year's AI-led migrations reach testing and cut-over.
• Any further OJK guidance on cloud use and system placement as banks modernise their cores.
• The supply of COBOL skills, which sets the price of doing nothing.