Like I've said many times: LLMs are useful for this (i.e. porting software from one programming language to another).
Porting software is painstaking grunt work which still takes a moderate amount of intelligence. It's therefore extremely expensive to port say, COBOL banking software running on mainframes, to another language like Java. That's why a lot of COBOL software is still in use. I expect this to die out in the coming years as many of these systems will finally be ported to another language (could be Rust or any other language).
In many ways the financial system is a distributed monolith. COBOL is still around because of bugs and issues (sometimes in code, sometimes in the OS it ran on, sometimes in the computer hardware) that have been around for decades are often dealt with downstream with their own exceptions. This is why IBM still sells mainframes. They literally emulate software and hardware bugs from equipment as far back as the 1960s.
I spoke with a semi-retired COBOL programer about a decade ago. They literally often can't fix specific bugs because multiple other consumers (from banks, hedge funds, insurance companies, the central bank) outside of their organization (and subsequent downstream consumers as well) would all need to adjust their code. Rewriting it is grand, but won't fix the spaghetti code mess. This is made even worse in the US, which has a much more fragmented banking system. "Modern" COBOL isn't even that bad, but they can't even use it most of the time. There is SO MUCH that isn't even documented - and if it is, is in a binder that's been shelved decades ago and half of this developers time was going into the corporate archives to dig it up.
This isn't to say that a lot of legacy code can't be modernized, but it's not always that easy.