What ends in May-June 2027
Ubuntu 22.04 LTS was released in April 2022. Its standard security maintenance ends in May 2027 according to ubuntu.com/about/release-cycle, and endoflife.date gives 1 June 2027 for the same milestone. Write "May-June 2027" in your plans and aim for the start of the window, not its last day.
After that date, a flaw fixed by Canonical is no longer fixed for you, unless you subscribe to Ubuntu Pro, which extends security maintenance to 2032 (the exact month differs between sources: April for endoflife.date, May for ubuntu.com, hence the year alone). The real cost of migrating is not the licence, it is time: a maintenance window, a trial clone and site-by-site validation.
For a fleet, the deadline reads in three columns: how many servers still run 22.04, which of them carry cPanel, which are plain application VPS. Each column has its own procedure. The full 2027 end-of-life schedule is in our 2027 end-of-life calendar: here we only cover this one line.
What this guide lets you do
- Date the deadline correctly — May 2027 for Canonical, 1 June 2027 for endoflife.date: plan before the window opens.
- Decide client by client — in-place upgrade, ELevate or new server, using measurable criteria rather than habit.
- Know what cPanel imposes — deprecation in version 132, removal in version 136, and why
do-release-upgradeis not run by hand on a cPanel server. - Have a real safety net — a server image that has already been restored once, not a promise of a backup.
- Anticipate what breaks — disabled third-party repositories, PHP, nginx, SSH, packages removed during the upgrade.
- Keep a way back — a named point of no return and a restore planned before you press Enter.
cPanel & WHM: 22.04 deprecated in 132, removed in 136
The "deprecation plan" page of the cPanel documentation lists Ubuntu 22.04 LTS among the deprecated, then removed, features: deprecation in version 132, removal in version 136, with the instruction "Use ELevate to upgrade to Ubuntu 24.04 LTS". The page gives no release date for these versions and we do not offer one: follow cPanel's own version schedule rather than a date read on a third-party site. It does not say whether an in-place upgrade outside ELevate is supported either.
On the ELevate side the instruction is clear: the tool wraps do-release-upgrade because running the distribution tool directly on a cPanel installation leaves it unusable. On a cPanel server the cPanel documentation points to ELevate; the other route is a new server on 24.04 to which you transfer the accounts. A plain application VPS without a control panel follows the standard Ubuntu procedure.
In-place upgrade or new server: the decision criterion
An in-place upgrade keeps the IP address, the accounts and the configuration. It fails where the server has drifted from a standard installation. A new server costs an account transfer, but leaves the old machine untouched until the DNS switch: it is the only scenario where rolling back simply means not switching.
Decide with four questions. Does your backup cover the whole system? cPanel account backups only protect data managed by cPanel, not the programs or system settings: after a failure you would have to reinstall the OS, cPanel, then restore the accounts. How much downtime does the client accept? ELevate can exceed 30 minutes and reboots the server several times. How many customisations live outside packages (third-party repositories, hand-built PHP, scripts)? Each one is an unknown during the upgrade. Finally, is the server described in code, Ansible or otherwise? If so, rebuilding it is faster than repairing it.
Rule of thumb: a historic, heavily customised server, or one whose backup has never been restored, goes to a new server. A standard server, an image restored successfully and an accepted window: upgrade in place.
Which route for which server
Scroll the table
| Server situation | Recommended route | Why |
|---|---|---|
| Application VPS on 22.04, no control panel, few third-party repositories | In-place upgrade with `do-release-upgrade` | Standard Ubuntu procedure, rollback by restoring the image |
| Application VPS described in code (Ansible, Compose) | New server on 24.04 | Rebuilding costs less than repairing, the old one stays intact until the switch |
| Standard cPanel server, restorable system image | In-place upgrade with ELevate | In-place upgrade via ELevate, the tool the cPanel documentation points to, with blocker detection before starting |
| Heavily customised cPanel server or backup never restored | New server and account transfer | Account backups do not cover the system; a transfer keeps the source intact |
| Sites on PHP older than 8.1 on the cPanel server | New server, or migrate the sites first | ELevate blocks if a user runs a PHP version that is too old |
| Server in a container-like environment | New server | ELevate refuses to run in a container-like environment |
Prerequisites with real figures before launching anything
For a standard VPS, the Ubuntu documentation asks for a fully updated system, room for several gigabytes of download and someone present: the upgrade is interactive and can take several hours. Plan an out-of-band console (the provider's web console or VNC) in case SSH does not come back.
For a cPanel server, ELevate publishes its free-space thresholds: 5 GB on /, 120 MB on /boot, 750 MB on /tmp for Ubuntu, 1.5 GB on /usr/local/cpanel and 5 GB on /var/lib. It requires interactive root access, a valid cPanel licence, the latest minor release of the cPanel version expected for your system (the ELevate documentation asks for version 134 when starting from Ubuntu 22: re-read that prerequisite on the day) and JetBackup 5 or later if you use it. Neither upcp nor a cPanel backup may be running at start. And plan several ways into the server: SSH, the provider console, and if possible IPMI.
Procedure for an application VPS, no control panel
Take inventory
Note the system version with
lsb_release -a, the third-party APT sources withls /etc/apt/sources.list.d/, then the versions of what serves your sites:php -v,nginx -v,mysql --version. This list becomes your test plan.Back up, then restore once
Take an image of the VPS at the provider and restore it on a test machine: a backup that has never been restored is a hypothesis. Back it with an off-server copy of the databases, volumes and
/etc. Our guide on Restic backups on a VPS explains the setup.Upgrade a clone first
Create a trial VPS from the image and run the whole procedure on it. Record every question the tool asks, every service that fails and every repository that gets disabled. The production upgrade should hold no more surprises.
Bring 22.04 fully up to date
Run
sudo apt updatethensudo apt dist-upgrade -o APT::Get::Always-Include-Phased-Updates=true, as the Ubuntu Server documentation prescribes. If the file/run/reboot-requiredexists, reboot before continuing.Open a session that survives a disconnect
Run
tmux new -s upgrade(orscreen) before the upgrade, so that losing the SSH connection does not interrupt the work in progress. Keep the provider console open in another tab.Start the upgrade
First check that a release is offered with
do-release-upgrade -c, then runsudo do-release-upgrade. The tool summarises what it will do and asks for confirmation. Warning from the documentation: once the download has finished, the process cannot be cancelled. That is your point of no return, and from then on restoring the image is your rollback.Answer the questions, reboot, re-enable
For each configuration file you modified, keep your version by default, except for the files needed to boot the new kernel. Reboot when the tool asks, because the system is only considered upgraded after that reboot. Then re-enable the disabled third-party repositories, rewriting them for 24.04, and replay your test plan.
Procedure for a cPanel server with ELevate
Check the starting point
Check the cPanel licence, the cPanel & WHM version expected by the ELevate documentation and the latest minor release installed. Update the system packages with
apt upgrade. Check that the MySQL or MariaDB version is compatible with Ubuntu 24.04.Take a full image of the server
ELevate takes no backup before upgrading. Snapshot the entire server and test restoring it: it is the only rollback the ELevate documentation describes in case of serious failure.
Download the script
Run
wget -O /scripts/elevate-cpanel https://raw.githubusercontent.com/cpanel/elevate/release/elevate-cpanelthenchmod 700 /scripts/elevate-cpanel. The script must run from/scriptsand be up to date.Run the dry-run check
/scripts/elevate-cpanel --checkchanges nothing and lists the known blockers: disk space, thesshd_configfile, PHP that is too old, a JetBackup version older than 5, a container environment, network interface names inethX. Re-run it until the report is empty.Clear the blockers one by one
Remove or migrate the sites that use a PHP version older than 8.1, give
upcpand backups time to finish, free up space. If cPanel manages your MySQL, the tool offers to move to MariaDB during the upgrade: decide that with the client, before the window.Start and monitor
Run
/scripts/elevate-cpanel --start. The process runs in five stages with a reboot between each and a last one at the end, over more than 30 minutes of unreachable server. Follow it with/scripts/elevate-cpanel --statusand/scripts/elevate-cpanel --log. If the process stops on an error, fix it then run/scripts/elevate-cpanel --continue.Validate after the upgrade
Open WHM, check the services, each account's sites, mail sending and receiving, and scheduled tasks. Test the sites under the PHP they actually use, not just their home page.
What breaks between 22.04 and 24.04, according to the release notes
This section draws on the Ubuntu 24.04 LTS release notes, not on a trial of our own on your stack. First, third-party repositories and PPAs are disabled during the upgrade, which leaves Docker, PHP or a monitoring agent on the old source until rewritten. Ubuntu's sources move to the deb822 format, in /etc/apt/sources.list.d/ubuntu.sources.
On the web side, nginx moves to version 1.24 (the previous LTS shipped 1.18), Apache to 2.4.58 and PHP to 8.3.6, where 22.04 provides PHP 8.1. A site that depends on a function removed between those PHP versions shows up at run time, not at upgrade time. Python 3.12 becomes the default, which affects your administration scripts.
For connections, the sshd_config settings are now read by a systemd generator that drives the ssh.socket unit: check the listening port after the upgrade. needrestart restarts services affected by a library update, including during automatic updates. TLS 1.0, TLS 1.1 and DTLS 1.0 are forcibly disabled, which can cut off an old mail client. Finally, the freeradius package is removed by the upgrade tool without always appearing in the summary.
To test on the clone before the client window
- Third-party repositories — each disabled source must be re-enabled for 24.04, with its key handled without
apt-key. - PHP sites — replay each site's critical pages under PHP 8.3: forms, payment, scheduled tasks.
- nginx and Apache — run
nginx -tafter the upgrade and compare vhosts, modules and redirects. - SSH — check the port and key access with a second session open before closing the first.
- Mail — send and receive, including from an old client that TLS 1.0 or 1.1 would break.
- Removed packages — compare
apt list --installedbefore and after to spot a vanished package, likefreeradius. - Scheduled tasks and backups — a backup that silently fails after the upgrade is the costliest breakage.
Write the rollback before the window
Write down, before acting, who restores the image, how long it takes, and at which symptom you give up. Restoring is the only rollback once the upgrade has passed its point of no return: set the threshold in cold blood, not at 2 a.m. Prefer a window where the client can validate the next morning.
After 24.04: the road to 26.04 goes through it
The Ubuntu documentation forbids skipping an LTS: you move from one LTS to the next, so the 22.04 to 24.04 upgrade is the mandatory step before 26.04. Ubuntu 24.04 stays under standard security maintenance until May 2029: once upgraded, your servers are no longer urgent. The upgrade from 24.04 to 26.04.1 has been open since 29 September 2026, which leaves you the choice of timing; it is covered in our guide Upgrade Ubuntu 24.04 to 26.04 on a VPS.
The same reasoning, on another control panel, is in our guide Debian 11 end of life with Plesk. For a fleet, group by client: one maintenance window that handles system, PHP and database costs less than three visits.
