Ubuntu 20.04 and RHEL 7 end of life: what to move to and how

Two of the most common Linux releases in production have passed the end of their standard support. RHEL 7 left maintenance in June 2024. Ubuntu 20.04 left standard support in May 2025. Both are still patched if you pay for it, and plenty of estates are doing exactly that while they decide what comes next.

This post sets out the dates as the vendors publish them, what extended support does and does not buy, which release to move each one to, and the two ways to get there.

The dates, from the vendors

Ubuntu 20.04 LTS, from Canonical's release cycle page:

• Released April 2020.
• Standard security maintenance ended May 2025.
• Expanded Security Maintenance (ESM), with an Ubuntu Pro subscription, runs to May 2030.
• The Legacy add-on extends that to May 2035.

Red Hat Enterprise Linux 7, from Red Hat's RHEL 7 end-of-maintenance page:

• Maintenance Support 2 ended June 30, 2024.
• Extended Life Cycle Support (ELS), a paid add-on, runs to May 31, 2029. Red Hat first announced four years of ELS, to mid-2028, and has since extended it by a year.

Vendors change these dates now and then, as Red Hat did with ELS, so check the vendor's page again before you commit a plan to them.

What extended support buys, and what it doesn't

ESM and ELS keep security fixes coming for the release you already run. That is worth a lot: it turns a hard deadline into a budget line, and it keeps you out of the audit finding for running an unpatched operating system.

It does not change anything else. You stay on the same kernel line, the same compilers and runtimes, and the same versions of PostgreSQL, Python and OpenSSL your applications were built against. New software increasingly needs newer libraries than the old release has. You pay per host for the time. And the date still arrives, only later, by which point the gap to a current release is wider.

Extended support is a good way to make room for a migration. It is a poor substitute for one.

Where to move Ubuntu 20.04

• Ubuntu 22.04 ends standard support in May 2027. Moving there now buys about six months before you are back in the same position.
• Ubuntu 24.04 has standard support to May 2029 and ESM to May 2034. It has been out for two and a half years, and it is where most fleets moving now should land.
• Ubuntu 26.04, released April 2026, has standard support to May 2031. It gives you the longest runway, at the cost of being newer: check that the vendors of the software you run support it before you standardize on it.

For most fleets the practical answer is 24.04. Nearly every package keeps its name between 20.04 and 24.04; the work is in the versions. PostgreSQL goes from 12 to 16 and MariaDB from 10.3 to 10.11, and their data directories have to be moved, not just reinstalled. The Ubuntu 20.04 to 24.04 guide covers what changes for that move.

Where to move RHEL 7

• RHEL 8 leaves maintenance on May 31, 2029, the same day RHEL 7's ELS ends. Moving to 8 now buys no time over paying for ELS, so treat it as a stop on the way, not a destination.
• RHEL 9 has full support to May 31, 2027 and maintenance support to May 31, 2032. It has been out since May 2022, so the software you run has had time to support it.
• RHEL 10, generally available since May 20, 2025, has maintenance support to May 31, 2035. It is the longest runway, with the same caveat as Ubuntu 26.04: confirm the software you run supports it.

For most RHEL 7 estates, RHEL 9 is the target. You keep your subscriptions; only the hosts are new. The jump is big enough to plan for: ntp becomes chrony, authconfig becomes authselect, network.service is replaced by NetworkManager, Java 8 applications meet OpenJDK 17, and PostgreSQL goes from 9.2 to a current release. The RHEL 7 to RHEL 9 guide covers what changes for that move.

What usually decides the timeline

The operating system is rarely the slow part. Three things are:

• Databases. Every move above crosses at least one major version of PostgreSQL or MariaDB. The data has to be dumped and restored, or upgraded with pg_upgrade, with the database stopped, so each database needs a window and a tested procedure.
• Language runtimes. Java 8 applications, Python 2 scripts and code pinned to the old release's Python 3 all need an answer before the new server can run them. Some of those answers come from a vendor, and vendors take time.
• Agents. Backup, monitoring, endpoint security and log shipping agents each need a version for the new release, and a server that moves without them quietly drops out of your controls.

Start these conversations first. The rebuild itself is the quick part.

How to get there: upgrade in place, or rebuild

In place. Both vendors upgrade one release at a time. On Ubuntu, do-release-upgrade moves from one LTS to the next, so 20.04 to 24.04 means going through 22.04 first: two upgrades, and two rounds of prompts about changed configuration files. On RHEL, Red Hat's Leapp tool upgrades RHEL 7.9 to RHEL 8.10, and then a second Leapp run takes the host to RHEL 9. Each run has its own pre-upgrade report and inhibitors to clear. Either way, the work happens on the production machine, and the way back is a restore from backup.

Rebuild. Read what the old server does, write that down as a plan, build a fresh server on the new release from the plan, check it against the old one, and switch traffic over. It is one step regardless of how many releases you are crossing. The old server is untouched, so it is your rollback, and the new server carries only what you decided to carry, not years of leftovers.

In place can be the quickest route for a plain host close to the vendor defaults. For servers with local changes, third-party repositories and software that nobody fully remembers, the rebuild is usually less work and much less risk. We wrote up what goes wrong with Leapp and ELevate on CentOS 7, and most of it applies to RHEL 7 too.

A plan for the estate

• Inventory. List every host on the two releases, with its role and owner. You will find some nobody claims.
• Group by role. Web servers, database hosts and batch servers each migrate in their own way. Plan per group, not per host.
• Pick the target per group and confirm the software vendors support it.
• Pilot one host per group. The first rebuild of each kind finds the decisions the rest of the group will need.
• Buy extended support only for the hosts that will not make it in time, not for the whole fleet by default.
• Decommission properly. Retire the old host after the new one has been checked, and take it out of inventory, monitoring and DNS.

Where vrtmv fits

vrtmv does the reading, the planning and the checking for a rebuild. It reads the old server over SSH without an agent, or from a copy of its disk, and changes nothing on it. The Index translates its packages, services and settings to the target release, and the plan lists every change, with the decisions it will not guess at on a punch list for you. It generates an Ansible role (or Terraform) to build the new server. After the rebuild, vrtmv verify checks the new server against the plan, from its package database and the carried configuration paths, writes a parity report, and exits non-zero on any gap, so the cutover can wait on it.

It never uploads your data, and copying it is a step you start: vrtmv data plan writes the copy runbook, with a sha256 manifest of the source's files, and vrtmv run --copy copies the paths you name. It does not test your application; that stays in your runbook. Supported distributions and major versions are on the supported page, and your exact source and target are confirmed in scoping.