Migrate from Plesk to AdminBolt: Routes, Scope and What Moves
A Plesk renewal lands on your desk with a different number than last year. You cross the next tier threshold on domain count and the bill climbs again. You read about AdminBolt pricing and the arithmetic for a server with unlimited accounts starts to look obvious. The question that stops you is the one every operator asks before they move: what happens to the production work already running on the current panel.
This guide is about the exit from Plesk specifically. AdminBolt ships bolt-migrate for cPanel and DirectAdmin servers; that tool is where most of our migration coverage lives. Plesk is a different situation. There is no one-click Plesk importer in AdminBolt today, so the move is either an assisted run with our team or a do-it-yourself transfer using Plesk's own export output with AdminBolt's account tools. Both routes work; the difference is who holds the stopwatch.
What follows is each route in enough detail to decide between them, plus what moves cleanly, what needs a touch and where the common traps sit.
The Short Answer
AdminBolt has no built-in Plesk migrator. The practical options are an assisted migration run by our team at no cost, or a manual transfer using Plesk's backup export and the AdminBolt admin panel. Websites, databases, mail content, DNS zones and SSL certificates all come across; Plesk-only features like the WordPress Toolkit or Plesk extensions do not.
| What you are moving | Assisted migration | Do it yourself |
|---|---|---|
| Who runs it | AdminBolt team, with you reachable while it runs | You, on your own schedule |
| Cost | Free | Free |
| Typical duration | One scheduled window | Depends on account count |
| Rollback | Source Plesk stays up until cutover | Source Plesk stays up until cutover |
What You Get
- A route out of Plesk that does not depend on a vendor-shipped Plesk importer.
- Websites, databases, mailboxes and DNS zones recreated on AdminBolt as first-class accounts, not approximations.
- Your Plesk server kept running until you repoint DNS, so the fallback question answers itself.
- A target panel that keeps account layouts familiar enough that your customers' muscle memory still works the day after the move.
- A hand-over trail: an account inventory on the target side and the Plesk backups you exported as the paper copy.
- The option to migrate via an intermediate panel when a Plesk-to-cPanel step first makes the rest of the move a bolt-migrate run.
The Problem It Ends
Most "how to leave Plesk" guides stop at "export your sites". The job is bigger than that. A production Plesk server has mailboxes receiving while you work, databases with applications connected to them around the clock, DNS zones with records nobody has touched since setup and SSL certificates on auto-renew. Copying website files is the easy part. Carrying the state is the actual migration.
The quieter cost is the one that keeps operators where they are: no vendor has written the exit. You can export from Plesk, but a target panel that imports those exports natively has to exist for the exercise to feel finished. AdminBolt covers that gap in two ways. For the assisted route we take the Plesk exports and run the restore for you on the target side so you are not alone with it on a Sunday night. For the do-it-yourself route the admin panel's own account tools accept the pieces one at a time: a website is a website, a mailbox is a mailbox and the panel does not care which product produced the export.
Route A: Assisted Migration With Our Team
The assisted route starts with a conversation and ends with your accounts running on AdminBolt. Three stages run back to back. No step inside them asks you to script anything you have not scripted before.
Scoping. You tell us how many servers and how many accounts, which Plesk edition and version, which Plesk extensions you rely on and which window suits you for the cutover. We send back what will move cleanly on your inventory and what needs a decision from you first.
The export. You run Plesk's backup against the accounts in scope. Full-server backups are the common shape; per-subscription backups work too when you want to move a subset. The output lands on storage you control. We agree on how to transfer it to the target. Your Plesk server keeps serving the whole time.
The restore. On the target side we provision the target, recreate the accounts with the same domains and plans you had, restore websites, databases and mailboxes from the Plesk exports and apply DNS and SSL. You review on the target, we agree on the DNS cutover and the final switch is a planned quiet window of its own. The Plesk server stays available afterwards so you can verify at your own pace.
Our migration team runs this with you. The migration is free and a real person from our side stays reachable throughout the run, so a question in the middle of the window gets answered the same window. Request an assisted migration to start the scoping stage.
Route B: Do It Yourself With Plesk Export and AdminBolt Account Tools
The do-it-yourself route uses the same raw materials, just without us driving. It is the right choice when you want full control over the schedule, when the account count is small or when you want to rehearse on one account before you book a window for the rest.
The AdminBolt admin panel has the pieces you need. Account creation, website setup, database creation and the file manager live where you would expect them to; the sidebar's layout follows the same shape as your other panels. The sections below walk the capabilities you touch, in the order a real migration touches them.
Prepare the target
Install AdminBolt on the server that will host the accounts. See the installation guide for the one-line install and the first-login walkthrough. The target does not have to be empty; existing accounts are not touched by anything you do next. Name collisions are something you simply avoid by picking distinct usernames when you create the new accounts.
Export from Plesk
Plesk's own backup manager produces the exports you will restore. A full backup gives you the lot; per-subscription backups let you move an account at a time. Whichever shape you choose, keep the exports on storage you can reach from the target. Do not take the source server down while you are working. The migration is a copy rather than a move, until you repoint DNS.
Recreate accounts on AdminBolt
Create one hosting account per Plesk subscription on the target side. The account carries the primary domain, the plan and the owner; the websites, mailboxes and databases attach to it in the next steps. The admin panel's Create Hosting Account screen asks for the same fields you are used to, with the same meanings. Give the new account the domain the Plesk subscription was using so the restored data lands where DNS already points when you cut over.
Websites and PHP
Each hosted domain in Plesk corresponds to a website on the AdminBolt account. Add the domain, pick its PHP version and upload the website files from the Plesk export; the admin panel's file manager handles the upload step. AdminBolt serves REMI PHP on MyApache and LSPHP on LiteSpeed Enterprise or OpenLiteSpeed; you choose which web server runs at install time or later. For sites that were on a specific Plesk PHP version, set the matching version per domain and keep the choice visible so a theme or a plugin surprise is caught early.
Databases
For each MySQL or MariaDB database in the Plesk export, create a database and a database user on the target side with the same name and privilege set the application expects, then restore the SQL dump into it. The admin panel's database management screens do both halves. Applications read database credentials from a config file on the website; after the restore you check that file so the migrated application connects to the renamed user if you changed the name during the move. For most migrations the simplest path is to keep the names identical and avoid that edit entirely.
Plesk's full backup carries mailbox content; per-subscription backups do too for the subscriptions you include. Create the mailboxes on the target side with the same addresses and restore their contents. The receiving mail server offers SMTP and IMAP with autodiscovery for the common clients, so once the mailbox has its content the client reconfigures itself on the next launch. Forwarders, autoresponders and mailing lists are a separate layer: list them from the Plesk side and recreate them on the target side as part of the same account setup.
DNS zones
The DNS records in the Plesk export are a reference list, not something you have to import blindly. AdminBolt builds the baseline zone for each hosted domain from the account you just created, which gives you a working zone immediately. The records that are specific to your setup, such as third-party verification records, mail provider records and anything you added by hand in Plesk, come across from the Plesk export one zone at a time. The admin panel's DNS management screens let you add records in the shape the Plesk export used.
SSL certificates
For domains with Let's Encrypt certificates, AdminBolt will issue new ones automatically after the cutover; the Plesk certificate does not need to come across. For domains with a purchased certificate you want to keep, export the certificate and the private key from Plesk and upload them to the target side before the cutover. The admin panel's SSL management screens accept the standard PEM format.
The cutover
When the target has every account restored and you have verified a sample of them against the source, repoint the authoritative DNS to the target. The Plesk server keeps serving the long tail of resolvers for a day or two; mail flows into the target as DNS propagates. The last step is retiring the Plesk license on your terms, once nothing is calling it anymore.
Route C: Via an Intermediate Panel
A third route exists for operators who already have a cPanel or DirectAdmin license and want to use bolt-migrate for the target side. You migrate from Plesk to cPanel or DirectAdmin first using Plesk's own tooling or a cPanel migration script. Then run bolt-migrate from the intermediate server to AdminBolt.
The reason to pick this route is specific. It is slower and it costs you a second license on the intermediate step, so it only pays off when you were going to run bolt-migrate anyway, or when a long-standing operator relationship already covers the intermediate panel. For most Plesk operators, Route A or Route B is shorter.
Where It Fits Next To The Alternatives
Plesk is a mature product and the longer you have been on it the more of its features are woven into daily work. The migration decision is not a feature contest, it is a question of what moves cleanly and what you are willing to replace.
What moves cleanly: websites, databases, mailboxes with content, forwarders, autoresponders, mailing lists, DNS records, SSL certificates and the account structure around them.
What you replace: anything that is a Plesk extension or a Plesk-only feature. The WordPress Toolkit is a Plesk product; AdminBolt handles WordPress sites as standard PHP websites and the sites keep working, but a per-site admin UI that bundled installs, cloning and the staging workflow is a Plesk convenience you give up. Plesk's own security add-ons are the same shape. AdminBolt ships its own security surface for the account; it is not the same screen you are used to clicking in Plesk.
What is better here: flat per-server pricing with unlimited accounts and domains. A multi-server Hub gives you one place to run several AdminBolt servers from. The renewal does not grow when your customer count does.
Common Mistakes
Taking the source server down during the migration. Keep it serving until you repoint DNS. A production source is your fallback until the day you decide you no longer need one.
Importing DNS blind. The Plesk export's DNS records are a reference. Compare them against the baseline zone AdminBolt builds for each domain and port only the records that are not already in that baseline, so you do not end up with duplicated A records or stale MX entries.
Renaming database users on the way across. It is possible, but it means every application config file on the migrated website has to agree with the rename. Keep the database user names the same across the move and the application configs stay untouched.
Treating Plesk extensions as a feature gap. They are an extension gap. AdminBolt's shipped feature set is what you compare on; a WordPress site served on AdminBolt is the same site, served the same way.
Underestimating the mail cutover. A mail client that was configured for the source server keeps trying it until DNS tells it otherwise. Autodiscover handles the reconfiguration on next launch; the handful of clients that cache aggressively need a nudge.
Running the cutover without a verified sample. Pick five accounts of different shapes, log into their websites on the target, send and receive mail for them and connect to their databases. If all five work, the rest usually do too.
Waiting for a Plesk importer that is not announced. We are not making future-feature claims in this article, which also means we are not asking you to wait on one. Route A and Route B both work today.
FAQ
Q: Does AdminBolt have a one-click Plesk migrator?
A: No. bolt-migrate is for cPanel and DirectAdmin. Plesk migrations are run as an assisted move with our team or as a do-it-yourself transfer using Plesk's own backup export.
Q: Is the assisted migration free?
A: Yes. Our migration team runs it with you at no cost; the only expense is any new server you are moving to.
Q: Can my Plesk server keep running during the migration?
A: Yes. Every route in this article keeps the source serving until you repoint DNS to the target. That is deliberate: the source is your fallback.
Q: What happens to the WordPress Toolkit sites?
A: The WordPress sites themselves move across and keep working as standard PHP websites served by AdminBolt. The WordPress Toolkit as a Plesk UI does not come along; AdminBolt does not reimplement it.
Q: What about Plesk extensions I pay for separately?
A: They do not move. Where AdminBolt has an equivalent feature in its shipped surface, you use that; where it does not, the extension's job is one of the things to list during scoping so nothing is a surprise after the cutover.
Q: Can I migrate account by account instead of the whole server at once?
A: Yes. Plesk per-subscription backups let you move one subscription at a time; AdminBolt accounts are created one at a time on the target. This is also how you rehearse: pick one account, verify end to end, then run the rest.
Q: Do I need the same server size on the target side?
A: Not necessarily. AdminBolt has no per-account or per-domain fees, so one well-sized AdminBolt server can replace a Plesk setup that was constrained by tier limits rather than hardware.
Q: What if I want to consolidate several Plesk servers into one AdminBolt server?
A: The assisted route handles that as a single scoping conversation covering all the sources. Routes B and C do too, done source by source over your own schedule.
Summary
Plesk operators have had the quiet assumption that no vendor would write the exit. AdminBolt does not ship a one-click Plesk importer; this guide does not pretend otherwise. What it does is name the two routes that work today: an assisted migration our team runs with you or a do-it-yourself transfer using Plesk's own export output with the AdminBolt admin panel. It also sets out what moves cleanly on each.
If you want us to run the move with you, open a migration request and we take it from the scoping stage. If you want to do it yourself, the sections above are the walkthrough. Either way the target side ends in the same place: your accounts on a server you own with a renewal that stays flat as your customer count climbs. Join the Discord or the community forum if you want to talk the plan through with other operators before you book a window.