I’ve previously answered a specific question about whether or not .NET 4.6.2 is legacy technology. Let’s broaden the scope and have a look at some examples of legacy technology. This will allow us to distill some common properties of why certain technology can be regarded as legacy technology, and what our options are.
Some Specific Examples
Creating a full list of legacy technology would be an impossible task. We could list hardware, operating systems, code libraries, applications, and services across a variety of eco-systems. The list would be endless.
But here are some well-known examples of what I regard as being legacy technology:
- Early third-generation programming languages like COBOL or Fortran (or anything older)
- Unsupported or no longer maintained languages like Visual Basic
- Unsupported or no longer maintained databases like FoxPro
- Older hardware like mainframe computers
- Discontinued operating systems like OS/2 or Windows XP
- Older software like Office 2000
Common Characteristics of Legacy Technology
These technologies have one or more of the characteristics in common:
- no longer maintained or supported
- a decreasing pool of talent you can hire
- a lack of support for necessary features
Staying with Legacy Technology
Any business with legacy technology must seriously consider moving to newer technology. But there may be reasons to stay with the legacy technology:
- the legacy technology performs mission-critical tasks
- necessary features are no longer present in the newer technology
- there is currently no budget to cover the transition
In essence, these reasons come down to a single reason: the costs outweigh the benefits.
An example that many large enterprises will recognize, is the mainframe system that performs very important tasks. There are often still people to be found that want to work on these systems (though you may have to pay them enough). And the vendors have a solid reputation of providing updates and support.
Moving Away from the Legacy Technology
But it’s important to really look at both the benefits and the costs. Because moving an existing operation to a newer technology isn’t just a pure cost, even if no new functionality is added.
Investing in newer technology has several benefits:
- less security risks
- better support from vendors
- more potential candidates to hire
It is also important to look at the costs and benefits regularly. It might not have been worth the time and money to move away from Office 2007 in the year 2010. But today, I would recommend setting out an update path.
At a certain point in time, the costs of keeping the legacy technology alive will increase, and the benefits will diminish.
How to Transition
There are several ways of moving from legacy technology to modern technology. It depends on your context, the specific technology, your budget and time available, and other factors. It might be sufficient to just update certain pieces of the technology, or you might need to replace it entirely (in the case of software, this is the refactor or rebuild discussion).
It’s important to do at least a minimum of planning and to adjust as you proceed. Also, make sure you don’t misuse this momentum to add on all kinds of new features. Focus on replacing the legacy technology first.
Don’t Panic, Just Start Planning
If you’re using any of the legacy technology examples I’ve listed, or if you’re using something that has the characteristics of legacy technology, that shouldn’t necessarily indicate a pressing problem.
Take a moment to objectively look at both the costs and benefits of maintaining this system. If the costs outweigh the benefits, only then should you start planning to switch to an alternative.