Usual disclaimer: the following are mostly my personal (strong) opinions and rants. I express myself as “we” being Coop Symbiotic, because it’s teamwork, but this is not our official policy and any rants or errors or anything that might make you angry are purely my fault :-)

First, bear with me, let’s put things in context:

For the past 14 years, I have been working mostly Drupal sites with CiviCRM. In time, my focus has changed to mostly CiviCRM. We still leverage a content management system (CMS) heavily, such as Drupal or WordPress, but the focus of our work is on CiviCRM, because that’s what we’re good at.

Having gone through upgrades cycles from Drupal 5, 6, 7 and now Drupal 8 and 9, and working with non-profits on a small budget, we have long adopted the following strategy. I mention them now, because I recommend them as part of your post-Drupal7 strategy:

  • Our themes are often based on the same Bootstrap theme, with only a custom CSS file for a few tweaks (which can still be quite powerful, but it’s important to remind clients that no, not every page needs to be custom-designed and have its own CSS). Theming is often a huge factor in Drupal upgrades, and this is something we can avoid when using Bootstrap.
  • Saying “no” to certain features and keeping things intentionally simple. If a new feature is adopted, evaluate how it would survive an upgrade to Drupal8. This also meant keeping views simple, and avoid modules as much as possible, including modules that integrate with CiviCRM. Most modules do not have an upgrade path in Drupal8, and must be rebuild and may not have feature parity (this is true even for Views, which is now part of Drupal8 core).
  • Avoid Drupal Webform. It was groundbreaking at the time, but it was never very stable, does not have test coverage (hence regressions), required a lot of clicking around for bilingual forms, and basically re-invents half of CiviCRM. I would rather focus that energy on having good “core” forms instead, or formbuilder. CiviCRM is a rather small community, we can’t allow ourselves to divide ourselves into different sub-communities. As a service provider, it was a huge liability. Sorry folks, I know this will make some people really angry.
  • Use the CiviCRM User Dashboard. It can be improved, and we are slowly publishing extensions to improve it, but it provides a pretty good out-of-the-box experience. Avoid custom Drupal dashboards. They might start simple and easy, but quickly grow into a new CRM, with a lot of Views and Panels and other less-supported modules.
  • Avoid custom programming as much as possible.
  • If we must customize, do it with CiviCRM as much as possible, because CiviCRM upgrades are much more predictable and provide better backwards compatibility.

Few organizations can regularly spend a huge chunk of money on something that is an instant technical debt (with high maintenance fees). People expect solutions that “just work”. It shouldn’t take 4 months to create a website. Anyone can create a site on WordPress.com or SquareSpace and have something working within a day or two of work, without a designer or a programmer. It’s often what we are competing against, or at least, the expectation.

So that’s my starting point.

We started using Drupal8 (and WordPress!) since October 2018, but we still manage over 100 CiviCRM sites on Drupal7. As Drupal7 will be “End of Life” (EOL) in November 2021, it’s important to start planning the next steps.

Why now?

  • Drupal7 developers are difficult to find. Who wants to work with a CMS that is 9 years old?
  • Many Drupal7 modules are not actively maintained, if not abandoned. Many do not support PHP 7.3 (old-stable at this point), which means that it will be more and more difficult to find a place to host the website, and eventually being stuck on an old version of PHP will have security risks. When that happens, good luck finding a sysadmin who will want to work with that old version of PHP.
  • Drupal7 features are not competitive. It was great back then, but today there are more intuitive, efficient tools out there. Your client might be “OK” using something that works (they already paid for it), but whenever they have to train a new staff member, or have a new director, they will be reminded that it’s old tech, increasing your training and support costs. You might lose them completely.

Where do we go from there?

  • Migrating to Backdrop: Backdrop is a fork of Drupal7 which provides a few usability improvements, is actively maintained and also supports CiviCRM. This can be a good option if you liked Drupal7 and don’t like Drupal8. There is still an upgrade path, but it’s relatively minor compared to Drupal8. However, it does share some of the disadvantages of Drupal7: there are few developers, and the underlying technology is old.
  • Migrating to Drupal8: it’s still Drupal, but the migration path is quite difficult.
  • Migrating to WordPress: Start a new website from scratch, then re-attach CiviCRM. WordPress is obviously well-known, easy to host (always supports the latest PHP version), easy to find agencies/developers that support WordPress.

At Coop Symbiotic, we decided to support both Drupal8/9 and WordPress. Our long-term goal is to go towards CiviCRM Standalone (CiviCRM without a CMS).

Drupal8 (or 9 and later)

Drupal8 is still Drupal. There is no upgrade path for Views and Webform from Drupal7 to Drupal8, but upgrading the theme is fairly easy (if using a common theme, such as Bootstrap). Hopefully you don’t need a million different views, or you can simplify them, and rebuild them fairly quickly. Get rid of all the duct tape (custom views for random tweaks or workarounds). The Drupal8 migration module does work pretty well for migrating the basic content and users. Unfortunately it’s also difficult to find Drupal8 developers, and I have to admit that Drupal “core” code can be very cryptic at times. I really appreciate that it’s “standard” PHP (with Symfony and Composer), but Drupal folks strongly insists on making everything an Entity which really just complicates things. That said, since we do not use Drupal very much, the core features are well tested and most hurdles were easy to overcome. I just can’t say I’m a “Drupal developer” anymore.

If you do use Drupal8, I recommend using Gutenberg. It’s the basic WordPress content editor for Drupal8. Yes, that sounds a bit crazy, but it works well. It also avoid ending up with crazy-complicated sites in Drupal that have 50 fields for a simple node, or using the Drupal8 layout builders which are overly complex. CiviCRM users who enjoy Mosaico will probably enjoy Gutenberg.

2021 update: A last thing to consider: it took a while for CiviCRM to work on Drupal 8. Fortunately, Drupal9 support was much easier, but upgrading from 8 to 9 is not as easy as we would have expected. Given that the update cycles are rather short, and disruptive, we do not look forward to these upgrades.

Switching to WordPress

What about WordPress? Well, WordPress is great. Lots of plugins, well-known, well-supported. I’m not a fan of paid plugins or annoying adverts from free plugins, but we can often do without them if we use the same philosophy for WordPress as we did for Drupal, i.e. avoid plugins as much as possible. WordPress does lack a good Views equivalent. Some people are working on it (content-views), your mileage may vary. It’s still a major reason why we sometimes prefer Drupal. Another inconvenient: migrating users, passwords, content, is still much more work. Many organizations want to start from scratch anyway, so it might not be a problem. It’s still a much bigger endeavour than if just upgrading to Drupal8.

CiviCRM Standalone

Finally, another solution could be to detach the CMS and the CRM. CiviCRM does lose one of its key advantages when detached. However, we increasingly have situations where the website is managed by another company. We do a bit of theming on the CiviCRM site to match the branding of the main the site, and users are bounced back and forth between the main website and the CRM forms or views, combined with single sign-on.

Technically, we need a more simple way to get started with CiviCRM. Currently, for many organizations, the first CRM question is “Which CMS?”, which is a barrier to entry. People want to learn a CRM, not WordPress or Drupal. Installing CiviCRM should be as easy as downloading a zip file onto a web host, and be done with the installation in a few clicks.

With regards to third-party integrations, CiviCRM SearchKit is now a reliable replacement for Drupal Views, and CiviCRM Form Builder still needs a bit more work, but it’s slowly becoming a viable Webform replacement. The CiviCRM extension ecosystem has also significantly grown in the past few years.

As of December 2021, this is not yet possible, but the idea has been brewing for some time, and might be a solution by December 2022. A proof of concept is already working, but it is missing key pieces such as user management. More information here.