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

Obey the 80/20 rule. Sit down with the client and write specs for the 20% of the app that gets 80% of the use. Write that in a modern system. Then either keep the old system for a shrinking number of special cases or phase it out as you flesh out a new system.

Don't try to rewrite the old code 100%. That's just silly. The best case scenario is you have a complete port of a obsolete system. The worst case scenario is you burn a lot of time and money to have a failed new system and you're still stuck with the old system.

Use the time and effort to improve the system, not just port it. After porting the most important parts, use the time to re-consider the special cases.

Answer 2

If you use OpenVMS, BridgeWorks may help you to build a web application using your old code with minor modifications.

Answer 3

A company I know struggled with exactly the same question for many years; eventually, they dropped the COBOL application and switched to SAP. Doing that was a huge project that took several years to complete, but it worked out well.

Answer 4

What about using one of the third party apps that take cobol and convert it to C# like:

http://www.softwaremining.com/index.jsp

Or porting it to COBOL.net, that should be easier, then everything you add could be in one of the other .net languages.

Answer 5

I'm a strong believer of updating legacy applications to cutting edge technology (much to my manager's dismay). This should always be a phased approach and only undertaken if it is necessary. Try to keep the legacy application running and serving it's purpose, but create small parts of it in a newer technology, and over time phase out the old code and replace it with newer code. I always make sure I prioritize these in benefit/cost to business first.

If the application is too tightly woven then it sounds like you need to hire some COBOL scripters to help pull out the isolated services, so you can depricate them when you are ready.

Note this: sometimes bugs and quirks in the original legacy code serve a purpose that the business relies on, so be wary of fixing errors that other code later relies on.

Answer 6

Insufficient data to determine the proper course.

Though many folks have chimed in with appropriate answers given particular circumstances, the correct answer really depends on the business situation your company is in.

Things like existing roadmaps, delivery commitments, service contracts, time-to-required-launch-of-new-features, and the like will determine what's best in your situation.

That said, many technologist's answer will be #1, while many business people's answer will be #4. Knowing nothing more than what was presented, I'd push the team to deeply investigate #3 as it's probably the lowest risk. #1 has a proven track record of failure, and #2 is just #1 with less resources. #4 is probably not a long-term solution, UNLESS you're EOL'ing this product line in the near/medium term.