Upgrade Ubuntu in place or reinstall?

Upgrade in place or reinstall: the short answer

Upgrade Ubuntu in place with do-release-upgrade when the server does one job, every package on it comes from Ubuntu's own archive, you took a snapshot minutes before starting, and an hour of downtime is acceptable. Build a fresh Ubuntu 26.04 VPS (virtual private server) and migrate when the server carries PPAs (personal package archives) or vendor repositories, hand-edited config files, a history that began on 22.04, or data you would rather restore cleanly than carry across. The inventory below tells you which of those two servers you have.

The decision matters because the in-place upgrader is a package transaction, not a reinstall. It swaps every Ubuntu package for its 26.04 version and leaves everything else where it found it. What it leaves behind is exactly what breaks.

What do-release-upgrade does to your server

do-release-upgrade is the release upgrader from the ubuntu-release-upgrader-core package. It rewrites your apt sources to point at the new release, disables every source that is not Ubuntu's archive, calculates one large dist-upgrade, runs it, then removes packages that no longer exist in the new release. The disabling step is the one that matters for this decision. The tool prints it plainly before it starts:

Third party sources disabled
Some third party entries in your sources.list were disabled. You can re-enable them after the upgrade with the 'software-properties' tool or your package manager.

A package you installed from a PPA or a vendor repository is not removed. It stays at the version you have, with no source behind it, so it gets no updates until you re-enable the source and the vendor publishes builds for 26.04. If that package depends on a library that 26.04 replaced, it either blocks the upgrade calculation or is removed as part of it. That is why third-party sources are the first item in the inventory.

When to upgrade Ubuntu in place

Upgrade in place when all four of these are true.

• The server does one job: a web server, a database, a VPN endpoint, a game server. One job means one service to test afterwards.
• Every installed package comes from Ubuntu's archive. The check for this is below, and the answer is either zero third-party packages or it is not.
• You have a snapshot taken minutes before the upgrade, and you know how to roll back to it. A snapshot is the undo button for an in-place upgrade, though it is not a backup, because it lives on the same host as the server.
• An hour of downtime is acceptable. The upgrader stops services while it replaces them, then reboots once at the end. Nothing serves during the package transaction.

If all four hold, follow the in-place upgrade from Ubuntu 24.04 to 26.04. If it stops half way, the recovery guide for a failed release upgrade covers the half-configured dpkg state and the roll-back to the snapshot.

When to reinstall and migrate

Build a fresh 26.04 VPS when any one of these is true.

• Packages come from PPAs or vendor repositories. Docker, Tailscale, PostgreSQL from apt.postgresql.org, a mainline kernel. Each is a source the upgrader disables and a set of packages it cannot replace.
• Config files under /etc have been edited by hand over years. Each changed file that the new package also changed produces a prompt during the upgrade, and you answer each one while the service is down.
• The server was installed as 22.04 or earlier. Ubuntu does not skip LTS (long-term support) releases, so the in-place path is two upgrades, 22.04 to 24.04 and then 24.04 to 26.04. Two transactions, two sets of prompts, two reboots, two chances to fail.
• The data is worth more than the install. A database, a mail spool, a Nextcloud data directory, a game world. Restoring it onto a clean install is a procedure you can rehearse. Carrying it through an upgrade is not.

The reinstall path is migrating the server to a new VPS: build 26.04, install the same services from their 26.04 sources, copy the data, cut over DNS (the domain name system). The old server keeps serving until the new one is proven, so the downtime is the DNS cut, not the whole procedure.

The pre-flight inventory

Run these on the existing server. Every command here is read-only and changes nothing. Together they answer the question.

1. Third-party apt sources

ls /etc/apt/sources.list.d/
grep -rhE '^(deb |URIs:)' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

On a stock 24.04 install the directory holds ubuntu.sources and nothing else. Every other file is a source somebody added. The grep prints the URL behind each one. Ubuntu's own archive answers as archive.ubuntu.com or security.ubuntu.com, and many providers point their images at a local mirror of it, which is fine. Any other host is third-party.

The sources tell you what was added. A second command tells you which installed packages actually came from outside the archive:

ubuntu-security-status --thirdparty

ubuntu-security-status ships with update-manager-core, the same package that provides do-release-upgrade. With --thirdparty it lists only packages whose installed version did not come from Ubuntu. A summary that counts zero packages from third party sources means the archive-only condition holds. Any package it lists is one the upgrader will leave frozen at its current version. Read the list and ask what each package does. A monitoring agent is a small thing to reinstall after the upgrade. A database engine or a container runtime is not.

Run ubuntu-security-status --unavailable as well. It lists packages that no configured source can download any more, which means a repository was removed but its packages stayed. Those are the same problem, with the source already gone.

2. Held and pinned packages

apt-mark showhold
ls /etc/apt/preferences.d/

apt-mark showhold prints one package name per line. Healthy output is nothing at all. A held package is one you told apt never to change, and the release upgrader has to change nearly everything. A hold on a package whose dependencies change between releases produces this:

Could not calculate the upgrade

An unresolvable problem occurred while calculating the upgrade.

The upgrader then names unofficial packages as the likely cause and stops before it has changed anything. That is the good outcome, because the server is still exactly as it was. Remove the hold with sudo apt-mark unhold <package> if you can live with the newer version, or count it as a reason to reinstall.

/etc/apt/preferences.d/ holds pin files. An empty directory is the default. Any file in it deserves a read: a pin that names a release codename such as noble, or sets a priority above 1000, can hold the whole system at the old release and produce the same calculation failure.

3. Snaps

snap list

The release upgrader does not touch snaps. Each one tracks its own channel and updates on its own schedule, so a snap is neither a blocker for the in-place path nor a thing the upgrade fixes. The list matters for the other path: every snap on it is something you install by hand on the new server. A fresh 26.04 image shows only the snaps Canonical seeds, and if you would rather they did not update themselves at random moments, controlling snap refreshes on a server is worth setting up on the new box from the start.

4. The kernel

uname -r
dpkg -l 'linux-image-*' | grep '^ii'
apt-cache policy "linux-image-$(uname -r)"

The first line is the running kernel. The second is every kernel package installed. The third shows where the running kernel came from. A kernel from Ubuntu's archive lists a 500 http://archive.ubuntu.com/ubuntu line (or your provider's mirror of it) under its installed version. A kernel that shows only 100 /var/lib/dpkg/status was installed from a downloaded .deb, a mainline build from kernel.ubuntu.com or a vendor package, and no repository stands behind it. The upgrader installs the 26.04 kernel next to it, and GRUB boots whichever has the higher version number, so pinning which kernel boots becomes your problem on the first reboot.

Then check that a kernel metapackage is installed:

dpkg -l 'linux-generic*' 'linux-virtual*' 'linux-image-generic*' 'linux-image-virtual*' 2>/dev/null | grep '^ii'

You want at least one line. On most VPS images it is linux-virtual or linux-generic; the HWE (hardware enablement) form is linux-generic-hwe-24.04. The metapackage is what pulls each new kernel in for you, during the upgrade and for every security kernel after it. No line means somebody removed it to freeze a kernel, and the box keeps whatever kernel it has until you put the metapackage back. The GA (general availability) kernel and the HWE kernel are the two tracks, and GA versus HWE kernels on Ubuntu Server explains which belongs on a VPS.

5. Disk headroom

df -h / /boot /var
sudo du -sh /var/cache/apt/archives

The upgrader downloads every replacement package before it installs any, and refuses to start if the space is not there:

Not enough free disk space

The upgrade has aborted. The upgrade needs a total of <N> M free space on disk '/'. Please free at least an additional <N> M of disk space on '/'.

It tells you how much it wants, and the number is computed from your package set, so no figure quoted here would be true for your box. What you can do before asking: sudo apt clean empties the download cache, and sudo apt autoremove --purge removes packages nothing depends on. If /boot is a separate small partition, old kernels are what fill it, and removing old kernels is the fix. Do it before the upgrade, not when the upgrade discovers it.

6. Hand-edited config files

sudo dpkg -V 2>/dev/null | grep ' c /etc/'

dpkg -V compares every file a package installed against the checksum the package recorded. A conffile, which is dpkg's name for a configuration file a package owns, prints with a c marker when it differs, like ??5?????? c /etc/ssh/sshd_config, where the 5 says the checksum changed. Every line is a file you or a script edited. That is normal. A server with no edited config is not doing anything. What the list tells you is how many decisions the upgrade will ask you to make while the service is down. When the 26.04 package also ships a new version of a file you changed, the upgrade stops and asks:

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.

Keeping yours can leave a directive the new version no longer accepts. Taking theirs throws your edit away. Each prompt is a decision, made with the service down. A short list of files you know well is fine for an in-place upgrade. A long list, or files you no longer remember editing, is the strongest reason to reinstall. On a fresh 26.04 box you write each config once, from the new default, while the old server keeps serving.

The timing: the LTS path opens at 26.04.1

On a server, /etc/update-manager/release-upgrades is set to Prompt=lts, which means do-release-upgrade offers only LTS releases, and only once the new LTS has its first point release. Canonical keeps the 24.04 to 26.04 path closed until 26.04.1 ships, so the first point release collects the early fixes before LTS servers are offered the move. Until then the tool prints No new release found., and that message has other causes worth ruling out before you assume it is only the calendar.

Check what your box is being offered today:

cat /etc/update-manager/release-upgrades
sudo do-release-upgrade -c

-c only checks and reports. It changes nothing. If it names a new release, the path is open. If it reports none, do not force it with -d: that flag targets the development release and exists for testers, not for a server you depend on. What changed in 26.04.1 and when a server should move covers the point release itself. The path is open when -c says so, whatever the calendar says.

Two hops from 22.04

If grep VERSION_ID /etc/os-release prints 22.04, the in-place path is two upgrades. The upgrader moves one LTS forward at a time, so 22.04 goes to 24.04, and then 24.04 goes to 26.04, each hop with its own snapshot, its own disabled sources, its own conffile prompts and its own reboot. The 22.04 to 26.04 upgrade walks both hops if you want them. A server that has run since 22.04 has had years of package additions and config edits, though, and the inventory above will show them. Build 26.04 fresh and migrate.

Making the call

Add up the inventory. Zero third-party packages, no holds, a short conffile list, a metapackage-tracked kernel, room on disk, a snapshot you trust, and a 24.04 starting point: upgrade in place, and plan for the hour. Anything else on the list, and above all a vendor repository behind a service you rely on: build the new box and migrate. The migration costs more of your time, but every step of it happens with the old server still serving, and every step can be repeated until it is right.

FAQ

Is it safe to run do-release-upgrade over SSH?

Yes, with two preparations. The upgrader warns that the session appears to be running under SSH (secure shell) and starts a second SSH daemon on port 1022 as a fallback, so open that port in the server firewall and in your provider's network firewall before you begin. It also runs itself inside screen, so a dropped connection does not kill the upgrade. Log back in, run sudo screen -ls to find the session, and reattach it with sudo screen -d -r.

Why does do-release-upgrade say "No new release found" on Ubuntu 24.04?

With Prompt=lts in /etc/update-manager/release-upgrades, a 24.04 server is offered 26.04 only after the 26.04.1 point release exists in Canonical's meta-release file. Run sudo do-release-upgrade -c to see what the box is being offered today. If the point release is out and you still see the message, check that the file does not say Prompt=never and that the server can reach changelogs.ubuntu.com.

Can I skip 24.04 and upgrade from 22.04 straight to 26.04?

No. The upgrader moves from one LTS to the next LTS only, so 22.04 has to pass through 24.04 first. Two upgrades means two snapshots, two rounds of disabled sources, two rounds of config prompts and two reboots. A server that old is the case for a fresh 26.04 install and a migration.

Will my PPAs and third-party repos survive the upgrade?

They are disabled, not deleted. The upgrader comments out each one-line .list entry and marks it # disabled on upgrade to resolute, using the 26.04 codename. The packages installed from those sources stay at their current versions with no source behind them. After the upgrade, re-enable a source only once the vendor publishes builds for 26.04, then run sudo apt update and sudo apt upgrade. A source with no 26.04 builds is a package you carry unpatched.

Does a snapshot count as a backup for the upgrade?

For the upgrade, yes: it is the roll-back, and you take it minutes before you start so nothing written after it is lost. As a backup, no. A snapshot lives on the same host and the same storage as the server, so it protects you from the upgrade and not from the host. Keep the snapshot until the upgraded server has run cleanly for a few days, then delete it, and keep your real backups off the box either way.