Some level of technical debt will exist in every organization. The problem is that NJ never had prioritized this work and now they have an emergency and they are looking for volunteers. They should absolutely should be paying for this work.
For the record, I wrote enterprise software in COBOL back in the late 70s and early 80s. COBOL itself is no big deal to learn or read. Working with huge volumes of data stored in proprietary binary formats (which COBOL was designed for) is not something I want to go back to -- relational databases rule the world for a good reason.
As for shunting some work to another system, imagine how you would do that with something much simpler. Suppose Excel suddenly stopped working for you with some big spreadsheets. How would you shunt that to another application? How would you do it without risking the important data? It's not a simple problem of just spinning up more servers and replacing some old data management code with MySQL or Redis.
Maintaining legacy code isn’t always easy, but it has a big advantage over a rewrite: it works and satisfies requirements to some non-zero percentage, whereas imaginary code built with “modern tooling” does not work or meet any requirements. COBOL and old business systems aren’t that hard to understand.