How to Upgrade Ubuntu Server to a New Release over SSH Safely

Ubuntu’s do-release-upgrade command moves a server to the next release, for example from one LTS (long-term support) release to the next. Run over SSH, it replaces the operating system beneath your session, so prepare a console route, a backup and a rollback plan first, then check a fresh boot before returning the server to service.

This guide is for administrators of an Ubuntu server, such as a Noiz VPS or dedicated server. It adds the decisions and gotchas around Ubuntu’s official procedure rather than repeating it. Plan a maintenance window even when another server provides redundancy.

Last reviewed: 13 October 2026, against the current Ubuntu Server release. This guide is written for Noiz hosting and is kept current against Ubuntu. It complements, and does not replace, the official Ubuntu documentation linked below.

Official Documentation Reference

• How to upgrade your Ubuntu release (Ubuntu Server): the official procedure, upgrade paths and configuration prompts.
• About apt upgrade and phased updates (Ubuntu Server): why some updates arrive gradually and can block an upgrade.
• sshd manual (Ubuntu): including sshd -t to test the SSH configuration.
• netplan try (Netplan): apply a network change with automatic rollback.
• Package manager locks (Debian dpkg FAQ).

Prerequisites

• Console access that does not depend on the server’s own network. On a Noiz VPS this is the VNC console in your VPS panel (SolusVM or Virtualizor), which works when SSH and the network do not. Open it and log in once before you start. A web-based SSH terminal fails when SSH fails, so it does not count.
• A non-root user with sudo whose password you know, for logging in at the console. See Initial Server Setup with Ubuntu on a Noiz VPS.
• SSH key login; see How to Set Up SSH Key-Based Authentication on a Linux Server.
• A current, restorable off-server backup of your data and configuration. If your provider offers snapshots, take one immediately before the upgrade and confirm you know how to restore it.
• A maintenance window. The commands below are examples to adapt, not an unattended script.

1. Check the Upgrade Path and the Server’s Health

Read the release notes for the target release and check that your applications and any control panel support it. Ubuntu only upgrades one LTS to the next: you cannot skip an LTS. Ubuntu also offers an LTS-to-LTS upgrade only after the new release’s first point release (for example .1); until then do-release-upgrade reports that no release is available.

cat /etc/os-release
sudo do-release-upgrade -c
df -h / /boot /var
free -h
sudo dpkg --audit
apt-mark showhold
systemctl --failed --no-pager

Fix package errors, unexplained held packages and failed services before you start. The upgrade downloads several gigabytes, so make sure the root filesystem has that much free and /boot has room for a new kernel. Do not force the upgrade with the development-release switch (-d) or by editing repository release names on a production server.

Third-party repositories and PPAs are disabled during the upgrade. Decide in advance how each of those applications will get packages built for the new release; do not simply re-enable the old repositories afterwards.

If the server is one of a redundant pair (for example a secondary nameserver), confirm the other server is healthy and leave it unchanged until this one passes every check.

2. Fully Update the Current Release

Ubuntu requires all current updates to be installed first, including phased updates (updates Ubuntu rolls out gradually), which can otherwise block the upgrade. Review the plan, then apply it:

sudo apt-get update
sudo apt-get -s dist-upgrade -o APT::Get::Always-Include-Phased-Updates=true
sudo apt-get dist-upgrade -o APT::Get::Always-Include-Phased-Updates=true

The first dist-upgrade line, with -s, only simulates. Check what it would remove before running the real one. If /run/reboot-required exists afterwards, reboot now, log in again and confirm your services are healthy before continuing.

3. Start the Upgrade from Your SSH Login

Run the upgrader directly from your SSH session, not inside tmux or screen:

sudo do-release-upgrade

Run from SSH, the upgrader starts a spare SSH server on port 1022 and keeps itself running in its own screen session. If your connection drops, log in again and run sudo do-release-upgrade to reattach. Inside tmux it cannot tell that you are on SSH and skips the spare SSH server. You can still use tmux for the update step above.

The upgrader does not open port 1022 in your firewall. If you use UFW, allow it from your own IP address only. Replace 203.0.113.10 with your address:

sudo ufw allow from 203.0.113.10 to any port 1022 proto tcp

Test a second login on port 1022 with your SSH key before you accept the package changes, and keep your normal session open. Accept the host-key warning only if you are sure it is the same server; never disable host-key checking. The spare SSH server shares the server’s network, so it is a convenience, not a replacement for the console. See How to Set Up a Firewall with UFW on Ubuntu and Debian.

Once package installation starts, do not start a second upgrader or kill package processes to get a terminal back. Reconnect, reattach or use the console.

4. Answer the Configuration Prompts

When a configuration file you have changed also has a new version from the package, the upgrader asks what to do. Press D to see the differences before choosing. Keeping every old file can leave obsolete settings; taking every new file can remove settings your server needs.

Prompt	Check before answering
Upgrade summary	Which packages will be removed or are no longer supported, and the download size.
SSH configuration	Port, authentication methods and access rules. You test the result in step 5 before closing any session.
Service configuration (web, mail, DNS, database)	Your own settings. Keep them, or merge them into the new file.
Remove obsolete packages	Whether a package is genuinely unused, especially kernels you might need for recovery.

If the server runs BIND, also follow the checks in How to Disable Recursion in BIND to Stop an Open DNS Resolver after the upgrade.

5. Check Before You Reboot

At the final restart prompt you can choose not to restart yet, so you can run checks first. This does not undo the upgrade, and the reboot is still required to finish it.

Wait for package activity to finish. Never delete apt or dpkg lock files; if a lock is held, find out which process holds it and let it finish. Then run:

sudo dpkg --audit
sudo apt-get check
sudo /usr/sbin/sshd -t

sshd -t prints nothing when the SSH configuration is valid. Open a fresh SSH login in a new window while keeping the existing one open.

Look through the upgrade output for bootloader or kernel errors and resolve them before rebooting. A server that boots in BIOS mode and one that boots in UEFI mode need different fixes; see How to Fix GRUB After a BIOS/UEFI Mismatch on an Ubuntu Server. Then reboot.

6. Check the Server After the Reboot

Log in on the normal SSH port and compare with how the server looked before:

cat /etc/os-release
uname -r
systemctl is-system-running
systemctl --failed --no-pager
ip -brief address
ip route
ip -6 route
resolvectl status

Then test what the server is for: open the website, send and receive a test email, query the DNS zones, connect the application. A running process or open port does not prove a service works.

If boot reports that the network was not ready (a systemd-networkd-wait-online failure), look at why rather than disabling the unit:

networkctl status
sudo journalctl -b -u systemd-networkd-wait-online --no-pager

If the network configuration needs a change, back up the file under /etc/netplan/ first and apply the change with sudo netplan try, which rolls back automatically unless you confirm it. Keep the console open while you do this, and reboot once more to confirm the change persists.

7. Clean Up

When everything works, close the temporary firewall opening and stop the spare SSH server if it is still running:

sudo ufw delete allow from 203.0.113.10 to any port 1022 proto tcp
sudo pkill -F /var/run/release-upgrader-sshd.pid

Re-enable or replace any third-party repositories with versions built for the new release.

If the checks fail, leave the other server of a redundant pair untouched and use the console. Repair the problem, or restore from backup or a snapshot. Downgrading Ubuntu in place is not a supported rollback. Before restoring older data, make sure you do not overwrite anything newer, such as mail received or DNS changes made since the backup.

If Noiz manages your server, contact Noiz support to schedule the upgrade and agree the recovery plan and service checks in advance.