Using the Plesk Migrator

The Plesk Migrator is Plesk’s own tool for server-to-server moves — and it’s preinstalled on every one of our vServers. You enter the source server login, the Migrator pulls everything over: files, DB, mail, DNS, Plesk config. Here’s how it works in practice.

What the Migrator can do

Source systems:

• Plesk server (all versions from Plesk 12)
• cPanel account (via backup or live access)
• Generic Linux server (with FTP/SSH access) — limited

What gets migrated:

• Website files (complete)
• Databases (MySQL/MariaDB)
• Mailboxes with all mails (via imapsync)
• DNS records
• Plesk settings (PHP versions, SSL, subdomains, aliases)
• Cron jobs
• FTP accounts
• End-customer accounts (with a Plesk source, and the Web Host Edition on the target server)

What doesn’t get migrated:

• Custom OS configuration (e.g. your own Apache directives)
• Server-level scripts outside of Plesk
• Special installation tools (some older CMS setups)

Opening the Migrator

In Plesk → Extensions → Plesk Migrator.

On first launch, the Migrator asks for:

• License confirmation (free, but requires a confirmation click)
• Source server details (enter them now or later)

Single-site migration

The classic use case: you have a website at your old provider and want it on your new vServer.

Prerequisites

• The source server runs Plesk or cPanel
• You have SSH or a Plesk admin login on the source server
• The domain is added on your side (or will be soon)

Steps

1. Plesk Migrator → Add a Source
2. Choose the source type:
   • Plesk server: URL, username, password
   • cPanel: URL, username, password
   • SSH server: IP, SSH port, username, password/key
3. The Migrator connects and lists the available sites
4. Select the site to migrate
5. Target configuration: the domain on your vServer, the service plan (if you run a Web Host setup with end customers)
6. Extra options:
   • Migrate mailboxes along with it
   • Migrate DNS records along with it
7. Start Migration

The Migrator runs. For larger sites: hours. You can check the status along the way.

After the migration

• Open the test URL on your vServer — does everything look right?
• If there are problems: check the Migrator logs, re-pull specific parts
• DNS switch at the domain registrar: nameservers to ns-a.xaweho.de, ns-b.xaweho.de and ns-c.xaweho.de

DNS propagation: 1–24h. During that time some visitors still see the old site, others the new one.

Bulk migration of multiple sites

If you’re bringing over multiple end customers from the old provider (requires the Web Host Edition on your vServer):

1. Add a source with the Plesk login of the source server
2. The Migrator shows all end-customer accounts on the source
3. Mark the ones to migrate
4. Start the bulk migration — it runs sequentially per end customer

With 30+ end customers: can take several days. The Migrator does it in the background.

Mail migration

Mail is the trickiest part. The Migrator uses imapsync:

• IMAP connection to the source mail server
• Copies all folders, all mails, read/unread flags
• Incremental (a second run only picks up new mails)

Large mailboxes (>10 GB): can take hours.

Recommendation:

• Start the first sync well before the DNS switch — the Migrator copies the existing mails
• Run the final sync shortly before / during the DNS switch — new mails come along
• Optionally a third run after the DNS switch, for mails that arrived between sync phases

DNS strategy

The old DNS stays active at the old host until you:

1. Reduce the TTL at the old DNS provider to 300 (5 min) — at least 24h in advance
2. Switch the nameservers at the registrar to ours
3. Wait out propagation (typically 1-24h)

During propagation:

• Some visitors go to the old server, some to the new one
• Mails may arrive on both servers

With the Plesk Migrator and a final imapsync run: no data loss, all mails arrive.

Test URL on Plesk

Plesk gives every domain a test URL: <deinedomain>.preview.xaweho.de.

You can test the site without switching DNS yet — content is visible, all functions are testable.

If everything’s fine: switch the DNS.

Common pitfalls

The source server has restricted SSH access

Some old providers give no SSH or only heavily restricted access. The Plesk Migrator can also talk to it via the Plesk API — works, just a bit slower.

If nothing works: download the Plesk backup from the old server, upload it manually, restore. More in Migrating your website to xaweho (Plesk Web Hosting KB).

PHP version incompatibility

If the old server ran PHP 7.4 and you’re on PHP 8.x: some plugins break.

Solution: after migration, set the PHP version per domain individually and upgrade step by step.

.htaccess with Apache modules we don’t have

If the old setup has special mod_xyz directives that aren’t active with us: they won’t come through. If needed: activate the module — open a ticket.

Database charset

Old DB latin1, new one utf8mb4 — umlauts broken. The Migrator typically does the conversion, occasionally it doesn’t. To fix afterwards:

ALTER DATABASE deinedb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

URLs hardcoded in the DB

WordPress often has hardcoded URLs in DB tables. After migration:

• The Better Search Replace plugin: http://altedomain → https://neuedomain
• Or via WP-CLI

More in Migrating WordPress to xaweho.

Very large databases

DB > 10 GB: the Migrator gets slow. Workaround: a separate mysqldump via SSH, move the file over, import on the target Plesk.

For really big sites: open a ticket, we’ll do it with optimized tools.

We also do the migration entirely for you

If you can’t be bothered with the Migrator UI or have special requirements:

Open a ticket: “Please migrate from my old provider, credentials attached”.

We do:

• Source data analysis
• A migration plan
• Data transfer with our tools (Migrator, manual, or rsync+SQL)
• Agree the DNS switchover date with you
• Go-live

Migration service: €49 flat. For extremely complex setups we estimate the effort in advance and let you know before we start.

Migrator vs. Plesk backup restore

Two ways to bring data from an old Plesk to us:

Plesk Migrator

• Pro: live, no intermediate backup file
• Pro: incremental mail sync possible
• Pro: bulk across multiple end customers
• Con: needs a running source server

Plesk backup restore

• Pro: no access to the source server needed
• Pro: good for “all I have is a backup file” scenarios
• Con: mail is frozen at the backup point in time
• Con: one restore per end customer

Recommendation: Migrator if the source server is live, backup if it’s gone / unreachable.

Frequently asked questions

How long does a single-site migration take? Small site (1 GB files, 100 MB DB, 1 mailbox): 30-60 minutes. Medium site (10 GB, 1 GB DB, 5 mailboxes): 2-4 hours. Large site (50 GB+): several hours up to a day.

Migrator license — does it cost anything? No, the Plesk Migrator is free.

Does the Migrator abort on connection problems? It has retry logic. On longer outages (source server gone for hours) it aborts — can be restarted manually and picks up where it left off.

Is the data transferred encrypted? Source-to-target connection is TLS. The Migrator uses SSH/HTTPS. Secure.

Does it also work from Hetzner / Strato / 1blu? Yes, as long as Plesk or cPanel is installed there. For plain web hosting without a panel: different method (manual or backup file).

Can I access the new site during migration? During file migration: yes, but shaky. During the final DB sync: better not. During mail sync: yes.

What if the migration breaks off halfway? The Migrator status shows where it stopped. A restart picks up there and finishes. If problems persist, check the logs or open a ticket.

Multiple migrations in parallel? Limited. The Migrator can run one active job queue. For very large bulk migrations: better sequential, it’s less error-prone.

What’s next

• Service plans and end customers
• Requesting changes via ticket
• Migrating WordPress (Plesk Web Hosting KB)