Originally Posted by
dilettante
I can remember back in the day when there was a push to get Cobol68 programs converted to Cobol74 back in the late 1980s when the Cobol68 compiler went out of support.
Those languages operated within a few very narrow paradigms, call them "project types," and both the syntax and semantics were very, very close. Yet even so the tools to perform automatic conversions were a disaster.
At the bonehead "line of code at a time" level 90% of "programmers" operate at sure, they could translate over 95% of the source code. But then you had the part left over to do manually... and worse yet all of the hidden flaws in the automatically translated part.
There were very few programs that converted automatically well enough to be worth manual fixup after the fact.
It turned out the the best results required programmers who knew both languages and what the programs were supposed to do. Even with testing to find translation bugs there were problems that slipped through and still turned up for years. It was a long and drawn out process as big as the later "Y2K" problem but without any patience or investment to support it. Management said "just suck it up."
At least with Y2K management could hire "expert" consultants and outsourced coders. That only prolonged the effort and increased the cost, but at least that process paid them in kickbacks and stock options and future sinecure gigs.
VB to VB.Net can be another order of magnitude harder for a lot of reasons. But like those old Cobol programs the originals tend to have been hacked together originally by neophytes and then been patched and patched and patched to fix old bugs and adapt to new requirements. In both cases understanding the programs before trying to convert them can be quite a challenge.