Linux distributions such CentOS, Debian and Ubuntu provide not only a base Operating System (OS), but also a selection of libraries and application software packages, including Apache, MySQL and PHP. Each release of a distribution will generally keep the same versions of these software packages throughout its lifetime, only updating them to fix security vulnerabilities or certain other bugs, and will not upgrade them to new versions with new, possibly incompatible features.

For example, there are currently two supported releases of the CentOS distribution: 6 and 7. CentOS 6 provides Apache 2.2, MySQL 5.1 and PHP 5.3; CentOS 7 provides Apache 2.4, MariaDB 5.5 (a replacement for MySQL) and PHP 5.4. A useful resource for finding which software versions are provided by the various distributions is DistroWatch.com.

Throughout the support lifetime of a release, fixes will be backported by the distribution's maintainers. In other words, they will take the fixes provided by the software's original authors, and apply them to the older versions that they maintain for their distribution. As long as you are running a supported release and keep your server updated (or we keep it updated for you as part of a management service), you don't need to worry about running outdated software versions from a security standpoint.

The reason for all this is to provide a stable platform on top of which you can build and run your own applications. In this context, stability doesn't mean not crashing (although hopefully that will also be the case!) but rather not changing unnecessarily. For example, if you have developed and tested your websites on PHP 5.3, you don't want to have to update your server to PHP 5.4 in order to fix a security vulnerability, possibly breaking your websites due to incompatibilities.

Of course, each release can't be supported indefinitely, so at some point you will have to upgrade. For CentOS, the only supported method of upgrading to a new release is a fresh install. Debian and Ubuntu provide methods of performing an in-place upgrade. We do not recommend this, however, as if anything goes wrong, or there are incompatibilities between your applications and the software versions provided by the new release, you will be left with a live server in a broken state. At this point, the only solution would be a bare-metal restore from a backup, installing a base OS and restoring websites manually from your own backup, or trying to fix your applications on the live server, which could result in a long period of downtime.

To be more specific, on Ubuntu servers, you should avoid running the do-release-upgrade command. On Debian servers, you should ensure that the /etc/apt/sources.list file contains a specific release codename, such as 'jessie' for Debian 8 or 'stretch' for Debian 9, rather than a generic codename such as 'stable' or 'oldstable'. Otherwise, you could find yourself inadvertently upgrading the server to a new release when one becomes available.

Whatever release of whatever distribution your server is running, you should be aware of the End Of Life (EOL) date for that release. After that date, the server will no longer receive any security updates, and will become a potential target for hackers looking to exploit newly-discovered vulnerabilities against which it will not be secured. You can find EOL dates for the various distributions at the following locations:


Well before the EOL date, you should start planning your upgrade to a new, supported release. Ideally, this should be done by building a brand new server, and migrating your data over to it. This way, you will have plenty of time to test the new server and fix any problems that might occur, while the old server is still online serving your users. Both Plesk and WHM include tools to ease the migration process, and we can also provide assistance if required.

Once you are happy that everything is working as expected on the new server, it can be made live by switching IP addresses or updating your domain names' DNS records, synchronising any changed data from the old server beforehand if necessary. The goal is to have the old server decommissioned before the EOL date, so that you are never in a position of having a server that isn't receiving security updates.

In certain cases, you may find yourself needing newer versions of software than those provided by your distribution, in order to take advantage of new features, but not wanting to upgrade your entire server. Your control panel may be able to help here. For example, newer versions of Plesk and WHM allow you to install several different versions of PHP simultaneously, and switch your sites between them quickly and easily. WHM also allows you to rebuild Apache and MySQL (or MariaDB) as required.

For other software, it may be possible to install a newer version from a 3rd-party repository, or build it manually from source. However, care must be taken when installing software in this manner, to ensure that it doesn't interfere with anything else on the server, that the software is coming from a trusted provider, and that security updates will be provided in a timely manner. If you are unsure, let us know your requirements, and we can advise accordingly.