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:
- Support for any database other than MySQL, MariaDB or equivalent.
- Support for alternate field storage (anything other than the active MySQL database).
- See the complete list of modules removed from Backdrop core for more details.
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:
- Create a new theme for Backdrop CMS,
- Port your existing one, or
- Install a comparable alternative from contrib.
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:
- Make do with the 10 Layout Templates provided by Backdrop core.
- Create your own Flexible Layout Template using the Backdrop admin interface.
- Create custom layout templates for Backdrop CMS, by porting existing panels or Omega layouts
- Install comparable alternatives from contrib.
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.
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.
We use this category when, for example, a Drupal site uses a module we'd prefer to replace with a different one (e.g. Colorbox -> Featherlight). 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)
Tip: There is a Drupal 7 module Backdrop Upgrade Status, that will show you the current status of each contributed module on your Drupal 7 site.
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
<a href="https://docs.backdropcms.org/api/backdrop/core%21modules%21system%21system.api.php/function/hook_update_N/1" title="Perform a single update.">hook_update_N</a>();
- 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).