Ubuntu 16.04 end of life: upgrade or rebuild

Ubuntu 16.04 end of life: where a server stands now

Ubuntu 16.04 end of life is no longer a future date. Standard support ended in April 2021, and ESM (Expanded Security Maintenance) under Ubuntu Pro ended in spring 2026. A 16.04 VPS today gets no security patches from Canonical unless someone pays for the Legacy add-on. You have two real ways out: four release upgrades in a row, or a fresh 24.04 or 26.04 server with your data moved across. For most 16.04 servers the rebuild is the better choice, and this guide explains why.

The 16.04 dates, from Canonical's own pages

These are the dates that matter for a server running Ubuntu 16.04 LTS (long-term support), code name Xenial Xerus:

• Released on 21 April 2016.
• Standard security maintenance ended in April 2021.
• ESM under Ubuntu Pro ended in 2026. The 16.04 page on ubuntu.com says April 2026. The release cycle page and the ESM page say May 2026. Canonical's pages differ by one month, so do not plan around a specific day.
• The Legacy add-on covers years 10 to 15 of an LTS life cycle. For 16.04 that runs to April 2031 on the 16.04 page, or May 2031 on the release cycle page.

The 16.04 page states the current position directly: "Ubuntu 16.04 is out of ESM support. In order to get support, please activate the Legacy add-on." Legacy is sold as an add-on to an Ubuntu Pro subscription. You request it through Canonical's contact form. Canonical's 16.04 page does not list a price.

Free personal Ubuntu Pro is a separate thing. Canonical says Pro is "free for personal use on up to 5 physical machines", or 50 machines for official Ubuntu Community members. That page does not mention 16.04 at all. So do not assume a free Pro token still brings 16.04 patches. Check what your own server receives, as shown in the next section. For background on how Pro, ESM and the client fit together, read how Ubuntu Pro and ESM work on a server.

How to check what your 16.04 server receives today

Start with the release and the Pro client status:

lsb_release -a
pro status

lsb_release -a should print Release: 16.04 and a description such as Ubuntu 16.04.7 LTS. 16.04.7 is the last point release.

pro is the Ubuntu Pro client. The xenial updates pocket carries client version 37.1 (package ubuntu-advantage-tools, version 37.1ubuntu0~16.04.1), so a server that installed its updates this year has the pro command. If the shell cannot find pro, the client is old. The same tool used to be called ua, so ua status works on those servers. You can also install the current client:

sudo apt update
sudo apt install ubuntu-advantage-tools

Read the service lines in your own output. Look at the esm-infra line and at any line that mentions legacy. Older guides were written while ESM was still running, so their example output may not match a 16.04 server today. Then run pro security-status for a package-level view of the same question.

The most direct test is one package with a known fix. Canonical released a PHP fix for 16.04 on 21 October 2026, covered in its own section below. Check which PHP build you have:

dpkg -l 'php7.0*' | grep '^ii'

A version of 7.0.33-0ubuntu0.16.04.16 is the newest build in the public archive. A version ending in +esm22 is the Legacy fix. If you see the first one, this server is not receiving Canonical's current patches. To see the wider picture across every package, scan the server for known CVEs.

Is the Ubuntu 16.04 archive still online?

Yes. On 1 November 2026, xenial (16.04) and bionic (18.04) are still served from archive.ubuntu.com. They have not moved to old-releases.ubuntu.com, which lists neither of them. The Release files for xenial-updates and bionic-updates were regenerated on 1 November 2026. So a server that uses the official archive needs no change to its sources to install packages or to reach 18.04.

If your server uses a provider mirror instead, check what it points at:

grep -rh '^deb' /etc/apt/sources.list /etc/apt/sources.list.d/
sudo apt update

If apt update reports errors for that mirror, change those lines to http://archive.ubuntu.com/ubuntu and run it again.

The release upgrader reads a metadata file at changelogs.ubuntu.com/meta-release-lts. That file still lists Xenial 16.04.7 and Bionic 18.04.6 with Supported: 1, and it still points at the 16.04 upgrade tool on archive.ubuntu.com. So do-release-upgrade on 16.04 should still offer 18.04. This guide could not test the hop on a live 16.04 server, so treat that as the expected result, not a promise. Note also that the upgrader package on xenial (ubuntu-release-upgrader, version 1:16.04.32) was last updated on 16 October 2020. The first hop runs on a tool that has not changed in six years.

Path one: upgrade 16.04 one LTS release at a time

You cannot jump from 16.04 straight to a current release. Canonical's 16.04 page says: "There is no direct upgrade path from 16.04 LTS to Ubuntu 20.04 LTS/22.04 LTS/24.04 LTS/26.04 LTS." The Ubuntu Server documentation gives the rule behind it: you can only upgrade from one LTS release to the next one, and you cannot skip releases. So the path is four hops: 16.04 to 18.04, 18.04 to 20.04, 20.04 to 22.04, and 22.04 to 24.04.

Stopping half way does not help much. These are the dates from Canonical's release cycle page:

• 18.04: standard support ended May 2023. ESM runs to May 2028.
• 20.04: standard support ended May 2025. ESM runs to May 2030.
• 22.04: standard support runs to May 2027. ESM runs to May 2032.
• 24.04: standard support runs to May 2029. ESM runs to May 2034.

18.04 and 20.04 only receive security fixes through Ubuntu Pro. 22.04 leaves standard support in about six months. 24.04 is the first stop with years of standard support left. 26.04 LTS (released April 2026, standard support to May 2031) is a fifth hop from there.

Before every hop

Do these steps before each of the four upgrades, not only the first one.

1. Take a snapshot of the VPS from your provider's control panel. A snapshot is the fastest way back if a hop fails half way.
2. Copy your data off the server as well: database dumps, /etc, your application directories and every user's crontab. The Server documentation calls this "extremely important". A snapshot lives with the same provider, so it does not replace a real backup.
3. Remove or disable PPAs (personal package archives) and other third-party repositories. Re-add versions built for the new release after the hop.
4. If you run a hosting panel such as Plesk, check the panel vendor's list of supported operating systems first. The panel has its own support matrix, and a release in the middle of the chain may not be on it.

Then bring the current release fully up to date and reboot, so the upgrade starts from a clean state:

sudo apt update
sudo apt full-upgrade
sudo reboot

Run the upgrade

Install the upgrade tool and check which releases it is allowed to offer:

sudo apt install update-manager-core
grep Prompt /etc/update-manager/release-upgrades

The line should read Prompt=lts. If it says anything else, edit the file and set it to Prompt=lts. Then start the upgrade inside tmux, so a dropped SSH session does not kill it. Install it with sudo apt install tmux if it is missing.

tmux new -s upgrade
sudo do-release-upgrade

The upgrader asks before it replaces a configuration file you have changed. If you edited the file, keep your version and compare it with the new default after the hop. When it finishes, reboot and check the result:

lsb_release -a
pro status
systemctl --failed

lsb_release -a should now show Release: 18.04. systemctl --failed should list no failed units. Test your application now, before the next hop. A fault is easier to find when only one release has changed.

If do-release-upgrade prints No new release found, work through why do-release-upgrade finds no new release. If a hop stops part way and leaves the system half upgraded, read how to recover a failed Ubuntu release upgrade, or roll back to the snapshot. The later hops follow the same pattern, and the Ubuntu 20.04 end of life upgrade guide covers the 20.04 stage in more detail.

What changes under your application

Each hop replaces the PHP series. 16.04 ships PHP 7.0, 18.04 ships PHP 7.2, 20.04 ships PHP 7.4, and the later releases move on again. PHP settings live in a versioned directory such as /etc/php/7.0/, so a change you made there must be redone in the new version's directory. An application written for PHP 7.0 has to survive every one of those jumps.

Python changes too. 16.04 ships the Python 3.5 series. A Python virtual environment keeps its installed packages under a directory named after the interpreter version, so after the upgrade the new interpreter does not find them. Recreate each virtual environment on the new release.

Path two: rebuild on Ubuntu 24.04 or 26.04 and move the data

For most 16.04 servers, a fresh server is the better choice. These are the reasons:

• The application must move from PHP 7.0 to a current PHP in either path. On a new server you can do that porting work while the old server keeps serving.
• 16.04 runs the OpenSSL 1.0.2 series and the Python 3.5 series. Anything built against them, such as compiled modules and virtual environments, gets rebuilt in either path.
• Four hops means four chances to stop half way, and the first one runs on an upgrader last updated in 2020.
• Rollback is simple. The old server stays as it was, so if the new one has a problem you point DNS (domain name system) back at the old address.

Path one still makes sense for a small server that only uses packages from the Ubuntu archive, or one whose IP address you cannot change. For a longer comparison, read when to upgrade Ubuntu Server in place and when to reinstall.

Step 1: list what the old server runs

apt-mark showmanual > ~/manual-packages.txt
systemctl list-units --type=service --state=running > ~/services.txt
sudo ss -tlnp > ~/listening.txt
sudo crontab -l
ls /etc/cron.d

apt-mark showmanual lists the packages someone installed by hand. ss -tlnp lists every program that listens on a TCP port. Together they show what the new server needs. Check each user's crontab too, not only root's.

Step 2: build the new server

Order a new VPS with Ubuntu 24.04 or 26.04. Install each service from the new release's own packages. Do not copy old binaries or old package lists across. If the old server was a classic PHP site, start from a LAMP stack on Ubuntu 24.04 and add your configuration on top.

Step 3: move databases as dumps

Dump each application database to its own file. Do not use --all-databases, because that also copies the internal mysql system schema, and its layout changes between versions.

mysqldump -u root -p --single-transaction --routines --triggers appdb > appdb.sql
sudo -u postgres pg_dump -Fc appdb > appdb.dump

Use the first line for MySQL or MariaDB, and the second for PostgreSQL. On the new server, create the empty database first. Then restore with mysql -u root -p appdb < appdb.sql, or with pg_restore -d appdb appdb.dump run as the postgres user.

Step 4: copy files and switch over

Copy application files with rsync. The address below is an example. Use your new server's address:

sudo rsync -aH -e ssh /srv/app/ admin@203.0.113.20:/home/admin/app/

Lower the TTL (time to live) on your DNS records a day before the switch, so the change spreads quickly. Test the new server first by adding its address to the hosts file on your own computer. Then update DNS. Issue new TLS (transport layer security) certificates on the new server rather than copying the old ones. Keep the old server for a few days in case you missed something, but close its public ports, because it is still unpatched. The full procedure is in how to migrate a server to a new VPS.

Here because of PHP2Shell?

On 21 October 2026 Canonical published USN-8948-2 (an Ubuntu Security Notice) for PHP on 20.04, 18.04, 16.04 and 14.04. It says PHP "could be made to crash or run programs if it received specially crafted network traffic." One of the CVEs (Common Vulnerabilities and Exposures entries) it fixes, CVE-2026-109618, is rated Critical with a CVSS 3 (Common Vulnerability Scoring System) score of 9.8. Canonical describes it as a remote code execution bug.

For 16.04, the fixed package is php7.0 version 7.0.33-0ubuntu0.16.04.16+esm22. The notice says: "Fix available with Ubuntu Pro via Legacy Support add-on." The newest build in the public archive is 7.0.33-0ubuntu0.16.04.16, without the +esm22. So a 16.04 server without Legacy gets no Ubuntu fix for this bug. The dpkg check earlier in this guide tells you which build you have.

For 18.04 (php7.2, 7.2.24-0ubuntu0.18.04.17+esm14) and 20.04 (php7.4, 7.4.3-4ubuntu2.29+esm5), the fix is listed under Ubuntu Pro, without the Legacy wording. That matters if you plan to stop at one of those releases.

You may find third-party repositories that offer newer PHP builds for 16.04. Such a build is not an Ubuntu patch. Someone else builds and signs it, apt installs it as root, and it is updated on that person's schedule. Adding it is a trust decision, and it fixes PHP only. Every other package on the server, OpenSSL and the kernel included, stays unpatched. If you cannot buy Legacy, the safe fix for this bug is the same as for the whole server: move the site to a supported release.

FAQ

Is Ubuntu 16.04 still getting security updates?

Only through Canonical's paid Legacy add-on. Standard support ended in April 2021, and ESM under Ubuntu Pro ended in spring 2026 (Canonical's pages say April or May 2026). Canonical's 16.04 page says "Ubuntu 16.04 is out of ESM support" and tells users to activate the Legacy add-on, which runs to 2031. Run pro status on your server to see which services it actually has.

Can I upgrade Ubuntu 16.04 directly to 24.04?

No. Canonical states there is no direct upgrade path from 16.04 to 20.04, 22.04, 24.04 or 26.04. You must go one LTS at a time: 16.04 to 18.04, then 20.04, then 22.04, then 24.04, with a snapshot and a backup before each hop. For most servers, a fresh 24.04 or 26.04 install with the data moved across is less work and easier to roll back.

Are the Ubuntu 16.04 repositories still online?

Yes, as of 1 November 2026. Xenial (16.04) and bionic (18.04) are still on archive.ubuntu.com, not on old-releases.ubuntu.com, and their update indexes were regenerated that day. A server that uses the official archive needs no change to its sources to install packages or to start the upgrade to 18.04.

Does free Ubuntu Pro cover a 16.04 server?

Do not assume it does. The free personal subscription covers up to 5 physical machines, but its page does not mention 16.04. Canonical's 16.04 page says support now needs the Legacy add-on, which is an add-on to an Ubuntu Pro subscription that you request through Canonical's contact form. Check the service lines in pro status, and check whether dpkg -l 'php7.0*' shows a version ending in +esm22.

Why does the PHP fix not install on my 16.04 server?

The 16.04 fix for USN-8948-2 is php7.0 version 7.0.33-0ubuntu0.16.04.16+esm22, and Canonical publishes it only through the Legacy Support add-on. Without Legacy, apt sees 7.0.33-0ubuntu0.16.04.16 as the newest version, so apt upgrade has nothing to install. The lasting fix is to move the site to Ubuntu 24.04 or 26.04.