Some companies (whom you could consider our competitors – so feel free to take this article with a grain of salt) offer the service of migrating your code to a different platform – some of them into the cloud. So if you accept that offer, then you would still have (nearly) the same code, but run it on a different operating system and possibly on different hardware.
There are COBOL compilers for Windows and Unixiods and even JCL-interpreters for linux. You can manage your files much easier with modern file-browsers, edit your code with modern text editors / IDEs and even manage your revisions with state-of-the-art tools like git and gerrit. This would drastically improve your workflow compared to all the tedious, inefficient1 ways you deal with files on mainframes. I have even read about services that allow you to put all these things into the „cloud“, running on cloud-based virtual mainframes. These don’t even require you to adapt anything to different compilers, encodings, etc.
This sounds great and – in my opinion – it is a step in the right direction. But I don’t think you should stop there, because only switching the platform is like driving this car on a brand-new highway, compared to driving it on an old highway full of potholes.
Sure, it is nicer without the potholes – but COBOL is still COBOL. Streamlined workflows don’t solve the shortage of COBOL-programmers in the job-market, which is your real problem. It also doesn’t solve the serious security- and performance- problems that I have detailed earlier. Especially COBOLs inherent vulnerability to SQL-injection attacks turns cloud-migration into a written invitation to hackers.
So to summarize
Platform-Migration: Only as a first step.
Cloud-Migration: Not without migrating to a different programming-language first!
1 Notice: this 14 minute video only shows how to create, compile and run a hello-world program. I have measured myself doing the same in C++ on Linux in about 1 minute.