Migration from a VPS Ubuntu 20.04 to 22.04 step by step

1. What you should check before migrating

The first step is to know exactly what you are running. You have to check the system version, kernel, free space, memory, network interfaces and failed services. If errors already exist before the migration, When updating you will have more variables and diagnosing will be much worse.

Practical recommendation: if the disc is very tight, expand it first. The update can download hundreds of packages and generate logs, caches and additional kernels. Making a major change with less than 2 or 3 GB free is bad idea.

2. Complete server inventory

This point is usually omitted and then you pay dearly. You need a photo of the current state: installed packages, enabled services, scheduled tasks and open ports. When something stops working in 22.04, this inventory will allow you to compare and retrieve much faster.

In addition to the technical inventory, manually write down at least these items:

• Hosted domains and Nginx or Apache vhosts.
• Versions of PHP, Node.js, Python, Java or any runtime installed.
• Active databases and approximate size of each one.
• External APT repositories: Docker, NodeSource, MongoDB, Elastic, PostgreSQL PGDG, etc.
• Old dependencies or unsupported software.

3. Mandatory backups

Before migrating, the most important copy is the supplier snapshot. If the boot fails, yes the SSH service breaks or if the system becomes inconsistent, the snapshot is the fastest way out. Still, It is also advisable to make copies at the file and database level.

If your VPS uses MySQL, MariaDB, PostgreSQL or Redis, make explicit copies and verify that they are generated without errors:

4. Review of external repositories and retained packages

Many migrations fail for a very specific reason: the base system goes up to 22.04 but the server depends on third party repositories that were only prepared for 20.04. Before continuing, check which APT sources you have active and what packages are on hold.

What you should do here:

• Identify files within /etc/apt/sources.list.d/.
• Check if each provider supports Ubuntu 22.04 Jammy.
• Temporarily disable unsupported repositories.
• Review held packages with apt-mark showhold.

If, for example, you depend on an old version of PHP, MongoDB or Node.js, first validate whether it will continue to work in 22.04. Don't wait to discover incompatibilities after the reboot.

5. Leave Ubuntu 20.04 fully updated

You should not jump from a partially updated system. First you have to bring 20.04 to its latest state stable, clean obsolete packages and reboot to boot with the latest kernel available within that branch.

After the reboot, log back in via SSH and confirm that everything is still operational: website, certificates, database, cron, workers and firewall.

6. Configure the system to receive LTS releases

Ubuntu uses update-manager-core to manage this version jump. You must ensure that the politics is in Prompt=lts, especially if the server does not receive release notifications normal or if the file was previously modified.

7. Launch the migration to Ubuntu 22.04

The main command is sudo do-release-upgrade. During execution, Ubuntu usually does several important questions:

1. Confirmation of start of the update.
2. Notice for using SSH and temporarily opening an alternative port.
3. Detection of services that will need to be restarted.
4. Questions about modified configuration files in /etc.
5. Removal of obsolete packages at the end of the process.

There is no universal answer to configuration conflicts. If you customized a file like sshd_config, nginx.conf, php.ini or a repository file, it is wise to compare changes and not automatically overwrite without knowing what your current version contains.

9. Reboot and basic validation after migration

Once the update is finished, restart if the wizard doesn't do it for you. The first start is key: checks version, kernel, pending packages and errors of the current boot.

The goal here is to confirm two things: that you are really on 22.04 and that the system has not failed silent.

10. Validation of web services and application stack

In a VPS for hosting or applications, the operating system is only one part. Then it's time to review each service real of the business. Start with the main demons:

Then validate the installed versions. In Ubuntu 22.04 they change libraries, OpenSSL, base PHP, Python system and, depending on your installation, also some service names.

And finally check local connectivity, listening sockets and firewall:

11. Functional validations that you should do at a minimum

• Open the main website via HTTP and HTTPS and review response codes.
• Check TLS certificates and auto-renewal with Certbot if you use it.
• Enter the administration or login area.
• Test uploading files, forms and sending email.
• Run real queries against the database.
• Verify workers, queues, PM2 processes and cron jobs.
• Review Nginx, Apache, PHP-FPM, MySQL, PostgreSQL and application logs.

If you use Node.js or Docker, pay close attention to native libraries and changes to OpenSSL. There are applications that They start but fail at runtime due to modules compiled against old versions.

12. Typical problems after moving to 22.04

• External APT repositories disabled or still pointing to focal.
• PHP version change and modules not installed in the new branch.
• Services that do not start due to legacy configuration files.
• Node applications incompatible with the version available on the server.
• Old containers or images that depend on host libraries.
• Firewall rules or ports other than expected.
• Cron jobs that depend on paths or binaries that no longer exist.

The recommendation here is simple: don't try to correct everything at once. Prioritizes SSH access, network, front-end web, database and then secondary processes.

13. Rollback plan

If the migration leaves the VPS unstable and the recovery time is high, the correct thing to do is to go back. The method The faster it usually is to restore the provider snapshot. If the system boots but there are missing settings or data, you can restore partial backups.

In serious environments, rollback should not be improvised. You must decide before migrating: If SSH, web and database are not recovered in X minutes, snapshot is restored.