How to Safely Upgrade Ubuntu Server to the Next LTS Version

ubuntu-lts-to-lts-upgrades-matter-for-production-servers">Why Ubuntu LTS-to-LTS Upgrades Matter for Production Servers

Ubuntu LTS (Long Term Support) releases receive security updates and bug fixes for five years from their release date through Canonical’s standard support. After that window closes, the OS stops receiving security patches. Running an end-of-life Ubuntu version on a production server is not just a best-practice violation — it is a concrete security liability. You are one unpatched CVE away from a serious incident, and you will have no vendor path to remediation.

Beyond security, major LTS upgrades bring newer versions of the entire software stack: PHP, Python, MySQL, OpenSSL, glibc, and the Linux kernel itself. Applications that require newer language features, performance improvements, or security library versions can only access them through an OS upgrade. Ubuntu 22.04 ships with Python 3.10 and PHP 8.1. Ubuntu 24.04 ships with Python 3.12 and PHP 8.3. These are meaningful differences for most application stacks.

This guide covers the full process for upgrading from Ubuntu 22.04 LTS (Jammy Jellyfish) to Ubuntu 24.04 LTS (Noble Numbat), but the steps apply to any adjacent Ubuntu LTS pair. The upgrade can be performed on a live, running server — but only if you prepare correctly and follow the process carefully.

The Pre-Upgrade Checklist: Do Not Skip This

An in-place OS upgrade is the riskiest maintenance operation you will perform on a production server. Upgrades interact with every installed package, every configuration file, every running service. The difference between a smooth upgrade and a broken system is almost entirely preparation. Block out time to go through this checklist completely before touching do-release-upgrade.

1. Take a Full Backup or Snapshot — This Is Non-Negotiable

If you are on a cloud provider (AWS, Azure, GCP, DigitalOcean, Linode), take a snapshot of the entire VM before proceeding. This gives you a one-click rollback if anything goes catastrophically wrong. If you are on bare metal, ensure your backup is current, tested, and that you know the restoration procedure from memory — because if things go wrong, you will be executing it under pressure.

# On AWS: Create an AMI from the running instance
aws ec2 create-image 
  --instance-id i-0123456789abcdef0 
  --name "pre-upgrade-22to24-$(date +%Y%m%d)" 
  --description "Pre-upgrade snapshot before Ubuntu 24.04 upgrade"

2. Verify Available Disk Space

The upgrade process downloads and installs hundreds of packages. You need at minimum 5 GB of free space on / and at minimum 300 MB on /boot.

df -h

If /boot is nearly full — extremely common on servers that have received many kernel updates over the years — clean up old kernels first:

# List installed kernels and their sizes
dpkg --list | grep linux-image

# Let Ubuntu automatically remove old kernels (keeps current + one previous)
apt autoremove --purge

# Verify /boot now has space
df -h /boot

3. Update All Current Packages First

The upgrade tool requires your current installation to be fully up to date. Running a partial upgrade is the most common reason do-release-upgrade aborts with an error before even beginning.

apt update && apt upgrade -y && apt dist-upgrade -y
apt autoremove --purge -y

After this completes, reboot if a new kernel was installed, then verify the system is stable before continuing.

4. Check for Held Packages

Held packages are packages pinned to a specific version that will not be upgraded. They can block the release upgrade tool or cause conflicts during the upgrade.

apt-mark showhold

If any packages are held, investigate each one. Check why it was held, whether it is safe to unhold, and what the upgrade impact will be:

apt-mark unhold package-name

5. Document Third-Party PPAs and Repositories

Third-party PPAs (Personal Package Archives) often do not have packages for the new Ubuntu release. The upgrade process automatically disables them, but you need to know which ones you have so you can re-enable (with the new release codename) or replace them afterward.

ls /etc/apt/sources.list.d/
cat /etc/apt/sources.list

Note everything. After the upgrade, you will need to update each PPA’s URL from jammy to noble and then run apt update again.

6. Verify the Release Upgrade Configuration

cat /etc/update-manager/release-upgrades

The Prompt setting must be lts for LTS-to-LTS upgrades:

[DEFAULT]
Prompt=lts

If it is set to never, the upgrade tool will find no available upgrades. Change it with a text editor if needed.

Running the Upgrade in a Protected Session — Critical Step

This is the single most important preparation step that admins skip — and the one that turns a routine upgrade into a crisis. Never run an OS upgrade directly over a plain SSH session.

Here is why: during the upgrade, the SSH daemon itself (sshd) will be upgraded. If your connection drops — due to a network blip, SSH timeout, or the daemon restarting — the upgrade process running in your terminal will be killed mid-flight. The system will be left with a partially upgraded package database, broken dependencies, and potentially unbootable services. Recovery from this state can take hours.

The solution is to run the upgrade inside tmux or screen. These are terminal multiplexers that create persistent sessions on the server. If your SSH connection drops, the session continues running on the server. You reconnect and reattach to find the upgrade still progressing normally.

# Install tmux if not already present
apt install tmux

# Start a new named tmux session
tmux new -s upgrade

# If you get disconnected, reconnect via SSH then run:
tmux attach -t upgrade

Inside the tmux session, you are protected. Now start the upgrade:

do-release-upgrade

For a freshly released LTS (within its first few months) where Canonical has not yet opened the formal upgrade channel:

do-release-upgrade -d

The -d flag enables the development/testing upgrade path. Use this only when you have a specific need to upgrade before the stable announcement — for most production servers, wait for the stable upgrade path.

What the Upgrade Asks You — and What to Answer

The upgrade is interactive and will pause multiple times. Knowing what to expect prevents making the wrong call under pressure.

Configuration File Conflicts: The Most Important Decision

When a package has a new version of a configuration file and you have modified the existing one, you will see a prompt like this:

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 default action is to keep your current version.

The right answer depends on the specific file:

• For files you have customized (sshd_config, nginx.conf, mysql.conf, application configs): Keep your version (N). Then manually review the new version’s changes afterward and incorporate any security or compatibility improvements.
• For system utility configs you have not modified: Accept the new maintainer’s version (Y). You have nothing to lose and may gain security improvements.
• Always press D first to see the diff before deciding. Understanding exactly what changed — new directives, removed deprecated options, security hardening — lets you make an informed choice rather than guessing.

Removing Obsolete Packages

Near the end of the upgrade, you will be asked whether to remove packages that are no longer supported in the new release. Review the list carefully. Packages installed from PPAs that were disabled during the upgrade will appear here. Generally it is safe to say yes, but confirm that nothing critical to your application stack is listed.

Services That Commonly Break After an Ubuntu LTS Upgrade

Even a technically successful upgrade can leave certain services in a broken or incompatible state. These are the failure points experienced admins watch for:

PHP Version Changes

Ubuntu 22.04 ships PHP 8.1. Ubuntu 24.04 ships PHP 8.3. PHP minor versions can introduce deprecation warnings that become errors, breaking legacy applications. PHP extensions also must match the new version:

# After upgrade, check what PHP version is active
php --version

# Install missing modules for the new PHP version
apt install php8.3-fpm php8.3-mysql php8.3-xml php8.3-curl php8.3-mbstring

# Update the active PHP-FPM version in nginx or Apache configs if needed

Python Virtual Environments

Python 3.10 to Python 3.12 is a significant jump. Virtual environments with compiled C-extension packages (numpy, lxml, cryptography) will need to be recreated because the compiled binaries are version-specific:

# After upgrade, recreate Python virtual environments
rm -rf /opt/myapp/venv
python3 -m venv /opt/myapp/venv
/opt/myapp/venv/bin/pip install -r /opt/myapp/requirements.txt

MySQL and MariaDB

If you installed MySQL or MariaDB from Ubuntu’s official repositories, the upgrade typically handles the transition. If you installed from a third-party repository (MySQL’s own apt repo, for example), the upgrade will have disabled that repo. Re-enable it with the correct release information and upgrade the database engine separately.

Post-Upgrade Verification

After the upgrade completes and the system reboots, run through this verification sequence systematically:

# Confirm new OS version
lsb_release -a

# Confirm new kernel is running
uname -r

# Check for any failed services
systemctl --failed

# Check recent system logs for errors
journalctl -p err --since "1 hour ago" --no-pager

# Verify critical services are running
systemctl status nginx
systemctl status mysql
systemctl status sshd
systemctl status your-application

# Verify application endpoints are responding
curl -I http://localhost/health

Expected output from lsb_release -a after a successful upgrade to 24.04:

No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 24.04.1 LTS
Release:        24.04
Codename:       noble

How to Roll Back If Something Breaks

There is no supported in-place downgrade path for Ubuntu LTS. You cannot run a reverse upgrade command. If the upgrade leaves the system in a broken state, your options are:

1. Restore from snapshot (preferred): This is why the snapshot step is non-negotiable. On AWS, launch a new instance from the pre-upgrade AMI. On other cloud providers, the process is similar. This restores the entire system state to exactly where it was before the upgrade began.
2. Fix broken packages manually: If the breakage is minor (a few misconfigured packages, a service that needs its config updated), you can often fix it in place. Start with apt --fix-broken install and dpkg --configure -a.
3. Fresh install with data migration: Last resort. Install Ubuntu 24.04 fresh, restore application data from backup, and rebuild configuration manually. Time-consuming but produces the cleanest result.

In-Place Upgrade vs Fresh Install: When to Choose Each

In-place upgrade is right when:

• The server has complex, well-documented configurations that would take significant time to rebuild.
• You have a reliable snapshot or backup for rollback.
• The application stack is standard and well-supported by the new Ubuntu release.
• Downtime must be minimized — an in-place upgrade is typically faster than a fresh install with full migration.

Fresh install with migration is right when:

• The server has accumulated years of ad-hoc changes, undocumented manual edits, and configuration drift. Upgrading carries all that technical debt forward.
• You want a clean, auditable starting point on the new OS version.
• The application stack has significant compatibility issues with the new OS that require reconstruction anyway.
• The server is being replaced as part of an infrastructure modernization effort.

For most production servers where uptime is critical, rollback options are solid, and configuration is managed with something like Ansible or Puppet, the in-place upgrade using do-release-upgrade inside a tmux session is the right approach. Follow the pre-upgrade checklist rigorously, handle the configuration file prompts thoughtfully, and verify thoroughly afterward.