Old Ubuntu on your server: moving to a new LTS

The server runs, the site loads, nobody complains. But when the login banner tells you that standard support for your release has ended, it does not mean everything is fine. It means security fixes have stopped arriving.

Each Ubuntu LTS release gets five years of standard support. During that time, security updates simply flow in. After that, support can be partially extended (Ubuntu Pro / ESM), but that buys time — it is not a plan. Sooner or later the server has to move to a newer LTS.

Below: the options you have, which one I recommend in which situation, and what to check before you touch anything.

What an unsupported release actually means

The server does not stop working on the day support ends. The trouble arrives quietly:

• Vulnerabilities stay unpatched. When a flaw is found in OpenSSL, SSH or the kernel, no fix reaches your machine. A publicly known vulnerability on an unpatched server is exactly what automated scanners look for.
• New software will not install. The next version of your application needs a newer PHP, Python or library than the old release ships.
• The problem grows with time. One LTS step is routine. Three steps behind is a project.

Two paths: upgrade in place or build a new server

In-place upgrade (do-release-upgrade)

Ubuntu's own tool moves the system to the next LTS. One important limit: one LTS step at a time — for example 22.04 → 24.04 → 26.04. You cannot skip a release. The LTS-to-LTS upgrade is usually offered only after the new release's first point release.

Fits when the server is in reasonable shape, you are one step behind, the configuration is known and there are few applications.

Risks: if something breaks halfway, the server is left half-upgraded. Third-party repositories (PPAs) are disabled during the upgrade and have to be re-enabled by hand. With several steps, each one has to be run and tested separately.

A new server on Ubuntu 26.04, then migrate

A fresh machine is set up cleanly, applications and data are moved across, and the old server keeps running until the new one is verified.

Fits when you are several releases behind, years of undocumented changes have piled up, or you were planning to change hosting or hardware anyway.

Advantage: there is always a way back. I install new servers on Ubuntu 26.04, and it is a good moment to finally document the setup. The migration itself is described step by step in server migration without downtime.

My rule of thumb: one LTS step and a tidy server → upgrade in place. Two or more steps, or "nobody quite knows what runs on it" → new server.

Checklist before upgrading

1. A full backup or snapshot

Before anything else: a snapshot of the whole server (if your host offers it) and separate database dumps and a file copy. Then check that you can actually restore from it. A backup nobody has ever restored is a hope, not a plan.

2. Rehearse on a clone

Copy the server and run the upgrade there first. You see what breaks without taking the real site down. This is the single most valuable step on the list.

3. Language and database version jumps

This is where things break most often. A new Ubuntu brings a new PHP, Python, PostgreSQL or MySQL/MariaDB:

• old PHP code using removed functions starts throwing errors;
• a Python application's virtual environment has to be rebuilt on the new Python;
• a new PostgreSQL major version needs the data moved from the old cluster to the new one;
• defaults change between MySQL and MariaDB, and between their versions.

Find out which versions you run today and what your application supports.

4. Configuration file differences

If a config file was edited by hand, the upgrade asks whether to keep yours or take the package's new one. The wrong answer can wipe years of tuning — or keep an old file that no longer works with the new version. Copy /etc beforehand so you have something to compare against.

5. Third-party repositories

PPAs and vendor repositories (for example for a database, Docker or Elasticsearch) do not upgrade along with the system. List them, check that a version for the new Ubuntu exists, and set them up again afterwards.

6. Plan the downtime

An in-place upgrade means a stretch where services restart. Pick a quiet time, tell your users, and run the upgrade inside tmux or screen so a dropped SSH connection does not leave it half-finished.

7. A rollback plan

Write down before you start: at what point you decide it has gone wrong, and what you do then. Restore the snapshot, point DNS back at the old server — whatever it is, it must be decided beforehand, not in the middle of the night.

After the upgrade

Check logs, service status, certificate renewal, scheduled jobs (cron), backups and outgoing email. Then review security settings — a new system is a good moment to tidy them up. There is a separate Linux server security checklist for that.

If you would rather hand it over

I manage Linux servers day to day — Ubuntu by preference, but also Debian and the RHEL family — together with Nginx, Apache2, PostgreSQL, MySQL/MariaDB, Docker, Tomcat and Elasticsearch/OpenSearch. I have also moved applications more than ten years old onto current versions while keeping their business functionality intact. See Linux server management for details.

If your server is on an old Ubuntu and you are not sure which path fits, write to me. Describe your situation in a couple of sentences here — which Ubuntu release, what runs on the server — and I will reply within one working day and tell you honestly whether and how I can help. If you prefer a general form, use the contact page.

Frequently asked questions

Can I skip several releases at once?

Not with an in-place upgrade — each LTS step has to be done separately. With several steps, a new server plus migration is often faster and safer.

Does Ubuntu Pro / ESM solve the problem?

It extends security updates for part of the packages and buys time. But your language and database versions stay old, so the upgrade still has to happen — just later.

Will the site be down during the upgrade?

An in-place upgrade involves a short, unavoidable interruption. With a new server and a migration, downtime can be kept minimal because the old server runs until the switchover.