Ubuntu 20.04 to 22.04 / 24.04 migration

Ubuntu 20.04 LTS reached the end of standard support on May 31, 2025. Ubuntu Pro and Expanded Security Maintenance can extend security coverage, but ESM is a way to buy time. It is not a migration plan.

Source facts last checked May 3, 2026: Ubuntu 20.04 LTS page, Ubuntu ESM overview, and Ubuntu security ESM documentation.

For many VPS-hosted PHP, WordPress, Laravel, and WooCommerce systems, Ubuntu 20.04 is where the hidden risk now sits. The application still runs, but package sources, PHP builds, database packages, and support expectations are moving on.

1. Confirm the server inventory

Before deciding between Ubuntu 22.04 and 24.04, map what the current server actually runs.

• lsb_release -a or /etc/os-release
• uname -r
• pro status
• apt sources and PPAs
• PHP version and package source
• MySQL or MariaDB version
• web server and enabled modules
• Node, Python, Ruby, Java, or other runtime versions
• cron jobs and systemd services
• backup agents, monitoring agents, and security tools

On older VPS systems, the OS is often less important than the third-party repositories bolted onto it. Every PPA needs a target equivalent before migration day.

2. Pick 22.04 or 24.04 as a business decision

Ubuntu 22.04 is usually the conservative target for older stacks because the ecosystem has had more time to settle around it. Ubuntu 24.04 gives a longer runway and newer packages, but it can expose compatibility issues in older runtimes and extensions.

Use 22.04 when:

• the app is already fragile
• PHP or MySQL compatibility is unclear
• the hosting provider has stronger 22.04 support
• you need the smallest operational jump

Use 24.04 when:

• the app is already compatible with current PHP and database versions
• staging can mirror production
• you want the longer LTS runway
• the hosting platform treats 24.04 as its default

Avoid turning the OS migration into a full application rewrite. The first target is a supported server baseline.

3. Prefer a new server cutover

For revenue-critical systems, a fresh server cutover is usually safer than an in-place do-release-upgrade.

A new server lets you:

• build the stack cleanly
• document every package installed
• test web server configuration before DNS moves
• sync files and database deliberately
• keep the old server intact for rollback
• rehearse the cutover

In-place upgrades can work, especially for small low-risk systems. But rollback usually means restoring a server backup. That is a very different risk profile from changing DNS or load-balancer routing back to the old host.

4. Treat PHP and MySQL as separate risks

An Ubuntu migration often forces runtime decisions.

Check:

• whether the current PHP version exists on the target OS
• whether the app should move to PHP 8.3 or 8.4 at the same time
• whether MySQL 8.0 is being replaced by MySQL 8.4 LTS
• whether MariaDB is involved instead of MySQL
• whether Composer can install on the target runtime
• whether extensions are available under the same names

If PHP is the main risk, use the PHP 8.1 / 8.2 upgrade checklist. If the database is moving too, use the MySQL 8.0 to 8.4 LTS checklist. Do not hide those decisions inside “upgrade the server.”

5. Rebuild operational behavior

The application is not migrated until the operational behavior is migrated.

Confirm:

• cron entries and exact command paths
• systemd unit files and service users
• file permissions and upload directories
• log rotation
• SSL certificate renewal
• firewall rules
• fail2ban or equivalent protections
• backup jobs and restore process
• monitoring and alerting
• mail sending and DNS records

The most common post-migration failures are boring: a cron path still points at the old PHP binary, an upload directory has the wrong owner, or the backup agent was never installed on the new server.

6. Cut over with a rollback window

Before DNS changes, write the cutover plan in the order it will be executed.

• lower DNS TTL in advance
• freeze writes if needed
• take final database and file backup
• sync final data
• run smoke tests on the new server
• switch DNS or routing
• watch logs and business flows
• keep the old server read-only during the rollback window

Do not destroy the old server after a green homepage check. Keep it available until cron, payments, forms, backups, and the first normal business cycle have been observed.

When to audit first

Start with an audit when the server has unknown PPAs, no restore test, old PHP, old MySQL, no staging environment, manual deploys, or a client deadline driven by a host support notice.

The audit should produce a server inventory, upgrade target recommendation, dependency risk register, cutover plan, rollback path, and a 30 / 60 / 90-day sequence. Without that, the OS migration becomes the discovery process.