Cluster Accounts ​
The Cluster Accounts page lets the hub browse and act on hosting accounts across the hub and every connected node from one place. It is also where account migration between AdminBolt nodes is started.
Migration between AdminBolt nodes, not from another panel
The Migrate action on this page moves an account from one AdminBolt server to another under the same hub. Since panel 1.9.1 it moves the account configuration and, by default, its website files, email, and database contents. To bring a cPanel or DirectAdmin server into AdminBolt, use migrating to AdminBolt or an external migration instead. The features are compared side by side in Migration: which one do you need?.
Overview ​
URL: /admin/cluster/accounts - under Cluster > Cluster Accounts
The hosting accounts of the hub and its nodes - browse them and migrate them between servers
A server picker at the top chooses which server to inspect: This hub (the first tab, where the page opens) or any connected node. For the picked server it shows the connection status, the panel version, the last sync, and a Refresh button.
Accounts table ​
| Column | Description |
|---|---|
| Account | The hosting account's username. |
| Status | active or suspended. |
| Location | Where the account is: the listed server itself, Moving to a server while a migration runs, or On a server once a migration moved it. A failed or cancelled last migration is noted underneath. |
| Plan | The account's hosting plan on that server. |
| Disk | The disk space the account uses. |
| Domains, Databases, Mailboxes | How many of each the account has. |
| Data copy | Whether the account owner allows their data to be copied in a migration. See Data copy and the account owner. |
| Created | When the account was created. |
Filters narrow the list by Status, Location (on this server, moving, moved to another server, last migration failed), Plan, and Data copy allowed.
Row actions ​
Each account row has a menu with:
- Migrate - opens the migrate dialog (below). It is disabled while a migration of the account is still running.
- View migration - opens the page of the account's migration on Account Migrations.
- Open account on the hub, or Open on the node for a node's account.
- Suspend or Unsuspend - suspends or reactivates the account on its current server.
Select several accounts to use the bulk actions Migrate selected, Suspend selected, and Unsuspend selected. Migrate selected asks for a Target and checks each account against it first: the accounts that pass are queued and run one after another, and the others are listed with the reason.
Migrating an account ​
Migrate opens the Migrate dialog for the account:
Move this account to another server in the cluster. The copy on this server is kept.
| Control | Description |
|---|---|
| From | The server the account is on now. |
| To (required) | The destination server. The hub itself can host accounts too. |
| Content to copy | Three cards, all ticked by default: Website files (sites, uploads, and other files), Email (messages and filter rules), and Databases (tables and rows). Untick a card to leave that content behind. The account settings (domains, DNS, mailboxes, databases) always move. |
| Pre-check | Whether the account can move to the picked server, checked again whenever you change the target or the content to copy. |
| Suspend the account on this server afterwards | Suspends the source account as part of the migration. Hub Settings can tick it by default. |
Click Start migration to queue the migration. The migration's page opens, and its progress is also tracked on Account Migrations.
The pre-check ​
The pre-check shows whether the account can move to the picked server. It ends in one of three results:
- Ready to migrate - every check passed.
- Ready, with warnings - the migration can start; read the warnings first.
- Cannot migrate yet - the dialog lists the problems to fix before you start, each with what to do about it. Start migration is not offered until the check passes.
Some problems can be fixed from the dialog. Install on the target installs a service the account needs and the target lacks, and Copy plan name from the hub creates or updates the plan of that name on the target to match the hub. The check runs again when the fix is done.
Since panel 1.9.3, for an account with MariaDB databases, the check also fails when MariaDB is installed on the target but not running: "MariaDB is installed on target but not running; start it (systemctl start mariadb) and retry." Install on the target is not offered for this problem. Start MariaDB on the target, then run the check again. The same check runs when the account migration is queued, so an account migration started over the API or with Migrate selected is refused too. The check needs panel 1.9.3 on the hub and on the target.
What a migration copies ​
The account configuration always moves: the hosting plan and feature lists, domains, databases and database users, mailboxes, DNS records, SSL certificates, cron jobs, FTP accounts, and the rest of the account's setup. With the content cards ticked, the migration also copies:
- Website files - the whole account home, with every site and its uploads.
- Email - every mailbox with its messages and folders, and the mail filter rules.
- Databases - the tables and rows of the account's MariaDB and PostgreSQL databases.
When Suspend the account on this server afterwards is on and content is copied, the source account is suspended before a second copy pass, which brings over whatever changed during the first one. Nothing written to the source while the first copy ran is lost.
After the copy, the hub compares the source and the target before it switches DNS. If the copy does not match, the migration fails before DNS is touched and the copy is left on the target; Retry on Account Migrations starts it again with the same target and options. When the copy matches, the cluster DNS is switched to the target.
Since panel 1.9.3 the account's remote PostgreSQL access rules move too, when the target runs panel 1.9.3. The target sets each rule up with the same checks as the Remote PostgreSQL page, so a rule it refuses, for example because the plan on the target allows fewer rules, stays only on the source. The account migration then names the rule's address and the reason: "Remote PostgreSQL access for address was not set up on target: reason. Add these rules on target by hand once the cause is fixed."
An account migration whose DNS switch or source suspension did not finish, or, since panel 1.9.3, whose remote PostgreSQL access rules could not all be set up, is shown as completed with warnings. The account has moved; check the account migration's page for the step that needs your attention.
After the migration ​
The source copy of the account is kept. On the hub's Hosting Accounts page, a Cluster column shows where each account lives (This hub, Moving to, or Moved to a server), and the account page of a copy left behind says where the account now lives, with View migration and Open on the target. Changes made to the old copy are not copied to the target.
When you no longer need the old copy, Remove the copy on this server deletes its files, databases, mailboxes, and DNS on that server. It is offered once the migration completed and its data check passed, and it does not touch the account on the target. Migrate to another server on the same page opens the migrate dialog for an account.
Data copy and the account owner ​
The owner of a hosting account can refuse to have their data copied in a migration, with Allow my data to be copied when my account is migrated to another server on the client panel's Password & Security page. It is on by default.
When the owner has turned it off, the Data copy column shows it, and the pre-check fails a migration that copies any content. Untick the content cards to move the configuration only.
Notes ​
- Migrations require Hub Mode and at least one connected node.
- The Minimum node panel version set in Hub Settings gates migrations: a node running an older panel is flagged and cannot take part in a migration until it is upgraded.