Importing & exporting sites

Two operations sit outside the Clone/Migrate lifecycle: bringing a Drupal site that BOA did not create under management (import), and taking a managed site back out to run standalone (export). Neither is a whole-account move — for relocating an Octopus account between hosts use xoct/xcopy/xmass, see Cross-host migration.

Importing an existing site

BOA can adopt a Drupal site it did not install. The mechanism is the Provision provision-import verb plus the front-end hosting-import, and the same discovery runs automatically during a platform Verify.

The supported path:

  1. Place the code. The site's codebase must live inside a registered platform, as <platform>/sites/<domain>/. Either drop the site directory into an existing platform or build/register a platform around its codebase (see Building a platform).
  2. Load the database. Create the site database and import its dump. Verify will re-write credentials, so the import just needs the schema and data in place. Provision's importer expects a standard single-site Drupal database.

  3. Register the context. Give the site a Drush alias and let Provision read the on-disk site:

    drush @foo.example.com provision-save --context_type=site \
 --uri=foo.example.com --platform=@platform_name --server=@server_master \
 --db_server=@server_master
drush @foo.example.com provision-import

    provision-import reads the existing site's install profile, language and aliases, writes the alias, and then runs provision-verify — and, unless FastTrack is active, a front-end hosting-task … verify — so the package registry and settings are rebuilt for the adopted site (import.provision.inc:35-69).

  4. Register it in the control panel. Pull the back-end context into Hostmaster as a node:

    drush @hostmaster hosting-import @foo.example.com

The automatic path. You usually do not need step 4 by hand: when you Verify the platform, BOA discovers untracked site directories and queues an import for each allowed URL, because hosting_platform_automatic_site_import is on by default (hosting.module:1331, hosting_platform.drush.inc:49-108). Dropping a site into a platform's sites/ and Verifying the platform is often the whole job.

A few inherited Provision constraints are worth knowing: the site is keyed by its sites/<domain> directory (the sites/default directory is ignored), and Verify rewrites settings.php with BOA's literal DB credentials — so whatever credentials the imported dump assumed are replaced with the ones BOA manages.

The old single-site remote import flow (remote_import / hosting_remote_import) is retired — see Discontinued features. Use the on-disk import above.

Exporting a site off BOA

BOA has no dedicated "export to standalone" command: the backup tarball is the export artifact. Take a fresh backup (front-end Backup task, or drush @site provision-backup) and you have the full site — sites/<domain> files plus the database dump — in one archive under ~/backups.

To run that site standalone under a plain Drupal codebase on a non-BOA host, the work is manual and mostly about undoing BOA's management wiring:

  • Unpack the backup into a vanilla Drupal codebase of the matching core version.
  • Replace settings.php. BOA's generated settings.php carries literal DB credentials and BOA-specific includes (global.inc, Valkey/cache wiring); a standalone site needs a plain settings file with its own credentials. This is the opposite of stock Aegir, whose cloaked settings.php reads injected environment variables — do not assume the upstream export notes apply here.
  • Drop drushrc.php and any boa_site_control.ini / .dev. artefacts.
  • Wire the database credentials for the new host and re-point the files path.

Off-manager export is a deliberate, occasional operation, not an automated feature — BOA is built to keep sites under management. If the goal is only to move a site to another BOA box, use cross-host migration instead, which preserves all of the wiring.

Related