Backdrop CMS on your server

BOA runs Backdrop CMS as a first-class platform, side by side with your Drupal platforms: the same Ægir control panel, the same site tasks (install, verify, clone, migrate, backup, restore), automatic platform builds that always track the newest Backdrop release, Valkey caching with database fallback, and a native CLI (bee) next to the Drush you already use.

It also ships the piece most Drupal 7 owners are waiting for: a safe Drupal 7 → Backdrop upgrade built into the panel, which converts a copy of the site while the original keeps serving untouched.

Backdrop support is on by default: your normal upgrade pair brings the platforms, the panel module and the bee CLI with it — there is nothing to switch on.

Default on, easy off

The switch is _BACKDROP_SUPPORT, mirrored in two control files (each program reads its own), and it defaults to YES in both:

/root/.<user>.octopus.cnf — Backdrop platforms and the panel module. Platforms build when your _PLATFORMS_LIST includes the BDR symbol or is ALL (the shipped default).
/root/.barracuda.cnf — the system layer (the bee CLI).

To keep Backdrop off an instance, set _BACKDROP_SUPPORT=NO in its Octopus config (and mirror it in /root/.barracuda.cnf to skip the system tools too). A value already written in your control files always wins over the shipped default — so a server upgraded while the switch still defaulted to NO keeps NO until you flip or delete that line.

On a stock server the normal upgrade pair is all it takes, for example:

TXT

barracuda up-lts system
octopus up-lts o1

(Use up-pro on PRO instances — whichever tree your server already follows.)

When it finishes you have three Backdrop platforms (dev, stage and production trees) registered in the control panel, the Backdrop frontend module enabled, and bee on the command line. Enabling the module also re-verifies your platforms once, so Backdrop platforms that existed before the module always show up correctly as upgrade targets.

What you get

Platforms that maintain themselves. Backdrop platforms build from the newest Backdrop release automatically — there is no version pin to bump. Each platform ships the Backdrop-native Valkey/Redis cache module baked in; sites use Valkey when it is up and fall back to the database cache when it is not.
The full site lifecycle. Install, Verify, Clone, Migrate, Backup, Restore, Import and Delete behave exactly as they do for Drupal sites. Cloned and imported copies land with cron and Encryption disabled on purpose, so a copy never emails your users.
Both CLIs. bee (Backdrop's native CLI) and Drush 8 both work against Backdrop sites, with per-site aliases as usual. bee runs under the account's command-line PHP selection — cli.info and the instant phpNN.info markers — exactly like Drush, clamped to PHP 7.4 or newer; its launcher lives at /opt/local/bin/bee. Client shell accounts get the everyday bee verbs; destructive ones are reserved for the panel and admin identities.
Panel-owned cron. Backdrop's key-authenticated web cron is wired into Ægir's cron scheduling automatically; Backdrop's own visit-triggered cron is disabled so runs never double up.

Upgrading your Drupal 7 sites

On any Drupal 7 site node the panel offers Upgrade to Backdrop. The shape of the task is what makes it safe:

It converts a copy at a new domain on your Backdrop platform.
The original Drupal 7 site — database, files, vhost — is never in the write path and keeps serving throughout.
The task refuses to start unless the source is a fully updated Drupal 7 core, and the refusal happens before anything is created.
The task log prints a per-module compatibility report during validation: which modules Backdrop absorbed into core, which need a Backdrop contrib port on the platform, and which will be disabled by the conversion (their data tables are kept).
The copy lands enabled and serving with cron and Encryption switched off; you review it, enable both deliberately, and cut over whenever you are ready — the Cutover task on the copy retires the source and renames the copy to its domain in one step (re-enable Encryption for the new name afterwards), or repoint DNS instead. Any failure ends with "discard the copy and re-run" — the original is intact by construction.

Drupal 6 sites are refused by this task by design (the official Backdrop position) — they get their own first step instead, below.

Upgrading Drupal 6 sites: the two-step chain

A Drupal 6 (or Pressflow 6) site reaches Backdrop through two panel tasks: Upgrade to Drupal 7 on the Drupal 6 site node, then the standard Upgrade to Backdrop on the Drupal 7 copy it produces. Both steps convert a copy at a new domain; the site each step starts from is never in the write path. The in-between Drupal 7 site is a real panel site you can inspect and keep as a fallback.

Step 1 converts the CCK custom-field data along with the site, using a pinned kit of Drupal 7 module ports that your server stages from the BOA mirror automatically during every Octopus upgrade run (only the modules the source site actually uses are enabled on the copy, plus the migration engine and core file/image support). The field-data migration is a hard gate: a field that cannot be migrated aborts the task rather than deliver a site with content silently missing — the disposable copy is left for you to Delete before re-running.

What a Drupal 6 chain needs on the instance:

PHP 7.4 pinned for the instance (static/control/cli.info and fpm.info set to 7.4, then one Octopus upgrade run). The Drupal 6 code and the kit run under the instance CLI, and 7.4 is the supported interpreter for the legacy chain. Treat a 7.4 instance as a dedicated legacy instance: Drupal 8+ platforms on the same instance would break, so keep modern sites on a separate one.
Drupal 6 and Drupal 7 platforms: include the DL6 and DL7 symbols in the instance's platform list alongside BDR.
Backdrop support enabled as above — the kit stages automatically with it; if it is ever missing, step 1 refuses to start and tells you to run the Octopus upgrade (nothing is ever downloaded at task time).

The fine print

Migrate works for Backdrop sites the same way it does for Drupal sites: move a Backdrop site onto another Backdrop platform (the usual reason: a freshly built platform tracking a newer Backdrop release), or rename it to a new domain, with the same backup-first semantics. The one hard rule is that Migrate never crosses the lineage — a Drupal site never migrates onto a Backdrop platform or the reverse; the panel only offers same-lineage platforms and the backend refuses a cross-lineage pair outright. It also refuses a no-op self-migrate — a site aimed back at the platform it already sits on with no new name — because that moves nothing while still risking the site's live database; point it at a different platform, or give it a new name. Drupal 7 sites reach Backdrop through the dedicated upgrade task above, never through Migrate.
If you import an old Drupal 7 database dump from another server and its tables are still utf8, convert them to utf8mb4 before upgrading — a fresh copy database defaults to utf8mb4 and mixed collations can break JOIN-heavy pages after conversion. The panel does this for you: the Convert to utf8mb4 task on the site's page takes a fresh backup, converts every utf8 table and text column in a short maintenance window and verifies the result — and simply reports "nothing to convert" on databases created on this server, which are already utf8mb4. The Drupal 7 copy minted by the Drupal 6 step carries 3-byte tables too; convert it between the steps.

That is the whole picture for day-to-day operation. When you want to see exactly what an upgrade did, the task's own log narrates every phase as it runs — the validation checks, the module report, the backup, the conversion passes and the final verify — so the record of each run lives right on the task node in your panel.