I could make some claim about how stable and universal COBOL is. I could point to published evidence explaining how Java has not turned out to the nirvana many people were hoping for. There are any enough studies (or unilateral opinion presented as studies) out there for me to be able to list several compelling reasons why converting Java back into COBOL should be an option to consider.
Even so, it is a proposition you’ve never heard of, and there is a good reason for that.
It is because it is idiotic. I can make a case by twisting and selecting facts, but the reality is that converting Java back into COBOL makes no technical nor strategic sense.
Amazingly enough, the converse is almost as idiotic.
Converting COBOL to Java or C# makes no sense either.
I understand the temptation though: it should be a way to get away from legacy technologies, and moving your software system into the 21st century (at last). What is there not to like?
The problem is that the resulting system will be technically in Java or C#, but will give you none of the benefits you expect from the move.
It won’t take advantage of the advanced features that make these languages so valuable.
It will be something entirely different from what a Java or C# developer would write, and can therefore adequately maintain.
It will be crippled with COBOL idiosyncrasies, to care for a very different computing model and unique data types.
In a nutshell, it will be lipstick on a pig (And pigs may take offense)
Developers out of college have a choice when it comes to finding a job, and maintaining the COBOL-inspired ugly only-a-mom-can-love code produced by these migration projects is no one’s dream of a professional career. And not being able to tap the reservoir of Java or C# developers defeats the purpose of migration.
You don’t believe me? Check for yourself, but do not evaluate the vendors’ claims to maintainability of the code they produce based on their glossy brochures and catchy punchlines. The only person who’s opinion matters here is the engineer responsible for maintaining the translated code. At the end of the day, his/her opinion is what makes the proposition of converting COBOL to C# or Java viable or insane.
And if the person you’re talking to is a seasoned COBOL developer who has learned Java or C# to keep on maintaining the migrated application, you are going after the wrong demographic: the whole point of such migration processes is to be free from the dependency on those hard to find COBOL skills. If you need a COBOL developer to maintain your software system, you may as well keep it in COBOL.
No, you should look for a young, fresh out of college Java or C# developer responsible for the maintenance of such a migrated system, someone who thinks that phones used to have cords so that they could be easily found, someone who believes that VHS stands for Very High Speed, someone who assumes that historic pictures from the late 19th century have been photoshopped to be turned into artsy sepia. You should ask this young developer how happy he/she feels about this code which is technically valid Java or C# code, but does not meet any of the standards he/she is accustomed to.
You should definitely talk to such a person before making up your mind regarding a COBOL to Java migration project.
Good luck with that.