BOA Refines Drupal 7-to-Backdrop Upgrade Workflow

The BOA 5.88.811 release corrected faults in the system’s staged process for converting Drupal 7 sites to Backdrop CMS. According to the release notes, the follow-up fixes intermittent conversion and migration errors, restores an intermittently missing Backdrop admin bar, rebuilds stale registries after conversion, and refines parts of the control-panel task interface. The workflow was introduced in BOA 5.88.8, which enabled Backdrop support by default and added separate conversion and production-cutover tasks.

The staged process gives operators a way to assess a converted site without changing the production Drupal 7 installation. It reduces the risk of running an automated conversion against a live site, but it does not establish that the resulting Backdrop application is ready for production. Modules, themes, layouts, configuration, custom code, and user-facing functions still require review and testing.

Drupal 7 stopped receiving official community security and bug-fix support on 5 January 2025. W3Techs reported on 4 August 2026 that Drupal 7 accounted for 29.8% of websites it identified as using Drupal, compared with 31.0% for Drupal 10. The service updates its reports daily and bases them on websites where it can identify the technologies in use, so the figures are a dated survey snapshot rather than a census of every Drupal installation.

BOA runs the conversion against a separate copy with its own database, files, and domain. Its backdrop_upgrade task takes a fresh backup, restores the site under another domain, and runs Backdrop’s upgrade process on that copy. The original Drupal 7 site continues serving traffic while operators inspect the result, and an unsuitable conversion can be discarded or repeated without reversing changes on the production installation.

Before creating the copy, BOA generates a compatibility report for contributed modules. It groups modules according to whether their functionality is included in Backdrop core, a Backdrop port is available, or no target project has been identified. Modules without an installed Backdrop version are disabled on the copy, although BOA says their database tables are retained.

The report is advisory rather than a production-readiness gate. A completed task does not prove that every original feature has a working replacement or that the converted site behaves correctly. Operators must review forms, Views listings, menus, files, blocks, layouts, administration pages, and module-dependent functions before approving the result.

Backdrop’s planning documentation advises site owners to classify their Drupal 7 modules according to whether their functionality is in Backdrop core, available through contributed projects, replaceable, removable, or still in need of porting. It also says more complicated sites may require repeated development upgrades while modules, themes, and layouts are converted and tested. That assessment determines whether BOA’s automated task is the beginning of a short conversion or one stage in a longer application-remediation process.

Backdrop’s upgrade instructions require the relevant modules and custom code to be present before the database update runs. Themes that were absent during the update may require the process to be repeated, while block positioning, layouts, Views configurations, and contributed projects must be checked afterwards. The documentation warns that some Drupal 7 Views components do not have direct Backdrop equivalents and may require manual changes.

When the source and converted sites are on the same BOA instance, the backdrop_cutover task backs up and retires the Drupal 7 site before renaming the Backdrop copy to the production domain. BOA’s operator documentation says the domain remains unserved during the rename, with the interruption increasing according to the site’s size. The rename also disables HTTPS until the certificate is reissued, and additional domain aliases must be added again after the transition.

When the source site is hosted elsewhere, BOA’s documentation directs operators to complete the transition through DNS rather than the same-instance Cutover task. The retirement of the original installation must then be managed separately. These conditions mean that the separate-copy model reduces conversion risk but does not eliminate cutover planning or service interruption.

BOA says it validated the revised conversion and migration paths through a twelve-leg task matrix under PHP 8.3 and PHP 8.4, followed by another verification using a mirror-delivered installation. Those are project testing claims rather than independent findings. The supplied sources describe BOA’s own testing but do not include a third-party report of a completed production migration using the workflow.

BOA 5.88.822 has since replaced 5.88.811 as the newest listed release. Its release notes describe further Backdrop packaging and platform-management changes, including packaged Backdrop core and a shared contributed-project bundle, but do not document another alteration to the Drupal 7 conversion or production-domain cutover tasks. Based on the published release notes, the workflow remains defined by the separate-copy and cutover model introduced in 5.88.8 and refined in 5.88.811.