Beware, maintaining those systems is absolute hell and the companies experiencing exodus are working their people into the ground because the workload is crushing them and they can't find replacements.
A good friend of mine is an engineering director at a company that runs a massive COBOL mainframe platform and he always half jokes with me about picking it up. The money isn't that great at his company and the problems they have maintaining the system just blow my mind. The entire company sounds fundamentally unsustainable long term but they're running critical payments infrastructure.
I'm thinking of the Elixir->COBOL like this: https://github.com/TheFirstAvenger/cobol_to_elixir
Was speaking with the author about a year ago and he was having really good success with it.
Where you're going to hit major issue is with COBOL running under the likes of CICS or IMS, where sure, you can use some more recent languages, but what you'll get in the end will be possibly even worse because now you'll have to find Java programmer who knows CICS.
And CICS or IMS aren't that easy to replace.
I like this idea of writing Elixir and outputting COBOL. That way it can interface with the operating environment (CICS, IMS) exactly as a natively written COBOL program does. Not that COBOL syntax is particularly hard to learn one by one, but as a whole isn't very memorable. Why learn a programming language with peculiarities like a natural language when I can use something concise that translates to it? There may not need to be a step to eliminate the COBOL output step any more than a language that uses C or js as a target.
I've only seen two kinds of CICS programs in the wild: 1. screen I/O using preformatted BMS maps, 2. transactional with input buffer and output buffer. A third kind was one I wrote for sending dynamically generated terminal stream data for a hypertext online documentation system.
Any of these could be written in Elixir with appropriate libraries and translators. The company I worked at generated the BMS maps and COBOL source from assembling program components with an inclusion/override macro processor and wysiwyg editors--think Visual Basic for mainframes targeting both CICS and IMS.
Please tell me its not a payroll company.
My first dev job was COBOL on a Unisys mainframe. When the volume of "omg we need COBOL devs" articles got loud, I looked into what was available. The compensation graph for COBOL positions approximately matches those of any other dev job. You can do as well (or better) as a Python dev or Node dev or whatever.
The key to making more money is in specialization. The highest-paying jobs are looking for experience with specific combinations of technologies.
But being a Python dev has the added advantage of not having to deal with COBOL. ...speaking as someone who used Unisys' STRING/UNSTRING OS functions to implement input variable interpolation in COBOL because it has no native string operators or data type.