Rewriting in something where engineers are cheaper and that can use commodity/cloud servers probably looks quite good on paper Vs paying IBM in blood.
So goes almost every project that wants to rewrite a giant legacy system from scratch. In reality the number of developer hours will massively eclipse the price you'd have paid those hard to find COBOL engineers.
But doing that would require the DOGE folks to admit that they don't actually know everything and need to defer to someone with more knowledge. So it can't possibly be allowed.
Generally people choose technology that’s going to maximize their prospects in terms of employment. Maybe that is specializing in COBOL, systems and tech around it, and higher level abstractions that inevitably come along. For me that seems risky in terms of time investment, even more so in todays market, but I could be very wrong.
This was probably kicked off by someone with power seeing how much IBM were charging for support/consultants etc. "Whaaaa? IBM want how much?"
On the other hand while I think it is a bit of a stupid idea to migrate off/rewrite for no reason other than "fuck you IBM", there probably comes a time when it does make sense to migrate - there are often hallmarks of this in old legacy systems where you need to do a LOT of work just to keep things running.
Typical examples are: really hard to recruit/retain people who know the technology, difficult to change things where the use-case does something the original designers did not anticipate, decades of tech-debt that makes people scared to change anything, endless patching of security fixes, lots of "glue-work" trying to interface the legacy systems with more modern things (think database drivers, automation tooling etc etc).
If it is hard to maintain a legacy system today, its going to be even harder in 10 or 20 years. "If it aint broke don't fix it" is valid, but in IT systems (with endless security vulns, endless changes to data legislation and sovereignty controls etc) you cant stand-still and leave things alone if it is a connected system dealing with people's personal data/finances/health/etc.
Somewhere sooner or later you're going to need to pull the trigger and sustain your business by investing in new technology rather than pouring more and more and more money into keeping a legacy system that is no longer fit for purpose. It will hurt sure, but sometimes you have to do it. Just do it carefully and in a realistic way (timelines, testing, slow-migration path etc)
It will make the initial launch of healthcare.gov look like a paradise of puppies and flowers.
https://www.ssa.gov/open/materials/IT-Modernization-Plan.pdf
> Yet, we place extraordinary demands on an installed base of technology that is increasingly showing its age. Most of our core systems are over 30 years old and some embedded software components are older. Over the years, newer technologies have been integrated with these legacy systems without a fundamental redesign of the system and enterprise environment within which it operates. Today, the cost of operating in this legacy environment is expensive. Front- line SSA employees are finding these systems increasingly difficult to use, and members of the public are not getting the self-service opportunities they have come to expect based on their experience with commercial enterprises. Furthermore, systems engineers with legacy system expertise are retiring from SSA at an increasing rate. Replacing them with similarly skilled staff is also increasingly difficult in the current job market.
Let me introduce you to an IBM salesperson who knows you have no option apart from renew those contracts on the mainframe and COBOL consultants :)