Upgrade Plesk from AlmaLinux 9 to 10 with almalinux9to10

Plesk published almalinux9to10 on GitHub in October 2026, and the 18.0.82 release notes list it with the other new OS upgrade scripts. It is the first supported way to move a Plesk server from AlmaLinux 9 to 10 without rebuilding it. Plesk has supported fresh installs on AlmaLinux 10 since Obsidian 18.0.72, but until now the only route for existing servers was a migration.

This guide covers the tool's requirements and blockers, how to run it, how to recover when it stops, and when migrating is still the better choice. It is for operators running Plesk on their own KVM or dedicated servers.

Do you need to upgrade now

AlmaLinux 9 gets active support until 31 May 2027 and security fixes until 31 May 2032. Nothing forces a Plesk 9 box to move this year. The reasons to go now are newer base packages, a longer runway for new customers, and doing the upgrade in a quiet window instead of during the 2027 rush.

The reasons to wait are real. The tool is v1.0.0, released on 16 October 2026, and has almost no field reports yet. AlmaLinux 10 also has gaps on Plesk:

• Mailing lists. Mailman is not supported on Plesk for AlmaLinux 10. Plesk staff said in October 2026 that the task is backlogged with no ETA. If customers use mailing lists, stay on 9.
• Watchdog. The Watchdog extension is unavailable because its monit dependency is not in EPEL 10.
• SOGo webmail. The SOGo extension does not run on AlmaLinux 10. Roundcube does.

In-place upgrade or migrate

Migrate instead if the server runs in a container, if it has years of hand-installed packages, or if its CPU only supports x86-64-v2 (see below). For a clean KVM or bare-metal box, the in-place tool is faster. A fresh build follows installing Plesk on AlmaLinux 9 with the AlmaLinux 10 image, then Plesk Migrator.

Before you start

The tool's README sets these requirements:

• Plesk 18.0.71 or later, and no more than five releases behind the latest. With 18.0.82 current, that means 18.0.77 or newer. Update first with plesk installer update.
• AlmaLinux 9. Other RHEL 9 rebuilds are untested.
• EPEL enabled. Plesk on AlmaLinux 10 needs perl-Digest-SHA1 from EPEL.
• MariaDB as the database server. Servers on MySQL Community must move to MariaDB first.
• XFS filesystems with the crc and bigtime features, and grub2.
• At least 5 GB free in /var/lib, 250 MB free in /boot, and 3 GB of memory, with at least 1.5 GB of it physical RAM.
• No Webalizer, and no PHP 7.1, 7.2, or 7.3. The tool refuses to run if those PHP versions are installed. It removes PHP 5.5 and older itself.
• Only one kernel-named interface such as eth0.

You also need out-of-band console access (IPMI, KVM-over-IP, or your provider's VNC console). During conversion the temporary OS does not bring up the network, so SSH is gone for 15–30 minutes. Take a full backup with Plesk Backup Manager to S3 or Wasabi, then a hypervisor snapshot immediately before you start.

Pre-flight checks

plesk version
dnf repolist enabled | grep -i epel
xfs_info / | grep -E "crc|bigtime"
df -h /var/lib /boot
ls /sys/class/net
plesk bin php_handler --list | grep -E "7\.[123]"
/lib64/ld-linux-x86-64.so.2 --help | grep x86-64-v

Things to check in the output:

1. bigtime=0 on XFS. You can enable it without reformatting, but only while the filesystem is unmounted. For root, boot into rescue mode and run xfs_admin -O bigtime=1 against the root device. Filesystems with crc=0 (the old v4 format) cannot be converted. Back up, recreate with mkfs.xfs, and restore.
2. PHP 7.1–7.3 handlers. Move any subscriptions still on them, then remove those PHP versions in the Plesk installer.
3. CPU level. If the ld-linux line does not show x86-64-v3 (supported, searched), the CPU is v2-only. Standard AlmaLinux 10 targets v3. AlmaLinux's v2 upgrade path runs through ELevate NG and is still for testing, and the Plesk tool does not document v2 support. Migrate those servers instead.

Run plesk repair all -n as well. The Plesk repair utility checks everything in diagnostic mode, and the upgrade will not fix what it reports.

Run the upgrade

Check the repository's Releases page for a newer version first. At the time of writing, v1.0.0 is the only release:

wget https://github.com/plesk/almalinux9to10/releases/download/v1.0.0/almalinux9to10-1.0.0.zip
unzip almalinux9to10-1.0.0.zip
chmod 755 almalinux9to10
./almalinux9to10 --show-plan

If the plan is clean, start it inside screen:

screen -S almalinux9to10
./almalinux9to10

The run has three stages and reboots three times:

1. Preparation (30–40 minutes). Installs ELevate, disables Plesk services, runs the Leapp pre-upgrade, and reboots.
2. Conversion (15–30 minutes). A temporary OS converts packages to AlmaLinux 10 and reboots. There is no network, so watch it on the serial console.
3. Finish (5–10 minutes, longer with many sites). Runs on first boot of AlmaLinux 10, restores Plesk services, configuration, and databases, then reboots one last time.

Reconnect after each reboot and follow progress:

./almalinux9to10 --status
./almalinux9to10 --monitor

When it succeeds, the SSH login banner says the conversion is complete. Remove that message from /etc/motd.

Options you may need

• --migrate-network-config converts legacy ifcfg files to NetworkManager keyfiles. Without it, the tool refuses to run while ifcfg files exist. If cloud-init regenerates them, disable that first.
• --fix-deprecated-if-scripts wraps /sbin/if*-local scripts into NetworkManager dispatcher scripts.
• --upgrade-postgres upgrades hosted PostgreSQL databases. PostgreSQL older than 10 blocks the run unless you use it.
• --remove-unknown-perl-modules removes CPAN modules with no RPM equivalent. Only use it if nothing needs them.

Avoid --allow-unsigned-packages and --allow-raid-devices unless you understand the risk. The first marks the conversion unsupported. The second can leave the server unbootable.

When it stops

Logs live in three places:

• /var/log/plesk/almalinux9to10.log for the tool itself
• /var/log/leapp/leapp-upgrade.log for ELevate
• /var/log/leapp/leapp-report.txt for the inhibitors that stopped the pre-upgrade

The common failures, from the README:

• Leapp cannot handle a package. Usually something from a custom repository. Remove it, rerun, and reinstall it on AlmaLinux 10.
• Package conflicts between el9 and el10. Usually a non-standard repository left enabled. Disable everything except the AlmaLinux, EPEL, and Plesk repositories.
• The temporary OS hangs. Check the serial console, then reboot. An interrupted run can leave packages missing, which is when you restore the snapshot.
• The finish stage fails on first boot. The login banner points to the log. Fix the cause and run ./almalinux9to10 --resume.

For a bug report, run ./almalinux9to10 --prepare-feedback and attach the archive to a GitHub issue.

After the upgrade

cat /etc/almalinux-release
plesk version
systemctl --failed
dnf check-update

dnf check-update exposes any vendor repository still pointing at el9. Security agents and backup tools ship their own repositories, so confirm each one resolves for el10, or reinstall from the vendor. For Imunify360, follow installing Imunify360 on Plesk. If plesk installer update then fails, work through the Plesk update failure checklist. Finish with plesk repair installation, then test mail, FTP, and one site per PHP handler.

The OS upgrade does not touch your license. The key stays bound to the same installation. If you migrate instead, you need a second key during cutover. That is a good moment to check whether a different edition fits, using Plesk license tiers explained. Running CloudLinux rather than AlmaLinux? See migrating CloudLinux 8 or 9 to CloudLinux OS 10.

Next steps

• Read what else changed in Plesk Obsidian 18.0.82, the release that announced the tool.
• Compare with the Debian route in upgrading Plesk from Debian 11 to 12.
• Renew or change editions on the Plesk license page.