Ubuntu 20.04 end of life: your upgrade path

Is Ubuntu 20.04 end of life?

Ubuntu 20.04 end of life for standard support came on 31 May 2025, according to Canonical. Security updates continue only through ESM (Expanded Security Maintenance), which comes with Ubuntu Pro and runs until May 2030. If your VPS (virtual private server) still runs 20.04, codename focal, you have two real choices. You can attach Ubuntu Pro and keep receiving patches, or you can upgrade to a newer LTS (long-term support) release.

This guide sets out the dates, what each path costs you, and the checks to run before you trust either one. Every command here runs on your own server. A release upgrade and a Pro attach both need network access to Canonical's servers, so plan a maintenance window and take a snapshot first.

The Ubuntu 20.04 support dates, from Canonical

Canonical's release-cycle page is the source for every date below. As of October 2026, it lists these dates for the releases that matter to a focal server:

• 20.04 LTS: standard security maintenance ended May 2025. ESM through Ubuntu Pro ends May 2030. The Legacy add-on ends May 2035.
• 22.04 LTS: standard support ends May 2027. ESM ends May 2032. Legacy ends May 2037.
• 24.04 LTS: standard support ends May 2029. ESM ends May 2034. Legacy ends May 2039.
• 26.04 LTS: released April 2026. Standard support ends May 2031. ESM ends May 2036. Legacy ends May 2041.

Canonical's 20.04 page gives the exact day: "Reached end of standard support on 31 May 2025". The same page says that with Ubuntu Pro, 20.04 "will be fully supported until 2030".

Why some sources say 2032 and others say 2035

You will find two different end dates for the 20.04 Legacy add-on. The difference comes from a change in Canonical's policy.

In March 2024, Canonical announced the Legacy add-on as two extra years after ESM, for 12 years in total. That post does not name 20.04 or 2032. The 2032 figure is arithmetic: April 2020 plus 12 years. In November 2025, Canonical extended the add-on to 15 years in total. The release-cycle page now shows May 2035 for 20.04, and the kernel lifecycle page shows the same date. So 2035 is the current answer. The 2032 figure belongs to the older 12-year model.

The release-cycle page describes the add-on this way: "At the end of the 10 year ESM period, the Legacy add-on can be purchased to cover additional 5 years of the lifetime of Ubuntu LTS". It is a paid extension. The pricing page says a subscription with Legacy "is 50% more".

Check what your server is running

Start with the facts about your own machine. You need the release, the running kernel, and the current Pro state.

cat /etc/os-release
uname -r
pro status

/etc/os-release should show VERSION_CODENAME=focal on a 20.04 server. uname -r prints the kernel that is running now. A version starting with 5.4 is the 20.04 GA (general availability) kernel. A version starting with 5.15 is the 20.04 HWE (hardware enablement) kernel. pro status reports which Ubuntu Pro services are active. If ESM is not active, your focal packages have received no security updates since standard support ended in May 2025.

Option 1: attach Ubuntu Pro to keep receiving patches

Attaching Ubuntu Pro turns on ESM. Your server stays on 20.04, and Canonical keeps shipping security fixes to it until May 2030. Pro does not move you to a newer release. Your PHP, Python and OpenSSL versions stay the same. For a full description of what the subscription changes on a server, read Ubuntu Pro on a server, explained.

Is Ubuntu Pro free for a VPS?

Check the terms before you rely on the free tier. The Ubuntu Pro page says Pro "is and always will be free for personal use on up to 5 physical machines", or 50 machines for official Ubuntu community members. The Pro documentation uses different words: free "for personal and small-scale commercial use on up to 5 machines". The two pages do not agree on the word "physical". Neither page says whether a rented VPS counts. Read the current terms at ubuntu.com/pro and decide for your own case. For paid plans, read the pricing page directly, because the right tier for a single VPS depends on how you use it.

Attach the server

The current Pro client starts a browser code flow when you run attach with no token:

sudo pro attach

The terminal prints a link and a code. Open ubuntu.com/pro/attach, enter the code, and choose a subscription. The Pro client documentation says that by default "the Free Personal Token will be selected". You can also pass a token directly. The pro manual page describes the token as one "obtained from: https://ubuntu.com/pro/dashboard".

sudo pro attach YOUR_TOKEN
pro status

pro status should now report the ESM services as enabled. The manual page quoted here is from the 24.04 release of the client. If your focal machine rejects an option, run pro attach --help and use the syntax it prints.

Attach Pro from cloud-init user-data

If you build focal servers from user-data, the key that attaches Pro depends on the cloud-init version inside the image. This is the part people get wrong, so check the version first.

cloud-init --version

The current cloud-init module docs use ubuntu_pro, with the token under token:

#cloud-config
ubuntu_pro:
  token: <your-token>

Older cloud-init only knows the old key. In cloud-init 23.1.2, the module was named ubuntu_advantage and accepted ubuntu_advantage or ubuntu-advantage:

#cloud-config
ubuntu_advantage:
  token: <your-token>

cloud-init 24.1 deprecated the old keys in favour of ubuntu_pro. Version 24.4.1 still accepts the old keys, but marks them as deprecated. Launchpad lists three focal versions: 20.1 in the release pocket, 23.1.2 in focal-security, and 24.4.1 in focal-updates. An image that was never updated runs an old cloud-init at first boot. Upgrading cloud-init later does not change what already ran at first boot, so the version installed in the image decides which key works. Use ubuntu_advantage on 23.x and ubuntu_pro on 24.1 or later. For any older version, read the docs for that exact release. Then confirm the result after boot:

pro status
sudo grep -i -E 'ubuntu_pro|ubuntu_advantage|ubuntu-advantage' /var/log/cloud-init.log

If pro status shows ESM as not enabled, the key or the token did not take effect. pro status is the check that matters. A clean user-data file proves nothing on its own.

Option 2: upgrade from 20.04, one LTS at a time

do-release-upgrade cannot skip an LTS. The Ubuntu Server upgrade docs say it plainly: "You can only upgrade from one LTS release directly to the next sequential LTS release." So the path from focal is two upgrades: 20.04 to 22.04, then 22.04 to 24.04. The upgrader also offers an LTS-to-LTS upgrade only after the target's first point release.

Why stopping at 22.04 gains you little

Standard support for 22.04 ends in May 2027. From October 2026, that is about seven months away. You would do the hard work of one release upgrade and then face the same decision again next spring. Plan for 24.04 as the minimum target. Its standard support runs to May 2029.

Before you start

Canonical's upgrade docs say: "It is extremely important that the data is safely copied to a backup location to allow restoration if any problems occur." On a VPS, take a provider snapshot. The upgrader also disables third-party repositories and PPAs (personal package archives) during the upgrade. Software from those sources may stop updating until you enable them again.

Run the upgrade inside tmux. A release upgrade can take a long time, and a dropped SSH connection should not leave it in an unknown state. First bring focal fully up to date and reboot into the result:

sudo apt update
sudo apt full-upgrade
sudo reboot

Then start the first upgrade:

tmux new -s upgrade
sudo do-release-upgrade

Read each prompt before you answer it, and reboot when the upgrader asks. The upgrade docs say "The system is not considered upgraded until this reboot occurs." After the reboot, cat /etc/os-release should show VERSION_CODENAME=jammy. Run the same steps again to reach noble, which is 24.04.

If the upgrader says there is no new release, read why do-release-upgrade reports no new release before you change anything. If an upgrade stops halfway, do not reboot without a plan. Follow how to recover a failed Ubuntu release upgrade.

What happens to the 5.4 kernel during the upgrade?

The 20.04 GA kernel is 5.4, and its HWE kernel is 5.15. On 22.04, the GA kernel is 5.15 and the HWE kernel is 6.8. If you held or pinned the 5.4 kernel, you need to know what the upgrader does with it. No Canonical document that we found answers that directly.

The upgrader source gives partial evidence. In DistUpgradeQuirks.py, the upgrader records the kernel metapackage, skips removing it, and reinstalls it after the upgrade if it went missing. That protects the metapackage. It does not tell you which kernel image you will boot. So treat this as something to check, not something to assume. Run these commands before the upgrade. Run them again after the upgrade, but before you reboot into it:

uname -r
dpkg -l 'linux-image*' | grep '^ii'
apt-mark showhold

After the first upgrade, you want to see a 5.15 kernel image installed, alongside a kernel metapackage such as linux-generic or your provider's own kernel package. If only 5.4 images are listed, do not reboot yet. Work out why first. To control which kernel the bootloader picks, read how to pin which kernel boots on a VPS. For the trade between the two kernel lines, read HWE vs GA kernels on Ubuntu Server.

Does an apt pin survive a release upgrade?

No primary source we could find settles this either. Apt pins live in /etc/apt/preferences and in files under /etc/apt/preferences.d/. The apt_preferences manual shows that a pin can match a release by codename, for example Pin: release n=trixie. A pin written as n=focal may stop matching once your sources point at jammy. That is a reasonable reading, but we have not confirmed it. Verify it on your own server.

Record the pin state before the upgrade. The second file may not exist, and that is fine.

ls -l /etc/apt/preferences.d/
cat /etc/apt/preferences
apt-cache policy

Save the output to a file. After each upgrade, run the same commands and compare. For any package you care about, apt-cache policy <package> shows its installed version, its candidate version, and the priority each source gets. If the candidate is not the version you expected, your pin is no longer doing its job.

Go on to 26.04, or rebuild?

24.04 is a reasonable place to stop, but 26.04 gives you two more years of standard support. The path from 22.04 through 24.04 to 26.04 is covered step by step in how to upgrade Ubuntu 22.04 to 26.04 via 24.04.

A focal server that has run since 2020 often carries years of manual changes. Three release upgrades in a row carry all of those changes forward. A fresh 24.04 or 26.04 server, with your data and config moved across, is often the cleaner result. Upgrade Ubuntu in place or reinstall sets out how to decide.

Which Ubuntu 20.04 upgrade path fits your server?

• Attach Pro when an application depends on focal's library versions and you cannot test a new release yet. Pro gives you patches while you plan.
• Upgrade in place when the server is simple, well documented, and backed up. Go to 24.04 at least.
• Rebuild when the server has drifted and nobody remembers every change. Move the data to a fresh LTS server.
• Combine them when you need time. Attach Pro now, then upgrade or rebuild on your own schedule before May 2030.

Doing nothing is not on the list. A focal server without ESM has received no security updates since May 2025.

FAQ

Is Ubuntu 20.04 still getting security updates?

Only through ESM, which needs Ubuntu Pro. Standard support ended on 31 May 2025. With Pro attached, Canonical's release-cycle page lists ESM for 20.04 until May 2030, and the paid Legacy add-on until May 2035. Run pro status to see whether ESM is enabled on your server.

Can I upgrade directly from Ubuntu 20.04 to 24.04?

No. Canonical's server docs say you can only upgrade from one LTS release to the next sequential LTS release. Run do-release-upgrade twice: 20.04 to 22.04, reboot, then 22.04 to 24.04. Take a snapshot before each step. If you want a clean 24.04 or 26.04 server instead, install it fresh and move your data across.

Is the free Ubuntu Pro subscription allowed on a VPS?

The terms do not say clearly. The Ubuntu Pro page says it is free for personal use on up to 5 physical machines. The Pro docs say up to 5 machines for personal and small-scale commercial use. Neither page says whether a rented VPS counts. Read the current terms at ubuntu.com/pro before you depend on it.

Which cloud-init key attaches Ubuntu Pro from user-data?

It depends on the cloud-init version in the image. Current cloud-init, from version 24.1, uses ubuntu_pro with a token field. cloud-init 23.1.2, the version in focal-security, only knows ubuntu_advantage and ubuntu-advantage. Run cloud-init --version on the image, use the matching key, and confirm with pro status after first boot.

Should I stop at Ubuntu 22.04?

Usually not. Standard support for 22.04 ends in May 2027, so you would face the same decision again within months. Continue to 24.04, which has standard support until May 2029, or to 26.04, which has standard support until May 2031.