Within Ghyston we have a department that is dedicated entirely to supporting legacy systems for our clients. A legacy system is one that a business still relies on for some parts of its functionality but uses technology that has been superceded or written in old languages. In other words, there’s something about it that means it’s not up to the standards it would be if we were writing it today but it still needs to be alive for business reasons.
Sometimes our job is simply to keep the lights on, as it were, picking the system up if it falls over and making sure it works well enough to fulfil its business function with a view to doing a complete rebuild in the longer term. With others we can iteratively build in new functions or add new features so that their lifespan is lengthened.
The latter option is a good halfway point but it does come with compromises. When it comes to doing a cost benefit analysis of the various options, it’s important to look at what costs are associated with a rebuild compared to the risks involved with keeping the old system alive.
So, can a legacy system be maintained? The answer is: maybe! It really depends on a number of important factors:
Is the operating system supported?
If the element of your system that is obsolete is technology that is owned in-house, it can potentially be maintained. However if the technology is owned by another company - for example, you’re using a Microsoft operating system - and that goes out of date, there’s much more cause for concern. When that company stops providing updates, patches and so on, you’re open to a host of security risks and may have no choice but to upgrade, rebuild or part rebuild.
Does the system include automated testing?
One of the most vital things that makes a system easier and less risky to support is automated testing. While some manual testing is possible, you simply can’t cost effectively retest every situation every time you release a change.
A good high quality system is generally built hand-in-hand with an automated test suite. But in the case of a legacy software system it may be missing. In this case you’ll almost certainly need to upgrade or, as a cost saving alternative, retrofit this function into either the entire system or one part of it.
How clean is the code?
Quality code is created when clean code principles are followed. Legacy System often implies large ‘spaghetti’ code, which makes it harder to update with any real confidence.
It can be done though. We operate on the Boy Scout principle, which simply says that whenever you’re changing any piece of code, try and leave it in a better state than when you found it. So if you find code that hasn’t been written with quality in mind when you’re doing the updates, then you must also update the code that is associated with it so it’s more maintainable in the future. By doing this we can improve the system iteratively over time.
Do you have reasonable documentation?
A system can still be maintained without it but reasonable documentation makes the process an awful lot easier and cheaper. This, along with the points above, needs to be factored into the cost-benefit analysis or whether it’s worth keeping a system going, adding in new features or taking the plunge and committing to a rebuild.
Can you update part of your legacy system?
As we alluded to in the last point, the question of whether or not to maintain a legacy system doesn’t have to be black and white. You don’t have to choose between keeping a system going and upgrading to a new one. You can simply add new features or rebuild parts of the system rather than waiting until you need a big bang approach.
Doing this reduces the risk of moving away from something that, yes has issues, but is fundamentally working for your business. By investing in smaller chunks of updates over a longer period of time, you’ll be able to concentrate on the areas that are most important, most unstable or causing the most problems.
However, there is a trade off. Building a new function into an old system is more expensive than building one into a newer system. You have to conform to more restrictions, which drives both cost and risk. If you’re talking about a business critical function, you have to ask yourself how much it might cost the business if fixing a glitch in the legacy system actually ends up breaking something else.
As with most decisions about software development, it comes down to cost benefit analysis. That’s why we work closely with our clients to understand both their system and the challenges they’re facing. Legacy systems can be updated but that doesn’t always mean they should.
