Migrate Server

Server > Migrate (/server/migrate) moves everything on this server to another one: every hosting account, and the settings that make the panel behave the way it does here.

The page starts hitechcloudcli server-migrate in the background and returns straight away — a migration takes far longer than a request. Its output goes to /var/log/hitechcloud/admin/migrations/server_migrate.log, and /server/migrate/status reports whether it is still running and, once it has ended, whether it succeeded or failed, with its exit code and what it printed. A failed run shows its last lines on the page.

hitechcloudcli server-migrate -h <DESTINATION_IP> --user root --password <DESTINATION_PASSWORD>

Before you start​

Migrate to a freshly installed server on the same version of HiTechCloud. Before it copies anything, the migration checks that the destination:

• runs its services on the host, as this server does;
• has no accounts of its own. A destination that an earlier run of this migration started is fine — see Running it again;
• has every PHP version and web server this server's sites use. Anything missing is listed with the command that installs it there, for example hitechcloudcli phpversions install 8.1.

If a check fails, nothing is copied and the run ends as failed. From the command line, --force goes past the last two checks. A destination on a different version is not refused, but the summary names it.

What moves​

Every account, one at a time, through the same per-account transfer as user-transfer: its panel records, system user, files, MySQL and PostgreSQL databases, websites, SSL certificates, DNS zones, mailboxes, DKIM keys, FTP logins and cron jobs. The administrator's own accounts go first, then each reseller's. Each account's permission groups, MCP tokens and passkeys follow it, and a domain signed with DNSSEC is signed again with the same keys, so the DS record at the registrar stays valid.

An account that fails does not stop the others. The log shows each account as it goes ([3/40] alice: transferring), and a summary at the end names every account that did not move and why. If any account or step failed, the run ends as failed.

Two kinds of account are not moved, and the summary names each one:

• A suspended account. Unsuspend it here (hitechcloudcli user-unsuspend <name>), run the migration again, then suspend it on the new server (hitechcloudcli user-suspend <name>).
• An account that lives on a hosting node. Its files, databases and mail are on the node, not on this server.

This server's settings, carried before the accounts:

• Administrators and resellers. Sign in to the new server with the logins you use here; the new server's own administrator login is replaced.
• Plans and permission groups, matched by name.
• Panel and administrator settings: everything in the panel's configuration except the server's identity, the administrator settings, notification rules, feature sets, reseller defaults and limits, e-mail templates, reserved usernames, single sign-on providers and the SSH allow list.
• Defaults for new sites: web server and PHP version, AutoSSL, HTTPS and HSTS, PHP limits and resource policies. A default the new server has not installed is left as it is there, and the summary says so.
• Branding and content: logos, custom code, translations and the default language, hooks, dashboard sections, knowledge base links, the DNS zone templates, the files a new account starts with, WordPress sets and the AI assistant's settings.
• Backups: the backup destinations and remotes.
• Mail: the outgoing relay and its login, mail policies, suspended senders and recipients, webmail branding.
• Accounts' and domains' host settings: PHP version, web server, limits, error pages, MIME types, password-protected directories and mail autoconfiguration.
• The panel's cron jobs, the logs, the firewall (CSF) rules with this server let in, and /root/hitechcloud_run_after_update.

The log lists every file it carries.

What never moves​

The new server keeps its own identity: its hostname and IP addresses, its license, the panel's TLS certificate, its database root and service credentials, its session keys and sign-in sessions, its SSH host keys, its address pool, its audit trail, and its DNS cluster, hosting node and VPN memberships. The log lists these too.

Dedicated IP addresses belong to this server's network. On the new server those accounts use its shared address, and their DNS zones point there; the log lists them so you can give them one of the new server's addresses.

Running it again​

A migration can be run again at any time, for example after fixing what made an account fail. Each account's progress is recorded on this server, under /var/lib/hitechcloud/private/server-migrate/<the new server's address>/:

• an account that moved is skipped;
• an account that failed part way is transferred again, over what the last attempt left;
• the settings are carried again.

The new server's own accounts — ones this migration did not put there — make the run refuse before it copies anything. With --force it goes ahead: an account of the same name is transferred over, and the others are left alone.