Like a challenge? Trying to figure out your disaster recovery plan for a legacy system could be just the thing.
But don’t come complaining when you’ve run out of aspirin to take the pain away, because DR for old apps and the machines on which they run can be a very complicated affair.
If you’re lucky, the people or the organisation responsible for making the system can still be contacted, spares can still be obtained, and you can reproduce the legacy system elsewhere and switch over to it (with your data backups, right?) if you need to. But what if you’re not so lucky?
One of the worst case scenarios is an app that is critical to your company because it has unique and vital business logic embedded in it, runs on old hardware that they stopped making when typewriters went out of fashion, and was written by an ex-employee who left five years ago.
Oh, and the network address is hardcoded into the client software to use the app, just so that you can’t just switch them over to another box elsewhere.
At this stage, you might start looking for the biggest bottle of aspirin you can find – but this, as any doctor will tell you, is treating the symptom, not the problem.
Alternatively, you could start thinking about rebuilding the system elsewhere, or rather creating a solution to do what the legacy system does.
It’s a longer term solution, but perhaps the only viable one. Even if you don’t feel like coding in some esoteric programming language, there are other user-friendlier possibilities.
If you start from the business process that the legacy machine serves, cloud-based solutions let you reconstruct that process and automate it to bring it all into the 21st century.
But maybe you’re thinking “It could never happen here” because your systems are all bang up to date.
If so, just wait until your CEO decides to merge with, or acquire another company, whose IT department has been praying that someone like you will come along to solve their legacy system disaster recovery headache.