Since the release of Drupal 8, Drupal 6 is no longer supported by the Drupal Community. Because of this, many sites need to be migrated to Drupal 7 or 8, and quickly!
That means that at Evolving Web we've been doing a lot of Drupal migration projects lately. I would like to talk about the things we have to take into account when running these projects.
Migration Isn't a Straightforward Process
There is no magic process that completely converts a Drupal 6 site into a Drupal 8 one. Drupal 6 and 7 are similar in many ways, but D8 is a total revolution. Although it still uses many of the same concepts—content types, nodes, taxonomies, users, etc—it's also built around brand new technologies like Symfony, Twig and Composer. These are important changes, making Drupal 8 more scalable, flexible and reliable, but they're not easy to adapt to.
You Have a Second Chance to Get Your Information Architecture Right
If your current Information Architecture (IA) was created five years ago, there's a good chance that your needs have changed in the meantime. Maybe you have fields that were never really used or data that has to be duplicated in multiple places.
When you migrate to D8, your old existing IA isn't just copied to the new site—instead, it's rebuilt. This gives you a chance to make the changes that you need, fixing old problems and adding improvements. You can make old Taxonomy Terms into Nodes if they should be revisioned. Or you can convert a Text List field to be a Taxonomy Vocabulary, so you can add new items easily.
Your Data Needs to Stay Intact
Just because you're moving to D8, it doesn't mean you want to throw out your old data! Many of the nodes, users, terms and other parts of your old site will need to be moved to D8, without getting scrambled or changed. Data migration needs to be carefully planned in advance. It's important that you and your developers decide exactly what data should be kept, and what's safe to discard. For everything that you're keeping, you'll have to plan where it belongs on the new site.
Although there used to be many ways to bring your old data to a new site, Drupal 8 now comes with a core Migrate module. This allows developers to build custom migrations that are appropriate for your site. Each migration takes care of matching all fields on the source site (D6) with the fields on the new one (D8), according to your specifications.
If migrations are set up properly, it's even possible to run a migration multiple times as the old site changes and the new site is being developed. This lets you quickly make progress on the new site, without a need for "content freezes".
Contrib Modules Sometimes Introduce Risks
Drupal sites commonly use dozens of contrib modules, especially older sites. But since Drupal 8 is still quite new, there's a good chance some of the modules on your old site don't yet have a polished D8 release. The most important modules are already stable, but you should think carefully before making any decision about contrib modules.
Not all modules are made the same, and not all of them are well-maintained. Some modules like Views and Commerce have a solid development team that is constantly fixing bugs. But some modules are used by only a dozen sites and have nobody fixing bugs at all. Other modules are overly complex and might be a poor fit for your needs.
An experienced Drupal Developer can identify when it's best to use a contrib module, and when it's too risky. In that situation, a custom, tailor-made solution can often get the job done more safely.
Custom Modules Will Need to Be Refactored
This is one of the major risks of migration projects. By definition, a custom D6 module has no D8 version, so each custom module needs to be carefully evaluated:
- Someone has to figure out what the module is trying to do. If there was no written specification when the site was built, an experienced developer will have to read and understand the module's code.
- A decision has to be made: Is this module worth keeping? Sometimes a better alternative has popped up in the last five years! Or perhaps the functionality was never really needed after all.
- If the module is kept, the code will need to be refactored to use modern Drupal techniques: the Database API, Config API, entities, and so on.
- Basic PHP operations can sometimes remain the same.
- Use of external services through APIs can also often remain the same.
The Drupal community has already established best practices for contrib module upgrades, most of which apply to custom modules as well.
Your Theme Will Need to Be Rewritten
Drupal 6 and 7 use a completely different template engine from Drupal 8. There are major advantages to using Twig in D8, but it also has a very different syntax. There are a lot of things that have to change, as you can see from this list from Drupal's documentation. So be ready to put a lot of work into a new theme.
Since most Drupal 6 sites were built between 2008 and 2013, they rarely incorporated a responsive design that's appropriate for mobile and tablet users. Our rough estimate is that 70% of D6 sites are not mobile-ready. Now in 2017, responsive design is considered essential, so you'll likely need an updated design to go with your new theme.
Theme migration considerations:
- Some hooks may be re-used but probably not all of them. Check the Drupal 8 Hooks API.
- Custom template coding will need to be re-written.
- Most CSS properties can be re-used, although selectors will need to adapt to the new theme structure.
- You'll need to choose an appropriate base Drupal theme.
Conclusion
After all of this, you can finally achieve your goal: A website that is secure, accessible, beautiful, modern and responds to your needs. Thanks to the new Drupal 8 roadmap, your new site should stay compatible with updates for years on end. All the steps I listed might sound like a ton of things to keep in mind—but this is what it takes to do it right. There is no silver bullet.
For a successful migration that follows all these steps, you'll need to work with experienced developers. So if you're interested in a D6 to D8 or D7 to D8 migration project, I suggest you take a look at my blog post 5 tips for choosing the right company to move your site to Drupal 8.