What Drupal 7 end of life means for your charity website
Drupal 7 will soon reach end of life. You must update your website now. If you fail to do this there’ll be no new security updates, hackers will take over your website, the pictures of your cat will be held to ransom for 8 bitcoins, which - just to top it off - you won’t be able to buy because they've nicked your credit card.
Okay, we’re being dramatic. But it’s definitely worth thinking about how to approach Drupal 7 end of life for your charity’s website. We will run you through some options to ensure the best of life.
Update: Drupal 7’s ‘end of life’ was originally scheduled for November 2021. Given the impact of COVID-19 on budgets and businesses, this has been pushed back to November 28, 2022.
Why we love Drupal
We want to break down in plain English, what Drupal end of life means for your charity’s website. But first, why Drupal?
Drupal is an immensely popular CMS in the charity sector. It’s out of the box features and interoperability make it a good fit for charities that have CRMs and other systems that their website integrates with.
Importantly, for charities with tight budget controls, Drupal is free with no licences. It has a large developer community that provides a huge number of modules for free.
Drupal 7 will be end of life in November 2022. This means that after this date there will be no fixes, new features or security updates from the Drupal community, Drupal Association or Drupal Security Team. Considering Drupal 7 was released in 2011, you have to say it’s had a pretty good run!
Why does this end of life matter?
Firstly, and pretty importantly, Drupal 7 end of life could leave your site vulnerable as a result of missing security updates. Essentially, no new updates mean you’re hitting a wall, unable to progress and get to where you want to be.
But don’t panic, you aren’t alone! With over 700k sites running on Drupal 7 there are plenty of sites still to upgrade.
The release of Drupal 8 in November 2015 brought Drupal up to date with advances in technology and specifically the advances in the CMS sector. We wanted to break down the improvements that Drupal 8 has brought over Drupal 7:
- Drupal 8 is mobile-first out of the box, allowing users to view content on the device of their choosing
- A revamped content authoring experience with a focus on providing content editors with a first class media management system and content workflow
- Drupal 8 boasts extensive multilingual features out of the box. The admin interface has built-in translations and adding translations for your content is simple and easy
- Drupal 8 takes advantage of developments in performance to deliver a lighting fast experience to users
- Integrations have become a whole lot easier with Drupal 8’s changes to its underlying architecture
- Drupal 8 can be used as a data source for other systems using the JSON:API standard meaning any other system can pull content from Drupal. For example you may have an app that pulls in the latest news from Drupal
- SEO-friendly content out of the box
- Painless upgrade path to Drupal 9. Taking the learnings from the Drupal 7 to Drupal 8 upgrade
First step. What do I have?
For some sites, the upgrade will be a quick and easy experience. For more complex sites it can be more challenging.
The first step is to have your current Drupal 7 site audited by a developer. They will be looking for the following pain points to gauge how simple or complex the upgrade will be:
- How many modules your site currently uses which have a Drupal 8 version. The good news is that some of the most popular Drupal 7 modules have been moved into Drupal 8 core and so now come out of the box
- How many custom modules have been written for your site. Due to the re-building of Drupal 8’s underlying architecture, most custom modules will need to be re-written
- Integrations with 3rd party services like CRMs. These may need to be re-written, but the good news is that Drupal 8 is architected to be great for integrations
- How complex your theme is and how much it has been customised
The next step will be to have a look at your content. It’s always useful to do an audit of content periodically, so view this as a great chance to see if what you’re putting out there is actually serving the needs of your users in the best way possible.
A content audit is qualitative and quantitative insight into your content, looking at how well it is performing and why. It means creating an extremely detailed site map that represents every page – and any other piece of content – of your website.
This overview allows you the auditor to make recommendations for adding, removing, consolidating or improving content to ensure it is meeting your users needs.
The developer will be keeping an eye out for fields and functionality that aren’t available in Drupal 8 and will suggest alternatives.
With all this information a report will be produced outlining the effort required to upgrade, potential pain points plus a recommendation on approach. Given the complexity of your site and the upgrade this report may recommend:
Upgrade to Drupal 8
If the upgrade path is straightforward then a straight upgrade is recommended. This has the advantage of minimal disruption and keeps your site the same across versions of Drupal.
Rebuild in Drupal 8
If your site is very complex or you rely on a lot of the modules which do not have Drupal 8 versions, then a rebuild may be on the cards.
Rebuild in another CMS such as WordPress
If you have a simple site that can be served easily by WordPress, then it is often the most cost effective to use WordPress for your website due to its low maintenance cost.
The report produced will give the pros and cons alongs with a rough cost and time for each option. This will be followed by a recommendation on which path to go down.
How will it work?
In all scenarios it’s advisable to setup a ‘staging’ site if you don’t already have one. This is a copy of the live site that you can test changes on.
Upgrade to Drupal 8
A lot of work has been put into the upgrade path from Drupal 7 to Drupal 8 by the community. The developer will do all the heavy lifting here to upgrade the codebase.
Your content and URLs will remain the same so the impact on SEO is minimal here.
There will be no impact on users who have accounts on your site.
Rebuild in Drupal 8
The process of rebuilding in Drupal 8 is similar to a new site build. Except, you have the head start of having a complete brand and a clear idea of what works and what doesn’t work for your users.
Once the new site is built then there are a couple of considerations. First off is what to do with your current content? There are a couple of options here. The first is to use Drupal’s Migrate API to load your content into the new site. This has the advantage of reducing the load on your content editors as they will only need to check the content has moved across correctly.
The second option is to manually migrate the content across. This is more time consuming for your content editors but it does come with the advantage of being able to roll a content audit into the migration.
Drupal 8 will handle redirects for content titles that have changed, so your old links will still work and your SEO isn’t affected too much. Drupal also has great redirect tools so that administrators can add redirects from old content to new.
The second consideration is deployment. To reduce risk you may want to deploy the new site to a duplicate ‘live’ environment and then point your domain at the new site. This will require some coordination to make sure the database is up to date when the switchover is made. The old ‘live’ site can be turned off once you’re happy the new site is up and running correctly. We would almost always recommend this method.
Alternatively you can deploy to the current live site. This comes with its risks, but is much more straightforward. There is no domain switchover and no need to grant access to any third party systems to a new environment.
If you have users with accounts on the site you will need to stop them logging in while the switchover is completed. This can be done easily by putting the site into maintenance mode which only allows administrators to login.
It is recommended that all deployments are done under maintenance mode, but in our experience this can be safely ignored for deployments that are small or those which don’t affect users with accounts.
Rebuild in another CMS such as WordPress
Rebuilding in another CMS takes some of the same steps of rebuilding in Drupal 8. You already have your brand and a good idea of what works for your users.
When evaluating other CMSs there are a few things to be mindful of:
- The functionality offered by the CMS and what your current Drupal site offers
- Expertise in the CMS. Not only your internal content editing staff, but your developers or development partner
- Some CMSs charge licence fees, Drupal and WordPress do not
Content migration is a larger consideration here also. Taking WordPress as an example, there are plugins that can migrate your content across to the new site. However these aren’t as slick as the Migrate API in Drupal and there is a chance that functionality that your current Drupal site has, doesn’t necessarily exist in another CMS.
The switchover considerations are the same as the rebuild in Drupal 8. User accounts can be ported across, but all users will need to reset their passwords after switchover.
When you’re up and running on Drupal 8 you can start to take advantage of all the new features listed at the start of this article.
You can also look forward to the Drupal 9 release on the 3rd of June 2020 without worrying about another big upgrade. The community has been working hard on making this one as simple as possible. There are no big architecture changes so the upgrade to Drupal 9 will be as simple as a routine update. Hallelujah!