What’s the oldest third-party software your company uses? Why is it still in use? I asked IT professionals these questions, and gained a bit of insight into business motivations: what makes businesses hold onto software long past the presumed expiration date.
I recently listened to an IT manager talk about how many Novell Netware servers his organization still used (and needed to back up). I could hear the pain in his voice.
It got me thinking about the entrenched legacy software in enterprises today – software that IT folks and software developers have to support. So I solicited input from techies around the world, asking about the oldest third-party software used by their companies, and why they still used it. I heard from nearly 40 people, most of whom had strong emotions about the topic. And by “strong emotions,” I mean I heard a lot of swearing.
The results are entertaining, in a schadenfreude way. (“Oh wow, someone who has it worse than I do!”) More usefully, the “why” answers give us a spark of insight into what makes organizations hold onto legacy applications, for good or ill.
I didn’t ask people about legacy custom-written applications or other in-house software. The reasons to hold onto old custom code are relatively well-known (such as, “Nobody knows where the original source code is” or “It was written in an obscure language that nobody remembers”). So that’s a different discussion.
But software you acquired from a vendor…? That’s another story.
Even though we techies have a tropism towards the latest-and-greatest, most people don’t like change. Once you learn how to use a piece of (relatively dull) business software, you want to put the skill on automatic. As a result, users understandably resist moving to new versions or replace “the devil they know” with a new supposedly-better application. That isn’t horribly wrong, because, “If it works, don’t fix it” often is a valid response.
So I heard from one techie whose company still uses CAD 98, because his engineers won’t give it up. And a network admin told me of an architect who relies on Ecco Professional for PIM functions “because nothing on the market is as powerful and flexible,” as well as folks he’s met who continue to use Interleaf or FrameMaker. In short: “They feel it’s superior for their purposes and think it would be too laborious to convert to something else.”
Nor are techies immune. The same network admin confessed, “I personally rely on Emacs because it’s ever-fresh and on Eudora because I haven’t found an email client that can cope with the complexity of how I use it.” Why? It’s a combination of habit, conversion cost, and “It’s the nearest thing to a blank screen to write on.”
Similarly, a friend who works for a large multinational enterprise with offices in 57 countries tells me that the company continues to have user community pockets where Lotus Notes reigns. Until only five or six years ago, he said, Microsoft Exchange and Lotus Notes were on par for features, so there was no compelling reason to move. “New offices, new operations, new companies launched or moved to Exchange, but there are still a few Notes installations,” he said.
Other users have a legitimate need (at least in their perception) to deal with documents and other data from the old applications. While some kinds of files are based on a standard format (such as PNG or JPG), that isn’t always the case. Personally, I’ve a few documents written in the DeScribe word processor’s proprietary format that “I might need someday,” so I keep one old computer running OS/2 Warp. Just in case.
The users might be happy to use old technology until all the knobs break off, but that causes problems for the IT staff who have to keep gluing the knobs back on.
The problems ensue less in the case of “if it’s not broken, don’t fix it” but when it’s just a “little” broken. “Management wants the least painful, least risky fix,” one admin explained. “And for some low value of risky, we delivered that fix. Management usually doesn’t have any incentive to expend resources on a fix that has to work a year from now, only incentives for sufficient resources to get past the current ‘event,’ i.e., port off of a dying machine, operating system end of life, etc.”
Examples of legacy software your compatriots are still supporting? Try these:
One buddy from the League of Professional System Administrators said that, in addition to user reluctance to change, the other scenario for running old software is a matter of infrastructure: the difficulty of transitioning from old to new. “This includes the dollar cost of the new software (and hardware) and the huge amount of staff time needed,” David wrote. Beyond the immediately obvious time and money needed for the actual transition or migration are additional challenges. Among them, wrote David, are “the costs and time necessary to really understand and deal with all the dependencies, both technological and business-process. It is very hard to know all the ways that people are using the features (and oddities) of any major software infrastructure. And getting people to change how they work is really hard, especially when they don’t see any advantage or benefit.”
So, a few examples of situations where old software would cost too much to replace because the infrastructure cost is (perceived as) unreasonable:
Of course, “infrastructure” is not only hardware and software. It’s wetware, too, often spelled job security. As one reddit contact explained:
The company that I used to work for had an old PBX from the 90s running off of two pair. The “engineer” that maintained it was the only person who knew how to run it and refused to teach others. The phone vault was this monstrous mess of stripped wires all over the place leading to this old 9 inch CRT running I have no idea what…
No one wanted to touch the damn thing for fear of it breaking, outside of the one guy. If that system broke, they had no failover for phones. Half of the wires were just stripped out and sitting in space doing nothing. No labeling. Nothing. No one knew where anything went to. And management didn’t want to gut it and replace it with up-to-date tech because it was so mismanaged and yet still functional that they had no idea what it would cost to gut and replace… [What a] nightmare.
Sometimes, the old application remains in use because it’s waiting for a bigger project to replace it… rather the way I haven’t fixed my screen door because I am planning to remodel the dining room in the next year or so.
For example, one friend told me about a large retail business still uses Datacom DB as the heart of its data entry systems. While several core systems have been replaced, some remnants remain. As she explains it, Datacom DB is not easily removed code; and it makes more financial sense to replace entire systems than to do surgical strikes.
Thus, writes one IT staffer, “We use Access 97. We wrote an application using the built-in Visual Basic feature, and it runs our entire shop floor. It’s ‘compiled’ down into an MDE which is a read-only database, but it still requires Office 97 to be installed to run.”
And, of course, that means a whole department (at least) is stuck using Office 97 because of the single legacy application. That isn’t efficient, in any kind of holistic way, but it’s the real world.
The bigger the organization, it seems, the harder it is to remove the application and – more painfully – its platform dependencies. As of 2012, the UK government was still suggesting developers writing Web software work to support IE6, “as this is still in large-scale use in government departments.” Despite pleas from those in government IT, there’s still some indication that IE6 remains in-use to this day; “We have insufficient technology change happening out loud in public sector organisations; bravery is rare,” said the now-retired Chris Chant, once Director of GCloud, which was an initiative to give more government business to smaller organizations.
More examples, to make you feel better about your shop (I hope!):
Drive images and virtualization can help with these situations, sometimes, as a stopgap – which is better than having to keep an inventory of IBM PS/2s because some application was written to the hardware bus and the client’s custom code had disappeared. (I knew someone, once, with that particular problem. He drank heavily.)
Creating a virtualized system for a given application can be time consuming, too, which means it’s the sort of task we all procrastinate. For instance, one reddit commenter has to support a dBase IV application written in the mid 90s, running on a Windows 3.1 box. “I’m scared to death to touch it as the machine hasn’t been restarted in years. The floppy drive is dead,” he wrote. “One day I’m going to have to down it and turn it into a VM.” I don’t envy him.
In the meantime, it might be just as easy to dedicate some hardware to running the legacy software. One admin’s shop is using ETC Unison Light Manager, a 16-bit program that won’t run on 64-bit OSes; they keep a couple of 32-bit Windows 7 installations around for the handful of times they need to use the software each year.
But the preferred way to support the legacy application is to build a virtualized system that has all the components it needs. One sysadmin described his company’s door access control software that dates from 2000; it runs on Windows 98, as the 16-bit program locks up after a few days if run on Windows NT. “Luckily, it has no problems running in a VM, and it’s only accessible through the VSphere console (no network card configured; it communicates with controller through serial port), so it’s not too much of a security risk (also, this lets me have a VM with years of uptime; it’s been surprisingly stable given that it’s Win98).” A familiar refrain for why the company is not replacing it: “The new software apparently isn’t compatible with the existing controller, so we’d also have to replace the controller and the 50 or so access cards.”
At some point, of course, it’s time to jettison the old software and look for better, modern options that provide more feature depth as well as integrating with the current enterprise infrastructure. This affects business strategy (especially if your company’s competition is using more modern tools) as well as missing out on technology innovation (since the old “it just works” software is a pain to integrate with modern conveniences, such as mobile devices or even the Web). Plus it hurts the techies who have to support the old stuff, since they don’t have the opportunity to learn new, marketable skills. Network admins’ time is worth something too; and the energy you expend in duct-taping together old systems is time not spent adding value by making things better. And isn’t that what all of us would prefer to be doing?
Get a free trial of Druva’s single dashboard for backup, availability, and governance, or find out more information by checking out these useful resources: