Some companies -- like Apple -- seem to think that older versions of their software simply vanish from the world when new versions are released. Not only is that not true today, it’s never been true.
Mainframes running mission-critical Cobol apps persist to this day in major corporations and governments. AS/400 green screens are still in use in huge numbers. Windows XP-based point-of-sale systems are everywhere. An ancient Commodore Amiga still runs the heat and AC for a school system. DOS systems are still in use across the globe. I doubt we'll see the eradication of Windows XP within the next 30 years.
Much as we’d like to wave a magic wand and have everything magically upgraded to the latest version without hassles or issues, that’s not going to happen. Ignoring this significant reality from either the vendor or customer perspective does nobody any good -- quite often, it paints us into corners.
Anyone who has spent enough time in IT is familiar with the phenomenon that manifests as a series of individual minor issues that form a collective roadblock across a seemingly straightforward path. A common example would be the mismatch between the browser you’re currently using and the Web-based administration UI you’re trying to access, where the client doesn’t have the proper version of Flash installed or needs updated plug-ins in order to function -- or in the worst cases, where the Web UI refuses to function at all unless an older version of the browser is running.
If all you want to do is change a minor setting that should take a minute or so, the 10 or 20 minutes of downloads and updates required to get there can be maddening. Having to build an entire VM with old software to get there is infinitely worse.
Then there are the unfortunate number of midgrade and enterprise hardware and software solutions that have dependencies on now-ancient client packages to perform any management or administration. Ideally, firmware updates are available that lighten these restrictions, but that’s certainly not always the case.
There are many infrastructures in which critical components are several years old at least and functioning perfectly, but have been neglected or “end of lifed” by the manufacturer. In some cases they can be maintained only through a Windows XP box running IE6 and Java 5. In many cases they are expensive, industry-specific tools such as manufacturing equipment, environmental control systems, security systems, or other solutions that are not easily or cheaply replaced.
It’s not uncommon to see elderly Windows XP, Windows 2000, and even Windows NT systems running manufacturing control software. The software typically runs only under those versions or requires accompanying software that is similarly restricted.
Everyone knows this is a liability, but upgrading the system may be impossible apart from a wildly expensive wholesale upgrade of an entire manufacturing line, or it may cost tens or hundreds of thousands of dollars to be spent on software licenses. When faced with a choice between maintaining a few older systems or replacing perfectly functional hardware and software, the bean counters will almost certainly choose the former. Ergo, that Windows 2000 box gets “fixed” regularly.
The danger comes into play when software vendors stop making older software versions available. I’m not necessarily talking about operating systems, but other foundational elements. When a software vendor pulls old releases from its download sites, it forces admins trying to rebuild an older system to look elsewhere for those packages, usually from not-entirely-trustworthy sources. As time goes on, this problem only gets worse. If older versions are end-of-lifed, it would be much safer for a vendor to supply verifiable, completely unsupported downloads of those releases than to remove them entirely and force people to resort to questionable sources.
Another issue is overzealous security restrictions that effectively block certain tools from functioning. Java 7 and Java 8 block untrusted SSL certificates, for instance, so if you’re trying to access an internal Java-based management app via browser with a self-signed cert, you’ll have to jump through a bunch of hoops to get there. Sometimes the only option is downgrading your Java version, which will typically screw up other apps. You’re damned if you do and damned if you don’t.
Reliance on aging systems naturally leads to increasingly difficult and dangerous maintenance and administration procedures -- but in many cases, that danger is the artificial, needless result of vendors restricting access to older software releases. Nobody wants to maintain older software forever, and there are certainly security risks to consider, but the incredibly short lifespan of some software ultimately leads to more problems, not fewer.