Cross-host migration & cloning

Moving sites and accounts around a BOA fleet splits into two problem classes, and BOA solves each with a different toolchain.

Within one host — duplicating a site, or moving a site between platforms during a Drupal-version upgrade — is the front-end's job: the Ægir Clone and Migrate tasks, accelerated (and made cheaper to mass-run) by BOA's FastTrack/MyQuick control files. No data leaves the box; the work is a Provision backup/restore plus a Hostmaster node rewrite.

Across hosts — relocating a whole Octopus account, duplicating an account onto a second box, or evacuating an entire server — is the root-side xoct / xcopy / xmass toolchain. These:

• wrap mydumper/myloader (per-account) or xtrabackup + GTID replication (whole-server);
• freeze the source with a PHP-level http-off 503;
• rename the moved account in place with renameaegirhost;
• convert the old box into a real-IP-recovering reverse proxy until DNS is repointed.

The toolchain is storage-aware — each store lands on the target's attached /mnt mount or its root, per the target's disk reality — and its transfer steps are DRY-by-default, running live only with an explicit --live.

A related root-side tool, migratefs, relocates account file stores onto attached storage before — or independent of — any move.

A third axis runs through both: TLS is never carried across a machine-name change. Clone, a name-changing Migrate, and every cross-host move auto-disable Encryption on the new node, because the old certificate and ssl_key are bound to the old machine-name. You re-issue deliberately for the new hostname.

The pages below cover cross-host moves and copies, in-host cloning and migration, aliases and redirects, storage relocation with migratefs, and importing and exporting sites.

See the Reference appendix for the consolidated configuration-variable, command, and control-file tables, and Discontinued features for the retired xboa tool and the legacy manual remote_import flow.