Where things stand since 31 August 2026
Debian provided two years of long-term support for Debian 11 (bullseye), until 31 August 2026. That date has passed: the Debian project no longer publishes security fixes for this release. Plesk has aligned its calendar: the announcement of 15 October 2026 states that Plesk Obsidian 18.0.81 is the last release to support Debian 11, and that the server can either be upgraded to Debian 12 with Plesk's dist-upgrade tool, or be replaced by a server running a supported system, to which you migrate the domains.
In practice, a Debian 11 server keeps running and serving its sites. But it will receive no Plesk update beyond 18.0.81 and no more system security fixes. The risk is invisible: it grows quietly, until the first flaw is published against a package nobody will patch.
What staying on Debian 11 means
- No more Debian fixes — the project's long-term support ended on 31 August 2026; flaws discovered afterwards stay open.
- Plesk frozen — versions 18.0.82 and later neither install nor update on Debian 11.
- Paid third-party support is possible, but outside Debian — vendors offer extended security until 30 June 2031; it is not a Debian project service, and Plesk's announcement mentions no support for such a scheme.
- Integrations falling behind — Plesk plans to remove, in version 18.0.82, XML-RPC protocol versions earlier than 1.6.9.1; a billing or management integration relying on an older version will stop responding.
- A growing debt — the longer you wait, the wider the gap to the target version and the more expensive the work becomes on the day it turns urgent.
Dist-upgrade or migration: the decision criterion
Plesk's documentation presents two ways to upgrade a server's operating system: migrate to a server already running a newer OS with Plesk Migrator, or perform an in-place dist-upgrade. It recommends migration, because dist-upgrade is not a simple process: it requires solid system administration experience and knowledge of the OS components. It also advises against combining it with Plesk updates, which therefore must be done beforehand.
The practical rule that follows: migrate critical servers and those loaded with third-party modules by default, and keep dist-upgrade for simple, well-backed-up machines that you can clone and test first. Dist-upgrade imposes a full outage of Plesk, sites and mail for the whole conversion; migration leaves the old server in service until the switchover.
In-place dist-upgrade or migration to a new server
Scroll the table
| Criterion | Dist-upgrade (Plesk tool) | Migration (Plesk Migrator) |
|---|---|---|
| Plesk's recommendation | Possible, but not a simple process | Recommended route |
| Downtime | Plesk, sites and e-mail down for the whole conversion, 20 to 30 minutes announced | The old server stays online until the switchover |
| Reboots | Three, resumed automatically by the plesk-dist-upgrader service | None on the source server |
| Rollback | Snapshot and backup; the tool's revert option only covers the stage before packages are upgraded | The old server stays intact as long as you do not shut it down |
| Prerequisites | Up-to-date Plesk, 5 GB free, 2 GB of RAM, Remote management module, not a container | A new server on a supported OS, and a data transfer |
| Best suited to | A simple server you can clone and test | A critical server, third-party modules, or an OS you need to renew anyway |
Inventory the fleet before deciding
Before choosing a route, you need to know where each server stands. On every machine, cat /etc/os-release gives the system version: a VERSION_ID of 11 flags an affected server. plesk -v shows the installed Plesk version, plesk installer list the versions available for installation, and apt list --upgradable the packages awaiting an update. Record the results in a fleet table, with the client, the server's role, the third-party modules installed and the date of the last backup.
Then order by criticality. Start with a test or low-stakes machine to prove the procedure, then handle servers in increasing order of importance, warning clients of the outage before each intervention. Also check that the server is not a container: the tool does not apply there, and only your host can confirm the type of environment.
Preparing the dist-upgrade to Debian 12
Check eligibility
Plesk's tool for Debian 11 to Debian 12 requires Plesk Obsidian 18.0.57 or later. Check with
plesk -v. Confirm 5 GB of free disk space and 2 GB of RAM, and that the server is neither a Virtuozzo nor a Docker container.Update Plesk first
Bring Plesk to the latest available version before touching the OS: Plesk advises against combining dist-upgrade with Plesk updates. Check pending packages with
apt list --upgradable.Install the Remote management module
The tool requires the Remote management module to be installed: without it, you may lose access to the server if the SSH service does not restart during the conversion.
Back up, then take a snapshot
Make a full server backup, databases included, then a snapshot at the hypervisor or at your host. The snapshot is your real rollback: the tool's revert option can itself fail.
Test on a clone
If you have never done a dist-upgrade, restore the snapshot onto a test machine and run the whole procedure there. You will see the blockers, the real duration and the behaviour of your third-party modules before risking production.
Announce the outage
Warn clients: Plesk, hosted sites and e-mail are unavailable for the whole conversion, which the tool's page estimates at 20 to 30 minutes. Pick a quiet window and allow a margin, as the duration depends on the server.
Starting the conversion and following it
Log in as root, download the tool from the releases page of the plesk/debian11to12 repository and make it executable. The repository page gives the example wget https://github.com/plesk/debian11to12/releases/download/v1.0.7/debian11to12-1.0.7.zip, then unzip debian11to12-1.0.7.zip and chmod 755 debian11to12; re-read the list of releases to take the most recent one. Then run the tool inside a screen session, so that an SSH drop does not interrupt the conversion: screen -S debian11to12, then ./debian11to12. To resume after a disconnection, screen -r debian11to12. Before launching, ./debian11to12 --show-plan displays the planned stages.
Following and resuming a conversion
Monitor progress
From another session,
./debian11to12 --statusgives the state and./debian11to12 --monitoropens a live view. The log is written to/var/log/plesk/debian11to12.log.Wait for the three reboots
The conversion requires three reboots. After the first, the plesk-dist-upgrader systemd service picks the work up on its own. You can check its state with
systemctl status plesk-dist-upgraderand read its messages withjournalctl -u plesk-dist-upgrader.Restart if the process is interrupted
If the interruption happened before the first reboot, restart with the
--resumeoption. If it happens afterwards, runsystemctl restart plesk-dist-upgrader.Revert if the failure is early
If the conversion fails during the preparation phase, before packages are upgraded, the
--revertoption restores Plesk. Past that point it can no longer undo the changes: the snapshot takes over.Check the final message
At the end, a message from the tool states that the server has been upgraded to Debian 12; you can remove it from
/etc/motd. Then checkcat /etc/os-release,plesk -v, that the panel opens, a few sites, sending and receiving an e-mail, and the scheduled backups.
Third-party modules and server protection: check before, not after
The tool's repository page mentions neither Imunify360 nor any other third-party security module. That silence is neither a green nor a red light: before converting a server that runs one, ask each module's vendor whether it supports Debian 12 with your Plesk version, and test on the clone. Do the same check for Plesk extensions, custom scheduled tasks and firewall rules.
Troubleshooting a conversion that stalls
The most thoroughly documented case involves multiple disks. With version 1.0.7 of the tool, a BIOS server on software RAID can stop during preparation with the message Grub's install-device is not found: /dev/sda, /dev/sdb, even though both disks exist: the check reads the comma-separated list of devices as a single path. The repository says the fix is in the source code but not in the 1.0.7 release archive; use a release or build that includes it. To tell this false positive from a genuinely missing disk, inspect the system without starting the conversion using debconf-show grub-pc and lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINT.
The repository also warns: do not remove a valid GRUB target and do not bypass the check just to get it to pass. If a configured device is really missing, fix the boot configuration first. For any other blockage, ./debian11to12 --prepare-feedback produces an archive to attach to a GitHub ticket.
Choosing migration: what it changes for the fleet
Migrating to a new server means building a healthy machine and moving the domains onto it with Plesk Migrator. You gain a clean system, an old server intact until the switchover and a trivial rollback. You lose preparation time: a server to provision, a data transfer, a DNS change to plan, and certificates and mailboxes to recheck after the switch. For a critical server, that cost is often lower than the risk of an outage with no escape hatch.
For an agency: a fleet project, not a server task
For an agency running several Plesk servers, the OS upgrade is a fleet project: three reboots per machine, outage windows to negotiate client by client and third-party modules to validate one by one. An alternative is to entrust the infrastructure to a provider who runs it for you: you keep the client relationship, we run the infrastructure. If your servers also need Plesk licences, the Plesk licences page details what is available. Server administration remains a separate option, never included by default.
The official documentation
Plesk Obsidian 18.0.81 announcement: https://www.plesk.com/blog/plesk-news-announcements/plesk-obsidian-18-0-81-is-now-available/
Debian 11 (bullseye) release page: https://www.debian.org/releases/bullseye/
Plesk dist-upgrade procedure: https://support.plesk.com/hc/en-us/articles/12377714344983
Debian 11 to 12 conversion tool: https://github.com/plesk/debian11to12
The Plesk documentation page on dist-upgrade support sets out the migration recommendation: https://docs.plesk.com/en-US/obsidian/administrator-guide/plesk-administration/dist-upgrade-support.74627/
