Some clients have had significant issues moving to the newer platforms since Drupal updates its systems every two to three years.
Some older themes and templates are incompatible with Drupal 8, requiring developers to rebuild websites in order to operate with the newer Symfony framework. During the transfer process, certain sites become unavailable or illegible. As a result, earlier Drupal versions are still being used in more projects than Drupal 8. Although migration is expensive, failing to do so exposes businesses to the dangers associated with obsolete technology.
Problems within modules
Drupal is heavily reliant on contributed modules. Modules govern a large portion of the functionality required by Drupal sites. Because Drupal is open source, developers have been able to build over 44,000 downloadable modules for the platform. While many of these modules are actively maintained and reliable, others are minimally maintained, at best, with some being abandoned completely.
Another significant problem with Drupal modules has been the lack of backwards compatibility. A module written for Drupal 7 won’t work with Drupal 8, for example. With the advent of Drupal 8, this is no longer a problem, as long as module maintainers keep up with the pace of Drupal core development. Drupal 9 is essentially Drupal 8 with all of the deprecated APIs removed, meaning that modules written for Drupal 8.9 should work ok with Drupal 9. The more active release cycle that began with Drupal 8 has the effect that Drupal 8 End of Life (EOL) will occur before the Drupal 7 EOL.
Drupal depends largely on a sophisticated hook mechanism to load modules automatically. The PHP code implements a particular hook, which triggers the auto-discovery of the relevant module. However, the problem arises when Drupal must load every enabled module on each server request in order to identify the one that implements that hook. Drupal may be forced to utilise extra memory resources since PHP lacks long-running threads that can effectively handle these memory problems.
While caching helps to alleviate the platform's memory and performance problems, it may sometimes cause odd bugs on Drupal-based websites. Users may have problems if the CMS's multiple levels of caching aren't refreshed when anything changes. That's why, when anything goes wrong with Drupal, system administrators may often resolve the issue by emptying the cache or freeing up resources using tools (such as Memcache) and methods (such as reverse proxies).
Challenges in DevOps
Drupal 8 is unquestionably resource-intensive, and DevOps teams are tasked with meeting high-performance expectations. Drupal utilises a SQL database, which may be challenging to scale and manage across development and production settings. As a result, many IT experts consider delayed database installations to be a software delivery barrier.
In-memory caching technologies like Memcache, Redis, or Varnish are another method to enhance speed, but they need additional effort from IT operations to deploy and manage across environments. Drupal, in any event, places a strain on DevOps teams to provide the performance that businesses need.
Migrations can become complex; a full rebuild might be better
Since a lot of new objects have been introduced with Drupal 8 (and carried through to D9), it may be worth rebuilding the entire site's structure, including its presentation layer (design/theme/UI). In which case, the process becomes more complex, requiring more custom logic to be implemented.
A few examples we have encountered in our own experience include:
1. Simplifying site's structure by merging content structures, such as taxonomy vocabularies or content types:
For example, a D7 site with many content types merged into fewer content types in D8.
2. Leveraging new modules, objects or content structures:
- Porting files and images to become media objects, leveraging D8 new Media library features.
- Merging multiple fields into a single paragraph field providing multiple potential fields and formats
- Changing/converting field types to leverage newer data types, such as core telephone, link, email fields, etc
Revamping the front-end layer (theme), to give a fresher look and feel or support newer standards:
- Rework organization of the site (sidebar, dropdown menus, etc
- Responsiveness and better support for newer devices (phones, tablets, laptops, etc
- Better accessibility support while improving performance (loading times)
In other words, in most cases, the process is not going to be as straightforward as migrating the same content structure or objects from/to an identical Drupal site, with newer technology, but would most likely include transformations in the process (merging/splitting, transferring, converting, etc).
There are ways to make the process go much smoother.
Drupal 8/9 provides an extensive framework to support migrations, on which several industry-standard modules are based, among which:
- Drupal core Migrate module: Foundation framework, allowing migrations from any system to Drupal
- Migrate Drupal module: Drupal to Drupal migrations
- Migrate tools: Additional tools for running and managing Drupal 8 migrations
- Migrate plus: Extensions to core migration framework functionality, as well as examples
- Migrate Scheduler: provides the functionality of executing the migrations on a particular schedule
This suite of modules facilitates migrations. In particular, for any potential custom logic that could have been implemented in the source system.
For Drupal 7 to Drupal 9 migrations, we recommend starting from scratch
Given the numerous standards and technologies that have come out more recently and are now supported by D8/9, we would likely recommend considering rebuilding your site from scratch. Into which the content of the source site can then be injected: files (images, videos, etc...), users, nodes, taxonomy terms, etc.
Through multiple experiences we have been able to build a complete plan, taking your site step-by-step through a smooth migration process, resulting in a completely new site filled with all the content of the original site.