When is your software really “legacy”
So, how do you know when your software is so old that you just have to replace it? When is it really “legacy”? Sometimes it’s obvious. If you just sent a condolence card to your programmer’s widow and the system crashes daily, you probably need new software. Generally, it’s not so clear.
If someone tells you your software is legacy, you need to ask one key question: Can you find support for your system? If you can, you’re fine. If you can’t, you need to plan on a new solution. This support doesn’t have to be from an official vendor. Many companies stop paying maintenance and continue using the same software for years to come. They eventually may need a different solution but that can often be a decade in the future. It’s more important that you can find people with knowledge of your particular technology. Just because technology changes rapidly, doesn’t mean that old stuff just disappears once it’s no longer cool.
Here’s an example. A client of mine has years of work invested in a custom developed system on IBM’s AS400.* While the system doesn’t do everything they’d like, it works well enough. However, they are faced with a challenge. First, the developer who wrote the system is close to retirement. Second, the number of people out there who understand the technology is declining rapidly. So, they are starting to plan to replace the system. This is true legacy software.
On the other hand, my client I described in my last post is simply guilty of not giving into tech hype. Sure, their software may rely on COBOL but the vendor is still viable and there are hundreds of thousands of people who actively use the software and thousands who consult and support it. That is not legacy software.
* An AS400 is a computer from IBM designed to run business applications. It is a great machine but pretty much lost the market first to unix servers and now to Windows machines.
Post a comment