Sites & platforms — Cheat Sheet

Everything you host here is a site — one domain — living on a platform — one build of Drupal. This page is the quick primer: how to copy, move, rename, back up and take a site with you, plus the handful of settings you'll actually reach for. Everything here links to the full story.

The pieces in 30 seconds

Platform — one build of Drupal (core plus modules) that can carry many sites. → Concepts
Site — one domain on a platform, with its own database and its own files. → Concepts
Client — the account that owns a group of sites. → Concepts
Every site is really three things — a database, its own files, and the platform codebase underneath — which is why moving one is a real operation, not a copied folder. → Taking your site off-platform

Copy a site: Clone

The Clone task makes a full, independent copy of a site under a new domain on the same platform — its own database, its own files, its own everything. Behind the scenes it takes a fresh backup of the source and builds the copy from that, so the original is never touched. (The copy comes up deliberately dark — turn its cron and HTTPS back on when you promote it; see below.)

→ Clone vs Migrate, in full

Move or rename a site: Migrate Site

Migrate Site does the two things Clone won't: it moves the same site onto a different platform (say a newer Drupal), or renames it to a different domain. The golden rule is change one thing at a time — never platform and domain in the same move — and the form enforces it: it refuses to submit unless you've actually changed the platform, the domain, or the database server.

→ The one-thing-at-a-time rule, in full

The safe way to upgrade

The panel itself recommends this order, and it's worth following: Clone the live site → Migrate the clone onto the new platform → check it → then Migrate the live site. You test the upgrade on a throwaway copy before the real domain ever moves. A migrate takes anywhere from a few seconds to a few minutes depending on the site's size.

A habit that makes all of this easier: give every real site a unique, permanent local name and attach its public domain as an alias — then you can move the live domain between clones freely, without renaming the site underneath. → the naming strategy, why clones stay separate

Rename www ↔ non-www

Switching between example.com and www.example.com is an ordinary one-step Migrate: type the other variant into Domain name and submit. The site's own automatic www companion is recognised, so it won't veto the name, and both variants keep answering afterward. It becomes a two-step job only if you'd previously added that variant yourself as a manual alias — then remove it from the aliases first, save, and rename.

→ Renaming, in full

Aliases and a canonical redirect

Extra domains are set on the site's Edit form (the node edit form, not a task button), under Domain Aliases — type a domain into an empty box, or use "Add an alias." To make everything bounce to one address, set "Redirect all domain aliases to" to your main domain. Saving queues a Verify.

→ Aliases, the automatic www companion, and DNS

Cron: on a schedule or on demand

Each site's Edit form carries a Cron interval field — the default is once an hour, with choices from every minute up to weekly, plus Disabled (the field may be absent if your plan doesn't expose it). To run it right now, from your own shell:

BASH

drush @example.com cron            # Drupal 6/7 (Drush 8)

or use the site's own "run cron" link. → Site cron, in full

Take your whole site with you

No lock-in: from your own oN.ftp login you can pull the whole thing down yourself, with nobody to ask. The database in one line:

BASH

ssh [email protected] 'drush @example.com sql-dump' > dump.sql

(That's the Drush 8 spelling for Drupal 6/7; on Drupal 8+ it's drush11 with the hyphenated alias — see Drush aliases & contrib.) The entire site directory, real files and all:

BASH

rsync -avzuL [email protected]:clients/myclient/example.com ./

The -L flag resolves BOA's symlinks so you land real files, not shortcuts. One nuance for restores: everyday backups use a fast per-table dump with no single database.sql, so only the Backup Mode "Site files with classic mysqldump DB" produces an archive the on-demand Restore can use.

→ Exporting your site · Backups & Restore

Bring an outside Drupal in

Importing an external Drupal is a six-step recipe: upload the codebase → register it as a platform → create a blank site → copy the files in → prepare and import the database → Verify. The database prep is two commands:

BASH

cd ~/static; sqlmagic fix dump.sql
drush @new-name.com sqlc < ~/static/fixed-dump.sql

sqlmagic fix strips DEFINER lines and turns INSERT into INSERT IGNORE so the load doesn't choke. On a legacy Drupal 6/7 site, one Migrate rename afterward fixes the hardcoded sites/ file paths automatically.

→ Importing a site, in full

Install a platform yourself (if your plan allows)

On plans that expose it, you don't need root to add a Drupal build. Edit ~/static/control/platforms.info to the build keywords you want, then drop the trigger:

BASH

touch ~/static/control/run-upgrade.pid

BOA runs an on-demand Octopus upgrade and removes the .pid itself. One gotcha: platforms.info replaces the host default set, it doesn't extend it — put ALL in it to stay current with everything.

→ Platforms and platforms.info

The settings and files most people touch

Setting / file	Where	Default
Cron interval	site Edit form	once an hour
"Redirect all domain aliases to"	site Edit form	No redirection
Backup Mode	Backup task	Classic single file mysqldump (not Restore-ready)
`platforms.info`	`~/static/control/`	empty → host default set

The speed switch most people meet is FastTrack.info — drop it in ~/static/control/ to skip the clone/migrate pre-flight checks; its partner ClassicTrack.info turns verify-first back on (deleting FastTrack.info alone isn't enough). Four more presence-only files serve this topic — all six are catalogued in the control files reference. Where the Edit-form settings actually get written, and why not to hand-edit generated files, is on Which file do I edit?.

If something's weird

A clone or import came up "dark" — its cron arrives Disabled and HTTPS isn't carried over. This is by design: a staging copy shouldn't fire the live site's scheduled jobs, and a certificate is bound to one exact domain. Turn cron back on and re-issue HTTPS when you promote the copy → why cron arrives off.
A reused domain now shows an installer page or a 404 on /install.php → the old domain is still hanging on the renamed site as a leftover alias or redirect target, so two sites claim it and the wrong codebase answers. Open the renamed site's Edit form and clear it out → the fix.
A target platform is greyed out on the Migrate form → a module enabled on your site sits at an older database schema on that target (a data downgrade), so the panel refuses it. Compare platforms, disable the blocker and Verify, or pick a target carrying the newer module → the full diagnosis.

Going deeper

The whole topic, in depth: Sites and platforms — creating and verifying sites, choosing platforms, aliases, cron, cloning, importing, and every task and setting.
Moving a site between BOA servers, or adopting a whole Ægir server (for operators): Cross-host migration · Adopt an Ægir server.