When people ask me about Micro Focus COBOL Modernization, I’m always at a bit of a loss as to how to respond. First, is the question about moving off the mainframe and switching out the mainframe COBOL (such as Unisys COBOL or IBM COBOL) for the Micro Focus product? Or is the question related to getting rid of the customer’s existing Micro Focus COBOL and replacing it with a Java or .NET application? I’ve found that either could be the case.
Taking the first possibility, moving off the mainframe might be a good thing, but why stay with the COBOL? You’ve gotten rid of the mainframe, and maybe saved $1m per year or more. But you’ve traded one vendor lock-in (your mainframe company) for another (Micro Focus), and you still have to recruit, train, or steal COBOL programmers. Doesn’t Micro Focus have monopoly pricing power for COBOL licenses? They’re not teaching COBOL to most freshman computer science graduates, and those of us that wrote it in the 70’s and 80’s are more than eligible for retirement. Worse, you don’t have the wide variety of open source software and great development tools to choose from if you stick with COBOL, and it’s difficult to build highly responsive web applications using what will soon be a 50 year old computer language!
I’m often struck, also, by the cost of this kind of Micro Focus COBOL Modernization project. COBOL is COBOL, right? So why does it take years and millions of dollars to move it from one computer to another? Well, actually there are good reasons, starting with the somewhat mistaken idea that COBOL is COBOL, and moving past the compatibility problems to the performance and security issues. You don’t have RACF or DASD channels in your new environment!
Modernizing the mainframe COBOL to Java or .NET instead might cost a little more, or it might not. But, instead of just postponing the inevitable moment when the COBOL programmers are just not available, why not modernize once to something you know is going to be here 20 years from now? If you move from mainframe COBOL to Micro Focus COBOL on a server, you pay for modernization once — and then you will have to pay for modernization a second time, when the COBOL labor pool dries up. That’s not a deal, is it?
The other kind of Micro Focus COBOL Modernization is, of course, this second step we just talked about – changing over from Micro Focus COBOL to a more modern programming language environment like .NET or Java. Moving from COBOL to COBOL is not much of a modernization step, but COBOL to Java or COBOL to .NET surely is. You could, of course, try to do this by translating the COBOL line by line, but that path has a lot of problems. Our approach is different: it gives you fresh source code, properly optimized for the web, and extremely maintainable to boot. Our solution is SOA enabled, Section 508 compliant, and cloud-ready: that’s a deal in anybody’s book!