Old is not bad. Are you modernising legacy systems for the right reasons?

The Voyager 1 spacecraft, launched in 1977, has been flying through space for most of my life, and for longer than many people today have been alive. It was alarming therefore, to read reports that it was being shut down - and reassuring to find that those reports were somewhat exaggerated. Voyager is powered by the radioactive decay of plutonium, and it is starting to run out: power output is 40% less than at launch, so NASA is shutting down some systems to keep others operating into the 2030s.

I was also intrigued to learn that Voyager 1 is currently on its ‘extended mission’. Its original mission, to gather data on the outer planets and moons, was completed in 1980: the extended missions is effectively just . . . keep on going. And Voyager has kept on going for another 42 years and counting.

The idea of the extended mission immediately reminded me of the enterprise computer systems we build and run. When building business cases we usually plan on a three to five year horizon; when calculating depreciation, we often give software assets a seven to ten year lifespan. And yet software keeps going on much longer than this. I know of several core banking systems that are in their third decade, flying ever further into their future, just as Voyager flies ever further into space.

Unlike Voyager, though, we often lament the longevity of these systems. We regard them as antiquated, slow to change, difficult to maintain, and blame them for our lack of agility, inflated costs and alarming risk profile. Whatever term we use to describe them (remember that ‘legacy’ used to be a euphemism), they soon comes to be associated with drag, friction and waste.

These sentiments are not irrational. Legacy systems are often genuine problems for enterprises. But this is not just because they are old: as Voyager shows us, well built systems operating in a defined context can keep working almost indefinitely (until the power runs out). I think that legacy transformation often makes sense, but we do not always do it for the best reasons. Here are some reasons often given for modernizing legacy systems, in ascending order from bad to better.

Because they’re old

Old <> bad. See Voyager 1.

If your motivation for modernisation is simply to have something new, remember that it will get old too.

Because they’re written in old coding languages

COBOL was released in 1959. C++ was released in 1985. Java was released in 1995 Python was released in 1991. Go was released in 2012.

All of these languages were around before many of today’s generation of developers entered the workforce. While they have their differences (and enthusiasts, advocates and detractors), they have many similar logical constructs, and people can transfer concepts from one to the other. You can even write object oriented code in COBOL.

If your motivation for modernisation is simply to have code in one language rather than another language, think carefully about what advantages this gives you. And be cautious of code converters: do you value code being in another language more than you value readability?

Because nobody wants to work on them

Legacy systems are often perceived as unglamorous: they are the grimy engines in the basement, far from the glamour of the digital channels. ‘Back end’ does not sound like the place to advance your career.

But perhaps this is a self fulfilling prophecy: if we characterize legacy systems in this way, then it should be no surprise that nobody wants to work on them. What if we recognized the role of these systems in the core of our enterprises, acknowledged that they are critical to our ability to operate, and celebrated the feats of engineering required to get them to perform?

If your motivation for modernisation is to make people want to work on your core systems, then you need to think about how you make that work interesting and valued - legacy or not.

Because we don’t have the skills any more

We are starting to get to real reasons: when systems have been around for longer than many people’s careers last, then the people with the deepest understanding of them will start to leave the workforce.

However, we must be clear about which skills are being lost. It’s often possible to replace technical skills, even in unglamorous technologies (see above). But it’s harder to replace deep systems knowledge, especially when those systems have become impenetrable. Perhaps our problem isn’t that people are leaving, but that we haven’t invested in making the systems they leave behind easy to understand.

If your motivation for modernisation is a lack of skills, think hard about the skills you want to build and the skills you don’t: do you want excellent technology professionals who can build systems that anybody can understand, or do you want experts in systems that others find mysterious?

Because they’re slow to change

Legacy systems often have a reputation for being hard and slow to change, and this reputation is often deserved. Changing a complex legacy system can feel terrifying, like reaching into a vast and ancient machine and tweaking one component. Will it break something? Will it break everything? Will we be able to put it back together again? It is no wonder that teams working on such systems often take things slowly.

Yet this is not a necessary function of age. It is usually because every legacy system has been changed many times over many years, and many of those changes have been made in the wrong sort of rush, with the goal of hitting a project milestone rather than building high quality code that can be changed easily in the future.

If your motivation for modernisation is speed and agility, make sure that you build with a focus on code quality, readability and test coverage. Otherwise your new systems will soon feel as creaky and static as your old.

Because operating conditions have changed

The operating conditions have changed for Voyager 1, but only in a few dimensions: it is a long way from Earth, its power output has dropped, and temperatures are lower than anticipated. And yet it keeps on going.

Operating conditions have changed much more for legacy systems built decades ago. Many were built for a nine to five online day, with a big batch window. They were connected to private networks of a small number of machines which exchanged information via files. They were accessed solely by company employees. Now they are part of a world which didn’t exist before: a global network accessed by billions of people and devices that expect immediate responses and continuous availability. Some systems just can’t keep up.

If your motivation for modernisation is to cope with the new realities of a digital world, then thoughtful refactoring, redesign or replacement of your legacy systems may make sense. However, make sure that you learn the lesson of the last generation of systems: the operating conditions of anything that you build today will also change, and your systems will need to adapt.

Because they’re too big

We often hear that legacy systems are monoliths, and that this is bad. Just as with age, we need to be precise about why this is bad. When we say that a system is monolithic, we typically don’t just mean that it is one self-contained unit (that can be a good thing), but that it combines too many functions in one place, and that it’s hard to change one independently of the others.

When breaking down a monolith, we should reflect on how we created it in the first place. Often, legacy systems started with narrow, well defined responsibilities. And then we added to them and added to them and added to them. Nothing about new systems stops us from doing the same, if we are not careful.

If your motivation for modernisation is to break down the monolith, make sure that you don’t rebuild the monoliths of the future.

Because somebody else does it better

Finally, there is simply more software in the world today than when we built those legacy systems. We usually built new things because there was nothing else in existence that did the job that we needed doing, The world is now full of packages, Open Source projects and SaaS services that do many of the things that an enterprise needs. It is often sensible to choose not to do a difficult thing that someone else can do better. However, it is also sensible to ask whether adopting someone else’s solution will genuinely solve the problems that you have with your legacy systems. Will your teams want to work on it? Will you be able to build the skills? Will it be fast to change? Will it cope with changing operating conditions? Is it overloaded with features?

If your motivation for modernisation is to use someone else’s solution, make sure that solution has the characteristics you need, and does not replicate your legacy problems.

Old is not bad, but bad practices accumulated over time can make systems which are very bad. Those bad practices may be in the way we manage software, the way we manage people, or the way we manage architectures. The experience of running legacy systems over decades has taught us a lot of lessons: if we don’t learn those lessons then we will build our legacy all over again. If we do learn those lessons, then we may be able to build systems that survive extended missions far longer than we expected.