A Sure-Fire Migration Approach to Drupal 8 & Drupal 9

A good migration to Drupal 8 or Drupal 9 means you understand your existing Drupal site very well so you know what to migrate over and what to avoid. That's the real key to success.

Start with a sane configuration migration plan

If you are migrating from Drupal 7 to Drupal 8, don't try to migrate your configuration (content types, fields, module settings). It's very rare that you would want to do this without any changes. It's typically much more flexible and easier to manually rebuild the structure on your Drupal 8 website and only focus on migrating your content. You are already investing a ton of time in the migration—take the time to make sure you are setting your website up in the best way possible.

Now spreadsheet all the things

Create a migration spreadsheet to map what content types and fields will be migrated from your existing site to your new Drupal 8 or Drupal 9 site.

Take the time to audit existing content and content types. This is a great time to find and alleviate pain points in the content management process by combining, re-working, or removing content types.

This is a crucial exercise for getting buy-in and alignment from all of the project stakeholders, from editorial, business, and engineering. This detailed spreadsheet will surface important migration considerations that would otherwise have gone unnoticed until development was well underway. 

Plan ahead. Seriously — most issues we have seen pop up from a Drupal 8 build could have been worked out early on with proper planning. One important maxim of web development to never forget: The later you identify an issue, the more expensive it is to fix. In software, it is easy to save hours of planning with weeks of coding.

Ask why 

Good engineers keep asking about the what until all of the ambiguity is gone and they have a complete mental model of the problem. Good engineers are driven to build things the right way, with craft, and with care. The difference between good engineers and great engineers is that they take the time to stop and ask why.

Use this migration as an opportunity to reevaluate your site's technical architecture. One of the worst outcomes of a migration is moving over all of the existing bad architecture to a new platform. After you understand how something works, be sure to ask why it works that way.

We recently worked with a client that was upgrading a Drupal 7 site that featured a crucial distributor finder directory experience. This map-driven experience is powered by a list of several thousand distributors stored in a third-party, priority tool with limited functionality. In the technical planning, we talked through how the data integration worked, who managed the data, and what the current state of the data was. Because the platform lacked support for custom fields, we were hamstrung in terms of how the new experience could work in Drupal 8.

However, halfway through one of our team members asked, “Why do you store the data in this tool?” And of course, it turns out, no one on the client team has any idea why this tool was being used. And only a few people use the tool on their team. We were aware the client was also using HubSpot for some other use cases. So we asked, “Why not bring this data into HubSpot, simplify the integration work, since your site already has to integrate with HubSpot, and use custom fields to track the data better so the experience can be improved?” That opened the floodgates to all kinds of great possibilities, and what ended up being a far- improved distributor- finding experience. 

Here’s the point: Get out of your headspace. Go offsite. Use giant sticky notes or a whiteboard. Think about the user journeys and desired business outcomes first. Think about what will help get the client team promoted. And don't be too focused on the tech. Part of being a zealous advocate for your client's technology is to be the catalyst of perspective.

Don’t forget you are building a content management system…to manage content

Conduct an informal internal user test and watch how content editors are using the current site. Have the content editors record their screens while they are asked to do the tasks that they normally do. See if there is any confusion, or if content editors have trained themselves to workaround bad authoring experiences. Ask content editors about the most frustrating part of using this website, or what's on their website wishlist. The experience will be illuminating.

Use this information to inform how you rebuild your authoring experience. As you plan this out, go back to these content editors and to review your plans and make sure nothing was missed. You should absolutely do this for your website end users too, but content editors are often an afterthought.

Perform a technical audit

Are there features that aren't used, or features that have ballooned to the point they're used too widely? Is there code that's been plaguing developers for years, or code no one has been brave enough to touch? Are there security issues or performance concerns? Flushing out these issues and formulating an approach to solve them at the start of the project will help ensure a smooth update process by making sure the right issues are being addressed, and aren’t carried over into the new codebase.

Keep your eyes on Drupal 9

Unlike previous Drupal upgrades, upgrading from Drupal 8 to 9 should be a non-event. If it isn’t, you are likely to blame. Be sure to make good Drupal 8 architectural decisions that won’t complicate a future move to Drupal 9. Our Drupal 9 Readiness Guide is a great place to start.