Over a quarter million D7 websites
According to Builtwith, a company that detects the technologies powering all websites around the world, over 1.5 million websites have been powered by Drupal at one time or another. As of this writing, over 600,000 websites are currently powered by Drupal. Of those websites, approximately half (386,138) are currently powered by Drupal 7.
Drupal 7 is currently on life support, meaning that only critical security updates are being performed and provided for the D7 core. According to Drupal.org, the organization behind Drupal, bug-fixes officially discontinued last fall and official security support is likely to end in late 2019. Moreover, there are many D7 modules with outstanding bugs, for which patches have been posted, but the maintainers feel it is low priority to merge and release the fixes because they are focusing all attention on D8 issues. Websites powered by Drupal 7 could expect more problems and less support over time. So, if your organization’s is powered by Drupal 7 and that website is considered mission-critical to your organization, then you should have an increasing sense of urgency to get out of Drupal 7.
So, you want to get out of D7?
Proactive organizations with mission-critical websites and apps powered by D7 should consider the costs, benefits, risks, and alternatives. Let’s talk about alternatives.
Back in the day, when Drupal reached its peak circa 2010-2011 according to Google Trends, many web development companies, including ourselves, considered Drupal a development framework that could be leveraged to build highly complex websites and web applications. While Drupal allowed us to quickly stand up sites and apps to demonstrate a proof of concept and produce quick results, we also started to realize that there was a price to this approach, mainly in the areas of performance, unit testing, and forward compatibility. So, when we started having conversations with our D7 clients about what to do, we asked them and ourselves these questions:
- Have our needs changed since the site was first built?
- What are our functional requirements? Do we really need a CMS?
- Should we have used Drupal in the first place?
After having these conversations, we have discovered that moving to Drupal 8 is not always the right option. These are the paths that our client have been taking with regard to this dilemma:
- Remain in D7 for now
- Migrate and upgrade from D7 to D8
- Move instead to WordPress
- Abandon the CMS and use a framework like Symfony or Django
Remain in D7
The reason you might do this is because the cost to move out of D7 might be $100,000 or more and you simply don’t have that kind of budget right now. There D7 security support isn’t going away for at least a year and a half or two, then you can buy some time. It could also be that your organization itself is winding down and there would simply be no return on investment or ROI in upgrading. It could also be that if you waited until 2019 or 2020 then there will be a lot more people with D8 experience and a lot more D8 modules so the transition in 2 years might be better than doing it right now.
Migrate and upgrade to D8
Organizations that decide to upgrade to D8 now are typically proactive organizations that have mission-critical systems running off a D7 platform and it would be simply too risky to wait. We have found that Drupal 8 is actually a better-engineered content management system so by the time you actually upgrade from D7 to D8, you will likely end up with a better system solution that is more modular, object oriented, responsive, usable, and open. This is not to say that you couldn’t hack a sloppy, unintuitive, cumbersome website out of D8 – this can be done, we’ve seen it, and we’ve been charged with cleaning up somebody else’s D8 mess. But, generally speaking, D8 is a better system than D7. Out-of-the-box Drupal 8 has superior functionality, such as Web Services, “Features” (a.k.a. Configuration Synchronization that right now is provided by a third-party module), accessibility improvements, and improved performance. In short, there are some things that Drupal does very well, so it works for: big organizations with different roles, and restriction access. It works for organizations that needs to manage and classify documents. It works for organizations with a real need to manage different content types, taxonomies, and fields.
Move instead to WordPress
You might find yourselves realizing that Drupal was overkill and never that intuitive or easy to use in the first place. Could be that your organization simply needs WordPress and a Drupal 8 alternative such as WordPress could more than satisfy your needs. It could also be that rebuilding your site in WordPress rather than D8 could be faster, cheaper, easier, and more satisfying. For enterprises, there is also WordPress VIP built for extremely high traffic websites.
In fact, according to Builtwith Trends, WordPress powers more than half of all websites in the solar system and across the planet and Internet. Meanwhile, Drupal powers only 2% of the galaxy’s websites. Now, if you drill down to the most popular websites on the planet, the huge ones with high traffic that are either commercial, educational, government, or nonprofit, the statistics do change a bit. When it comes to the most popular websites, WordPress is still the dominant choice of content management system (CMS) holding 37% market share while Drupal is the second largest player holding 9% market share. Drupal still comes in second, but a distant second. So, don’t rule out WordPress as a viable alternative.
However, migration from one platform to another requires not only migrating data, but also entirely shifting data-structure paradigms and workflows. This can add significantly to development time and costs. Having said that, many people feel that Drupal 8 is an entirely new and different platform than Drupal 7. So, leaving Drupal 7 to something else, i.e., WordPress or Drupal 8, would involve similar issues. Drupal fans would say: Seriously? Drupal is better. But if you have a marketing or news website, you should consider WordPress because it could be more affordable. Drupal is expensive, not only in terms of development but also in terms of required infrastructure. WordPress, in general, seems to have a better evolution process. Moving from one version of WordPress to another is less traumatic, less intensive, and less costly.
Abandon the CMS and use a development framework
It is possible that Drupal never should have been used in the first place. Or, perhaps your site has grown in complexity and functionality over time, particularly with regard to database integration, database functionality, and data itself. If your site has become data-intensive, it is possible that Drupal 7 or 8 or 9 or 10 is not the right solution. Could be that a full-blown CMS is not needed at all. In cases like this, you might consider a development framework such as Ruby on Rails, Django, or Symfony. In our experience, when we move apps out of Drupal and into something that makes more technical sense, we are surprise and excited to see significant increases in performance and better use of memory.
The cost of upgrading out of Drupal 7
Regarding costs, we have found that moving from D7 to D8 costs about as much to build an entirely new website. So, if it cost $100,000 back in 2013 when you built it in D7 then it could cost at least $100,000 when you rebuild it in D8. But, you also need to consider the cost of enhancements since the original build.
Say you invested $100,000 five years ago and then have been maintaining and enhancing it ever since, you may not be sitting on a $100,000 website anymore. If fact, you might be sitting on a $500,000 to $1,000,000 website and the cost to move from D7 to D8 could be equal to what you have into it. Of course, $500k to one million dollars represents a pretty complex, highly secure, and accessible government or nonprofit agency website. Most of the half million Drupal websites out there would not be this complex or expensive to rebuild in Drupal 8.
Timing your migration can be tricky
One one hand, you have a vague idea when the Drupal community will stop supporting critical security updates of Drupal 7. That deadline is sometime between late-2019 to mid-2020. As of the date of this writing, that gives us about 1.5-2 years to perform the migration. So here is the thing…
The sooner you get started, the fewer D7 modules will be fully built and supported in D8. So, there could be a lot of custom work that has to happen to rebuild this functionality. Then, after those modules do get built in D8, you might have to decide if you want to continue using the custom functionality that you built or replace them with the more widely supported D8 modules. Either way, there will be extra costs and redundant (non-value-added) costs.
Moreover, if you delay the move from D7 to D8 then you will likely introduce redundancy simply by delaying. For example, say you decide to add something new or enhance something on your D7 site. Whatever you do in D7 will need to be redone in D8. At some point, it might make more sense and cents to simply move to D8 and then invest those enhancement dollars once in D8 instead of twice in D7 and then again in D8.
It is also important to realize that when a major upgrade happens – like from D7 to D8 – the development community tends to gravitate toward the newer release. People are more excited about learning and contributing to D8 than maintaining a legacy D7. This means that modules will eventually stop receiving new features, and in the best case those modules will end up releasing only security updates. Anything you need, you will have to use outdated modules or create your own, instead of supporting yourself with the community. This increases development and maintenance costs.
So, the later you get started, the more D7 modules will have been migrated to D8 and you can spend less time building custom modules. But, at the same time, as we get closer to that impending deadline, more and more D7 clients will be demanding D8 developers. There will be less qualified people to do the migration, competition will increase D8 developer rates, and you may find yourself in a backlog resulting in a D7 site that has reached its end of life without community support.
Of course, some of this risk is mitigated if you decide to move to something else like WordPress or a custom framework like Symfony, Ruby on Rails, or Django.
Some tips and things to think about
- Before you move a ton of content, which might actually be outdated or obsolete, consider cleaning house and purging the site of unnecessary content, files, and images before you migrate the site to another D7 alternative.
- Make a decision whether or not you are going to simply replace the current site as is with a new CMS or if you are going to make improvements to design, usability, and/or functionality as well. Simply replacing the CMS is more of a technical matter and the type of people required for CMS replacement as well as the time and budget are completely different than the people, time, and budget that would be required if you wanted to take the opportunity to improve things as well.
- Existing D7 modules are only being maintained for security but they’re not under active development.
- A clean D7 website is easier to migrate to D8 than one that has many custom modules.
- Websites that do not have a ton of content and new content is not frequently added can be easier when it comes to flipping the switch. But, if your site has a very high volume of web visitors and a significant amount of new content produced on a daily basis, it is very difficult to sync content between the live, staging, and development sites. It is even more difficult to time the release because the site could be down for minutes at best and days at worst. Therefore, you need a rollback strategy in case you flip the switch and content is not delivering correctly.
- The effort to migrate from D7 to D8 (or WordPress or anything else) could take several months to redesign, redevelop, migrate content, test, and assure quality. You need to plan ahead and work backwards from the estimated date at which D7 will no longer be supported.
- If your D7 themes was built with business logic, now is the time to think about decoupling that functionality from the theme. In theory, themes should be switchable without losing logic or functionality. But, many people tended to build logic and functionality within the D7 themes. That practice needs to be halted and reversed. However, it will add to the cost and time of migration.
- Before you get started, it would be very important to create an inventory of all functionality, include even the smallest details, so you don’t lose anything with the migration. Product owners get frustrated when things that used to work in the early version no longer work in subsequent versions.
- Don’t underestimate time and cost. It will always be bigger and longer than expected. So, if you are thinking of budgeting $100,000 for the D7-D8 project, you should probably double that number. Whatever budget you have budgeted, double it. However much time you have estimated, double it. There are going to be countless obstacles and issues that were not on your radar but flush out during the process.
- Don’t forget about mapping the 301 redirects from previous URLs and file paths to new URLs and file paths. Otherwise, you are going to get a billion 404 page not found errors, Google might stop ranking you on its search engine results pages, and you could see a significant drop in website traffic.
- Know in advance that new bugs can be introduced in the D7-D8 migration process, particularly because there is not a 1:1 ratio or correlation of D7 modules to D8 modules, which increases the cost, time, and risk of the migration process.
- Ensuring data integrity and validating the migrated data is a very complex task and can consume significant resources from the migration process. You cannot and should not assume that all data and content migrated flawlessly. A significant amount of effort needs to be set aside for quality assurance.D8 has excellent migration capabilities built-in, but if you are using contrib modules to handle fields and entities, there may not be built-in migration for those modules, particularly in cases where there is no D8 version of the module you were using in D7. Your migration team will have to devote time to coding migration plugins to handle this, which means understanding both the underlying model of your old data structures, and those that you have chosen to migrate to.
If you are still running D7 and are thinking or worrying about getting out of it, give us a call, perhaps we can help.