Ubuntu 26.04 LTS "Resolute Raccoon" shipped on April 23, 2026 — but if your server runs 24.04 LTS, do-release-upgrade has spent the last four months telling you there is no new release available. That isn't a bug: Canonical does not open the LTS-to-LTS upgrade path on release day, it opens it at the first point release. On the official schedule, that point release — 26.04.1 — is set for August 27, 2026.

Why the Wait Exists

Those four months belong to the upgrade path itself. Blockers found after 26.04 went out — package dependency conflicts, config migration failures, driver regressions — get fixed and folded into the 26.04.1 media and upgrader. Waiting for .1 isn't caution; it's the first day the path has actually been tested.

The calendar is worth doing honestly too. Standard security maintenance for 24.04 LTS runs to May 2029, so there is no emergency. 26.04 LTS carries standard maintenance to May 2031 and Expanded Security Maintenance to May 2036. If you're still on 22.04 the picture inverts: its standard support ends in April 2027, and there is no direct jump to 26.04 — you go 22.04 to 24.04 first, then 24.04 to 26.04, so budget for two upgrades rather than one.

Five Things That Matter on a VPS

  • Take a snapshot you can actually roll back to: if the upgrade dies halfway, restoring the whole machine is far faster than hand-repairing packages. No snapshot capability? Take a full backup and verify the restore — an untested backup isn't a backup.
  • Leave yourself a way back in over SSH: do-release-upgrade starts a second sshd on port 1022 as a fallback in case the main connection drops. Open that port in your firewall and cloud security group first, or a dropped session locks you out. Run the whole thing inside tmux or screen so a network blip doesn't kill the upgrade process.
  • Deal with third-party repos first: the upgrader disables most PPAs and third-party apt sources, but repositories you added yourself for Docker, Node, PHP or a database are worth checking in advance for a 26.04 branch — otherwise you finish the upgrade with a set of packages pinned to the old release.
  • Look up the major-version jumps beforehand: crossing two LTS releases can move PHP, MySQL/MariaDB, Python and Node across major versions. Rehearse the same stack on a throwaway hourly instance, collect the error list, and only then touch production.
  • Don't do it at peak: config conflict prompts (keep the local version or take the maintainer's) need human judgement, especially for nginx, sshd and postfix. When it finishes, reboot and verify each service individually rather than accepting "the machine came back up" as proof.

There Is a -d Flag — Don't Use It in Production

Administrators can force an early upgrade with do-release-upgrade -d before the path opens. That route exists for testing, and Canonical does not recommend it for production systems. With the normal path opening on August 27 anyway, there's little reason to take the risk.

Treat the Upgrade as a Drill

An LTS-to-LTS upgrade happens once every two years, and that rarity is exactly why the first attempt goes badly. The sane approach is to run the whole thing on a cheap small instance first: same stack, same command, notes on every point where a human decision was required — then repeat it on production. SharkCloud has nodes in Japan, Singapore, Hong Kong and the US, and the cost of a temporary instance for a rehearsal is far below the cost of a production box stalling mid-upgrade.