Drupal 7 has been around for a long time. It was first released in January 2011, and had active development until November 2015 when Drupal 8 was released. You would be forgiven for expecting Drupal 7 to have become end of life (EOL) (that is the software is no longer supported for security vulnerabilities) when Drupal 9 was released, but no - in fact, Drupal 8 became end of life first in 2021, half a year after Drupal 9 was released. As time marches on, Drupal 9 is also now end of life, and at the time of writing, Drupal 10 is the major (and only) stable version, with Drupal 11 on the near horizon.
Yet Drupal 7 is still supported. Why, you might ask? There was a fundamental change of the codebase on which Drupal runs when version 8 came out. If you are on Drupal 8 or above, upgrades are trivial in comparison, as the process is an upgrade. A move from Drupal 7 to Drupal 8 or above however is an involved and sometimes lengthy process, as rather than an upgrade, it is a new site with a “migration” where the data structure and content moved over to the new version. On large sites where data is changing all the time, such as e-commerce sites with orders, the site must be rebuilt first with an initial import of data, then once completed, the data must be rolled back and a new import run to ensure no newly created or updated data is missing.
There are a few reasons for the delay in Drupal 7 becoming end of life, Covid-19 was one, but ultimately it is down to the huge task of migrating major sites off the platform. The end of life date has been changed several times, but now 5th January 2025 has been announced as the final date with no further extensions. Many would argue this date is long overdue already.
If you are still on Drupal 7, what options do you have?
Given Drupal 8 has been stable for over nine years, it would be a reasonable assumption that if your site is on Drupal 7, it is at least ten years old. With this in mind, there is a good chance the look and feel of the site may also be of this age and would benefit from a refresh. The underlying modules your site is running on will also be dated and quite likely would benefit a refresh too.
We would recommend a completely new website built from the ground up is the best action to take, be that to the latest version of Drupal, or another content management system.
But what if your data is so large and intrinsic to your current Drupal 7 site that a brand new site is simply not feasible?
We have worked with clients in this situation. The thought of re-entering hundreds of thousands of data entries from scratch is not an option. In this scenario, we would recommend a “migration” of your Drupal site.
At Logic+Magic, over the past decade, we have performed many migrations, both small, large and very large. There is no way of avoiding it - this will be a major undertaking, larger than a ground up new site, but crucially, your data will be retained.
The process would initially start with a site audit. This would be broken down into the following sections:
Migration path
We would examine what data there is and what modules are used within Drupal to provide that data structure. Often this is provided by Drupal core - simple fields such as number, plain text, rich text, image, files etc, but also third party (contributed modules) provide extended functionality for fields such as metadata, date, time, country, address, latitude, longitude etc. For each of these field types, it must be identified if a migration path exists. If no migration path exists, this data must be migrated manually (copied and pasted) or a migration path must be written. It would depend on how much data there is to migrate as to which route to take - a hundred entries it is feasible to manually migrate, but a hundred thousand entries is not.
Contributed module support
A contributed module is one that is provided by the Drupal community, but is not part of Drupal core. The equivalent to this in Wordpress is a plugin. We then review all modules enabled on the site and identify if the same module exists in Drupal 10. If no module exists, we would look to see if an alternative module is available to do the same job, assuming no data has to be migrated. Sometimes it may be possible to remove the feature entirely if it is deemed minor or no longer required. However, if a contributed module does not exist which provides a major feature, then this it must be built new, and if necessary with a migration path.
Custom code
This is usually in a custom theme and one or more custom modules. A custom module could be simple, perhaps less than two lines of code that does one small change. Or it could be thousands of lines of code which provides an advanced feature, which is not possible to achieve with by a contributed module. There is not usually any issue with re-writing a custom module to work in the latest version of Drupal. We aim here to estimate how much there is to do.
At this point, if there are a large number of blockers identified, you may choose to walk away from the migration. The work involved may simply stack up to it not being a viable undertaking.
However, assuming there no issues raised from the audit, to begin the migration we would create a new Drupal 10 site, and install all the modules that are required, specifically those which are required for data migration.
The data architecture is then migrated, which in Drupal are known as entity types. These are things such as content types, taxonomy vocabularies and commerce products to name a few, with all the fields that exist on them. The data for these entity types is then migrated in to the new site.
If the dataset is large, this can take several hours to run. The dataset is chained and the migration often needs to run in a specific order. Once complete, it is followed by a full review to make sure that everything has come across that should. If something has not migrated successfully, which is often the case, it must either be rolled the data back and the missing migration path fixed, or quite often starting the migration process from the beginning.
On a large site with many differing field types, this can take many attempts to perfect. If it takes several hours to run one data migration, it is easy to see how quickly this task can take many days, often weeks to get a perfect import.
Once the data is successfully migrated, the remainder of the site is rebuilt. This usually involves a custom theme being converted from PHP templates to twig, Drupal “views” all rebuilt from scratch and many other configurations all re-configured from the ground up, much like a new build.
After the rebuild is complete, the data is then rolled back. Your production site is put into maintenance mode and another export is taken for a final data import. Your site should then be ready to be made live again, running on the latest version of Drupal.
How long does this process take?
That entirely depends on the scale of your site. A small site can be rebuilt and migrated in a week, but a large site can take four months or more.
If you have a Drupal 7 site, there is not much time left before vulnerability support ends in January 2025. Now is the time to have your site rebuilt so you aren’t left open to attackers. Whether you are looking for a new site or a migration, Logic+Magic have the skilled and experienced developers to undertake your journey. Please get in contact with us today to discuss.
Software Services Director
