Legacy. When we’re talking about custom software, it’s such an emotive term. It implies different things to different people and it’s sometimes used in such negative terms to shut down discussion. I was asked to write a blog article about ‘legacy’ because, apparently, I’m Mr. Legacy! What does that mean? Is it my crusty unix beard? (I’ll have you know I do own some beard trimmers, and I’ve even been known to use them on occasion…) Anyway, it is a subject that I am passionate about and something I’m happy to explore further.
Legacy can mean all sorts of things when discussing custom software:
- A technology that you can’t find people to work on. There’s just no one on the market with that skill set.
- A system with so much complication or complexity such that any change or fix causes all sorts of regressions and user confidence in the system is low.
- A system just a few years old, but not running on the very latest, shiniest, up to date, cutting edge technologies.
- A Window 95-style grey user interface that at best can be called utilitarian? Brutalist?
- A system that has some level of technical constraints inherited from the underlying technologies that precludes enhancements or expansion.
These are all scenarios that might lead someone to describe a system as ‘legacy’ and not worth investing in. Throw it out. Rewrite it. We’ll get it right this time around. I’m sure you can think of other statements that fit this theme.
I do prefer a different definition of legacy. A legacy system is one that costs the business more to maintain and support than it brings in value to the business. This definition, to me, cuts through the vested interests, gets to the real meat of the matter. What is the impact to the business?
In that first example I gave above, a system might well be implemented in an older technology that you are struggling to recruit staff to support. If that system still brings in considerable value to your business then it may well be worth the cost to bring someone in and train them up. If that cost is worth it versus the benefits of the system, then I would argue your system isn’t ‘legacy’. It is a bit of a red flag, of course, let’s not pretend it isn’t. I would encourage you to think long term about migrating away from such a technology, but here I’m talking about having a planned roadmap of migration rather than a big bang (more on this below).
If you’ve invested in a custom system rather than a commercial off the shelf (COTS) system, you want to get as much value from that investment as you can, whether because that system is business critical, provides you with competitive advantage, or just the move to a COTS system would constraint your business too much. Or, of course, if your sector just isn’t well served by COTS software.
So what do you do? You should look into COTS software as an option. The software industry moves fast and the number of commercial packages out there targeting a wide variety of industries has increased massively over the last few years. There may well be a software package with a great fit that is now available. Now, don’t get me wrong, I’m a huge advocate of the power and benefits of custom software systems, but those benefits come at a cost and the economics of managing such a system sometimes don’t hold up. If you can get 80% of the functionality for 20% of the cost, that’s a trade off that’s hard to ignore. Perhaps there is then an opportunity to look at a custom solution for some of the remaining 20% of functionality. Either through a smaller custom solution, some integration work (e.g. link the data to Excel), or a low-code solution. A hybrid approach, bringing packaged software together with custom systems or integrations is a perfectly valid approach to supporting business processes and digital transformation.
What about a re-write then? Yes, in certain situations it is a valid way forward. But if you ever hear the phrase “It’ll be quicker to rewrite” then that should start the sirens wailing. Sure, it might be quicker to write something from scratch rather than expending the effort to understand an existing codebase and architecture, and identifying the required changes. The development effort isn’t the only effort required when developing a custom system. Have all the nuances of the current working system been captured correctly during the analysis stage? The whole functionality will need to be tested from scratch, not just regression tested. We’re potentially replacing an entire system of battle hardened code that has been in use for years with brand new code. That is certainly going to increase the risk on the work considerably. Have all the lessons from the previous time this functionality was implemented REALLY been learnt? You get the gist.
So where does that leave us? My preferred option in most situations is a form of progressive enhancement. How that is done very much depends upon the current state of the system and might involve one or more of the following approaches:
- Bring the system up to date with vendor supported technologies.
- Replace or refresh parts of the system over time. This might be based on a schedule of enhancements to those parts of the system focused on business benefits, or just on a roadmap of works over time.
- If you need to move away from an old unsupported technology, there are options around replacing individual parts of functionality with new systems in a supported technology and link both systems with some form of communication layer.
This approach does take longer but it has a lower impact to the business and much more manageable risk than a big-bang style rip out and replacement project.
To summarise, ‘legacy’ means different things to different people when it comes to custom software systems and technologies. The majority of the time, if there are excess costs or inconveniences being incurred then a big-bang complete rewrite and replacement project is not the way to go. It’s far too risky and disruptive. There are approaches that can be taken to manage that ‘legacy’ code and bring it up to date, maintaining the value that that system provides to the business.
