How to Upgrade An Unsupported OS: An In-depth Checklist

Official vendor support for operating systems always has a limited window – nobody expects a vendor to support a minority of users indefinitely. It is accepted that a major version of an operating system (OS) is supported for roughly, say, ten years.

When the OS is end of life (EOL), official support stops. This means no security and maintenance patches, and no standard support options if something goes wrong. That is a risky position to be in, and users from consumers through to enterprises typically upgrade to a newer version in time. After all, users want the latest features too.

But for enterprise users an OS upgrade project is not something to be undertaken lightly and it is easy to underestimate what is truly involved.

In this guide we outline the risks of using an OS that is no longer supported and suggest key steps across three stages to ensure safe migration that does not risk operational continuity. We also point to some alternatives in case you are unable to proceed with an upgrade right now.

Content

• Understanding end-of-life – and the risks of not upgrading
• What does end of life mean in practice?
• What are the risks?
• A real and present danger
• Three-stage migration checklist
• 1: Preparing for migration
  • Test and test thoroughly
  • Select and communicate a maintenance window
  • Verify driver support
  • Assemble a trained team
• 2: Migration steps
  • Step one: initiate the maintenance window and backup
  • Step two: installing and configuring the new OS
  • Step three: install and configure specific software, restore your backups
• 3: Failback process
• Upgrade now – or buy some time
• Consider ELS from CloudLinux

Understanding end-of-life – and the risks of not upgrading

Any major piece of software, including operating systems, progresses with time. A major new release enters the market every few years – offering new features and capabilities, and users upgrade to take advantage of the new release. It is in the nature of technological progress.

Vendors will commit to maintaining older versions up to a point, giving users the time to migrate to a newer version. This support window often stretches into the past to cover a couple of software versions, and large vendors will publish roadmaps detailing when support will end. This happens in stages, with support tapering down until standard support channels are essentially closed.

What does end of life mean in practice?

Standard support includes two layers – first, the software vendor will commit to fixing any problems found after the software is released. These could be glitches in functionality, performance improvements or patches for security vulnerabilities.

Next, vendors will typically offer some type of support channel that users can utilize if they experience issues with the software that they purchased – whether it’s by email, chat or even an upgraded support experience.

In turn, vendors publish a support schedule. Full, comprehensive support covering every detail – including performance issues – may last for three years, for example. Some support elements may be removed over the coming years and, say, eight years after release, the vendor may only publish critical patches.

Eventually, all support stops, and the software is officially end of life.

What are the risks?

End of life software is static: the software vendor will no longer publish any changes to the software. At first glance this can appear to be a good thing – after all, many workloads require stable supporting operating systems. But unsupported, static software can lead to a range of problems:

• Security vulnerabilities. Software security is a fluid environment. For major operating systems in widespread use, it is almost guaranteed that new vulnerabilities will be found long after official support ended. However, with the vendor no longer releasing patches for new vulnerabilities, these security holes will persist – and users who have not upgraded can have significant vulnerabilities in their operations.
• An entry point. One error commonly made when deciding whether to upgrade an unsupported OS is assuming that it is running on a secondary or non-critical system, and therefore poses no real risks. In reality, a vulnerability in an unsupported OS can give attackers an opportunity to enter your networks – and to escalate an attack towards more valuable systems.
• Performance, reliability, and compatibility. An unsupported OS does not receive performance tweaks and enhancements and any emerging reliability issues will no longer be amended by the vendor. Similarly, unsupported software eventually requires expensive and poorly performing workarounds to maintain compatibility with the rest of the technology world that has inevitably moved on.
• Regulatory and compliance issues. The risks of running unsupported software are widely known, so much so that governments and agencies around the world use compliance frameworks to force organizations to use supported, patched software. Large enterprises are also accountable to a range of stakeholders, using unsupported software would demonstrate a lack of accountability.
• Blocking digital transformation. Where unsupported software is in widespread use it will eventually block technological progress inside your organization. Transformation will stall or move slowly as legacy, unsupported software obstructs the implementation of transformation programs.
• Frustrated clients and employees. Unsupported operating systems are also likely to offer an outdated feature set. By implication, clients will get frustrated by slow responses from your organization while your employees will suffer from low morale as tedious, unresponsive systems obstruct their work.

Clearly, the implications of relying on end-of-life OS versions can lead to a range of bottom-line implications – from a costly catastrophic security breach through to higher running costs and lower profits, and lower revenue growth.

A real and present danger

It is worth taking a moment and pausing. Most enterprises are highly dependent on technology to remain a viable business. When software such as an OS is no longer officially supported, there is essentially no-one to turn to when something goes wrong – and it can be challenging to find out whether it’s your unsupported operating system, or your application causing the problem.

Worse, your unsupported operating system could open the door to that security attack that ends up in the press – costing your organization substantially financially, and in terms of your reputation.

Either way, relying on unsupported operating systems puts your business at risk – and at serious risk.

Three-stage migration checklist

Migrating to a new operating system is clearly the best route, but often migration is postponed because of the perceived complexity of migration or uncertainty about the steps to take to minimize the risks of migration.

In other cases, migration leads to problems that could be avoided – from missed deadlines right through to costly service downtime. In this checklist we aim to cover the key steps your organization should take to maximize the probability to migrate successfully and to provide a path to recovery should you encounter hurdles when you migrate.

Many of the points below will apply to software migration in the broad, but we focus on OS migration. You might not need the third stage – failback, but you must plan as if it may be required.

1: Preparing for migration

Needless to say, preparation is key. This includes testing, finding a window to perform the migration – and ensuring that your organization has the necessary resources in place to perform the migration. We think these are the key steps in preparing for migration:

Test and test thoroughly

Before you attempt migration, you must test the ability to run your workloads on the new operating system inside of a test environment. In other words, set up the new operating system in a temporary environment and run your applications to see whether your configuration and dependencies execute flawlessly – before you try to push your configuration on a new OS into the production environment.

Testing should be your very first step. If you cannot verify that your workloads operate flawlessly on the new OS version inside of a test environment, you need to pause the migration process until any issues are resolved. It is not worth setting up migration windows and reserving resources until you have thoroughly road-tested your workload. If you skip or perform just simple basic tests without addressing the real workload on the system in a reproducible manner, the success of the whole upgrade will boil down to sheer luck rather than actual skill.

Select and communicate a maintenance window

Migration can be disruptive, and you need to communicate a maintenance window to all stakeholders to ensure sufficient time to migrate. As you determine the length of this window think about the following factors:

• backup time and time to copy data across
• live testing and giving important stakeholders the opportunity to test everything works as intended
• a buffer for overruns – for when something does not go to script, think of 10% to 15% at least

At the minimum, you need to account for time to rapidly recover your system from a backup or to re-install old hardware should something fail. We cover failback in more detail in a later section.

Verify driver support

In many instances your new OS will run on hardware that is already in place – and hardware that is older. But even when you install a new OS on new hardware you must double-check that driver support does not become an issue.

For example, ensure that the support agreement with your hardware vendor is in effect to ensure that you can receive vendor support if needed. You don’t want to get an unpleasant surprise that your support agreement has expired or has gone unpaid.

Old hardware running a new OS can trigger unexpected behavior as new functionality interferes with regular device operations. So again, test, test, test. For example, you may find that a virtualization layer interferes with direct hardware access or reduces the communication speed between devices.

Assemble a trained team

There are many moving parts in a migration process and problems can easily crop up. Make sure you have all the right experts on your side – from backup restoration through to integration and monitoring as well as a DB expert, a security expert and experts in both the OS you’re migrating to and the software that you run.

It is perfectly acceptable if some team members are off-site, as long as they can come online on a call if needed. Check your SLAs too and ensure your vendor’s support hours overlap with the maintenance window.

2: Migration steps

Before we discuss the migration process, a quick note about documentation. As you proceed through the following steps you must carefully document the steps taken and the outcome. Think of factors such as:

• anything you found that acted or performed unexpectedly
• incompatibilities that had to be mitigated
• any special or custom configurations to accommodate the migration

We suggest that you do this for two reasons. First, if any issues emerge later, you have a better chance of tracking down the root cause. Your documentation can also serve as a template for future, similar migration – reducing the friction when you repeat the process.

Step one: initiate the maintenance window and backup

With your team in place, you can initiate the maintenance window and start removing the system from active use. There are a few key steps you should take to smoothly go offline:

• stop user sessions, but aim to do so in a graceful manner
• where you can, disconnect the machine from the outside world by blocking traffic on your perimeter firewall
• stop running services in a sensible sequence – web server, DB server, file server etc.

Immediately after you have taken your system offline you should create a brand-new backup that captures your system in that state, and which ensures that unprotected changes are not made after you have taken the backup.

NB: it is critical that you test a restore of your backup at this point. It is an often-forgotten point, yet backup restoration is one of the most common points of failure. Test your backup before proceeding with the migration.

Step two: installing and configuring the new OS

It is now time to install the new OS. You should consider following the official upgrade path if it is available and appropriate, but in some cases you will need to do a fresh install – erasing the content on your machines first. It is worth taking the time to closely follow official documentation when you install your new OS as installation or upgrade steps are OS-specific.

Follow OS installation by adding third-party drivers where needed. Hardware testing right after the OS is installed is critical, most devices will have some type of testing feature.

Next, configure your OS for your requirements. Consider the following points:

• perform system-specific optimizations as required
• integrate with identity providers, authentication mechanisms and directory services where needed
• install monitoring tools including security services – it’s also a good time to make a security assessment
• configure local networking rules as well as your firewall

Step three: install and configure specific software, restore your backups

Your final step is to reinstall and configure the software that handles your workload. It may require specific integration, optimization, and customization steps.

It will require validation: involve your stakeholders and trained staff to ensure the software is running as expected; stakeholders use the software daily and will be able to spot failures more easily than a sysadmin. Next, perform a backup at this point in time so that you can fall back to it if you need to.

You can now end your maintenance window. Restart any service that did not start automatically, and re-open communication on your perimeter firewall if you need to do so.

3: Failback process

Hopefully your upgrade went smoothly, and everything is up and running. However, if you encountered any problems you need to ensure that you have a failback process in place.

Across the previous two stages you will have created and hopefully also tested a backup. Should the migration fail during the maintenance window you should waste no time in falling back to this backup that you create at the start of the process – restoring your system to a working state as soon as possible to:

• minimize the impact on users
• ensure that you do not breach compliance measures and upset stakeholders by overextending downtime
• get the opportunity to evaluate what went awry: repeating the test scenario, identifying the block and documenting a process to repair it

As a final note about failbacks, be aware that the fact that you de-synchronized the system before migration may mean that you need to take specific steps to re-integrate the system with other systems. This can be a concern particularly where significant time has elapsed between the backup and the restore. Domain controllers, for example, can get desynced in this process. Plan for this.

Upgrade now – or buy some time

If, after reading the above migration checklist, you come to the realization that planning for migration and performing migration will take some time, you may want to consider some alternatives to keep your systems safe while your structure your migration process.

One option is to ringfence your vulnerable systems through network zoning, or you could rely on sophisticated firewalls. Neither method is foolproof. Another option is to try and acquire extended lifecycle support (ELS) from the vendor – but this can vary from expensive to exorbitant, depending on the operating system you are using.

Consider Extended Lifecycle Support service from CloudLinux

As an alternative, Extended Lifecycle Support service from CloudLinux is significantly more affordable compared to vendor support. For a minimal monthly fee, you can buy extended support for one of several key Linux distributions – including CentOS and Ubuntu.Extended Lifecycle Support service from CloudLinux delivers critical security updates that ensure your end of life operating system is protected against security threats.

The only option you do not have is inaction. Simply continuing with an unsupported operating system places your enterprise workload at unacceptable risk. Plan for migration – or purchase the Extended Lifecycle Support now.

Get a FREE 7-Day Supported Trial of KernelCare