TL;DR: What you need to know
Moving to Ubuntu 26.04 means moving your sites to a brand-new 26.04 server. Our recommended route is Migrately, which copies a whole server in one go. The Server Clone tool in your dashboard is also available if you’d rather avoid the command line.
The golden rule: build the new server with the same web stack (Nginx or OpenLiteSpeed) and the same database type (Percona or MariaDB) as your current server. Moving between Percona and MariaDB on 26.04 is likely to fail, and support for fixing those failures is limited.
If your current server runs Ubuntu 18.04 or 20.04, please be aware these are unsupported stacks and it’s likely Redis caching (object and page) will need a few extra steps before and after the move, and even with those precautions you may need to roll up your sleeves – but we will be happy to provide guidance if you need it.
Introduction
Ubuntu 26.04 is our newest server stack. It runs newer database versions and a different Redis setup from older servers, so a move takes a little more planning than usual.
This article is a rundown of the recommended course of action and what to watch for. It doesn’t repeat step-by-step instructions. For those, see these articles:
What Changes on 26.04
Every move is also a database upgrade
26.04 servers run Percona 8.4 or MariaDB 11.8. Percona 8.0 doesn’t run on 26.04, and MariaDB 10.11 isn’t published for it. So every site arriving on a 26.04 server lands on a newer database version than the one it left.
Percona and MariaDB are no longer interchangeable
MariaDB started as a copy of MySQL (which Percona is based on) and could stand in for it for years. That’s no longer true. By Percona 8.4 and MariaDB 11.8, the two have drifted far enough apart that a database exported from one may fail to load on the other.
The main culprit for WordPress sites is collations, the rules a database uses to sort and compare text. Each engine now has defaults the other doesn’t fully recognise, so tables created by plugins can carry one engine’s collation into the other and break the import.
In short: treat Percona and MariaDB as two different databases, and keep each site on the type it came from. More information is available here:
Migrating From 18.04 / 20.04
Ubuntu 20.04 is also past the end of standard support. Our help for servers on this version is limited to providing guidance on migrating to a supported release, and we can’t help troubleshoot other issues. Security updates are also rarely backported to Ubuntu 20.04 or the software packages it runs (such as PHP, Redis, Percona, and MariaDB). Begin steps to migrate off of this release as soon as possible.
Ubuntu 18.04 reached its EOL over 3 years ago on May 31, 2023. We cannot provide support for 18.04 servers.
Redis is set up differently than on 18.04 / 20.04
Newer servers run separate Redis services for object caching and page caching. Servers on 18.04 and 20.04 use a single shared Redis. If you’re coming from one of those, sites with Redis caching switched on won’t have working caches after the move unless you follow the extra steps in the Migrately article.
Before You Start: Checklist
- Note your current server’s details. Check its Ubuntu version, web stack (Nginx or OpenLiteSpeed) and database type (Percona or MariaDB) in your GridPane dashboard. You can find these details inside your server customizer.
- Check your disk space. The new server should have at least double the space your sites currently use, with room left over.
- Provision a brand-new 26.04 server with the same web stack and the same database type. If you’ve built one with the wrong stack or database, delete it and provision a new one.
- Keep the new server empty. A full-server migration overwrites everything on the destination, so don’t use a server holding anything you want to keep.
- Switch off WP_DEBUG on any site that has it on. It can cause a fatal error on the destination site.
- List any custom server work, such as extra software, server-level cron jobs, or custom server-wide configs. Some of this may need recreating on the new server (see below).
- On 18.04 or 20.04? Plan for the extra Redis steps: caching gets switched off before the move and back on afterwards.
- Pick a quiet time for the cutover, or plan to put sites in maintenance mode while the final copy runs.
The Recommended Path: Migrately
Migrately is the same command-line tool our support team uses to move sites between servers. It works from any supported stack (22.04, 24.04 or 26.04) and copies the whole server in one run: every site’s WordPress files, the full database, web server and PHP settings (including custom rules like server-wide 7G and cache exclusions), Redis settings, and SSL certificates.
You run it from your current server, and it works through each stage in order: building sites on the new server, copying files and databases, then moving settings across. If one site can’t be moved, Migrately skips it, carries on with the rest, and tells you exactly what needs fixing at the end.
Full instructions: Migrately – A CLI Tool for Full Server to Server Cloning.
The alternative: the Server Clone tool
If you’d rather not use the command line, the Server Clone tool on the Tools page of your dashboard clones your production sites (and, optionally, their staging sites) to a new server. It works site by site, using the same process as cloning a site to another server. A few things to know:
- Server-level configs aren’t copied. Things like an Nginx config for WP Rocket or webp, extra software, and server-level cron jobs need to be set up again on the new server.
- Canary sites are skipped and won’t be transferred.
- AutoSSL doesn’t transfer. This mostly matters for multisite networks.
- Coming from 20.04 or earlier? The same Redis steps apply, and you’ll need to run a few commands over SSH to finish the move.
Full instructions: Cloning One Entire Server to Another.
During and After the Migration
Your sites stay live. Migrately doesn’t pause anything, so visitors and orders keep reaching the old server until you switch DNS. For a clean cutover, stop new changes on the old sites (maintenance mode or a quiet window) before the files and databases are copied, so nothing gets left behind.
Expect it to take a while. The more data on the server, the longer it takes. Running the job in a screen session keeps it going if your connection drops, and any step can safely be re-run.
Check before you switch DNS. Migrately’s built-in check compares posts, users, plugins and themes between the two servers. Resolve any sites listed in the end-of-run summary first. To preview the new server before DNS changes, use a local hosts file entry.
Check your caching, especially if you came from 18.04 or 20.04. Confirm Redis object and page caching are working on the new server before going live. If you had a custom Nginx Redis override file, review it: it’s copied across as-is and may still point at the old Redis.
Copy backup settings last. Migrately can match your local and remote backup schedules, but only do this once you’re confident the migration succeeded.
Point DNS at the new server once everything checks out. You may still want to keep the old server for 1-2 weeks before deleting it, so you have a fallback and backups have time to run on the new server.
Backups, Restores, Clones, and Staging on 26.04
The same-database-type rule applies to every job that moves a database, not just migrations. Keep clones, staging pushes and restores on the same type: Percona to Percona, MariaDB to MariaDB.
Older backups still restore. 26.04 servers carry two versions of the backup tool (mydumper), one for each database type. That means a backup taken on a 24.04 Percona 8.0 server can restore onto a 26.04 Percona 8.4 server, and a MariaDB 10.11 backup onto MariaDB 11.8, as long as the type matches.
Backups stay clean. Clones, staging pushes and backups each name their database exports differently. They can run at the same time on the same site without overwriting each other, and a backup never accidentally picks up a stray clone or staging export.
If Something Goes Wrong
Moved between Percona and MariaDB and it failed? A move between the two types can stop partway through, leaving a site with its files copied but not its database, or worse. Support for these cross-type moves is limited. The fix is almost always to provision a new 26.04 server with the matching database type and migrate again.
A step failed or a site was skipped? Migrately is built to pick up where it left off, so re-running the same step is usually safe. Its end-of-run summary lists each affected site, the step it stopped at, and what to do.
Already migrated from 18.04 / 20.04 with Redis caching on? Nothing is lost. Your sites are still pointing at the old Redis setup, and the Migrately article has a short repair procedure.
Still stuck? Contact support with the server and site names, and the output from your migration run.