Ubuntu LTS upgrade — moving from one LTS to the next, safely

Ubuntu LTS releases every two years (20.04, 22.04, 24.04, 26.04 ...). When an LTS approaches end-of-standard-support (5 years from release), you have to either upgrade to the next LTS or move to Ubuntu Pro for extended support. This article walks the upgrade process, the things that bite people, and the safety net pattern LYLIX customers should always use.

Before you upgrade — the safety net

The single most important thing: take a snapshot first. LTS upgrades touch hundreds of packages and config files; even on a clean system, something can go sideways. A snapshot is your one-click reversion.

1. Customer portal → your service → Snapshots tab.
2. Name it before_ubuntu_upgrade, descriptive note.
3. Create Snapshot.

If anything goes wrong during or after the upgrade, you click Rollback and you're back. See snapshots article for details.

Prerequisites

• Fully updated current release:

  apt update && apt full-upgrade -y
  reboot   # if kernel was updated

• At least 2 GB free on the root filesystem. The upgrade downloads new packages before installing. Check with df -h /.
• A working snapshot (see above).
• Off-host backup of anything irreplaceable. Snapshots protect against in-host issues; off-host protects against the rest.

Running do-release-upgrade

Ubuntu provides do-release-upgrade, the official upgrade tool. It handles repo changes, package conflicts, and configuration-file merges.

# Install if missing:
apt install -y ubuntu-release-upgrader-core

# Run the upgrade:
do-release-upgrade

The tool walks you through:

1. Confirms the target release.
2. Updates the package list to the new release.
3. Calculates the upgrade (packages to install, remove, hold).
4. Asks you to confirm.
5. Downloads packages.
6. Installs and configures.
7. Prompts to reboot.

The full process takes 20-60 minutes depending on what's installed. Use screen or tmux so the upgrade survives if your SSH connection drops — losing your shell mid-upgrade leaves the system in a weird half-state.

screen -S upgrade
do-release-upgrade
# detach with Ctrl-A then D; reattach with screen -r upgrade

The configuration-file prompts

During the upgrade you'll see prompts like:

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation

The right answer depends on the file. General guidance:

• Keep yours (N) if you've customized the file and the maintainer's defaults would lose your changes. SSH config, nginx config, anything you've deliberately edited.
• Take the new (Y) if you haven't touched the file and the maintainer's update adds something useful (new config defaults, deprecation removals).
• Show diff (D) when you're not sure. Quick diff tells you what's actually different; usually obvious whether the changes matter.
• Shell (Z) if you need to inspect more than a diff. You drop to a shell while the upgrade waits; exit resumes.

After the upgrade

1. Reboot when the upgrader prompts. The new kernel won't be active otherwise.
2. Reconnect over SSH after the reboot completes (~30 seconds for a small VPS).
3. Verify the release:

   lsb_release -a

4. Check critical services started:

   systemctl --failed
   systemctl status nginx postgresql ...   # whatever you care about

5. Test from outside — actually hit your website, send a test email, log in to your application. Some breaks only show externally.
6. Clean up obsolete packages:

   apt autoremove --purge -y

If something broke

The snapshot is right there. Rollback is one click and a 30-second wait.

If you'd rather try to fix forward (the issue is contained, you're close to a solution), common patterns:

• Service won't start: check journalctl -u <service> for the actual error. Config-file format changes between LTS releases are common.
• "Package X has unmet dependencies": leftover from a third-party repo that hasn't been updated for the new release. Either find the new repo URL or remove the package.
• Boot fails entirely: rescue mode (see the rescue article). Boot the rescue ISO, mount root, chroot in, fix.

The PHP / Python / Node version trap

Each LTS bundles specific major versions of common languages:

• Ubuntu 22.04 → PHP 8.1, Python 3.10, Node 12
• Ubuntu 24.04 → PHP 8.3, Python 3.12, Node 18

If your application is pinned to a specific version (say, PHP 8.1), the upgrade will move it to the newer one and your application might break on deprecated functions. Either:

• Test against the new version on a staging snapshot first.
• Install the specific older version from ppa:ondrej/php (or the equivalent) and pin to it post-upgrade.
• Defer the upgrade until your application supports the new version.

Skipping LTS versions

Ubuntu's official upgrade path is LTS-to-LTS (24.04 → 26.04). You cannot skip LTSes (22.04 → 26.04 won't work directly). To go from 22.04 to 26.04, upgrade 22.04 → 24.04 first, verify everything works, then upgrade 24.04 → 26.04.

Each upgrade takes the same hour or so, but they're sequential. If you have a multi-LTS gap to close, schedule a half day.

Cleanup of obsolete snapshots

Once the upgrade has been running successfully for a week or two, delete the pre-upgrade snapshot to free the slot:

1. Customer portal → Snapshots tab.
2. Find the pre-upgrade entry.
3. Click Delete, confirm.

Don't keep upgrade snapshots forever — they cost storage and the rollback window for "this didn't work" closes after a few weeks anyway (too much divergence to safely revert).