Rewrite of legacy code

Question

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

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.

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

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 4

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 5

admiteddly, the problem involves cobol which makes any answer specific to your needs, if you said "we have an old VB app" or old C app, then option #3 is always the right way to go.

I've worked at 3 companies who decided to go for option #2. 2 went bust trying to pay for the new system whilst only gaining revenue from the old, the 3rd came very close indeed.

The other factor to opetion #3 is that you get to keep all the old bugfixes you've doen over the years. Every rewrite always introduces more and more bugs, partly because you'll want to get the rewrite done quickly, partly because you'll be writing it in a new, unfamiliar language, and partly because all new code has bugs.

Refactor and replace logical chunks of the old app, eventually you'll have a nice shiny new one. Start with the GUI to get the safest approach to the new. Besides, by the time you've finished rewriting the app in something new, something even newer will be the coolest and your new app will be obsolete and you'll be posting the same question all over again!

Answer 6

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 7

Another solution could be:

Translate the code to a modern language of your choice.

Typically, that would involve several big chunks:

• Rewrite parts of the legacy app that cannot be translated. At least, use structured programming constructs everywhere.
• Implement a internal DSL that makes it easier to map constructs from the old language in the new language.
• Implement a throw-away source-code translator for 90% of the code.
• Translate the remaining 10% of tricky code by hand.
• Spend a lot of time getting the darn thing to compile.
• Get the whole thing through some serious testing and fixing.
• Slowly clean up the resulting animal to make it idiomatic.

The main advantage of this approach is that it will preserve all the nasty business corner cases have been encoded over the years in the code base. The big problem with from-scratch rewrites is that they discard all this accumulated knowledge.

Another advantage is that it turns an annoying problem (maintaining a cobol app) into a a fun problem (automated language translation), so you have a chance to get a good programmer engaged with the project.

Comment by Jim Denver

Won't it be very hard to write a translator that translate into code that is somewhat readable and maintainable? Our problem is that the COBOL app is a maintenence nightmare. We don't want this to become the same nightmare in another language.

I cannot tell how hard it will be. It is easier if the code you are starting from is regular. But in any case you will end up with "COBOL written in $LANG". This is just a starting point to incremental rewrites until the maintenance nightmare is fixed.

This is just an alternative to "rewrite from scratch" and "maintain in COBOL". It might just be that the value of the accumulated knowledge in the code base is less than the expected cost of an incremental cleanup.

Answer 8

Migrate the application gradually?

Is there a way you can interface other code to the COBOL, and gradually rewrite components as changes bubble through? You may never get rid of all of it, but does it really matter?

Rewriting existing code is generally a bad idea. It will be very risky (e.g. risk breaking some poorly understood functionality someone is relying on) and use up a lot of time without achieving anything useful that is visible by most stakeholders.

Don't assume that a competent programmer won't be able to learn COBOL if the need arises- one programming language is much like another. If you hire someone competent at (say) C++ or Java, they'll be able to learn COBOL.

Answer 9

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

Answer 10

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 11

This is a variation of Option 3:

Microfocus provide a tool called Enterprise Server which allows COBOL to interact with web services.

If you have a COBOL program A and another COBOL program B and A calls B via the interface section, the tool allows you to expose B's interface section as a web service.

For program A, you then generate a client proxy and A can now call B via a web service.

Of course, because B now has a web service any other type of program (command line, Windows application, Java, ASP etc.) can now also call it.

Using this approach, you can "nibble away at the edges" to move the GUI to a modern, browser based approach using something like ASP while still utilising the COBOL business engine.

And once you have a decent set of web services, these can be used for any new development which provides a way of moving away from COBOL in the longer term.

Answer 12

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 13

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 14

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.

Answer 15

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 16

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

Answer 17

I've done a migration of an old system to a new one myself (though it was on a much lower scale).

We quite successfully used the "gradual replace" (#2) approach, for a client/server system (a smallish, inhouse-written reporting system). We actually did it with a twist, by using a "proxying" approach:

• First we implemented a new server that offered all the functionality / call interface of the old server, but internally just delegated everything to the old server, which was kept running.
• Then all clients were switched over to the new system; this was relatively painless as the new system was essentially just a wrapper.
• Finally, we gradually rewrote the new server to implement functionality without calling back to the old system.

This approach gave a lot of flexibility, and allowed implementing new stuff without touching the old code. The changeover lasted over a year, and the last parts of the app were only migrated to the new system because the old server was running on dedicated, aging hardware that was to be decomissioned.

I actually went down to the server room to personally shut down the old server when everything was migrated. That was fun :-).

Incidentially, this "gradual changeover" approach also allowed us to implement some logging in the new system, to decide which functionality was used how often. That way, some of the old server functionality could be scrapped, because it turned out clients no longer used it. That was a significant advantage of the "proxying" approach.