Migrating from Plesk
CoreCP reads the backup Plesk itself makes of a subscription — the .tar file from plesk bin pleskbackup or the download from the Plesk panel — and turns it into a complete account here: website(s), mail with every message, database(s), DNS,
Written for: Administrator
CoreCP reads the backup Plesk itself makes of a subscription — the .tar file from plesk bin pleskbackup or the download from the Plesk panel — and turns it into a complete account here: website(s), mail with every message, database(s), DNS, certificate and DKIM key. The import was measured against a real Plesk Obsidian 18 backup; what follows is what that measurement showed.
Administrators only. An import creates unix users, loads databases and publishes DNS on a whole server.
First: make the backup without a password
This is the one step that decides whether the customer keeps their passwords. A Plesk backup made without a backup password carries the passwords of mailboxes, of the system user and of the database user readable; CoreCP hashes them here and the customer notices nothing. A backup made with a password carries them encrypted with a key only that Plesk server has — nobody can carry those over, and the migration becomes a mass password reset.
On the old server, per subscription:
unset PLESK_BACKUP_PASSWORD
plesk bin pleskbackup --domains-name example.nl -exclude-logs -output-file /root/backup_example.nl.tarThe file is therefore a secret in itself: root-only, moved over SSH only, and every copy deleted once the import is done. The live route below does all of that for you.
What comes over
| The account | The subscription's system user as the account name, its password (readable in the backup, hashed here), the subscription's disk limit, and whether it had a shell |
| Websites | The main domain and every additional site of the subscription — an additional domain or a subdomain — each on the PHP version Plesk served it on |
| Files | httpdocs becomes the main domain's document root, each additional site's directory its own, and the rest of the webspace (error_docs, cgi-bin, the customer's own directories) lands in the home — see What stays behind |
| Databases | Every MySQL/MariaDB database with its data and its user(s) with their passwords |
| Every mailbox with its password and all its messages; autoresponders that were on | |
| DNS | The zone, with the records that pointed at the old server moved to this one |
| Certificates | Each website's certificate and key |
| DKIM | The key itself, republished under CoreCP's own selector |
What does not, and what to do about it
Every line below is named in the report of the import that met it:
| What you do | |
|---|---|
The database name and the user name change. Plesk calls a database shop with user shop_user; here they are <account>_shop and <account>_shop_user, because CoreCP reads the owner from that prefix (and removing the account takes its logins with it for the same reason) | For a WordPress site the import changes DB_NAME and DB_USER in wp-config.php itself and says so; for any other application you edit the configuration file. The report names the old and the new names. The password stays the same. |
| A database user that already exists here (Plesk user names are free-form) | Is left alone; give this database its own user with corectl db user add. |
| DANE (TLSA records) | They pin the old server's certificate and CoreCP renews certificates itself; they are not carried over. If the customer uses DANE, re-add them after the cutover. |
| Scheduled tasks (cron) | The report counts them; re-create them here with corectl cron. |
Protected directories (.htpasswd) | The backup carries no reusable password file; protect the directory again. |
| Catch-all | Reported, not set — the same choice as for DirectAdmin: corectl alias add @domain destination if you want it. |
| Per-mailbox spam settings | Filtering is per server here (rspamd). |
| CGI | CoreCP has no CGI handler; the scripts come over as files. |
| PostgreSQL | CoreCP has no PostgreSQL role. |
| Database users on the subscription level | Create them here per database with corectl db user add. |
What stays behind
What Plesk and its extensions keep in the webspace for themselves does not come over, named with its size in the report: the CloudLinux and Imunify directories (.cagefs, .cl.selector, .imunify*), WP Toolkit's and wp-cli's metadata, the LiteSpeed cache, Plesk's logs and statistics, and .ssh (keys for the old server; shell access is governed here through the account).
Route 1 — a backup file
Put the .tar file on the server and let the inspector look first:
python3 scripts/plesk-inspect.py /root/backup_example.nl.tarIt prints nothing confidential and says, per assumption, whether the backup matches what CoreCP expects — password forms, PHP versions, the database name, additional sites, TLSA records. Then:
corectl import plesk /root/backup_example.nl.tar --dry-run
corectl import plesk /root/backup_example.nl.tarIf the backup holds several subscriptions (a customer, reseller or server backup), name the one you mean with --subscription example.nl, or migrate them all through route 2 with --mode dir.
Route 2 — straight from the old server
corectl import plesk-server root@old.server --check
corectl import plesk-server root@old.server --accounts example.nl --dry-run
corectl import plesk-server root@old.server --accounts example.nlCoreCP logs in as root, has Plesk make the backup (without a password, without logs), streams it over SSH and deletes it on the old server. A Plesk subscription is named after its main domain, so --accounts and --exclude name domains; the account name becomes the system user from the backup.
The report
The same report as for a DirectAdmin or cPanel import: a checked line per website, mailbox, database and zone against the running server. What it says in addition for Plesk: that the passwords were readable and are hashed here (or, for a password-protected backup, which mailboxes need a reset), which database changed name and which site file still says the old one, which TLSA records were not carried, and what stayed behind in the webspace.
corectl import runs
corectl import run report <run> example.nlDoing it twice is safe
A second import of the same backup says "already present", duplicates nothing and leaves the zones alone. A truncated or corrupt backup is refused before anything is created: no account, no unix user, no website.
From the terminal
python3 scripts/plesk-inspect.py <backup> # read, write nothing
corectl import plesk <backup> [--subscription <domain>] [--dry-run]
corectl import plesk-server root@<host> [--accounts a,b] [--check|--dry-run]
corectl import plesk-server <directory-of-exports> --mode dir
corectl import run report <run> <domain>