When is it time to panic?
“God help us, we're in the hands of engineers.” – Jeff Goldblum as Dr. Ian Malcolm in Jurassic Park
With support for Drupal 7 soon to be extinct, many Drupal 7 website owners are anxious to migrate quickly to the next generation of the CMS, Drupal 8. With phrases like “end of life” and “sunsetting” now almost ubiquitously attached to Drupal 7, some are feeling chills of terror sweep over, as if the surface of the water in the glass resting on the dashboard has begun to ripple from the impact tremors.
If you have recently invested in a Drupal 7 website, you may be feeling a strong desire to “simply” upgrade. Some refer to this as a “lift-and-shift” or a “basic 1:1 migration” — the idea being to reproduce the same Drupal 7 website on Drupal 8. Much like visiting the dentist, the defining interests here are to do it as quickly and painlessly as possible. But rather than view it as a necessary evil, we kindly proffer that migrating to Drupal 8 is a fantastic opportunity to improve your Drupal platform.
With the promise of a cleaner upgrade path to future versions of Drupal, moving to Drupal 8 is a big evolutionary step for those leveraging the CMS. It represents a pivotal opportunity to solidify the foundational structure of your Drupal site. In other words, this isn’t the time to go rushing into a migration simply because the end is nigh. As in any replatforming, we should be thoughtful in our planning and approach.
From the Drupal 7 website owners we have spoken to recently, their hopes and dreams for Drupal 8 are paired with a familiar set of questions and anxieties about migrating from Drupal 7. How does it work? What level of effort is required? Have we budgeted enough for this migration? What should we be thinking about as we look at a migration?
Looking around the web, we’ve found excellent articles about the logistics of migration to Drupal 8, but less discussion of the risks and rewards that should inform how you plan a migration that is appropriate for your site. So, we’ve tried to capture some common topics from our conversations with clients for the benefit of all.
There Is No Such Thing as a Simple Migration (TINSTAASM)
“The kind of control you're attempting simply is... it's not possible. If there is one thing the history of evolution has taught us it's that life will not be contained.” – Jeff Goldblum as Dr. Ian Malcolm in Jurassic Park
Migrations come in many flavors. Migrations can be automated (we configure an existing software or service to manage the migration of code, configuration, and/or data). Migrations can be programmatic (we write a migration script to manage the transfer). Migrations can be manual (some poor individual must painstakingly copy/paste code, configuration, and content from one system to the other). Most likely, a migration from one web platform to another includes several of these types of migration. In the case of moving to Drupal 8, a migration likely encapsulates all of them.
The reality is that moving from Drupal 7 to Drupal 8 is not as straightforward as most of us would like. Yes, Drupal 8 comes with some excellent new migration tools, but those tools are limited to certain parts of a Drupal website and come with some caveats based on how your site has been configured and customized. One of Drupal’s greatest powers is how extensible it is, allowing Drupal to be a platform for an unlimited array possible web applications. However, this strength can be a weakness when trying to automate migration tooling because each highly-customized Drupal application becomes a fairly unique animal.
What this means for most site owners looking at a migration is that, while there are clear migration paths for some parts of a Drupal 7 site, others will require manual effort. For example, you will find no automated migration paths for your theme(s) or your views, which are significant parts of nearly every Drupal website. Both will almost certainly require some level of manual migration of the code and configuration from a developer. Specifically, PHP template files from your Drupal 7 theme will need to be rebuilt using Twig, so sites with a lot of different content types and/or templates will have a heavier lift migrating to Drupal 8.
Further, the quality of the build of your Drupal 7 site will have a big impact on the effort required in a migration to Drupal 8. Poor choices in the development of the Drupal 7 site can make a migration more complex. For example, themes packed with custom functionality and logic will require greater effort to detangle layout from function. Similarly, the use of custom modules or an over-reliance on modules that have no upgrade path to Drupal 8 can significantly slow down the process and impact the cost of a migration.
Careful planning for these exceptions is required. In most cases, that will include a combination of automated, scripted, and manual migration of various parts of your Drupal website.
Don’t recreate what is better left extinct
“Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should.” – Jeff Goldblum as Dr. Ian Malcolm in Jurassic Park
Before we even arrive at how we can migrate a Drupal 7 site to Drupal 8, perhaps we may benefit by first asking whether we should directly migrate the site.
Moving from D7 to D8 is more akin to replatforming to Drupal than, say, upgrading a version of software. As with any replatforming, it is an optimal time to address any issues or problems you’ve experienced with the current website. The reason being that if there are architectural or data model changes to be made, it will be most efficient to make those changes during the replatforming. It makes little sense to undertake the expense of a migration project, if part of what is migrated are the same problems and irritations the old site caused.
So, the first question to ask when considering a migration may be, “How happy are you with how the current site works?” If you’re totally happy, no complaints, then maybe a direct migration from old site to new site is appropriate. If there are some issues you’d like to address, as is common, it’s worth determining if it’s more cost-effective in the long-term to address those during the migration process.
Examine content entry, editing, and management. In particular, ask your content editors what is painful. Are they spending too much time entering or editing content that could be handled more efficiently? Are there data sources that could be better leveraged? Or better normalized and consistent? Or combined to greater effect? Do different types of content have the necessary relationships to other types of content to display those connections in the frontend?
Ask about edge cases and situations where the content model built in Drupal doesn’t always align with the realities of the actual content. Listen for circumstances where X is normally the case, but when Y happens, content editors have to do Z as a work-around. Ask about where the Drupal CMS feels rigid and needs to be more flexible, or where its too flexible and needs to be more constrained (that does happen!).
These are all areas where improvements to the content model begin to emerge. Having these conversations will bring to light whether your Drupal 7 foundation is sufficiently solid to continue as the basis for a new Drupal 8 platform, or whether some restructuring is needed to ensure the longevity of your new Drupal 8 website.
What’s at risk?
“If The Pirates of the Caribbean breaks down, the pirates don't eat the tourists.” – Jeff Goldblum as Dr. Ian Malcolm in Jurassic Park
What’s at risk if you make no improvements to the website when you migrate to Drupal 8?
In a word, disappointment. Any migration to Drupal 8 is going to be an investment of resources. If no tangible improvements come with the expense, it will feel like a disappointment to many. We’ve seen this happen to clients. While there are inherent benefits to Drupal 8, improvements may not feel tangible enough to stakeholders or site editors/administrators. And if no functionality, usability, or design enhancements accompany the change, it will offer no discernable improvements for site visitors. Taking a minimalist approach of migrating a site “as is” onto Drupal 8 often feels like a heavy lift without any gain.
Or worse, it may even feel like a step backward if bugs arise during or post-migration. There is always a risk that functionality will degrade in a replatforming project designed to simply replicate the old website. If the only improvements are experienced in the backend of the CMS, major stakeholders may view the project as an investment that simply made things worse.
Additionally, if you decide to address structural issues after migrating to Drupal 8, you risk paying twice for the re-architecture and reconfiguration work. In effect, you pay for some of the costs again because the new architecture and configuration required for the enhancements are “rework” of what the developers performed during the migration. In short, it’s an inefficient use of resources and degrades from the return on the investment in the website.
Lastly, given that future Drupal upgrades will resemble software updates more than replatforming efforts, getting your data and architecture ironed out on Drupal 8 will likely have the ongoing benefit of smoother transitions to Drupal 9, Drupal 10, etc. Without improving your website’s foundational structures, you risk re-introducing your legacy pain points into each new version of Drupal.
Mitigate the uncertainties
“See, here I'm now sitting by myself, uh, er, talking to myself. That's, that's chaos theory.” – Jeff Goldblum as Dr. Ian Malcolm in Jurassic Park
You can get answers to a lot of questions about the feasibility and cost of a migration by having a qualified, experienced Drupal 8 engineer perform a technical audit of your existing Drupal 7 website. It’s a small investment (relative to a migration) with a high return in insight and greater certainty. Such an audit should document and analyze:
- Contributed modules (specifically is there an upgrade path to Drupal 8?)
- Custom modules / integrations (specifically noting their function, whether there are better approaches or contrib modules, and can the code be ported to a custom Drupal 8 module?)
- Theme (specifically is there any logic or functionality embedded in the theme which should be pulled out into a custom module, and how many templates does the theme use?)
- Views (specifically are any views overridden or enhanced by custom code/modules?)
- Content types (specifically are there any duplicative or unnecessary content types that could be consolidated?)
- User roles and permissions
An audit from a qualified developer will give you a much clearer idea where the risks and opportunities exist in a migration to Drupal 8. It will surface the cost-drivers in a migration, pinpointing areas that will require special attention, effort, and time to migrate. This is valuable information because it can help you shape your migration plan strategically. For example, you may realize there are legacy modules, content types, views, menus, etc. that aren’t of value to migrate. The older the site, the more likely there is cruft to be excised. You may also determine that some parts of the site are critical for relaunch of a migrated site, whereas other parts can be migrated later.
Even more helpful than a technical audit alone is to pair it with a strategic discovery aimed at identifying pain points for site users, stakeholders, and administrators. Such a strategic discovery could include a functional audit to define both the site’s functional capabilities (actual and intended) and the business goals those functionalities are designed to achieve. A functional audit provides useful context for understanding if the architectures described in the technical audit are optimal for your desired outcomes.
Further, a UX audit including review of site analytics, and possibly even user-testing, would demonstrate the effectiveness of the site’s functionalities and architectures in achieving the your business goals. Such audits and analyses can be focused on both external users of the site (visitors) and internal users of the site (administrators and editors). Improving the editorial experience of a CMS can unleash massive productivity gains, especially with poorly architected content management systems.
This information will provide a valuable frame for understanding the opportunities for improving your website during a migration. With such insights, a migration plan may include several changes to the content architecture or site configuration that have meaningful impact and improvement for functionality or administrative efficiency. For example, as mentioned earlier, consider all of the template files that will need to be converted manually from PHP to Twig. Are all of those templates necessary? Are there layout changes that may be highly desirable and valuable that would make a lot of sense to adjust now? While it may cost more upfront to make such changes now, the efficiencies from consolidating these improvements to a single development window may yield a lower cost of ownership in the long-term.
Finally, another benefit of the technical audit, especially if paired with a strategic discovery, is that it should provide a clearer picture of costs for both a direct “as is” migration of the existing site to Drupal 8, as well as an upgrade in the functionality of a new Drupal 8 platform. The audits are relatively low-cost engagements that arm your decision-making with greater insight and cost-certainty. They are almost always worth doing.
So, what does a Drupal 8 migration cost?
“Boy, do I hate being right all the time!” – Jeff Goldblum as Dr. Ian Malcolm in Jurassic Park
Without the benefit of knowing the specifics of the Drupal 7 site to be migrated, it’s impossible to say what the cost could be, but it is possible to say with some certainty what the cost-drivers will be:
- Quality of the Drupal 7 build, architecture, configuration, theming, etc.
- High numbers of content types and templates
- Use of contributed and custom modules + upgrade states of those modules
- The Drupal 7 site’s ability to meet users needs currently
- Desired improvements to be made to your site during migration
If you are uncertain of the quality of your Drupal 7 site, if you rely heavily on custom modules or contributed modules without a Drupal 8 version, and/or if you have significant issues with the site you’d like to resolve, you have the most to gain from a technical audit. Without that insight, estimates for migration from Drupal 7 to Drupal 8 could be woefully off the mark.
The good news is extinction for Drupal 7 is still far enough in the future that you have time to do a proper and appropriate migration to Drupal 8. Get a good evaluation of your existing situation and make a solid plan before heading blindly into replicating old mistakes.
Don’t trip stampeding to the exit doors
“That is one big pile of shit.” – Jeff Goldblum as Dr. Ian Malcolm in Jurassic Park
At this point, you may be wondering why you use Drupal at all, perhaps thinking now is the time to move to WordPress, but don’t despair. The truth is Drupal and WordPress are not inherently superior or inferior to one another in any generalized way. Most often, we find that site owners feel frustrated with their Drupal website because it is poorly architected for their needs. WordPress sites can be just as poorly architected and painful. Regardless of the platform, it needs to be implemented well in order for you to draw maximum utility from your website. And to note, migrating your Drupal 7 site to WordPress will also be a replatforming of significant effort and cost.
As we’ve said, migration from Drupal 7 to Drupal 8 is the perfect opportunity to make your Drupal site work better for you and provide more value for the investments you’ve made in it. There is a lot to love about Drupal 8. To get the most out of it, it’s worth architecting it right since your website will rest on that foundation for all of the future Drupal versions to come.