It's the new year, but that doesn't usually mean a completely new approach to IT. You might still be running legacy software that has supported your business for years, along with the legacy hardware that it runs on. We know that migrating to something new (and sometimes cloud-based) saves money and makes you more agile. But companies don't always have the budget for that. How can you make the most of your legacy assets until you switch to something new?
Negotiate with your vendor
To some, 'legacy' means 'end of life', when vendor support is no longer available. That doesn't always mean you can't get help with it. Some vendors like Microsoft still offer extended support for a certain period, providing critical security patches for applications that are no longer fully supported with new features or service packs. Beyond that, you can sometimes pay extra for an even longer extended support programme.
Plan a hardware maintenance strategy
The older your legacy hardware gets, the harder it is to maintain. This is especially true for obsolete or unsupported equipment. Until you decide to migrate away from a system, ensure that you have a supply of spare parts handy to quickly fill the gap when a component fails.
Keep the right skills handy
Equipment isn't the only thing you need a good supply of. Skills are important, especially when the hardware or software you're working with has gone out of fashion. Just ask all the banks still running applications written in COBOL.
If you have internal people well-versed in your legacy system, then capture their knowledge before they retire by documenting it and training a new generation of experts internally. If you don't have the internal knowledge at all, then check your vendor's consulting capabilities to ensure that they'll still have knowledgeable people around to support your legacy software. And be prepared to pay handsomely for the privilege.
Automate what you can
Legacy doesn't always mean end-of-life. It can also mean IT that just doesn't do what you need it to anymore because vendors have committed their development resources to newer products. Your applications might lack interoperability or might leave you struggling to streamline manual business processes.
There are some ways to automate your way around this problem, squeezing more time out of them while making your business run more smoothly. The most basic hack is to write scripts that coordinate tasks between legacy applications. A more sophisticated approach is to tie legacy software together with robotic process automation (RPA). This automates the manual tasks that employees must do to fill the gaps between systems, such as re-entering data between one screen and another.
Track the cost of change
At some point, hacks like these won't be enough and you'll want to migrate your legacy system. The trick is deciding when. Keep reassessing this by examining the impact that using legacy technology has on your business. This is a multi-faceted exercise. Look at the cost of maintaining the hardware and software, the risk of the system failing, and the security implications of no longer having any system patches from the vendor.
Beyond this, though, you must also measure the cost of change. Legacy technology's rigidity and lack of interoperability usually makes changes harder and costlier. That creates an opportunity cost as you delay new functionality - or find yourself unable to introduce it at all.
Analyse these factors regularly, quantifying them where possible, and compare them to the cost of migration. That will give you the data you need to make a decision.
Modernise piece by piece
When you do decide to jump to a more modern solution, consider dividing up the modernisation into stages where possible. You can do this in two ways.
First, depending on your legacy application's hardware and operating system, you might be able to make a quick 'lift and shift' migration to a virtual machine running in the cloud. From there you could redevelop the application at your leisure to use more of the cloud's native features.
Second, when you redevelop the software, it might be possible to divide it into different functions and refactor each at a different stage, making the migration away from your legacy architecture more manageable.
You can teach old dogs new tricks, but eventually the downside of using a legacy system will force a move. Until then, you can at least manage it as professionally as possible - while beginning to build the business case for investing in a new system.