• Debian 11 is approaching its end-of-life (vendor EOL date - August 31, 2026). Plesk Obsidian 18.0.80 will be the last release to support it.
    If you are running Plesk Obsidian on Debian 11, we recommend you upgrade those servers to Debian 12 using our dist-upgrade tool.
  • We plan to deprecate and remove the support for XML RPC protocol versions earlier than 1.6.9.1 in Plesk Obsidian 18.0.82. We strongly recommend that you update all existing integrations using earlier versions of the XML RPC protocol to comply with the version 1.6.9.1 specification.

Question Moving Plesk from host with Ubuntu 22.04 to host with Ubuntu 26.04

pmg

Basic Pleskian
Server operating system version
Ubuntu 22.04
Plesk version and microupdate number
18.0.80 Update #5
Hi there,

I'm planning to migrate our Plesk from host with Ubuntu 22.04 to host with Ubuntu 26.04. Few questions:
  1. most important one, whether Ubuntu 26.04 is already supported?
  2. is there best-practice guide/blueprint/check-list for moving Plesk to new host?
  3. is there standard license transfer process?
Thanks!
 
1. most important one, whether Ubuntu 26.04 is already supported?
Not yet, but support will likely be introduced on the next release.

2. is there best-practice guide/blueprint/check-list for moving Plesk to new host?
See support article about migration. Equally as important, see this list of migration limitations. Not mentioned on this list but worth pointing out:
1. Webmail contacts and filter rules are not migrated either.
2. Any customization you might have done will not be transferred (think custom log rotations, custom configurations for services like Postfix, Dovecot, Nginx, SpamAssassin, ect).

3. is there standard license transfer process?
See this support article.
 
Not yet, but support will likely be introduced on the next release.


See support article about migration. Equally as important, see this list of migration limitations. Not mentioned on this list but worth pointing out:
1. Webmail contacts and filter rules are not migrated either.
2. Any customization you might have done will not be transferred (think custom log rotations, custom configurations for services like Postfix, Dovecot, Nginx, SpamAssassin, ect).


See this support article.
That's a lot of limitations.
Assuming:
- NO custom file edits being done,
- identical Plesk versions (extensions incl.),
- floating/elastic IPs,
- preserved userid/groupids between both servers
Is it enough to transfer /var/www/, /var/qmail and complete DB dump?
 
That's a lot of limitations.
Assuming:
- NO custom file edits being done,
- identical Plesk versions (extensions incl.),
- floating/elastic IPs,
- preserved userid/groupids between both servers
Is it enough to transfer /var/www/, /var/qmail and complete DB dump?
Doing a manual transfer of /var/www/, /var/qmail and DB dump instead of using the Plesk migrator you mean? Not something I ever tried, but I am pretty sure you'll lose most, if not all, of the user specific and Plesk configurations. It's likely much more of a hassle, would not recommend going down that route.

Personally I prefer to restore a backup on a new server as a method to migrate, instead of using the migrator. As restoring a backup also restores all server-wide settings from the Tools & Settings menu, which the migrator does not. It's more time consuming, but it's saves me having to do just one more manual post migration step.

What ever route you decide to go with, do a test run (or a couple) first. You're bound to bump into an issue, could be small, could be large. Doing a test run prevents you getting caught of guard.
 
Doing a manual transfer of /var/www/, /var/qmail and DB dump instead of using the Plesk migrator you mean? Not something I ever tried, but I am pretty sure you'll lose most, if not all, of the user specific and Plesk configurations. It's likely much more of a hassle, would not recommend going down that route.

Personally I prefer to restore a backup on a new server as a method to migrate, instead of using the migrator. As restoring a backup also restores all server-wide settings from the Tools & Settings menu, which the migrator does not. It's more time consuming, but it's saves me having to do just one more manual post migration step.

What ever route you decide to go with, do a test run (or a couple) first. You're bound to bump into an issue, could be small, could be large. Doing a test run prevents you getting caught of guard.
Thanks for the hint regarding backup/restore.
Could you please give couple of examples for `user specific and Plesk configurations`?
 
Could you please give couple of examples for `user specific and Plesk configurations`?
That's just my (educated) guess, as Plesk not only stores user and configuration data in it's PSA (MariaDB) database, but also stores configuration data in various files (mostly for services) and SQLite databases (mostly for extensions). If you just transfer the contents of /var/www/, /var/qmail and a DB dump to your new server, I suspect that you'll likely miss a bunch of data/configuration and run into trouble (sooner or later). But again, it's not something I ever attempted, so I am not sure how it would pan out exactly. Do a test run if you want to be sure :)
 
Back
Top