Documentation Level: 
Intermediate
Documentation Status: 
No known problems

Research what will be necessary to upgrade to Backdrop CMS

Before beginning an upgrade, it's important to understand exactly how your Drupal 7 site ie being used. 

Review limitations and changes

Backdrop attempts to support most Drupal 7 setups, but there are a few things that have been dropped. Modules & major features removed from core include:

Review Drupal themes

Most Drupal sites use custom themes that were built specifically for each site. Because of changes in how Backdrop renders pages (notably by the addition of Layouts), it’s likely that a Drupal 7 theme will need at least a few changes for Backdrop. Your options for the theme include:

Review Drupal page layouts

Review the page layouts in use on your current site. Most modern websites use more than one page layout. Backdrop provides several types of layout in core with commonly used arrangements of regions (e.g., single-column, columns with sidebars, etc.). You can:

The concept of a Layout—a structural layer that lives between themes and blocks—is new in Backdrop. If you’ve not worked with Layouts before, you might consider installing a new Backdrop site locally and playing around with it a bit to familiarize yourself with Layouts, what’s available, and how they can be used.

Review Drupal contributed modules

Very few Drupal sites run on what's in core alone. Have the modules you are using been ported to Backdrop already? If not, are you prepared to port them yourself? Most modules can be ported to Backdrop in a matter of hours; although a particularly complex module could take days. There is a Drupal 7 module Backdrop Upgrade Status, that will show you the current upgrade status of each contributed module on your Drupal 7 site: whether it has been ported to Backdrop, if there's a different module with equivalent functionality or if it does not (yet) exist.

Categorize Drupal contributed modules

We recommend creating a list of all the Drupal 7 modules installed on the site. Then go through and categorize each one based on the following criteria:

  • Core: the functionality has been added to Backdrop core, Backdrop will perform the necessary updates.
    See Backdrop's 'Features added to core' page.
  • Contrib: the module has been ported to Backdrop contrib, the Backdrop module will perform the necessary updates.
    Seach the list of modules for Backdrop.
  • To Uninstall: the functionality is no longer required, this module will be completely removed.
  • To Replace: a different Backdrop module provides the same/similar functionality, the Drupal module will be completely removed. There are two situations where this may occur:
    • First, when the functionality of a Drupal module has been moved to one or more differently named Backdrop modules (e.g., the Drupal Entity API module). See Modules that have replacements for further details.
    • Second, when a Drupal site uses a module we'd prefer to replace with a different one (e.g. Colorbox -> Featherlight). In both cases, be sure to note the module that's replacing it.
  • To Port: the module needs to be ported to Backdrop, the new Backdrop module will perform the necessary updates.
  • To Install: new module/functionality is needed in Backdrop.
    This is useful if a Drupal module was split into separate Backdrop modules when ported (e.g. Date -> main functionality in core, Date Tools, Date All Day).

See the complete list of contributed modules that are no longer necessary for Backdrop sites.

 

Review the upgrade process

Once you’ve gone through the above, you will have a good idea of the scope of work and its timetable. For simple, straightforward sites, you will only have to do a single upgrade and the whole process could be over in less than an hour. More complicated sites, though, may stretch over time and require multiple upgrade runs as you work through the porting of modules, themes, and/or layouts (carried out on development sites, of course—you only want to have to run an upgrade once on the production site).

A not-uncommon scenario is the following:

  • Make a local copy of the production site for development;
  • Upgrade it as much as possible (not necessarily including all “to-port” modules);
  • Port the remaining modules (and/or themes and/or layouts), testing them on the upgraded development site;
  • Try a new upgrade from scratch with the ported modules to verify (this is important if the ported module implements hook_update_N()).
  • Upgrade the production site.

Although most of the iterative development of ported modules, themes, and layouts can be done on one’s local development system, the upgrade of the production site will necessarily take some time. You should discuss the upgrade process with key stakeholders and explain that, ideally, the current Drupal site will stay online during the final upgrade process, but that no changes should be made to it during that time (to prevent the upgraded Backdrop site being out-of-date before it even launches).