Inside an AdminBolt Migration: How We Move You, Step by Step

·adminbolt team·6 min read

The migration is the scariest part of switching control panels. Not the pricing math, not the feature checklist - the move itself. Years of accounts, mailboxes, databases, and DNS, all of which have to land on the other side working exactly as before, ideally without a single customer noticing.

So we treat every migration the same way: nothing on faith. We show the work before we do it, we confirm before anything irreversible, and we keep a way back until you tell us you no longer need one. Here is exactly how a migration to AdminBolt runs - from the first conversation to the day you retire the old panel.

1. Technical discovery, before we touch anything

Every migration starts with a clear picture of what you run today. Before a single byte moves, we map:

  • The source panel - cPanel/WHM, Plesk, DirectAdmin, or something more custom - and its version.
  • The operating system and whether it is ready for the target (AdminBolt runs on AlmaLinux 9).
  • Scale - how many accounts and resellers, total data size, and the largest individual accounts.
  • The moving parts - PHP versions in use per domain, mail volume, databases, cron jobs, SSL certificates, and any custom configuration.
  • DNS - where your zones live today, and who controls the records at cutover.

The output is a shared understanding of the job and, just as important, which path fits: convert your current server in place, migrate onto fresh hardware, or hand the whole thing to our team. You are never pushed down a route that does not suit you.

2. The plan - and a dry run

Discovery becomes a concrete plan: the order accounts move in, the schedule, the cutover window, the DNS strategy, and the rollback plan if we ever need it.

Then, before the real thing, we rehearse. A dry run walks the entire process without changing a single file, and produces a summary of exactly what will happen. If there is a surprise - a clashing account name on the target, a mailbox that needs attention, a certificate that needs reissuing - we find it now, in rehearsal, not halfway through the real run.

3. A shared Slack channel, open the whole time

This is the part most people do not expect, and the one they end up valuing most: we open a dedicated Slack channel with you for the migration.

It runs in real time, for the whole move:

  • Progress as it happens - each account posted as it comes across, so you always know the exact state of your server.
  • Decisions flagged on the spot - if we hit something that needs your call, like a DNS TTL, a maintenance window, or a clashing account name, we ask right there and get an answer in minutes, not in a ticket queue.
  • Your questions answered live - no waiting on business-hours email while your migration sits paused.

You are never guessing what is going on with your infrastructure. And after cutover, the channel stays open for aftercare - so the people who ran your move are the same people you can reach if anything comes up.

4. Running the migration alongside your live setup

The migration runs while your current panel keeps serving traffic. Nothing is switched off to make room.

Accounts come across in waves. Websites, databases, and every stored email message are copied, and you watch the progress the whole time. Two details make the cutover painless for your customers:

  • Mailbox and database passwords are preserved exactly, so applications reconnect and users log in without noticing anything happened.
  • Existing SSL certificates come along too, so HTTPS never blinks.

On a move to a new server, the source is never modified - your old machine stays exactly as it was. On an in-place conversion, every change is journaled so it can be reversed.

5. Verification - and your sign-off

A migration is not done when the data lands; it is done when it is proven. We verify per account: sites load, mail flows, databases connect, DNS resolves. Every account reports its own result, so if one resource on one account needs attention, it is surfaced in the summary - not buried, and not allowed to silently break the rest of the move.

Then you review. Nothing is switched off until you sign off.

6. Cutover, on your terms

When everything checks out, DNS points to AdminBolt and you go live - with zero downtime. If you manage DNS elsewhere, you keep control of the records and switch whenever it suits you.

The old environment does not disappear the moment you cut over. On a new-server migration, the source server is still sitting there, untouched, as a ready-made fallback. On an in-place conversion, the rollback path stays open until you decide you are done with the old panel for good.

7. Aftercare

You get a full report: every account, what moved, anything that needs a second look, and the small set of credentials that had to be regenerated for technical reasons (FTP and reseller passwords), ready to hand to the people who need them.

We stay in the Slack channel. The fallback stays in place until you tell us it can go. The goal is not just to move your data - it is to leave you confident that the move is complete.

Do it yourself, or hand it to us

Not every team wants the same level of hand-holding, so there are three ways to move, and they all share the same safety net:

  • Convert in place - swap the panel on the hardware you already run, with a built-in rollback.
  • Migrate to a new server - bring everything onto fresh hardware while the old machine keeps serving as your fallback.
  • We do it for you - our migration team plans, runs, and verifies the whole thing, with the shared Slack channel throughout.

All of it is free, with zero downtime, and your source is never left worse than you found it.

Ready to see what your move looks like? Start your migration - or book a call and we will map it out with you.

← Back to BlogMore in Migration