How to Migrate from Plesk to a New Server Without Downtime (2026)
To migrate from Plesk without downtime, lower your DNS TTL a day ahead, copy the subscriptions to the new server, test them through your hosts file, and switch DNS only at the end, after a final sync. This guide covers the method in a way that works for any destination, then shows how to do it with Koapanel, which imports a Plesk subscription from a Backup Manager file or by connecting to the old server over SSH.
Why leave Plesk (and when you shouldn't)
Plesk reworked its pricing and billing for 2026: on a VPS, Web Admin starts at $14.29 a month, Web Pro at $25.49 and Web Host at $52.99 (source). Plesk has real strengths, though: it runs on Windows with IIS and ASP.NET, has a large extension catalog and manages Node.js, Python and Docker apps. If you rely on any of that, look carefully before switching: Koapanel runs on Ubuntu 24.04 only, doesn't support Windows, and its manual doesn't cover Node.js, Python or Docker app management. If you host PHP and WordPress sites, the move is simple. Full comparison: Koapanel vs Plesk.
Before you start: the checklist
- Per-subscription inventory: domains, aliases, subdomains, databases, mailboxes, forwarders, scheduled tasks and unusual DNS records.
- Size: shown in the subscription's statistics. The new server needs more than twice that in free space, since the archive and its extracted copy sit on disk together during the import.
- Who runs DNS: plenty of Plesk servers are also the nameservers for their domains. If that's you, the cutover involves changing nameservers at the registrar.
- Email: on the Plesk server or with an external provider? If external, leave the MX records alone.
- Web settings: check each domain's Apache & nginx Settings for additional directives, and note the PHP version and custom values (memory, uploads).
Step 1: lower the TTL at least 24 hours ahead
TTL tells resolvers how long they may cache a record. Plesk-managed zones often use a full day, which means some visitors keep hitting the old server long after the switch. Set A, AAAA, www and MX records to 300 seconds, then wait at least as long as the old TTL.
Check the current value (the second field of each line):
dig +noall +answer example.com A
dig +noall +answer example.com MX
You don't choose the TTL of the nameserver delegation at the registry, and it's often one or two days. So the quickest cutover is updating A records first and moving nameservers later, without pressure.
Step 2: copy the subscriptions to the new server
The Plesk backup
In the interface: Tools & Settings › Backup Manager › Back Up, then Download. You get a .tar (or zip) file containing the backup_info_*.xml index. From the command line, as root, one subscription into a single file (Plesk documentation):
plesk bin pleskbackup --domains-name example.com -output-file /root/example.tar
With Koapanel: two routes
From the backup file. In Koapanel open Migration › From a backup file and upload it. The panel extracts and analyses the archive and shows What we found: domains, databases, scheduled jobs, mailboxes and size. Choose what to import, rename domains if needed and set the PHP version. Before extracting it checks disk space (about 2.5 times the archive, with 10% of every disk always kept free). Manual: Migration from cPanel and Plesk.
Over SSH as root. Open Migration › From a server over SSH and enter the address, port, the root user and a password or private key. Credentials stay in memory only for the duration of the migration. Before sending any password, Koapanel shows the old server's key fingerprint; compare it on the Plesk server:
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
Analyse server lists the subscriptions with their status (active, suspended, disabled). For each one you pick, Koapanel runs plesk bin pleskbackup, transfers the archive and imports it; if the Plesk backup fails, it copies the subscription's files and databases directly. Suspended subscriptions start unselected and, if you bring them, arrive suspended (you can untick that). A bandwidth limit keeps the old server responsive.
Without root, Koapanel treats the machine as a generic Linux server: it suggests folders that look like sites (on Plesk, /var/www/vhosts/<domain>/httpdocs), finds databases through wp-config.php and asks for credentials for the rest. Mailboxes then have to be recreated. sudo access isn't supported. Details: Migration over SSH.
What lands in Koapanel
| Item | Result |
|---|---|
| Domains, subdomains, aliases | Become sites; aliases stay aliases of the main site |
| Files | Copied as the site user into /var/www/<domain> |
| Databases | Created with new passwords, shown once in the report |
wp-config.php |
Rewritten with the new credentials; .env and configuration.php best-effort |
| Mailboxes | Created when the mail service is on; if the backup's password is encrypted with the old server's key, a new one is generated and shown once |
| Scheduled tasks | Imported paused |
| DNS zones | Listed in the summary, not imported |
For mailboxes, Koapanel's manual guarantees messages and original passwords for cPanel only. The migration's detail page shows messages and space for each mailbox: if messages are missing, copy them over IMAP (see how to migrate email accounts with IMAP).
Then look for absolute paths. On Plesk, sites live in /var/www/vhosts/<domain>/httpdocs, and scripts, cron jobs and some plugins hard-code it:
grep -rl "/var/www/vhosts" /var/www/example.com
Step 3: test the site through your hosts file
Add a line with the new server's IP to your computer's hosts file, so only you see the migrated site:
- Linux and macOS:
/etc/hosts(withsudo) - Windows:
C:\Windows\System32\drivers\etc\hosts(Notepad as administrator)
203.0.113.10 example.com www.example.com
Try pages, the admin area, forms and checkout. The HTTPS certificate only arrives once the domain really points at the new server, so a browser warning is expected. Or from the command line:
curl -sI --resolve example.com:80:203.0.113.10 http://example.com/
When you're done, remove the line from the hosts file.
Step 4: from Apache + nginx to nginx only
By default Plesk puts nginx in front of Apache, so .htaccess files are honored. Koapanel runs nginx only, which ignores them:
| What you had on Plesk | On Koapanel |
|---|---|
WordPress permalinks in .htaccess |
Work with the standard configuration |
| Redirect to HTTPS | Automatic once the certificate is on |
php_value in .htaccess or the subscription's PHP settings |
The site's PHP settings: memory, uploads, max execution time, max_input_vars (PHP versions) |
| Custom 301 redirects | Move them into the application (a redirect plugin in WordPress) |
| Additional nginx directives, password-protected folders | Need rework: Koapanel's manual doesn't document a per-site nginx directives editor |
WordPress and the popular PHP CMSs work with no changes. A site with many custom Apache rules should be checked with the hosts-file test from step 3.
Step 5: final sync and DNS cutover
- Final sync (SSH migrations, within 7 days): copies only changed files and re-imports the databases; rewritten config files keep their new content. File-based migrations don't have this step: if orders or comments are coming in, put the site in maintenance mode before the backup, or use SSH.
- Update the A/AAAA records for the domain and
www. With a connected Cloudflare or 1PrimeCDN account, Point to server shows the changes and applies them only when you confirm. - Turn on HTTPS as soon as the domain resolves to the new server.
dig +short example.com A @1.1.1.1
dig +short example.com A @8.8.8.8
From Plesk DNS to this server's DNS
Koapanel can also be the authoritative DNS for your domains: it runs PowerDNS, creates each site's zone automatically (A/AAAA, www, CAA and, with mail on, MX, SPF, DKIM, DMARC), supports DNSSEC and a secondary server, and resellers can use branded nameservers (This server's DNS). Plesk zones aren't imported, so before moving nameservers list the old zone's records and recreate the special ones by hand (TXT verifications, SRV, external subdomains):
plesk bin dns --info example.com
If DNSSEC was active on Plesk, remove the DS record at your registrar before changing nameservers, or the domain stops resolving. Enable DNSSEC on the new zone once the delegation is stable, then publish the new DS.
Step 6: email after the cutover
- Records: MX, SPF, DKIM and DMARC via Set up mail DNS on connected providers, or already in the zone if DNS runs on the server. Mail on Google or Microsoft? Make sure the MX still points to them.
- New passwords: send users the regenerated ones, shown only once in the summary.
- Mail delivered to the old server during propagation: keep the old mailboxes alive for a few days and pull those messages over IMAP.
- Sending: outbound port 25 is often blocked by cloud providers, and the reverse DNS (PTR) must match the mail server name. Koapanel checks both and supports an SMTP relay. Send a test to Gmail and confirm SPF, DKIM and DMARC all show
pass(SPF, DKIM and DMARC guide). - Mail clients: IMAP 993 SSL/TLS, SMTP 465 SSL/TLS or 587 STARTTLS, full address as username.
Shut down the old server only once sites and mail answer exclusively from the new one.
FAQ
Can I migrate Plesk Windows sites?
No. Koapanel runs on Ubuntu 24.04 with nginx and PHP-FPM only; ASP.NET sites stay on Plesk for Windows.
Do Plesk mailboxes keep their passwords?
It depends on the backup: if the password is encrypted with the old server's key, Koapanel generates a new one and shows it once in the summary.
How do Plesk customers and resellers map over?
Koapanel has three levels: admin, reseller and user, with white label. Whoever imports picks the target account, and resellers can migrate into their own customers (resellers).
What about WP Toolkit?
Koapanel has a WordPress section with three-level caching and updates that roll back automatically if the site breaks (WordPress). It isn't a WP Toolkit clone, so compare the features you actually use.
Try the migration
Install Koapanel on a fresh Ubuntu 24.04 server with curl -fsSL https://get.koapanel.app | sudo bash, free for up to 3 personal sites (pricing), and migrate a small subscription as a test. Or explore the public demo and the migration page. Moving off cPanel too? Read the cPanel guide.