We met last week with a new client who is currently running off-the-shelf software and facing a dilemma. The next batch of required upgrades was adding up to an expense that they don't want to bear. Without going into too much detail, they are faced with a dependency-laden upgrade that requires updating the server, scripting language (PHP) and the front-end software itself (which will rename nameless to protect everyone involved).
The idea of a comprehensive update project came as a shock to them because they had already invested their budget on the development and subsequent amendments to the software. Now, after spending so much to get where they are (with minimal satisfaction, if I may add), they are being asked to invest another large sum to keep things humming along.
This situation got me to thinking more about the cycle of upgrades, ongoing maintenance, and how off-the-shelf software differs from custom solutions with regards to these issues. First, let me give some background on why these updates and upgrades happen, and then we can dig deeper into some thoughts I have on the topic.
Why Upgrades are Required
I've previously covered this exact topic in a post entitled "CMS Maintenance: Why Your Website Suddenly Breaks Down." I recommend you read this, when you get a moment, as I break down in-depth all of the reasons why maintenance is indeed essential. For this post, I'll summarize some of the points made in that article in addition to pivot just a bit to add some color to the issue of upgrades and updates, specifically.
In short, upgrades are most typically responses from software vendors and open-source projects to common issues that present themselves as time goes on. First, updates may involve amendments to code for security updates or software bugs. This means that software is being patched to address a recently discovered gap concerning security or a fault in operation. Secondly, upgrades may be released due to dependencies with other software. As an example, when PHP switched from 5.x to 7.x, platforms built on PHP were required to upgrade their codebase to adjust. Thirdly, updates may happen to address user-requested functionality or amend the offering. Though, in that case, the terminology of an "upgrade" may be more common.
Updates or upgrades for functionality reasons can typically be installed more deliberately unless there is an immediate and quantifiable benefit. However, updates which are driven by security, bugs, or dependencies usually has some level of urgency. Once a catastrophic security hole has been identified, you can't wait for years to handle it. You need to do something at some point. With that said, it isn't unusual for the holes identified not to be catastrophic anyway, and while it's best practice to act on them, you do have time to prepare (more on this later).
The Problem is Unpredictability
Updates and upgrades most often lead to complete chaos when a few conditions are met. First, if an update has a high level of dependencies with other required software packages. An example would be if you have to update your core PHP version, but your CMS won't work unless you update PHP first. This creates an unpredictable mess which inevitably will lead to some stress. Another example can be when you haven't run an upgrade in quite some time. This leads to an even deeper level of unpredictability. There are many moving parts to almost all software packages and skipping updates for a long time increases the chances that the next update will fail. Or, even worse, you may in some cases have to run multiple updates in the order in which they are released – a pain. A third possibility is when you have a piece of software running that is so large, bloated and glued together with plugins and extensions that a seamless upgrade may not be possible. There are many of these platforms out there… Don't even get me started!
Finally, if you have massive modifications or customizations to your platform (including code amendments to the core, which quickly can add up to technical debt) and run updates, it can turn into a bitter experience as one of two things may happen: You may not be able to run the update, or the update will break your modifications.
Sadly, it's worth mentioning here that in almost every case, more than one of the above issues presents itself, which leads to updates and upgrades in some cases taking more time than the original implementation.
The Custom Difference
Back to the point of this post – comparing custom versus off-the-shelf solutions when it comes to upgrades and updates. For the most part, it's worth noting that custom software doesn't have any relevant updates to the software itself. Primarily, you're going to deal with updating underlying packages that enable the software to run. The risk that you can run into here is that those updates change the dynamics of how the software runs, which could turn into some necessary coding changes. However, typically, this is a bit more predictable.
And that is the primary difference between custom and off-the-shelf solution: predictability. You see, underlying software updates at a slower pace. And, security updates to the software that powers your solution typically require a lower level of involvement. IE, when PHP updates a security patch, it's rare that the patch will dynamically change the functionality of the code and break what you have already written. When PHP does change its structure in a way that will affect your software's performance, they typically give you many months of warning before that version reaches end of life, and in some cases years. Compare this to an off-the-shelf platform – clients have no idea when updates will be issued; they don't understand how updates will affect existing functionality. There is just too much out of their control. With custom solutions, everything is under your control, and the urgency factor is typically much lower resulting in more time to make the proper decisions.
You're probably asking yourself at this point how custom software isn't plagued by the same issues as off-the-shelf when it comes to security exploits. Well, it does to an extent, but it also doesn't. Because off-the-shelf software is crafted to be utilized by many, hackers create worms and bots to crawl and look for sites that are vulnerable automatically. Custom software solutions typically do not suffer from this same level of vulnerability. It simply isn't worth it to the attacker unless there was a specific reason to target the victim. The fact is that code frameworks that typically power custom solutions are lighter and tighter, and result in fewer attacks and therefore less need for updates, whereas off-the-shelf packages are always on a potential attackers radar.
The Agency Game
One of the most significant issues with updates and upgrades is that almost every digital agency pressures their customers to perform them by labeling all of them as being catastrophic. It's a profitable business. Agencies appeal to the fear factor in pushing customers to update. They create an urgency, and as such, also have freedom in terms of pricing the services. In some cases, there is an urgency. Updates could be 100% necessary in a timely fashion, as mentioned above. However, sadly, often agencies will push upgrades and charge hefty fees simply because it's good for their business.
In the case of this potential client, the agency was pushing for an upgrade that was, in reality, six months old. It was a revenue push for the agency. An astute agency will alert you to catastrophic consequences in a timelier fashion. Preferably, within days of the updates being released, not many months later.
It's hard for customers to gauge the realities of an upgrade that's recommended by an agency. It's like any other news you receive from a service professional, whether it be a plumber, doctor, or mechanic. The truth is, you don't know what you don't know. I recommend some simple questioning to try to understand how much of an issue the update is to your business. Asking questions such as "can we wait until x, y, z," or "what's the risk if we do not update." Finding out more information to evaluate your risk levels is essential, and comparing those answers to what you read online is a good practice to determine whether or not you should commit to the expense of an update.
Wrapping Up
I know this post moved from one direction to another, but at the end of the day, there is a difference in the ongoing commitments required from licensed or off-the-shelf software versus custom software. Custom software offers you a better chance at predictability, a lower chance at chaotic updates and upgrades, and overall a more manageable maintenance experience. Off-the-shelf software helps in that a community or vendor manage what needs updating, but it also means you are at their mercy in when these are released and how involved the nature of the update is.
Often we mention that the determining factor between custom software and off-the-shelf solutions can be calculated by how much your specification deviates from the ability of the existing software packages. However, a second factor to be determined should also be the comparison of ongoing maintenance, what the commitment will look like on behalf of your company and your development resources, and the estimated costs associated with that commitment. When compared historically, the argument that custom software costs less to maintain is indeed a viable and statistically provable position.
