Legacy Operating Systems and Legacy Languages: If it ain’t broke, it still needs fixing
In my travels I’ve encountered systems chugging happily along on outdated, discontinued, unsupported technology stacks. Apps written in VB6, FoxPro, Classic ASP, still running without a hitch because the kinks had been shaken out years ago… Software users delicately avoiding upgrading their Windows 95 machine because it does what they need, in a manner they understand, running the apps they’ve built their business on… As a techie, the idea makes your hair curl, but the thing is: these applications work. They’ve been working, and they give the appearance of continuing to work indefinitely.
It’s an illusion, though. I sympathize with getting taken in by that illusion. After all, I’ve owned the same cell phone for seven years—I don’t mind that it doesn’t do the latest stuff because it does everything I need (makes phone calls). To replace it, just because someone else has something shinier, sounds ridiculous. I’m the same way with cars, computers, furniture: I evaluate an item’s utility against my own needs, not something else’s capabilities. Taking the same view of your software applications can seem like good sense.
Here’s the difference with software. Factors outside your control can make your application stop working. This is especially true when it is running on a legacy operating system or a legacy language.
I just had a sharp lesson in this on one of my personal websites. My site uses a content-management system written in PHP, which I had allowed to drift a bit behind on version updates. Last weekend my webhost, quite reasonably, upgraded their servers with the latest stable version of PHP. They had notified me, so I was looking out for it, and sure enough: my site was broken. My outdated version of the content-management system was calling deprecated and discontinued PHP methods. To drive the lesson home, I was enough out of date that upgrading the content-management system wasn’t trivial, either. Here is a case where “if it ain’t broke” turned into “it’s broke anyway.”
Keeping software platforms current is not about wanting the latest features. It is about routine maintenance that keeps your critical systems comfortably supported. If you fall behind the pack, software patches and operating system upgrades offer no guarantees. That’s what it means when a technology is no longer supported: it means the manufacturer won’t be testing whether their latest change will impact that end-of-life technology. Complacency is perilous.
You might find it daunting to estimate the value of rewriting an application in a supported language. The cost is plain, but what is the return? It can sound like spending considerable time and resources to end up with the same feature set. In order to make an informed decision, consider what it would cost to lose the application, to have it rendered non-functional—even non-starting—by an environment change. Is the application critical to your business? Is it your business’s product? What would it cost to lose it? Keeping current is insurance against that cost.