The hidden costs of deferred upgrades

Nobody likes to spend more money than they must. That’s a given. So long as that ten-year-old server in the corner over there keeps chugging along, it meets your needs and upgrading to a new system? That would be expensive. Margins are tight and the expense of a new system is not justified now. Or perhaps you’d have to change platforms to move to a newer operating system. All too often these are the reasons that an upgrade to IT infrastructure (hardware or software) is deferred.

To a certain extent, this is a reasonable approach. For many businesses, stability is more important than being on the bleeding edge. Mid-grade solutions are often a better fit than the best performing systems and “good enough” gets the job done while letting you keep the business above water. The problem is that eventually “we’ll upgrade it one day” becomes “it’s still running, no need to do it yet” but all roads eventually lead to failure and downtime. Now you’re hard down and that RAID backplane is no longer available the same day as it used to be and will take two days to arrive; or the software is out of support, and you need to purchase a special support package just to talk to someone. Your IT person is working overtime, or if you rely on an MSP, your IT provider is charging after-hours rates. And all the while, the rest of your business is either impaired, or worse, hard down. Often, recovering from events like this take more time and expenditure to get back up and running than it would have cost to plan for the upgrade and replacement ahead of time. By thinking you are saving money, you’re likely costing yourself more – two to three times as much, sometimes just to get back up and running – and you STILL must plan for the eventual replacement. Worse, most sales teams know this and don’t push so hard on the staged upgrade because they know there’s more money to be made on the other end when you desperately need to be back up and running. So, it’s not in their financial interests to push the upgrade too hard.

So how do you get around this? Plan for replacement and bake it into the budget. Servers and other major IT equipment have a standard lifecycle of five years. Prepare yourself for major IT infrastructure refreshes that often. Planned appropriately, there should be minimal downtime to perform these replacements. If you aren’t a 24/7 operation, end users shouldn’t notice a thing. Software refresh cycles are a bit trickier. The support lifecycle on most major software is ten years from initial release. But mainstream adoption tends to lag by a year or two, leaving you with only 8 years of support. Planned properly, you should be upgrading operating systems and other major business systems roughly in cadence with your hardware, aiming to have the oldest operating system or software release be no more than five years old. In an environment where DevOps and CI/CD are embraced, most major applications that support regular patching should be on the latest stable patches and major business systems that are less tolerant of updates should seek to be no more than one major revision behind. It is often a simpler and smoother transition from one major revision to the next than it is to play catch-up and try to jump up from three or four releases behind. Planning to stay current will usually play out in your favor in terms of economics, security and productivity. IT budgets should always factor in some overhead to allow for upgrades of existing hardware and software.

If you haven’t planned for a disaster already, plan now. “I can’t afford backup equipment” many say. Can you afford to be hard down? The answer to that is probably an even more resounding “no” than the question of if you can afford backup infrastructure. Also, gone are the days when you must purchase a dedicated set of backup hardware to run your infrastructure. In fact, if you aren’t already in the cloud, PARTICULARY if you aren’t already in the cloud, cloud DR is a good way to get your feet wet and begin your cloud journey. Both Azure and AWS provide methods for you to replicate and recover your on-premises systems to their respective cloud environments. Even better, if you decide that you like the cloud systems better than your old hardware that just died, using either service for disaster recovery essentially has the replicated systems already migrated to the cloud. It would just be a matter of choosing the new DR location and making your DR set your permanent server set in the cloud.

“I’m already in the cloud”, you say. “I shouldn’t need to plan for any upgrades.” Untrue in either the hardware or the software sense. Unless you are running only Software as a Service (SaaS) or Platform as a Service (PaaS), you need to plan for operating system and software upgrades still. Furthermore, Amazon, Azure and Google all have different generations of virtual machine instances. The generation you start out on will eventually be phased out. Downtime to migrate may be less than migrating to new physical hardware but keeping an eye on the available options may allow you to switch to another generation that will be supported for longer AND save you money.

In summary: deferred upgrades usually cost more than planning for the upgrade as a matter of reality. Save yourself time, money and frustration by engaging with an architect that can help you navigate this planning process.