Your fleet still runs Ubuntu 20.04 LTS, whose five-year standard support window has ended. What concretely stops happening on those machines, and what are your options?

## What actually changes at end of support The end of an Ubuntu LTS's five-year standard support window is invisible from inside the machine. Nothing stops, no service refuses to start, `apt` keeps working, and the repositories usually keep serving the packages that are already there. What stops is **publishing**: Canonical's security team no longer prepares and pushes fixes into that release's `-security` pocket. From that day, every newly disclosed vulnerability in OpenSSL, the kernel, glibc, your web server or any other installed package remains unfixed on those hosts, permanently. That silence is exactly what makes it dangerous. A stale release does not page anyone. It sits there passing health checks while its exposure grows monotonically, and the only signals are external — a vulnerability scanner, a compliance auditor, or an incident. Eventually the archive itself moves: end-of-life releases are removed from the primary mirrors and relocated to the historical archive, at which point even ordinary installs start failing with 404s until the sources are repointed. That is a second, later shock, and it often arrives at the worst moment, in the middle of an emergency change. ## The support boundary you probably already crossed Ubuntu's five-year promise applies to **main** (and restricted) — the components Canonical maintains. **universe** and **multiverse** are community-maintained on a best-effort basis. A busy server usually has a meaningful share of its installed packages from universe, so "we are on a supported LTS" was never the same as "everything installed is being patched". On 22.04 and later you can see the split per package with `pro security-status`, which reports how many installed packages are covered by standard maintenance, how many would be covered by ESM, and how many nobody is patching. ## Option 1: in-place release upgrade Ubuntu's supported upgrade tool is `do-release-upgrade` (from the `ubuntu-release-upgrader` package). Two constraints govern it. First, **you cannot skip an LTS**: 20.04 upgrades to 22.04, and 22.04 upgrades to 24.04. Second, whether the upgrade is offered at all is controlled by `Prompt=` in `/etc/update-manager/release-upgrades` — set to `lts`, the machine is only offered the next LTS, and only once that target's first point release exists. An in-place upgrade is a large, stateful mutation: it rewrites the APT sources to the new series, **disables third-party repositories and PPAs**, upgrades every package, and runs every maintainer script. Configuration files you edited produce conffile prompts. Services restart. It works, and for a pet machine with irreplaceable local state it is often the right call — but do it on a snapshot or a clone first, and expect to revisit anything you installed outside the archive. ## Option 2: rebuild rather than upgrade For anything cloud-hosted, image-based or configuration-managed, replacing the machine is usually the better answer. Build a fresh instance from the current LTS image, let your provisioning re-apply the configuration, cut traffic over, destroy the old one. You end up on a base identical to every new machine you will ever build, instead of a one-off artifact carrying five years of upgrade sediment. The work is not the upgrade; the work is discovering which of your automation, package versions and configuration assumed the old release. That discovery is the same either way, and rebuilding at least lets you do it on a machine that is not yet serving traffic. ## Option 3: buy time with Ubuntu Pro / ESM **Ubuntu Pro** is Canonical's subscription (free for personal use on a small number of machines, paid otherwise). Attaching it and enabling **ESM** resumes security patching for the expired release: `esm-infra` covers main, extending an LTS's coverage to ten years, and `esm-apps` covers universe — which is a genuine upgrade in coverage even on a release that is still in its standard window. Pro also bundles Livepatch for kernel fixes without reboot, and hardening and certification tooling. ESM is the right tool when you have a real constraint — a certified appliance, a vendor application unsupported on newer releases, a migration that genuinely needs another two quarters. It is the wrong tool as a permanent strategy, because you are still accumulating the same upgrade debt while paying to defer it, and the software stack keeps aging away from what the ecosystem targets. ## How to answer this in an interview The strong answer names the mechanism (publishing stops; the risk is silent), states the constraint (no skipping LTS releases), and then makes a judgment call rather than reciting all three options: rebuild what is disposable, upgrade in place what is not, and use ESM only to buy a scheduled, finite amount of time. The strongest answers finish with prevention — an LTS has a five-year clock that is known on day one, so the upgrade belongs on the roadmap years before it becomes an incident.