Our customers like to be as self-sufficient as possible, and we encourage taking real ownership of your website. However, clients who ask us to teach them how to upgrade their Drupal site often exhibit skills ranging from content manager to developer.

When confronted with an overview of upgrade steps that include Drupal-oriented development words such as "SSH", "git", and "drush", if you get nervous you probably shouldn't be trained quite yet. We encourage you to talk to us about upgrading your website if you think you might fit into that category, even if to just discuss planning for a Drupal 8 upgrade.

For those who remain undaunted it may be time to continue your training! First of all, we need to assume that you are using best-practices and tools:

  • You can get around on the Linux command line.
  • You don't make changes that can break you site on production. You will test these changes on a staging or test site first.
  • You have all of your source code in a release control system, like git.
  • You can use Drush.

Want something simpler?

Don't think you need all that? Check out Does our site really need release control and a staging site?. If you really can't implement release control and a staging site, you will just need to have a backup on hand and be prepared for down time should anything go wrong.

When I started working in Drupal, I used FTP (vs. the Linux command line) and I didn't have a staging site. The adrenaline rush of a roller coaster is nothing compared to bringing an important customer's site down and not knowing what to do about it!

To upgrade a Drupal site:

  1. Refresh your staging site by pulling all of the current source code from git and copying the production database to the staging site. If your developer is teaching you how to do this, she or he might tell you to execute a command like "git pull origin master" or somesuch.
  2. If you don't have a staging site, you could do a full database and code backup. If something goes wrong, your site will go down, but you should be able to copy everything back again. ssh into your server, navigate to your site's directory and run drush up.
  3. If you have your own, personalized .htaccess and .gitignore files, restore your originals as a core update will overwrite them.
  4. Thoroughly test your site. Ideally, nothing should change. However, it can break virtually anything.
  5. Once you're happy with the results, commit the code changes to your git repository.
  6. Navigate to your production site.
  7. Pull all of your update source code into your production site.
  8. Run drush updatedb to apply any database updates required by the new code.
  9. Test your production site.

This outline certainly isn't an exhaustive list, but it serves as a basic recipe for you to get started. The important thing to remember is: if you backup your website before you begin making modifications, you can always restore it in case you mess something up!