How to Inject New Life Into Your Legacy Product

It happened many moons ago when a professor of programming said on the first day of class, “last year I taught three programming languages during this course. This year I decided to drop one. We will not study Cobol as it is a dying language and I’m sure you’ll never hear about it after your graduation.”

“We will learn Fortran,” he continued. “There are many packages written on Fortran so you may have to support it.”

He paused and looked at the class. “The most important language you’ll learn here is Pascal,” he said. “It is the language of your future." 

Of course, time has shown he was wrong on all three counts: Pascal never became a mainstream language; Fortran is creaky at 64 years old; and while Cobol is still very much alive, it was the standard of 2014, not of today. (Fortunately, the professor was much better in teaching and in programming than in predicting the future!)

It sounds like an anecdote, but it’s not. It is a true story — proof of how difficult it is to predict the future in the software industry. Sometimes things that appear promising simply refuse to pick up steam, while others refuse to die.  

Aging Legacy Systems Pose Risks

There comes a moment with a successful software product when things just can’t continue as they are now. There are hard reasons for it. The software can’t run without hardware, and hardware is no longer available, or it became prohibitively expensive. 

Other reasons? The software systems can’t support the process. Or the company that used to provide necessary tools no longer does. Or the software engineers who developed and maintained the product are on the cusp of retirement. Or the software simply looks outdated. 

There are a million reasons why a system becomes outdated, even while continuing to function. Problem is, outdated legacy software poses efficiency, cybersecurity and business risks.

If you get to the point where Band-Aid solutions — those solutions that will allow the system to function for just a little while longer — are no longer adequate, you need to allocate time and resources to update the software in a radical way. 

Revamp Stale Software

The easiest way — or what initially appears to be the easiest way — to revitalize software is to ask your current team of in-house engineers to evaluate the effort. 

But, more often than not, this is a path to failure.

Engineers know the product, but usually think about it in terms of the existing implementation. In their minds, rewriting Cobol 1985 to Cobol 2014 seems easier than rewriting the entire product in C++ or Java. These engineers may not even consider using Java and C++ because they feel more comfortable writing Cobol code. From their perspective, using Cobol could be a viable solution when, say, full reimplementation of the product is underway, and the need is simply to keep the existing product for another year or two.

So what’s your next option? That would be fixing parts of the product one by one. The ole “Let’s switch to another database for now, and we'll know what's next after that.”

Problem is, this approach may work... or it may not. 

The danger here is getting into ‘continuous piecework improvement’ mode where the piece from the first dev step does not play nicely with the piece to be improved during the third step. This situation gives developers nightmares! 

And it can be costly. When budget considerations kick in, there’s always a tendency to say “let’s wait until next year” to spend the money to update the system. But this short-term view — kicking the can down the road — does not address the risks of holding onto a system well past its prime.

So, what’s the right way to update a legacy system? Start with long-term planning.

We’re talking about a software product that is already 10, 20, even 30 years old. To modernize it and make it relevant for today’s users, we must carefully plan for the next 10, 20 or 30 years. 

Piecemeal solutions simply don’t work. 

Sure, if the product truly only needs to survive for a few more years, it may be a better business decision to spend extra dollars on expensive hardware rather than spend a multiple of that on rewriting the software. But if this software needs to be robust, secure and reliable long into the future, a more drastic approach is needed.

Decide the Best Plan of Action

So how do you decide which approach to take? Talk to people outside of your company. Ask them to do product analysis and code analysis. It is not out of the realm of possibility that 15% of the code is responsible for 80% of the necessary functionality. 

Your own engineers get attached to their work, and they know why they implemented feature X or feature Z. (Sure, they say, feature X is no longer needed. But why not keep it since it is already there and we spent six months developing it?) 

You need unbiased advice and external engineers see things very differently. They are more likely to ask questions that have never been asked before; provide insight where you’ve run up against obstacles. They’re well-positioned to devise a plan that could reduce your risk, save you money and allow your product to run successfully for another 30 years!    

All Systems Have a Shelf Life

While the tools and systems you’ve relied on for years might be able to continue to meet your business needs in the short-term, meeting new challenges demands IT systems that can keep pace with your organization’s growth. Upgrading legacy systems the right way is money well spent to secure your organization’s future.

If you’re interested in updating your legacy system, ICS can help. Drop us a note and our team will reach out to explore options that make sense for your organization.