Account Migrations ​
The Account Migrations page tracks hosting-account moves between AdminBolt nodes managed by this hub. Migrations are started from Cluster Accounts (the Migrate row action) and their progress is recorded here.
Migration between AdminBolt nodes, not from another panel
This page only ever shows account moves where both the source and the target are AdminBolt servers in this hub. Since panel 1.9.1 such a move copies the account's website files, email, and database contents along with its configuration, unless you untick them when you start it. Moving a cPanel or DirectAdmin server's accounts into AdminBolt is a different feature that never appears here: see Migrating to AdminBolt, External Migrations, or Migration: which one do you need? for a comparison.
Overview ​
URL: /admin/cluster/migrations - under Cluster > Migrations
Every account moved between the hub and its nodes, newest first
Before any migration has run, the page shows No migrations yet. with a Cluster Accounts button that opens the page migrations start from.
Migrations table ​
| Column | Description |
|---|---|
| # | The migration number. |
| Account | The account, with the source and target servers underneath. |
| Status | The migration's current step while it runs, then completed, completed with warnings, failed, or cancelled. |
| Detail | The current step while the migration runs, or the outcome once it has finished, with the content being copied underneath. |
| Started, Duration | When the migration started and how long it has taken. |
| Finished | When it finished. Hidden by default. |
Filters narrow the list by Status (Running, Completed, Failed, Cancelled), From, and To. The table refreshes on its own while a migration is running. Click a row to open that migration's page.
Statuses ​
- completed - the account moved, and every step finished.
- completed with warnings - the account moved, but the DNS switch or the suspension of the source did not finish, or, since panel 1.9.3, the DNS on the source server could not be updated, or remote PostgreSQL access rules could not be set up on the target. The Detail starts with "The account was migrated, but some steps did not finish." and names each step, and the account migration's page names the step to check. Over the API this status is
partial. - failed - the migration stopped. When the copied data does not match the source, the migration fails before DNS is switched, and the copy is left on the target.
- cancelled - an administrator stopped the migration.
Cancel and Retry ​
- Cancel is offered until the DNS switch starts. The migration stops at its next step. An account already created on the target is removed when the migration is retried.
- Retry is offered on a failed or cancelled migration. It starts the migration again with the same target and options, and opens the new migration's page.
Only one migration of an account runs at a time.
A migration's page ​
Each migration has its own page, Migration # followed by its number, which opens when you start a migration and when you click a row in the table. It follows the migration live:
- A step tracker: Queued, Export, Import, Data copy, Data check, DNS cutover, and Done, with when each step began and how long it took.
- A progress bar with an estimate of the time left while the migration runs. With Suspend the account on this server afterwards on, the bar also shows the final data copy that runs after the source is suspended.
- What is migrated: the Website files, Email, and Database contents cards, each marked copied or not copied, and the account configuration the export carried, with counts and names.
- The Data copy results for each home directory and database, the Verification that compares the target with the source, and the DNS cutover result for each domain.
- Other migrations of this account, and Technical details for support.
The page carries Cancel and Retry too, under the same conditions as the table.
A migration that stops making progress is marked failed, so the migrations queued after it can start. If a migration stays queued, the page says why and what to check. When migrations queued earlier are still running, it lists them.
DNS on the source server after the cutover ​
Since panel 1.9.3, after the DNS cutover the hub also updates the source node's own copy of each moved zone. Every A and AAAA record there that still names the source server's address gets the address the cluster now serves for the same name, so a resolver that still asks the source node also gets the new server. Only the domains whose cutover succeeded are updated, and only their A and AAAA records; other records of the source copy, such as MX, SRV, and CNAME records, stay as they are. An account migration from the hub itself has no separate source copy, and account migrations between AdminBolt nodes that finished before the update to 1.9.3 are not changed.
When a record cannot be updated, for example because the cluster serves more than one address for its name, the account migration ends as completed with warnings, and the Detail says "DNS on the source server source still answers domains with its old address", followed by the reason and the next step: change those address records on the source server to the ones in the zone exported from Global DNS Zones on the hub.
The hub keeps the previous records. When the cluster serves the source's copy again, because the account on the target or the target node was removed, the hub first puts those records back. That happens the next time the hub checks the nodes, or at once with Resync DNS or Synchronize on Nodes, or Resync on Global DNS Zones. A record you changed by hand after the account migration stays as you left it. If the records cannot be put back, the hub does not serve the source's copy, the zone shows as Failed with the reason under Zone sync, and the hub tries again on every later sync.
For the same reason, a node that accounts were migrated to is removed only when the hub can save the records to put back. Otherwise deleting the node is refused with a notification titled Remove node: "The node node was not removed: accounts were migrated to it, and the addresses to put back on their source servers could not be saved." Try again, and if it fails again, look up the correlation ID in the hub log.
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.
- Since panel 1.9.3, an account whose records still belong to a domain deleted earlier, such as a mailbox, an FTP account, a redirect, or a certificate, no longer stops the Export step. On the target, FTP accounts and Git repositories are created without a domain; assign them to a domain again if needed. The other records of a deleted domain are left out, and What is migrated does not count them. The source server names each such record as a warning on the Panel Error tab of its Logs.