Rewrite of legacy code [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 6 years ago.

My department is currently faced with the responsibility for the task of maintaining a rather large COBOL code base. We are wondering how to add new features to keep up with business needs. COBOL programmers are hard to come by these days, and we also think we would get higher productivity from using a more modern language like Java or C#.

We feel that we have four options:

1. Rewrite everything from scratch, leaving the old application to itself until it is ready to be replaced
2. Rewrite everything from scratch, getting some people to maintain the old application to cope with new business needs as the new one is being built
3. Write all new functionality in a modern language and finding some way to integrate the new code with the old functionality.
4. Keep maintaining the old application.

What do you consider the best option for us, and why?

Answer 1

I'd maintain the old application, but then, I'm a cobol programmer....

Answer 2

Be careful attempting a full rewrite. There are a lot of examples of this going awry for many software companies. Netscape is a prime example

Answer 3

I would maintain the old code and add new functionality to it using some of the great stuff from Microfocus/AcuCOBOL. You can do GUI apps and call .NET and Java stuff right from your "legacy" code.

Why break the back-end if it is working for you? Keeping the working back-end and replacing the tired front-end is the solution that the company I work for is starting to employ.

So I guess my choice would be option #3, because there is a solution out there like that.

Answer 4

The beautiful thing about COBOL is that data requirements are spelled out right there at the top of the code. It also helps that COBOL was designed to be written using (relatively) plain BUSINESS English (TXTSPKers need not apply).

Of course, if your lawnmower is older than some of your programmers, forget about having them read the source. They'll just whine too much.

Answer 5

Options #2 and #3 are your best choices. If your COBOL application stores it's data in a SQL DB or some other sane format that you can easily access from a modern language that is the cheapest/easiest solution.

If not, then having someone on staff to implement critical new features while you rebuild would be necessary. But I would still suggest asking everyone to limit new features in the old code base to only the truly critical ones.

Maintaining COBOL, in the long run, is only going to get harder. The longer you wait, the harder it will be.

Answer 6

Honestly, having helped "port" an application from ColdFusion 5 to PHP to ColdFusion 8 I'd say go with #1. Leave the old application in place and freeze development. Meet with the customer and spec out what the new features are, in addition to how the old system works/was supposed to work and produce a good requirements document. That just leaves the construction and design details, which you can then intelligently choose the best language and platform for your application.

Where I work now, we're actually maintaining an old CF application while building the replacement .NET application. Can you imagine the code the .NET guys are going to have to write after they finish the base application? That's why I recommend freezing the development.