The (High) Cost of Not Being on Drupal 8
Site migration is never anyone’s favorite thing. Depending on how complex your website is, how much content is on it, and what resources you can allocate it, it can time consuming at best or, on the other end of the spectrum, a total nightmare.
However, when it comes to Drupal, the benefits outweigh the challenges.
Moving towards a new version of any package of software is normally the recommended choice from a technical point of view but, unfortunately, the tech side is rarely the only consideration to have in mind when looking at a complex enterprise solution. Costs, future-proofability, internal political landscape can all impact the decision of if and when to migrate.
We’ll try help anyone on that position making that decision easier with a few considerations that we can extract from 10 reasons why you should start your next project in Drupal 8.
Let’s jump straight to what it’s normally a key point in all companies: Doing a new project in Drupal 7 or not upgrading to Drupal 8 it’s going to be expensive.
Drupal 7 end of life is approaching, and with that all efforts in the community are in Drupal 8. That means that lots of features that you may need will not be available in Drupal 7, or may be poorly maintained, and missing key elements from security to new features.
In other words, you may have to invest your own time to implement features that may be already in Drupal 8. A recent example I found is Adobe Analytics. Sorry, not just in Drupal 8, so we had to invest a few sprints to do that custom work for the client, while in Drupal 8 it would have meant just a ticket with a not too high number of points (if you are in agile world).
Yes, all releases are covered, and big security issues have provided patches even for Drupal 6, but be aware that the focus of the community efforts is with Drupal 8.
Drupal 8 has all the attention now, everyone is focused on improving it, making it faster, more secure, and easier to use. Remember that major new security flaws are normally discovered in the current stable version, Drupal 8 in this case, and if they are really critical, they get backported to Drupal 7 (and in some rare occasions even Drupal 6 as we saw in the latest #drupalgeddon episode).
Drupal brings big improvements in performance for the average site. In Drupal 7, for example, talking about caching meant talking about anonymous users caching. But let’s be honest here, isn’t Drupal designed to have authenticated users in mind? What happens with the traffic for those users growth?
Well, you were basically in trouble. You could do things like leveraging caching on the auth_cache module, but if you did not have that in mind while designing your site, the level of work to ensure that the users were receiving the fast responsive expected experience that everyone expects this days is far from a small effort.
Drupal 8 has things like Bigpipe and authenticated users cache, which would make the effort of delivering the content to auth and anon users a breeze compared to what that meant in Drupal 7.
In general, if performance is a concern for you, you should have in mind that Drupal 8 comes with PHP7 support, which is extremely faster than previous versions, and caching and loading speed has also been improved. And better performance also means smaller bills from your hosting :-).
To support this with some numbers, I have seen sites while I was working on some big publishers whose servers were 90 percent busy with the 10 percent of the authenticated traffic. Just imagine how much money you can save in hosting fixing that part.
Believe the hype. One of the things I personally like most about Drupal 8 – and something that everyone is quite excited about – is the API-first initiative.
As Preston and Dries have put it, the web has changed. No, really the web has changed a lot. Not that many years back, desktop was the thing. Later on, everyone was talking about the mobile revolution. Nowadays, we have IoT, hundreds of connected devices, and everything is much more complicated. And change is happening even at faster rate.
That means that it’s time we stop talking about devices and just think about “content first” – the same way we used to talk about “mobile first.” Your CMS should be able to adapt to those new changing scenarios. And Drupal has survived all these years thanks to huge transformations like this one.
Companies have hugely demanding and changing requirements. What was acceptable yesterday – just having a website – is no longer enough. Today we we need to spread the information among very different devices. From the desktop, to mobile and tablets, to watches, to screens in the street – and again don’t forget the IoT revolution.
Having a CMS that is able to deliver on that promise basically ensures that we won’t have to spend thousands of dollars again in the future, and most important, that we’ll be able to deliver in this changing environment as quickly as the requirements and devices change.
Although you could flex Drupal 7 to adapt to this changing environment, the real power and flexibility comes with having a Drupal 8 architecture where this flexibility is already in the core. That has implications for performance, adaptability, simpler architecture of services around Drupal, etc.
So, if you think you just need a website, that’s completely fine. But if you have the slightest inkling that you may need a mobile app, content that can be reused in “who knows what” future devices, then you should probably rethink your strategy and think decoupled.
And, yes, you guessed my next point: Drupal 8 is the perfect platform for that.