Preparing Your Drupal 7 Site for an Eventual Migration

With the announcement of an extension on official community support for Drupal 7, now through November of 2022, many organizations were able to let out a sigh of relief. Their investments in Drupal 7 will continue to serve their needs. 

In addition, Drupal 7’s Extended Support(D7ES) program has announced its vetted vendors for paid support of Drupal 7 through November of 2025. Drupal 7 is here to stay for a long time, and this is good news, especially for organizations with limited time, limited budget, and limited support staff. If you are one of those organizations, you can feel safe and secure. Settle in for the long haul. Continue to improve your existing site, knowing you have plenty of time to see the ROI you need.

But eventually, like all good things, Drupal 7 will come to an end. The destination is now further down the road, and you can enjoy the journey at a more leisurely pace than expected, but eventually, you will arrive at the end of the path. You will need to transition away from Drupal 7.

You must eventually let go and say goodbye.

Since this sunset period is now longer, it is a good idea to take advantage of it. Without the threat of impending deadlines, you can use this extra time to start preparing your website for its inevitable evolution and do it in a calm, controlled, and orderly fashion. Some effort now can reduce risk and pay dividends later.

What are some things you can start doing to prepare your Drupal 7 site for migration?

We’ll cover the following topics:

• Shifting your coding and site-building culture
• Engaging with a content strategist
• Keeping everything secure and up to date

Begin to Shift Your Coding and Site Building Culture

There is a vast difference between the architecture of Drupal 7 and the architecture of Drupal 8+ (currently Drupal 8 and Drupal 9), and these differences will only grow with subsequent versions of Drupal. This is reflected in how custom code is written. 

For example, object-oriented code and paradigms in PHP are here to stay, and your team should begin to adjust to this new reality, if they haven’t already. 

Because of how Drupal 7 works, it resists a lot of OOP best-practices. But there are still things you can do to help your efforts down the road. These apply for both new features and refactoring of old code.

Move Business Logic to Classes

Instead of having long walls of code crammed into hooks or preprocess functions, start to encapsulate your business logic in well-named and organized classes. This helps improve readability and maintainability. It will also be less of a lift to move this logic to a newer version of Drupal.

Form alter hooks are a common way to customize Drupal. You can’t escape hooks altogether, but you can improve their clarity and make them less intimidating.

Instead of something like this:

function example_form_alter(&$form, &$form_state, $form_id) {
  if ($form_id == 'example_node') {
    $form['example_field'] = [
      '#type' => 'textfield',
      '#title' => t('Example field'),
      '#weight' => -10,
      '#maxlength' => 60,
    ];
  
    $form['submit'] = 'example_submit_handler';
  }

  if ($form_id == 'example_user') {
    // different stuff is added or hidden
  }

}

You can start using something like this:

function example_form_alter(&$form, &$form_state, $form_id) {
  $exampleFormManager = new ExampleFormManager();
  $exampleFormManager->alterForm($form, $form_state);
}

The ExampleFormManager class should then have all the methods necessary to determine when and how to change the form. If everything is well-named and documented, this will make it easier to port over to Drupal 8+. 

Write these classes for your future selves. In a year or two, you don’t want to be looking at this code, scratching your head, silently cursing the person who coded it.

Another opportunity to wrap business logic in classes is with entity wrappers. Let’s take the example of related articles for a node. In a theme preprocess function, you might grab a node’s taxonomy term, pass that to a function located in some other module, load the related nodes based on some criteria, and then format them back in the preprocess function.

Instead of this, you could create an Article entity wrapper:

class Article {
  private node;

  public function getRelatedArticles() {
    $related_nids = $this->getRelatedArticleNids();
    return $this->getRelatedArticlesRenderArray($related_nids);   
  }

  private function getRelatedArticleNids()  {
    // run the queries or pass to other internal function
  }

  private function getRelatedArticlesRenderArray(array $related_nids) {
    // construct a render array
  }
}

When the time comes to eventually migrate, you won’t be combing through a multitude of module and theme folders to figure out how in the world your site populates related articles. It will be there, packed up, and ready to move.

This process not only helps your code be more organized and portable, but it also helps your team start stretching beyond procedural modes of thinking, if they haven’t already. Shifting to Drupal 8+ won’t be as big of a shock.

Gravitate Toward Solutions that Rely on Structured Content 

At its most basic, this means avoiding Blocks and Panels.

Blocks underwent a fundamental change in how they were implemented for Drupal 8 and attempting to migrate them can introduce extra complexity. It is often easier to recreate them by hand or with a custom script.

If you have only a handful of blocks, this should not be a problem. But don’t let them get out of hand. Lean more on content entities to solve problems, as the migration landscape for them is documented, tried, and tested.

The easiest way for Block usage to get out of hand is with Panels, where almost anything can go. Their very nature tends toward the wild and unstructured. Panels can create additional risk when approaching a migration, and Panels that have not had strong content governance can end up being a garden made up of nothing but weeds. Better to just pull everything up, lay new soil, and start over.

This might be fine. As long as your eyes are open and you expect this to be the case, the risk can be planned for and mitigated.

Instead of a Panel, think about using an Entity with set Entity Reference fields, which then map to pre-defined templates. This type of thinking might require another paradigm shift, however, and for that, you might want some help.

Engage a Content Strategist

Preparing your Drupal 7 site for the future, no matter how far away that future might be, requires some thinking about how you envision that future. 

• What goals are you trying to achieve? 
• What message are you trying to broadcast? 
• What tools make for happy editors? 
• How does your content and CMS best serve these needs?

A content strategist can help you answer these questions and more. 

This expertise can come in many forms. You could hire one. You could contract with an agency for limited engagements. You could nurture the curiosity of someone on your team, so they grow to have the skills required.

What can a good content strategist help you do?

Audit Your Content

The more content you have, the more varied the content types, the more complex an eventual migration will be. You don’t want to spend time and brainpower migrating old content that isn't valuable.

A content audit can help you determine which content is stale and which content needs to be either archived or updated. It can also help surface duplication.

One of the most important benefits of a content audit, however, is finding content with problematic structure, or content that lacks proper structure altogether. Is everything being crammed into the body field? As a result, is the final look of a page different based on the editor who built it? Even pages of the same content type?

What are some things that raise red flags when seen in the body field?

• Metadata about the content itself, like author information or reading time.
• Iframes from various sources, with inconsistent sizes.
• Different methods of image embedding from one article to the next.
• Related links, some of which are outdated.
• Presentational HTML markup and CSS.

The SQueaLer Drush tool can be helpful for this.

Each of these will require different special cases when migrating, making the process more complex. Cleaning them up now will save time and money later while making your site more maintainable in the present.

Create a Plan for Content Governance

Auditing and cleaning up your content is great, but if you don’t change your old habits, weeds will keep popping up. Re-assess who is allowed to create content and what they are allowed to do within that purview.

Has your audit determined three different ways images are being embedded? Work toward settling on a single way, with input from your editors. Enforce it as best you can.

Have you spent some time identifying problematic content that doesn’t fit with your strategy? Work toward processes that help prevent the creation of more problematic content.

How much time should you spend per month cleaning up or archiving old content? Will it be one person’s job or a shared responsibility? Who makes the final decision on what content needs to be updated? The answers to these questions will be different for each organization.

If your editors keep cramming things that don’t belong in the body field, you should see it as a sign, one covered with blinking red lights and loud alarms, telling you that the system is not meeting their needs. So, find out those needs. 

A good content strategist can help facilitate these conversations, help you find ways to temporarily fill these gaps while you are still on Drupal 7, and help you determine what your future should eventually look like. Address these potential problems as soon as you are able. Start thinking about them early. 

If you don’t, they will continue to haunt your future site, even if you end up leaving Drupal. These specters are platform-neutral.

Take Time to Model Your Content

Many websites grow in an ad-hoc manner, with features pasted on whenever a stakeholder has a flight of fancy. Even if the site launched after a careful period of requirements gathering and needs analysis, its evolution afterward can descend into chaos. 

New content types are added for that big seasonal push, and then never get used again. Editors need to make a landing page look just right, and inject things in the body field as a quick fix. Questions and new requirements are always based on whether the site can do something, rather than whether the site should do something. “No” becomes the forgotten vocabulary word.

Now is a good opportunity to take stock. This is related to our “Gravitate Toward Solutions that Rely on Structured Content” recommendation above.

Your content audit has surfaced issues you need to fix at the structural level. Your content governance plan needs some guard rails to help with enforcement. Your Drupal 7 site needs to align better with the goals and message of your organization.

This can mean new content types, but it can also mean a modification of existing content types. 

Some common examples of structure changes:

• Moving related article links out of the body field and into their own Entity Reference field.
• Additional (or fewer) taxonomy fields.
• Summary and Lede fields.
• An “Authors” Entity Reference field, separate from the default author field.

For media management, think about using the Media module to help ensure proper metadata surrounding media, and to help enforce a single solution for including media in content. There is also a migration path waiting for you when you are ready.

Properly modeling your content, and beginning to implement that model, will net many benefits. It will be easier to change the presentation of your site consistently. Opportunities for content re-use will become clearer. Your next content audit will be less thorny. 

While you may give up some flexibility in the day-to-day creation of content, it pays off with more holistic flexibility. For example, if you desire to go down a decoupled route, with your content served via an API, structured content gives you that option.

But equally important, modeled and structured content will make your migration much, much easier. Well-structured content is always easier to migrate than unstructured content. 

And if your content strategist has helped you answer the proper questions, a lot of the big questions surrounding migration will be answered as well. This means a chunk of the hard work required will already have been done.

Keep Everything Secure and Up to Date

Your Drupal 7 site should be kept up to date. That means Drupal core and all the modules you use, but it also means your hosting environment. Don’t remain stuck on past versions of PHP. The latest versions of Drupal 7 support the latest versions of PHP 7, which has a nice symmetry to it.

All of this will not only keep your current site secure and performant, but it will also make a future migration easier. The latest versions of contrib modules are usually closer to their Drupal 8+ counterparts in terms of organization and how they store data. They also can take advantage of PHP 7 improvements and syntax.

This ties into our first recommendation of shifting your coding culture. Staying up to date with PHP will allow your team to start using methods and styles that do not exist for PHP 5. Being familiar with PHP 7 will ease the eventual transition.

Conclusion

Drupal 7 has been given a new lease on life, and if you are currently dependent on Drupal 7, you can breathe a little easier. Your CMS will be supported for another year, and even longer if you reach out to a qualified D7ES vendor.

Use this time wisely. Prepare for the future. Now that you know it will be around for a while, you can feel safe making smart investments in the platform and in your team. Make your Drupal 7 site work better for you in the present, while at the same time making your eventual migration go smoother.

You and your team can be seen as agents of foresight, clarity, and poise, recognized for preparing the organization to make the leap.

If you would like to start the conversation around some of these items, Lullabot’s support and maintenance team is ready to help. Through developer mentorship and close collaboration, we can help you squeeze every last drop out of your Drupal 7 investment.