Migrate from Plesk to Jabali Panel over SSH, step by step

Move Plesk subscriptions to Jabali Panel over SSH: discover, analyze, restore, then repoint DNS. Discovery is read-only on the Plesk source. Debian 13 or Ubuntu 24.04.

Moving off Plesk is a server project with a clear order: read the subscriptions, restore them on the new server, check the result, then move DNS. This guide follows that order and uses the steps in Jabali Panel’s Plesk migration docs. Plesk is one of four control panels that Jabali Panel reads over SSH. If you are still choosing a panel, the open-source panel roundup compares the licence and supported systems of eight of them.

The short version: Jabali Panel connects to the Plesk server, lists every subscription, and reads each one with Plesk’s own command-line tools. Discovery changes nothing on the source. You choose what to restore, the panel rebuilds each subscription on the new server, and you move DNS when you are ready.

Before you start

You need four things.

A fresh destination server. Debian 13 (Trixie) or Ubuntu 24.04 (Noble), with Jabali Panel installed. The installation guide covers DNS preparation and the panel hostname. The install page builds the install command.
A Plesk source on Linux. The Jabali docs list Plesk Obsidian 17.x and 18.x on Linux. The Plesk pipeline does not support Plesk on Windows, because Windows Plesk uses a different backend.
SSH access to the Plesk host. The default port is 22, and you can set another port. The account must be root or a sudo-capable admin. Discovery has to see every subscription, whatever its owner, and a non-admin account cannot do that.
Network reach. The destination must reach the source over SSH. If the source has a private IP address, an operator must turn on the “Allow private hosts” setting under Server Settings, then Migration. It is off by default to block requests to internal addresses.

Plan the cutover before you connect. Decide which subscriptions move, and which hosting package each one maps to on the new server.

Step 1: add the source

Open /jabali-admin/migrations and add a source with these values:

Kind: Plesk
Host: the Plesk server’s name or IP address
Port: 22, or the port your Plesk host uses
Authentication: an SSH password or a private key

The panel stores the credential in the migration secret store.

Step 2: discover

The panel opens an SSH session and lists every subscription. It runs read-only commands. Jabali’s docs list the commands it uses:

plesk bin subscription --list
plesk bin domain --info
plesk bin database --list
plesk bin dns --info
plesk bin mail -l -json
plesk ext wp-toolkit --list -format json

None of them creates, deletes or changes anything on the source. The Plesk server stays in service during discovery.

If you connect as a non-root account on a server with one subscription, the panel picks that subscription. On a server with several subscriptions, discovery stops and shows the list, so you can choose one. If you connect as root, the panel falls back to its list of accounts and asks you to pick one.

Step 3: select subscriptions

Choose one subscription, several, or all of them. For each one, pick the target hosting package on the new server. The package sets the limits for the user it creates, so choose it with the customer in mind.

Step 4: analyze

Analyze reads domains, databases, DNS zones, mail and WordPress installs from the source. It writes nothing. Run it days before the cutover, not on the day, so you can see every problem while there is time to fix it.

Step 5: restore

Restore builds a cpmove-shaped archive on the destination and restores each asset. The panel shows progress for each phase in the Migrations section. Freeze writes on the source before you press Restore, and press it at the planned cutover time, not during discovery.

What the restore creates is listed in the table below. Subscriptions become panel users. Domains and subdomains become panel domains, with Plesk’s alias and subdomain distinction kept. DNS zones are translated from Plesk’s BIND format to PowerDNS rows.

Step 6: send the new mailbox passwords

Mailboxes are recreated in Stalwart with new generated passwords. Plesk’s password hashes do not carry over, so no user keeps the old password. The migration report lists the new passwords. Send them to the mailbox owners through a channel you trust, or turn on Force password reset on next login for each user, so each person sets a new password at first login.

Step 7: repoint DNS and issue SSL

When the restored site checks out, change the A, AAAA and MX records at your registrar to the new server. SSL certificates are not migrated. Turn on SSL for each domain in the panel, and the panel requests a Let’s Encrypt certificate.

The cutover timeline

The Jabali docs use this timeline for a Plesk cutover. Adjust the times to your own DNS settings.

48 hours before: lower the DNS TTL for each domain to 300 seconds at the registrar.
1 hour before: put the source subscription into maintenance, so no writes reach it.
45 minutes before: press Restore on the analyzed subscription.
30 minutes before: check that the domains, databases and mailboxes are in place.
15 minutes before: test the new server with curl --resolve, so you see the new site before DNS changes.
At the cutover: repoint A, AAAA and MX records.
1 hour after: turn on SSL for each domain.
24 hours after: restore the original TTLs.

While the DNS change spreads, some visitors reach the old server and some reach the new one. Keep the source running until DNS has settled.

What migrates

Plesk item	What happens on Jabali Panel
Subscriptions	Become panel users. The login name is the subscription name.
Home directories	Copied over SSH from the source’s `/var/www/vhosts/<domain>/`
Domains and subdomains	Created as panel domains. Plesk’s alias and subdomain distinction is kept.
DNS zones	Read from the source and translated into PowerDNS rows
MariaDB and MySQL databases	Restored with users, with password hashes kept where the format is compatible
PostgreSQL databases	Restored into the panel’s PostgreSQL instance
Mailboxes	Recreated in Stalwart with new generated passwords
Forwarders, catch-all and autoresponders	Translated to Stalwart equivalents where the meaning maps
WordPress installs	Found with the Plesk WordPress toolkit and registered with the panel’s WordPress tooling
Customers	Suggested as user assignments. You merge or split them.
Service plans	Suggested as hosting package mappings. You confirm them.
SSL certificates	Not migrated. Reissued from Let’s Encrypt on the new server.

What does not migrate

Plesk extensions. Kaspersky Anti-Virus, Fail2Ban configuration, JetBackup, the Node.js extension and the Grafana extension do not translate. The panel’s equivalents are AppSec, CrowdSec, its built-in backups and the Docker apps catalogue.
Plesk firewall rules. Rebuild them with the panel’s UFW baseline and CrowdSec decisions.
Reseller structure. Jabali Panel has no reseller model. Reseller-owned customers move as separate panel users, and reseller branding does not carry over. If you bill customers through a reseller setup, use a billing system for that job.

Troubleshooting

Discovery fails with plesk: command not found. The SSH account is not root, and the Plesk binary path is not in its PATH. Log in to the source and check that sudo plesk bin subscription --list works. Then use a sudo-capable account for the migration.

Discovery stops at a subscription list. The source has more than one subscription, and the panel needs you to choose one. Pick the subscription in the Migrations section.

WordPress shows the “hello world” page after restore. The wp-config.php file still points at the source’s database socket. Change DB_HOST to 127.0.0.1 or to the socket the panel uses, then reload the site.

Try it before you cut over

Run the whole pipeline on a copy first. Pick one small subscription, restore it on a test server, and check the site, the mail and the database. Discovery and analyze do not change the source, so you can repeat them as often as you need. Only the restore and the DNS change touch production.

For the full reference, read the Plesk migration docs. For the case for leaving Plesk, read the free Plesk alternative post. For the other sources, see the migration hub.