I directly worked on the planning of a replacement deposits system for a major financial institution. The existing system was written in COBOL and the vendor di

I directly worked on the planning of a replacement deposits system for a major financial institution. The existing system was written in COBOL and the vendor did not want to continue any business, including maintenance support, on this old software. We were already able to extend the software ourselves without their help to add integrations or features. Consultants came in and offered the following suggestions: 1) Write new software to replace. Estimate $3-400 million dollars. 2) Use a product that would transpile the COBOL to Java. We chose option 3: offer a lump sump to license the software in perpetuity and maintain ourselves. Built a layer around it to better enable the systems of engagement use cases. The problem with #1 and #2 is documenting all the use cases and validating them after changes are made. Can you even imagine the resulting Java code for #2? There are many edge case behaviors that were either purposeful or accidental, but now relied upon by downstream software. To summarize, there's a huge price tag to replace these systems, it's an extremely high risk exercise, and the benefits to the business are at best incremental. It's easy to see why the financial sector won't bother until either regulators force them or they acquire another institution with a better system.