How to Migrate Cobol to C#.NET

Question

Can you please let me know how to migrate legacy Cobol based application to .NET based application and host it in azure

Answer 1

Assuming an IBM environment.... Having supported MVS/CICS for the first half of my career, and NT servers for the second half, I would recommend a complete rewrite of the application.

There are conversion tools like this, but I don't know how well they work.

https://www.ispirer.com/application-conversion/cobol-to-cs-conversion

I would think that a lot would depend on what data the program processes. If you've got a "batch" program the processes flat files or DB2 databases, those might translate ok. But if you've got "online" apps like IMS/DC or CICS, those are completely different animals and are typically dependent on the model of the 3270 terminal device that the user is using.

Have you ever heard the phrase "spaghetti code"? That is what we call COBOL programs that have been around for a while and where multiple programmers have made modifications over the years. The code typically has many GOTO's, paragraph names, PERFORM THRU's, and trying to make even a simple change can be a challenge trying to figure out the execution path. I can't imagine what the C# code would look like after being processed by a translator.

Micro Focus claims that it can compile to Dot Net. That might your best bet where you leave the COBOL source mostly intact.

https://www.microfocus.com/en-us/products/visual-cobol/overview

Answer 2

If you have a tiny application, just rewrite it and stop reading.

Most people have big applications they built over decades. You can't afford to rewrite a big application by hand. Your only serious hope is automated conversion.

People migrate from all sorts of legacy systems: Unisys, Tandem, IBM Mainframe, AIX, ... using all kinds of legacy technologies (green screens, hierarchical databases, job control, additional languages) and want to target the technologies du jour.

That means you can't expect to find an off the shelf translator for your particular combination of legacy technologies, that handles the target set of modern technologies you want.

What you can hope for is highly automated translation machinery that can be straightforwardly configured for your legacy and modern technologies.

My company offers that for a wide variety of languages. For COBOL (in many flavors), we offer Java to C# targest using SQL and web-based screens. See semdesigns.com/Products/Services/COBOLMigration.html?site=Microsoft for some details. These are mature tools; we've been doing this since 1995.

The other poster suggests that such translations must be bad ("spaghetti code", etc.). He "can't imagine what C# code would look like"; no surprise, he's got zero experience doing this.

Our experience (with considerable engineering on our part) is that the translated code is pretty readable (go check out the link!). One of the many things we do is remove all the goto silliness to produce completely structured codes. (If your translated code retains any GOTOs, how can your tool translate it to Java which doesn't have a GOTO? We do this just fine).

Answer 3

Hello there,

It's a late response, but I believe this information will be quite handy for anyone seeking a similar solution for migrating COBOL-based applications to a .NET environment.

Migrating from a legacy system like COBOL to a modern framework like .NET, especially when considering cloud hosting on Azure, is not a straightforward task. It involves several challenges and risks that need to be carefully managed. To get a better understanding of these challenges, I recommend checking out this resource:

https://kumaran.com/blogs/mainframe-to-cloud-migration-challenges/

It provides valuable insights into what you might face during this migration process.

One effective approach to consider is the refactoring and rearchitecting migration strategy. This strategy is beneficial because it removes dependencies on outdated technology and significantly reduces risks compared to completely rewriting applications from scratch.

When you refactor and rearchitect, you gradually modify and improve the existing codebase, generally incurring less risk than a full rewrite.

This approach aligns well with DevOps practices and avoids vendor lock-ins by reducing the reliance on legacy systems and vendors.

As mentioned in the above answers, there are tools available to refactor COBOL code to C#. It's important to remember that each migration journey is unique, and tailoring your approach to the specific needs and complexities of your application is crucial.

Thanks and have a nice day.