Ubuntu 26.04 LTS Upgrade Plan: Timeline and Checklist

How to plan your Ubuntu 26.04 LTS upgrade. Covers timeline expectations, hardware compatibility checks, package hold audits, and rollback strategies.

April 10, 2026·Linux Linux Administration

ubuntultsupgradechecklistlinux

Ubuntu 26.04 LTS is the next long-term support release, expected in April 2026. For organisations running Ubuntu 22.04 or 24.04 LTS in production, the upgrade represents a two-year (or four-year) jump in kernel, toolchain, and package versions. Getting it right requires planning that starts well before the release date.

This article provides a structured upgrade plan with timelines, pre-flight checks, upgrade procedures, rollback strategies, and post-upgrade validation. It is written for system administrators and SREs who manage Ubuntu servers in production environments.

The Linux topic hub covers broader system administration resources, and the Linux administration learning path provides a structured progression from command-line basics to production operations.

Release timeline and planning

Expected milestones

April 2026: Ubuntu 26.04 LTS release
April–July 2026: initial adoption period, point release 26.04.1 expected around July
July 2026 onward: safe for production adoption

Recommended timeline for production

Now: begin testing in non-production environments
GA (April 2026): test with your specific workloads on staging
26.04.1 (July 2026): begin production rollout for non-critical systems
Q4 2026: complete production rollout

Do not upgrade production servers on release day. Wait for the first point release, which addresses the most common bugs found in the initial weeks.

Pre-flight checklist

Run through these checks before upgrading any system:

1. Inventory your systems

Document every Ubuntu server: version, kernel, role, installed packages, custom repositories, and any kernel modules or DKMS packages. Systems with custom kernels or third-party drivers require extra testing.

2. Check application compatibility

Verify that every application running on the server supports the new versions of:

Python (Ubuntu 26.04 will ship a newer default Python)
GCC and glibc
OpenSSL (major version changes can break TLS configurations)
Database clients and drivers
Container runtimes (Docker, containerd)

3. Audit third-party repositories

Third-party APT repositories may not have packages built for the new release. Check each repository and either confirm compatibility or plan to disable it during the upgrade.

4. Test your configuration management

If you use Ansible, Puppet, Chef, or similar tools, run them against a 26.04 test instance. Look for:

Package name changes
Configuration file format changes
Service name changes (systemd unit renames)
Path changes for binaries and configuration

5. Verify backup and restore

Take a full backup of the system (including /etc, /home, and any application data). Test the restore process on a separate machine. If you cannot restore, you cannot safely upgrade.

6. Review kernel module compatibility

Custom kernel modules (DKMS packages, out-of-tree drivers) must be compatible with the new kernel. Test each one on a staging system.

Upgrade procedures

Option 1: do-release-upgrade (in-place)

The standard Ubuntu upgrade path:

Update and upgrade all current packages: sudo apt update && sudo apt dist-upgrade
Reboot to ensure the latest kernel is running
Run sudo do-release-upgrade
Follow the prompts, paying attention to configuration file merge decisions
Reboot
Verify services are running

Option 2: fresh install and restore

For systems where the in-place upgrade risk is too high:

Provision a new server with Ubuntu 26.04
Apply your configuration management
Restore application data from backup
Test
Switch traffic from the old server to the new one
Decommission the old server

This approach is cleaner but requires more infrastructure and a DNS or load balancer change.

Option 3: image-based deployment

If you use immutable infrastructure (AMIs, VM images, containers):

Build a new base image with Ubuntu 26.04
Apply your provisioning scripts
Deploy new instances from the image
Drain and terminate old instances

This is the safest approach for cloud-native environments.

Rollback strategy

In-place upgrade rollback

Ubuntu does not natively support rolling back a do-release-upgrade. Your rollback options are:

Restore from backup: restore the entire system from the pre-upgrade backup. This is the most reliable rollback.
Snapshot revert: if the server is a VM, take a snapshot before upgrading and revert if needed.
Btrfs/ZFS snapshots: if the filesystem supports snapshots, take one before upgrading.

The key requirement: your rollback mechanism must be tested before you start the upgrade.

Fresh install rollback

If you used the fresh install approach, rollback is simply routing traffic back to the old server (which is still running).

Post-upgrade validation

After upgrading, validate:

All services start and run correctly. Check systemctl list-units --failed for any failed units.
Application health checks pass. Run your monitoring health checks and end-to-end tests.
SSL/TLS connections work. OpenSSL version changes can affect cipher suite availability and certificate validation.
Cron jobs execute. Check crontab entries and systemd timers.
Logging works. Verify that syslog, journald, and application logs are being written correctly.
Network configuration is intact. Check IP addresses, routes, firewall rules, and DNS resolution.

Common upgrade pitfalls

Pitfall: configuration file conflicts. During do-release-upgrade, you are prompted to keep your configuration or accept the maintainer's version. The wrong choice can break services. Review each conflict carefully.

Pitfall: third-party repository breakage. Repositories that do not have packages for the new release will cause APT errors. Disable them before upgrading.

Pitfall: kernel module incompatibility. DKMS modules that do not compile against the new kernel will fail silently. Check dkms status after the upgrade.

Pitfall: Python version change. Applications that depend on a specific Python version (e.g., Python 3.12) may break if the new Ubuntu ships Python 3.14 as default. Use virtual environments to isolate Python versions.