Upgrade = Rebuild?
If you are at all aware of Drupal’s history or have any first-hand experience maintaining a site on the platform, you’ll know one tried-and-true concept that plagued us for years. You really can’t upgrade Drupal. Sure, you can write custom migrations of your content types, replace 1 contrib module with 2 others or vice-versa, reset all your users’ passwords (assuming you get them in cleanly), and the list goes on. Drupal simply wasn’t built for easy upgrading between most major versions so you had one choice - milk that site as long as you can until it shrivels up and dies.
Some might argue in favor of upgrading, proclaiming “Hey, it’s a great chance to re-evaluate your needs!", but that was usually just a cop out. While it may be true, giving that response to concerns over an upgrade path is akin to telling someone fresh off a breakup that “this is a chance to be free”, trampling all over their raw and turbulent feelings. The reality is that it was a hard knock against an excellent platform, especially on large projects that might take more than a year or two to finish, all the while knowing that 2 years later you are looking at a major rebuild and migration.
Enter Drupal Version Gr8
Drupal 8 came with a lot of whiz-bang features, better support for common CMS features in Core, a much more mature Symfony based architecture, etc - but possibly biggest of all, it adopted a new release cycle - rooted in semantic versioning - for ongoing development. While this is usually the domain of developers and engineers, it actually has huge implications on clients, especially regarding WHEN it could be considered the optimal time to upgrade to the latest version of Drupal. Before Drupal 8, there was endless debate on whether it’s better to get clients onto the new major version early on in its adoption - thus maximizing the time before end-of-life while increasing bugginess - or else waiting until it was extremely mature - thus providing high stability with a relatively short life cycle before the rebuild/upgrade discussion begins.
With semantic versioning, we now can all collectively breathe a sigh of relief as it’s now much safer to recommend upgrading to Drupal 8 because - guess what - the Drupal 9 upgrade shouldn’t really be that big of a deal. Here are the highlights of the new direction.
Patch releases are released every month.
Minor releases are released every six months.
Experimental modules accompany minor releases and have a stability deadline by which to either be included in Core or deprecated. (Go to the official page for a much more thorough explanation of this)
The last minor release of a major version (ex: 8.x) will have long term support and be the basis for the new major release branch (ex: 9.x)
So - to put it in layman’s terms - differences between versions of Drupal should now be much less significant and catastrophic as most major features make their way in through a minor version experimental module that is eventually adopted. So upgrading to Drupal 9 from the last stable release of Drupal 8 shouldn’t be that big of a deal. And if that’s true, then there’s absolutely no reason to wait for Drupal 9 and instead get upgraded to Drupal 8 as soon as possible to start enjoying the benefits.
Upgrading to 8 Will Still Be Hard
Despite the avalanche of delightful news that Drupal 8 brings, there are numerous challenges to getting over the hump and getting yourself moved onto 8 so you can start benefitting. These challenges aren’t new to Drupal 8 entirely, but are worth reviewing.
You have a history
If you have a lot of data and/or users - or a website that has evolved a lot since it’s original inception - that’s always a challenge for a number of reasons. Firstly, large migrations take time, prohibit using certain technologies, often contain more instances of “bad” data that may not be acceptable by the new system, etc. Data, and especially configuration, also has to often be translated between systems and if that data is rooted in Drupal 7 (or earlier) data models, then most certainly you’ll want to use updated field types and definitions and architectural approaches to take the most advantage of Drupal 8.
It should be noted that there are better Drupal migration tools in Drupal 8 that come right out of the box in Core, but in general it doesn’t take much to trip them up. For example, the migration infrastructure works on the concept of migrating “configuration” and then “content”, but “configuration” can consist of a lot of customization provided by contributed or custom modules that simply don’t exist in Drupal 8, or are else handled very differently. At Ashday, we lean 9 times out of 10 on writing a custom migration script that does exactly what we want. This means being steeped in Drupal database structure and underlying approach though and may not suit everyone.
Contributed modules have changed
Drupal 8 has considerably less stable contrib modules than Drupal 7. Why? Well, for one - Drupal 8 does a lot more out of the box. Views are included. More content concepts are entities. The block system is much more powerful. This makes for a tricky migration though because if your site-to-be-migrated is built on heavy custom programming or a host of contrib modules, you have to translate that functionality - and the underlying data - to the newer way of doing things. That likely involves redoing a considerable bit of the setup because it’s unlikely too much of it will translate cleanly.
It’s all a positive mark for Drupal because Drupal 8 contrib modules tend to be much more modular in design and more consistent, but the system isn’t going to magically be able to interpret how to translate your previous site’s setup into the new one, even if you can still accomplish most of it with site building tools. All of this means that it's better to focus more of your efforts on learning how Drupal 8 wants to do things, and then secondarily figure out how best to implement your intentions.
The web (and your needs) have evolved
The greatest challenge to a migration isn’t even the underlying technology - it’s that you likely don’t want to do things the same way you did when you built the previous site 3, 7, or even 10 years ago. The web is constantly evolving where user trends, device and browser behavior, and web-based business models are vastly different than they were not long ago.
Beyond that, you likely don’t even want the same things you did when the site was first built. So while it may not be complicated to sort out migrating users who have one or more of 5 different roles to your new Drupal 8 site with the exact same model, it may be vastly more complicated if you now need those users configured across 8 roles, all while consolidating or purging user accounts, with new and different forms of user-driven functionality or content.
It doesn’t take long before the migration work can start to compete on a resource level with the actual site build itself.
Making a Plan
So with all this in mind, about all we’ve established is that it’s a great time to upgrade to the latest version of Drupal, and also that it’s a lot of work. So what do we need to figure out?
What does your site do/need to do?
As stated earlier, Drupal 8 core is loaded with functionality that used to be accomplished with contrib or custom modules. This is broken into two components: content and functionality.
Clearly understanding your content model will greatly affect whether you can use the Drupal 8 migrate tools referenced earlier. If your content types and field definitions are pretty similar to what you used to have, you might be able to migrate a good chunk of your actual content using the tools. If this is a time to change how some of that is structured, it may be much easier and more flexible to use a combination of custom module development and SQL queries to split, aggregate, or alter your data to fit the new system.
Functionality is another matter and involves figuring out what precisely you want the site to do and what the user experience is. It would be wise to figure out how much of Drupal core can be leveraged to do what you need because more than ever, leveraging the core concepts of Drupal - and its underlying Symfony structure - is definitely the way to go vs workarounds or completely custom implementations.
Who is doing the work?
This is an important question for building any site, but especially when an upgrade is involved. If you have Drupal developers handy, then writing a custom migration using either the Migrate tools or something completely stand-alone is not really that big of a deal and it can be tailored exactly to fit your needs. If you have a php developer who isn’t familiar with Drupal, then you can likely use various export tools from older versions of Drupal, such as Migrate, Views Data Export, Views Excel Export, etc and then use the Drupal 8 Migrate utilities to import them. If you are completely outsourcing the job, then all you really need are the appropriate credentials and a relationship with a trusted, reliable vendor.
It's also worth noting that knowledge of the previous system can play a big part in the approach and the choice whether or not to outsource. On one hand, an external vendor is likely to be far more experienced in best leveraging Drupal to do what you want and may (hint hint) have a lot of experience doing custom migrations for various clients. On the other hand, someone internal may know the prior system backwards and forwards, thus saving a lot of inefficiency in a hand-off. It's all worth considering.
In Conclusion - Just do it!
So at the end of the day, all we’re really saying is that it has never been a safer and wiser time to jump into the latest version of Drupal. You won’t have to rebuild when version 9 or 10 comes out (unless you want to) and you’ll get to try things out before they become stable and official. You’ll also immediately start benefiting from all the great new features and better architecture and can say goodbye to the restless nights that “when should I upgrade?” has caused you. And sleep is a good thing.
If you could use some help with your Drupal 8 upgrade project, contact us today!