Hahaha port. Get a load of this person thinking COBOL is being ported! I bet they like the number 4.

I think just the size of the projects. My employer has had a team of ten-ish people working full time on porting a piece of our COBOL program (the full thing was deemed not possible to port to a single modern application, so it's getting split up) for about a year now. I was peripherally involved in four rounds of increasingly integrated testing environments. Go live was yesterday. They rolled it back three hours in.

It's hard for a company to invest multiple people's salaries for many years on reworking software that currently mostly works.

Mostly it's two things:

1. COBOL is very good at some specific things that other languages can't do as well. Not that other languages do them badly, not at all, but COBOL is absurdly efficient for certain operations. You need to do basic math operations on millions of rows of data every minute? COBOL can do that easily. Many other languages can get close to that speed - maybe a few seconds off - but COBOL is often used in environments where a hundred millisecond delay can mean everything breaks. Are there other languages which can match that speed? Absolutely. Are they any of the languages every company wants to upgrade to? No.

2. COBOL's best practices are sometimes the literal opposite of what every other language expects, especially when it comes to optimizing code for efficiency. You ever seen Evaluate, COBOL's equivalent of a switch statement? Rather than being used to Evaluate a variable to check its values, its most commonly used to "EVALUATE TRUE" and then use the WHEN clauses (basically case statements) to check statements or variables that you want to be true. That can be converted to another language directly, yes, but it absolutely will not be efficient best-practices code. Most likely you're going to need someone - not an AI, not an automated process - to do one-off rewrites to keep the code performance the same. As it is I have never seen any automated tool (LLM or otherwise) convert COBOL without falling victim to this issue.

There's also a third issue in that COBOL has some specific minor capabilities that other languages just do NOT, or not to the level of flexibility and efficiency COBOL has. The most common one is COBOL's "88" picture type (variable) definitions. Think of it like being able to set an automatic evaluation on a variable that returns true if the condition is met, e.g. the variable "05 WS-ERROR-STAT PIC X." with an 88 of "88 FATAL-ERROR VALUE 'F'." would mean you could check "FATAL-ERROR" anywhere in your code to see if the value of WS-ERROR-STAT has been set to "F". The thing is, this is done basically for free (resource wise) as part of allocation, and furthermore it can be used to get or set, i.e. "SET FATAL-ERROR TO TRUE" will change the value of WS-ERROR-STAT to "F". You can also use 88s for ranges, e.g. "88 ANY-ERROR VALUES 'F' THRU 'N'.", though you can't use them for set operations that way.

Bottom line: there's nothing that perfectly recreates its efficiency, the specific way it performs efficiently, and some of its more esoteric capabilities. Anything still running COBOL probably depends HEAVILY on one or all of these things.

the cobol system was already tested for years or decades, important bugs are already fixed, it's other quirks have became part of the workflow for people using it, and for other systems interacting with it, some of them likely also cobol. if you write a new system, it has to work the exact same way. same features, same bugs, same everything. but realistically it will have brand new bugs, it will miss some functions and do some others differently enough that it sometimes causes problems, and nobody knows why.