Major CMS upgrades (Drupal 7, Joomla 3, etc)

It’s an uncomfortable truth that many websites out there are still running on content management system (CMS) packages that have been end-of-life for many months or more.

if that’s you, you should be aware of some things:

• The primary downside of keeping that old CMS is that it’s no longer receiving security updates — so even if there are publicly known security vulnerabilities, the package providers aren’t publishing fixes for them.

• The primary downside of moving away from that old CMS is that often (e.g. Drupal 7, Joomla 3, and others), doing so is not a simple matter of “upgrading” — it requires building an entirely new site, and then moving your old content, data, and configurations into that new site. It’s not a small task to take on.

A few people have asked me recently about how such projects usually work, so I imagine there are others who might like to know. I’m copying here a response (lightly edited for privacy and generalization) I sent this morning to this question.

E. (whose site is on Drupal 7) wrote me to ask, essentially:

Understanding that the Drupal update is not quite the kind of thing that can be done quietly in the background - can you offer any insight as to the possibility of jumping to Drupal 11 versus baby-stepping our way through it so that we can limit the chance of breakage along the way?

Also, I’ve heard that CiviCRM can run well under WordPress. is that a viable option for us compared to Drupal 11?

To this I responded:

The website rebuild (or whatever we might call the work of moving beyond Drupal 7) would amount to the creation of an entirely new site, from scratch, and then moving your content, users, configurations, and CRM data into that site. This is the kind of thing that actually must be done in one go (albeit over a manageable timeline), rather than in incremental steps. In other words, one day your live site is on Drupal 7, and the next day it's on Drupal 11 or WordPress or whatever you decide to go with.

To make it all manageable and predictable, and to minimize the chance for unpleasant surprises under the new system, I would expect such project to proceed as follows (which is how I handle such projects for my clients):

NOTE: The live site ("legacy site") continues to run under Drupal 7 until a final agreed-upon launch date, mentioned below. During this time, you and your users/members continue to use the site normally -- add/modify content, CRM data, etc. without any special concern with regard to this project.

1. Developer builds the new site from scratch, including the creation of the visual theme (deisgn / look-and-feel), major menu structures, etc., as a base to receive the data from the legacy site.

2. Developer clones a snapshot of the live site into a development environment and creates an automated process to migrate all data (content, users, configurations, and CRM data, etc.) into the new site. Because this is an automated process, it can be modified and repeated as needed without the increased turnaround time and human error that a manual process would incur.

3. Developer stages the resulting "new site" online at a temporary URL (e.g. new.yourdomain.org) for your review. You take as much time as you need to review that new site, comparing it to the still-live legacy site if you wish.

4. If you find any errors or concerns, you communicate them to the developer, who modifies the automated process to accommodate those concerns.

5. Steps 3 and 4 repeat as needed until you are confident that the automated process is resulting in a site that meets your satisfaction.

6. You and the developer discuss and agree upon a launch date, when the live site will be replaced by the new site. The launch itself may require a few hours of downtime on the site, in order to ensure all live data is transferred properly.

7. On the agreed-upon launch date, developer places the live site into "under construction mode", clones the live site into the development environment, triggers the automated process, and places the resulting site at the live URL (e.g. yourdomain.org). The "new site" is now live.

8. At this point you should once again take time to give the site a full walk-through for your own assurance that all went well. If anything is amiss (which is unlikely because the new site was built with the same automated process which you've already reviewed and approved), developer can make case-by-case fixes on the live site to address your concerns.

Because that's an iterative process with active review on your part and automation of the major components, this approach has a track record of providing solid and reliable results.

As for WordPress: yes, I think it's a good candidate for your consideration. From many of my clients, WordPress can actually be a better fit than Drupal 11, which has (unlike Drupal 7) become much more focused on being a great platform for large commercial operations with significant in-house development talent or large budgets for agency-provided tech support. WordPress, on the other hand, still aims to be a good fit for smaller organizations with simpler needs. The difference lies in the underlying technology, which is (by design) much more specialized on the Drupal side and much more straightforward on the WordPress side.

Because of that difference, it's true that over the past few years, I’ve noticed that most of my clients are running CiviCRM under WordPress rather than under Drupal.

I hope this is all helpful. Please let me know if you have more questions about it!

Here’s the thing:

Obviously this is no small undertaking.

But considering the security downsides of remaining with an end-of-life CMS package, it’s worth taking seriously.

And it’s quite do-able, and is being done successfully by orgs very much like yours.

The keys to preserving sanity and reliability in such an effort are care, good planning, and experienced technical help.

All the best,
A.