Choose do-release-upgrade for well-maintained Ubuntu 18.04 systems, but choose a fresh installation when the machine is cluttered, fragile, poorly documented, or already showing package errors. Ubuntu 18.04 LTS reached the end of standard support in May 2023, while Ubuntu 20.04 LTS reached that point in 2025, so this move is often part of a broader cleanup or staged migration plan [source: Ubuntu]. If the server matters, do not treat this as a routine reboot. Treat it as a change window with backups, testing, rollback notes, and a clear reason for choosing one method.
TLDR: Use do-release-upgrade if the system is clean, patched, and lightly customized; it usually preserves users, services, and configuration with less manual work. Use a fresh installation if the server has years of PPAs, broken dependencies, unknown scripts, or security concerns. For example, a 25-user office server with standard packages may finish an in-place upgrade in 1 to 3 hours, while a fresh rebuild may take 4 to 8 hours but can remove years of hidden technical debt. If uptime risk matters more than labor, build fresh and cut over only after testing.
What do-release-upgrade actually does
do-release-upgrade is Ubuntu’s supported in-place upgrade tool. It changes package sources, calculates package transitions, upgrades installed packages, removes obsolete items, and asks about configuration files when local changes exist. It is designed for the exact path from one LTS release to the next, such as 18.04 Bionic Beaver to 20.04 Focal Fossa.
On paper, it sounds simple. In real life, old servers argue back. The catch is that the tool can only work with the system it inherits. If Apt is already broken, if third-party repositories are stale, or if someone edited service files three years ago and forgot why, the upgrade can expose every bad decision at once.
A typical upgrade path looks like this:
- Update the current Ubuntu 18.04 system fully.
- Remove unused PPAs and unsupported repositories.
- Back up application data, databases, and key configuration files.
- Run
sudo do-release-upgrade. - Review prompts about changed configuration files.
- Reboot and test services.
This method is best when the server has a clear role and a clean package history. A basic web server, internal Git host, monitoring node, or small office file server may be a good fit. It also helps when the system has many local users or custom paths that would be annoying to recreate by hand.
Where do-release-upgrade works well
An in-place upgrade is attractive because it keeps the machine intact. User accounts remain. Installed packages are upgraded rather than rebuilt from a blank image. Network settings, cron jobs, SSH keys, service files, and application directories usually stay where they are.
That can save serious time. If a small business has a single Ubuntu 18.04 server running Nginx, MariaDB, and a few internal apps, a tested in-place upgrade may be enough. The downtime might fit into an evening window. The team can update DNS, reboot once or twice, and confirm that ports are listening again.
do-release-upgrade is usually the better choice when:
- The system is already fully patched.
apt updateandapt full-upgraderun cleanly.- There are few or no third-party repositories.
- The server role is simple and well understood.
- You have a tested backup and console access.
- You can tolerate a short outage and some troubleshooting.
It drives me crazy that one forgotten PPA can turn a neat upgrade into a 90-minute dependency hunt. Before starting, disable non-Ubuntu repositories. Do not trust “we’ll fix it later” thinking. Later usually arrives at 1:17 a.m., with a broken PHP module and a manager asking why the login page is down.
When a fresh installation is safer
A fresh installation means you install Ubuntu 20.04 on a clean disk, virtual machine, or new cloud instance. Then you reinstall applications, copy data, restore configuration, test everything, and switch traffic over. It takes longer, but the result is cleaner and easier to support.
This approach is often safer for production systems with a messy past. Servers that have changed owners several times are prime candidates. So are machines with manual /usr/local builds, abandoned PPAs, custom kernels, mixed Python versions, or unexplained firewall rules.
Fresh installation is usually the better choice when:
- The machine has unknown history.
- Security is a concern.
- You want to standardize builds across servers.
- The current system has broken packages.
- You need to change disk layout, encryption, or filesystems.
- You can test the new server before switching users to it.
The biggest benefit is control. You decide what comes forward. Old packages do not ride along just because they happened to be installed in 2019. Bad habits get left behind. The cost is labor. Expect to spend time comparing service versions, exports, database dumps, permissions, secrets, and application behavior.
Risk comparison
do-release-upgrade has lower setup effort but higher surprise risk. It touches the live system directly. If the process fails halfway, you may need recovery mode, console access, or a snapshot restore. This is why virtual machines and cloud servers should have snapshots before the upgrade begins.
Fresh installation has higher setup effort but lower long-term risk. You can build in parallel. You can test without harming the old server. If something fails, users stay on the old system while you fix the new one. That alone can make the longer path worth it.
For databases, be extra careful. Check version changes for MySQL, MariaDB, PostgreSQL, Redis, and Elasticsearch. Dump and restore tests are not optional. A service that starts is not the same as a service that returns correct data.
Practical decision guide
- Use do-release-upgrade for simple, clean, well-backed-up systems.
- Use fresh installation for complex, exposed, or business-critical servers.
- Use fresh installation if several admins have changed the system with no records.
- Use do-release-upgrade if downtime must be short and the current OS is healthy.
- Use fresh installation if you want a repeatable build for future upgrades.
For workstations, the choice is more personal. An in-place upgrade keeps user settings and installed apps, which is convenient. A fresh installation gives better performance hygiene, especially on machines that have collected old desktop packages, drivers, themes, and language runtimes for years.
Preparation checklist
Before either method, do the boring work. It is boring for a reason: it prevents ugly surprises.
- Confirm backups by restoring a sample file or database.
- Record IP addresses, DNS entries, firewall rules, and mounted volumes.
- List installed packages with
apt-mark showmanual. - Copy key directories such as
/etc,/home,/var/www, and application data paths. - Check disk space with
df -h. - Review active services with
systemctl list-units --type=service --state=running. - Disable unsupported repositories before an in-place upgrade.
Final recommendation
If you trust the current Ubuntu 18.04 system, use do-release-upgrade. It is faster, supported, and reasonable for clean machines. If you do not trust the system, rebuild it. A fresh Ubuntu 20.04 installation costs more time upfront, but it gives you a cleaner base and fewer inherited problems.
The serious answer is not “upgrade or reinstall” in the abstract. The serious answer is based on evidence. Check package health, repository history, service complexity, backup quality, and downtime tolerance. If any of those look weak, do not gamble on a live in-place upgrade. Build fresh, test hard, then switch over with a rollback plan ready.
