Are You Prepared for Your Software’s Inevitable Demise?

p>Wow...! Can the title of a post be any more depressing? 

We were first-hand witnesses last week to what happens when business owners neglect their custom-built software, and it wasn’t pretty. First, some background... A client resurfaced recently after 2 years of silence. Their site was deployed on a custom platform and since then, the client opted out of maintenance or an ongoing relationship. This is fine – clients can do what they want with the software we develop for them. And, to a certain extent, the fact that they spent 24 months with zero technical expense other than hosting is a remarkable achievement in itself – I’d call that a pretty good value received. However, they ran into trouble when their web host decided it was time to upgrade the server out from underneath them.

Now, I’m not sure if they were forewarned or the changeover simply happened. But, the web host completely bumbled the transition. This was issue number one – a major transition happened and it was not properly managed. The end result was that the site, on a Friday no less, was down and the client was left with nothing over the entire weekend.

We were notified and had a look on Monday. The web root was a complete disaster. The host had moved files all over the place. I have no idea why or how this happened, and frankly, this was easy enough to fix as we knew what belonged where. The real trouble happened after we realized that the host had also upgraded core software underneath the account, which rendered key areas of the code unusable.

And this is where the title of this week’s post comes into play. All software is eventually deprecated. That is the technical term for, well, killed off. In this particular case, the host had upgraded the customer from a flavor of PHP5.x to PHP7. This is all fine and good – most people today are building in PHP7 and have made the change. However, there are significant changes between the two versions, especially around how PHP operates with MySQL, the database that powers a large portion of applications created with the language. PHP7 deprecated all of the core code that developers were using for pretty much the previous 15 years in favor of new techniques. This means that at a very base level, all software written for PHP5.x is now at risk as web hosts upgrade to version 7.

You are probably asking why this happens in general. Well, like anything else with technology, it’s usually to solve some problems and take things to the next level. Sometimes these changes make a lot of sense, and sometimes we’re left wondering what the heck is happening. As we all know, changes happen to hardware all of the time. A friend of mine sent me this hilarious video about the MacBook changes in the past few years that resulted in everyone buying dongles (watch it!). Was that a step in the right direction? Honestly, I’m not sure. But it’s a good example of how things can change on us and require us to adapt. Apple is notorious for this, making people buy Lightning adapters and USB-C. In most cases, you could argue they were changes for the better.

With software, the one thing we have going for us is that it moves relatively slowly, especially with core software such as PHP and MySQL. While CMS platforms such as WordPress move quickly, software underneath iterates at a slower pace and developers have ample time to adjust their code to future changes. In this case, we’ve had advanced warning of these changes for quite some time. PHP, like most open-source (and commercial) software, publishes this information so that technologists can get ahead of it and plan accordingly. But now, in the case of PHP, the change is a bit more urgent because of something we call “end of life”. End of life is something that people should be concerned about because it indicates that software is no longer supported by the community for critical security updates. In the above case, the host upgraded to PHP7 from 5.x because they know that come December 31st, 2018, the PHP community will no longer support the software. It would most likely be libelous for hosts to continue to provide that software on shared hosting environments knowing they would be at risk, so most hosts are conducting upgrades now. This means, anyone who has built software on PHP in the past few years needs to upgrade, and do so by the end of the year.

With PHP, this means a large percentage of sites on the web need some sort of upgrades. For the most part, off-the-shelf software such as CMS platforms and other applications provide updates that handle this issue. Wordpress as an example has supported it at a core level for some time, and there are plug-ins available that can scan your installation to ensure compatibility (https://wordpress.org/plugins/php-compatibility-checker/). While the core packages for WordPress and most off-the-shelf software has been compatible for quite some time, there are still plug-ins and extensions that should be carefully evaluated for compatibility.

Why Does Software “Expire”?

The bottom line is that eventually; software has to move on. Software can’t continue to be supported by the community as it ages and is replaced by better options. It is actually a good thing that the community forces these changes upon website operators, in that it enables them to have some level of influence in ensuring that the community maintains currency on these platforms. No one wants insecure software floating around on the internet. Web hosts are afraid of the liability of such software being accessible, companies are afraid of what possible vulnerabilities are out there, and developers like working with current technology. In all, end-of-life is a win-win for almost every party, except perhaps those that are unhappy to foot the bill to upgrade.

What if you don’t upgrade?

The potential risk of not upgrading is hard to predict. All software has security vulnerabilities that present themselves over time. If you check the past schedule of software upgrades across your favorite open-source platforms or frameworks, you’ll see many are in response to threats. Typically, those upgrades are relatively easy and automated. It's a rarer occurrence that an entire version of software is deprecated. However, in the PHP example, that is what the community is facing.

The largest risk is that vulnerabilities will continue to be found and taken advantage of. Only, when software is past its window of support by the community, fewer resources will be dedicated to tracking these issues and none will be crafting workarounds or fixes. This means the potential for security gaps in your applications exists, and depending on your risk tolerance, could mean your software faces the possibility of intrusion or other nefarious manipulation.

It’s worth pointing out that no one is holding a gun to your head to do the upgrade unless you are on a web host that is forcing the upgrade. You can still maintain your own server on old software if you like. However, just be aware of the risks and worst-case scenarios that are possible.

How to Upgrade Dying Software

I’m going to focus this section on the current PHP upgrade scenario we face. However, many of the tips and the sequence of events and diagnostics can apply to any similar situation. 

The first thing you have to do is evaluate if you are indeed affected by the upgrade. Chances are, if you have custom built software prior to 2017 utilizing PHP, you could have been built using version 5.x. One quick way to verify is by asking your developer, or your web host, what version of PHP you are running. If you have the ability to change files yourself, you can always create PHP Info page with the following code:

<? phpinfo(); ?>

This will output a page that indicates all sorts of information about your installation.

If you are running on an older version, you need to start to determine how you can upgrade, and how much time you have left to do it. If you are still in touch with your developer, have them evaluate the depth of changes that you need and arrange for a quote. Your developer will need to either update their development environment to PHP7 or arrange for a new environment to work in. From there, they will have to remove all of the old code and update with the new equivalents. This can be easy or difficult depending on your software.

Deployment should be carefully planned and executed to avoid downtime. You can either take your server down, perform the upgrades and redeploy the site. However, it may make more sense to create a new server instance or a new hosting account for you to flip over to when ready. It makes deployment easier and can mean going backward isn’t as tedious, just in case you have to revert.

Should You Panic?

Whether the PHP scenario applies to you or you find yourself in some other similar situation, remember that end-of-life usually doesn’t mean your software is just going to cease working at that very moment. In fact, unless you are paying ongoing subscription fees to a provider, most likely the software will run just fine after the last date of its support is exceeded. However, this doesn’t mean you should ignore it. Depending on your risk profile, you may very well get away with running on old software for many months if you need to. But, keep in mind this will expose you to uncertainty and risk about the safety of your situation.

Wrapping Up

I said in a past blog that your website isn’t a slow cooker. You don’t set it and forget it… The same analogy applies to the software underneath your website or application. It takes many, many software packages to make your end project work. Any of those pieces can be presented with an end-of-life scenario. You must plan in advance how you will handle the updates or upgrades required.

The most important thing to remember is that you simply must be in the know. Don’t ignore your maintenance team’s updates. And listen when your web host indicates an upgrade. Avoiding surprises like our poor client last week is the number one thing you need to do for the sake of your software, company, and application.