How to Upgrade Your Ubuntu Server to the Latest LTS Version

Ubuntu LTS (Long Term Support) releases are the backbone of most production Linux servers. Released every two years and supported for five years (with extended security maintenance for up to ten years), LTS versions give server operators a stable, well-maintained platform without the churn of upgrading every six months. Canonical releases a new LTS version each April in even-numbered years: 20.04, 22.04, 24.04, and so on.

Upgrading between LTS versions is a significant operation that carries real risk if done without preparation. A botched upgrade can leave your web application down, your database unreachable, or your server inaccessible over SSH. This guide walks you through a complete, safe upgrade process — from pre-upgrade preparation through to post-upgrade verification — so you can perform the upgrade with confidence.

Why Upgrade to the Latest LTS?

Staying on a supported LTS version matters for security. Once an LTS version reaches end-of-life, it stops receiving security patches for the kernel, system libraries, and packages. Running an end-of-life Ubuntu version means your server is exposed to every known vulnerability discovered after that date with no official fix available.

Beyond security, newer LTS versions ship more recent versions of critical software: PHP, MySQL, OpenSSL, Python, and the Linux kernel itself. PHP version changes in particular can have a significant impact on WordPress and other PHP-based applications — a major PHP version bump (e.g., from PHP 7.4 to PHP 8.1) often ships with the new Ubuntu LTS and requires testing your application before and after the upgrade.

Check the Ubuntu lifecycle and release cadence publication to see the support status of your current version and plan your upgrade timeline accordingly. Ubuntu recommends waiting for the first point release (e.g., 22.04.1 released in August 2022) before upgrading production servers, as it includes fixes for issues discovered in the initial release.

Pre-Upgrade Checklist

Complete every item on this checklist before you run a single upgrade command. Skipping preparation is the most common reason upgrades go wrong.

• Back up your databases. Export all MySQL or MariaDB databases with mysqldump -u root -p --all-databases > all_databases_backup.sql. Store the export somewhere off the server — an S3 bucket, your local machine, or a separate cloud storage service. Verify the dump file is not empty before proceeding.
• Back up your web root. Create a compressed archive of your web files: tar -czvf webroot_backup.tar.gz /var/www/html. If your application files are spread across multiple directories, back up each one. Copy the archive off the server.
• Create a cloud snapshot or AMI (if on AWS/DigitalOcean/GCP). This is your fastest path to full rollback if something goes catastrophically wrong. On AWS, go to EC2 → Instances → select your instance → Actions → Image and templates → Create image. On DigitalOcean, take a Droplet Snapshot from the control panel. This is not optional if you are running production workloads.
• Check available disk space. The upgrade process downloads and unpacks a large number of packages. You need at least 5GB of free disk space on the root filesystem (/). Check with df -h /. If you are below 5GB, clean up old packages first: sudo apt autoremove --purge && sudo apt clean.
• Check for custom PPAs. Third-party Personal Package Archives (PPAs) you have added (for example, ppa:ondrej/php for a specific PHP version) may not have packages available for the new Ubuntu version yet, which can cause the upgrade to fail or produce broken dependencies. List your PPAs with ls /etc/apt/sources.list.d/ and research whether each one supports the target Ubuntu release.
• Notify users of downtime. A major OS upgrade typically requires at least one reboot and may take 30–90 minutes depending on server speed and package count. Schedule a maintenance window and communicate it to your users or stakeholders before you begin.
• Test your SSH connection and verify you have console/out-of-band access. If your SSH session drops during the upgrade (it can happen), you need an alternative way to reach the server. For cloud servers, use the provider’s browser-based console (AWS EC2 Serial Console, DigitalOcean Console, etc.).

Step-by-Step Upgrade Process

1. Update and Upgrade All Current Packages

   Before upgrading the OS version, ensure all packages on your current version are fully up to date. The apt update command refreshes the package index from all configured repositories, telling apt which versions are currently available. The apt upgrade -y command then downloads and installs newer versions of all currently installed packages. Running both ensures you are starting from a clean, fully-patched state.

   sudo apt update -y && sudo apt upgrade -y

   During the upgrade you may be prompted about configuration files for services like SSH, MySQL, or Nginx — packages that have been updated may include new default configurations. When prompted, select Keep the local version currently installed to preserve your existing configuration. After the upgrade completes, reboot the server to ensure the new kernel and system libraries are active before proceeding:

   sudo reboot

2. Confirm Your Current OS Version

   After rebooting and reconnecting via SSH, verify you are running the expected current version before initiating the upgrade. The /etc/os-release file contains the canonical version information for the running OS:

   cat /etc/os-release

   Look for the VERSION_ID and PRETTY_NAME fields. Confirm this matches the version you expected (e.g., 22.04 if you are upgrading from Ubuntu 22.04 to 24.04). Also run uname -r to confirm the new kernel version is loaded after the reboot.

3. Open an Alternative SSH Port (Port 2222)

   The do-release-upgrade tool starts a secondary SSH daemon on port 2222 as a safety net. If your primary SSH connection on port 22 drops during the upgrade, you can reconnect on port 2222 to continue managing the server. You need to open this port in your firewall before starting the upgrade so it is accessible when needed.

   If you are using ufw (Ubuntu’s default firewall tool):

   sudo ufw allow 2222/TCP

   sudo ufw reload

   sudo ufw status

   Confirm port 2222 appears as ALLOW in the status output. If you are on AWS with a Security Group, also add an inbound rule allowing TCP port 2222 from your IP address in the EC2 Security Group settings.

4. Install the update-manager-core Package

   The update-manager-core package provides the do-release-upgrade command that manages LTS-to-LTS upgrades. It may already be installed on your system, but running this command ensures you have the latest version:

   sudo apt install update-manager-core

   Also verify the upgrade configuration is set to accept LTS upgrades. Check the file /etc/update-manager/release-upgrades — the Prompt value should be set to lts. If it shows never, edit the file and change it to lts.




5. Run the Release Upgrade

   This is the main upgrade command. The -d flag means "development release" — use it only if the next LTS has not yet had its first point release and you want to upgrade to it anyway. For production servers upgrading to a fully-released LTS version, you can omit -d:

   sudo do-release-upgrade

   Or with the -d flag for the latest development LTS:

   sudo do-release-upgrade -d

   The tool will detect that you are connected over SSH and prompt you to confirm that port 2222 is open. Type Y and press Enter to continue. It will then calculate all the package changes needed and present a summary showing how many packages will be installed, upgraded, and removed. Review this summary — if you see a very large number of packages being removed, investigate before proceeding. Otherwise, type Y and press Enter to begin the actual upgrade.

   The upgrade will take between 15 and 60 minutes depending on your server’s internet connection speed and CPU. You will be prompted several more times about configuration files — continue choosing to keep your local versions unless you know the upstream default is what you want.

6. Handle Configuration File Prompts

   During the upgrade, package maintainers may detect that you have modified a configuration file that the new package version wants to replace. You will see a prompt like: "A new version of /etc/mysql/mysql.conf.d/mysqld.cnf is available, but the version installed currently has been locally modified. What do you want to do about it?"

   For files you have customised (MySQL configuration, PHP-FPM pools, Nginx server blocks, SSH config), choose Keep the local version currently installed. For configuration files you have never touched (package default configs), it is generally safe to accept the new maintainer version. When in doubt, keep your local version and manually review differences afterward using diff.

7. Reboot to Complete the Upgrade

   Once the upgrade finishes, the tool will prompt you to restart the system. Press Y and Enter to reboot. The server will go offline briefly as it reboots into the new OS version. Wait 60–120 seconds before attempting to reconnect via SSH on the standard port 22.

8. Verify the New OS Version

   After reconnecting, confirm the upgrade succeeded:

   cat /etc/os-release

   The VERSION_ID should now reflect the new LTS version. Also check the running kernel version:

   uname -r

9. Remove the Port 2222 Firewall Rule

   Now that the upgrade is complete and you can connect normally on port 22, close the temporary port 2222 you opened earlier:

   sudo ufw delete allow 2222/TCP

   If you added port 2222 to an AWS Security Group, remove that inbound rule as well from the AWS Console.

10. Free Up Disk Space

    The upgrade process leaves behind old package files that are no longer needed. The autoremove command removes packages that were installed as dependencies of other packages that have since been removed, and the --purge flag also deletes their configuration files:

    sudo apt autoremove --purge

    Also clean the local package download cache, which can accumulate several gigabytes over time:

    sudo apt clean

    Recheck your disk usage with df -h / to confirm you have recovered space.

11. Restart Your Web Services

    After a major OS upgrade, web-facing services may not automatically restart in the correct order or with updated configurations. Explicitly restart each service and check its status:

    sudo systemctl restart apache2 — or Nginx: sudo systemctl restart nginx

    sudo systemctl restart mysql

    Check that each service started successfully:

    sudo systemctl status apache2

    sudo systemctl status mysql

    sudo systemctl status nginx

    Look for Active: active (running) in the status output for each service. If a service has failed, check its logs with journalctl -u apache2 --since "1 hour ago" or journalctl -u mysql --since "1 hour ago" for the specific error.

Checking Your PHP Version After Upgrade

Each Ubuntu LTS release ships a different default PHP version. Ubuntu 20.04 shipped PHP 7.4, Ubuntu 22.04 shipped PHP 8.1, and Ubuntu 24.04 ships PHP 8.3. When you upgrade Ubuntu, the default PHP version upgrades with it — and this can break PHP-based applications, especially WordPress sites and plugins that have not yet been updated for the new PHP version.

Check your active PHP version immediately after the upgrade:

php -v

If you are running WordPress, navigate to your site and check the WordPress admin dashboard for any PHP compatibility warnings. You can also check PHP error logs at /var/log/apache2/error.log or /var/log/nginx/error.log for deprecation notices and fatal errors. Common breakage includes plugins using deprecated functions, themes calling removed PHP functions, and custom code using short tags or other pre-PHP 8 patterns.

If you need to run a specific PHP version that differs from the Ubuntu default, install it via the ondrej/php PPA (which typically adds support for new Ubuntu versions within a few weeks of each LTS release) and use update-alternatives or PHP-FPM pool configurations to control which PHP version each application uses. For Apache: sudo a2dismod php8.1 && sudo a2enmod php8.3 && sudo systemctl restart apache2.

What to Do If the Upgrade Fails or SSH Drops

If your SSH connection drops during the upgrade, connect on the alternative port that do-release-upgrade opened:

ssh -p 2222 user@your-server-ip

If the upgrade process is still running in the background (which it often is — SSH dropping does not kill the upgrade process), reconnect and check its status. If it crashed mid-upgrade, the server may be in an inconsistent state with partially upgraded packages. In this case, run sudo dpkg --configure -a to attempt to complete any interrupted package configurations, then sudo apt-get -f install to fix broken dependencies.

If services are broken and the above commands cannot resolve it, this is when your cloud snapshot or AMI becomes invaluable. On AWS, restore the instance from the AMI you created before the upgrade. On DigitalOcean, restore from the Droplet snapshot. This reverts the server to its exact pre-upgrade state in minutes, letting you start fresh with a better plan.

How to Roll Back If Something Goes Wrong

There is no built-in "undo" for an Ubuntu release upgrade — packages cannot be downgraded en masse. The rollback strategy is restoration from your pre-upgrade backup or snapshot. This is why the backup steps in the pre-upgrade checklist are not optional.

• Cloud snapshot/AMI rollback: On AWS, launch a new EC2 instance from your pre-upgrade AMI, or stop the current instance and swap its root volume. On DigitalOcean, restore the Droplet from the snapshot taken before the upgrade.
• Database restore: If the OS upgrade completed but MySQL is broken, restore your database from the SQL dump: mysql -u root -p < all_databases_backup.sql
• Web root restore: If application files were corrupted: tar -xzvf webroot_backup.tar.gz -C /

Final Verification Checklist

After completing the upgrade and restarting services, perform a thorough check of your web application:

• Load your website in a browser and navigate through key pages
• Test any forms, logins, and checkout flows if applicable
• Check sudo systemctl status apache2 (or nginx), sudo systemctl status mysql — all should show active (running)
• Review error logs for any new PHP warnings or fatal errors
• Run php -v and confirm the PHP version is what you expect
• Verify SSL certificates are still serving correctly (check your site with HTTPS)
• Confirm cron jobs are still active: sudo crontab -l and crontab -l for each application user