A common thing that I’m asked to do is keep an old system running beyond the official end of life date. This happens a lot during my freelance work, and also when I worked at a university. It comes with its own set of challenges, which may exceed the benefits of upgrading or moving to a new system.
Getting help
If you’re stuck with a particular problem, it can be difficult to get help. Software and system maintainers understandably don’t like to support old software, which they might define as anything other than the current stable version. For example, Ask Ubuntu considers any questions about 16.04 to be off-topic (unless you’re asking how to upgrade to a supported release). Some projects also delete documentation for older versions or functionality that has been removed in the latest release.
Reluctant third party providers
Sometimes you find yourself forced to upgrade because a third party refuses to deal with you otherwise, e.g. hosting providers that remove support for old versions of PHP. This is a common reason why clients contact me to upgrade – they don’t necessarily want to, but their hand is forced by someone else.
You often can’t ‘just upgrade’
The reality is that it’s not always possible to ‘just upgrade to the latest version’, and suggesting this is often unhelpful. Some of the reasons I’ve come across are:
Expensive hardware: If you’ve forked out millions of pounds for a machine that only supports Windows XP, you’re not going to replace it just so you can run Windows 11.
Dropped dependencies: I had to get a crucial piece of teaching software to run on the latest version of Scientific Linux. Unfortunately it was written as a 32 bit application, and SL was now 64 bit, with 32 bit libraries removed from the package archives. Eventually I managed to get the source code for the old libraries and patch the build process, but it was a huge amount of effort (see Maintaining old software on new systems for the details).
Bespoke application: Often these require so many changes to work on new versions (e.g. PHP 7 or 8) that it’s close to a complete rewrite.
No source code: I had to reimplement a system to upload files by FTP, because the existing software didn’t run on new systems and the source code wasn’t available.
Not under your control: I recently wrote some software for deployment to the customers of my client. I had to do some extra work to make sure it ran on 32 bit systems, because at least one customer still had very old hardware, and it wasn’t under my control (or my client’s) to upgrade. Likewise, I had to use an insecure protocol for data transfer, again because of restrictions on other systems that I couldn’t update.
Risk management: Upgrading software is risky, and if it happens to be essential to the day to day running of your business – as is the case for most of my clients – then it can be difficult to justify.
Security risks
Running old software means the risk of security vulnerabilities that are unlikely to be fixed. The longer the software is unsupported, the bigger the risk – though this varies depending on the popularity of the software (I had a client ask me about dBASE III, which I doubt anyone is actively trying to exploit now).
There are things you can do to mitigate these risks. An extreme example would be isolating the software from any network connections, but you could also restrict access in various ways, e.g. by only allowing access from certain locations.
Need to keep an old system running?
If you’re struggling to keep an old system running and want some advice on your options, get in touch and I can help you plan the next steps – whether that’s keeping things as they are or a plan to migrate to a new system.