This section contains guides to help you with installing a new copy of Drupal.  Information on updating and upgrading existing Drupal sites can be found elsewhere in the handbook.

Moving an existing Drupal site (either a production site or one built on a development server) to an OIT Web Hosting account is not terribly difficult, but it is important to make sure you follow all of the right steps.

Skills Required for Migrating a Drupal Site

• You will need to know how to access the Plesk control panel for your account in order to complete the rest of these steps you may also wish to set an SSH password or SSH key so that you can SSH into your web hosting space.
• You should have a basic understanding of filesystems and mySQL databases, as well as phpMyAdmin
• If you need assistance with some of these steps, check with your local unit's IT support staff 

Before You Begin

If you haven't done so already, you'll need to request a hosting account from OIT.  If you are moving a live site, you should ask for the account to be set up as the hostname of your live site, but ask that DNS not be updated yet, since that would disrupt your existing site.  Once the account is set up, you can do one of two things to access it while you are working on migrating your existing site:

1. You can edit your local computer's hosts list (on Linux and Macintosh computers, this is /etc/hosts) to locally map your live site's hostname to your OIT hosting account.  This is the quickest method, but while you have this mapping in place you won't be able access your existing live site from that computer.
2. You can create a DNS alias for your new site.  You or someone in your IT staff will have to create the alias in DNS, and then you'll have to go into the Plesk control panel for your new OIT Web Hosting site and add the alias there (via the Add New Domain Alias button on the main page) so that the Plesk server knows that your DNS alias goes with your OIT Web Hosting account.  This method takes a little more effort to set up, but with it you can access your new site from anywhere while you are testing it, and you can access your existing live site from the same computer at the same time.
3. You could actually mix these two methods for perhaps the most versatile option:  you can define an alias for your new site in your local computer's host file, and then add that alias to your Web Hosting account via the Plesk control panel, but without adding the alias to DNS.  This will let you access both the old and new sites from your local computer, but you still won't be able to access your new site from anywhere else.

When your new site is ready to go live and replace your existing live site, you can have DNS updated (see below) and remove any unneeded aliases that you have created.

Moving Any Drupal Site to an OIT Web Hosting Account

1. You will need to create an archive of the filesystem of your existing site, and an archive (often called an SQL dump) of your existing site's database.  How you do this will depend on where your existing site is located.  Please note that if you are comfortable with using SSH, you can archive your site's filesystem as either a GZipped Tar archive (.tar.gz extension) or a Windows style ZIP archive (.zip extension).  If you are not comofrtable with SSH and prefer to upload your archive to your Web Hosting account via the Plesk control panel, your archive must be in Windows style ZIP format.
2. Upload the archive file to your OIT Web Hosting Account and unpack it where you want your Drupal installation to live.  From within the Plesk control panel, you can upload the archive file via the File Manager.  Once the file is uploaded, just select it in the File Manager to unpack it.  After the archive file has been unpacked, move it to your hosting account's "/private/" folder.
3. In the Plesk control panel, go to the Databases manager and create a new database.  Copy down the database name, the database user name, and the password, as you will need them later.
4. While still in the Databases manager, on its main page select the phpMyAdmin link for the database you just created.  This will open phpMyAdmin for this database in a new browser window or tab.  On the Import tab of phpMyAdmin, import the SQL dump of your existing site's database.
5. Either via SSH or the Plesk control panel's File Manager, modify your Drupal site's sites/default/settings.php file and update the database information in it to match what you copied down in step three above.
6. Navigate to your Web Hosting account's main URL, and you should hopefully see the front page of your Drupal site.  Try logging into it and check the Drupal status page and error logs to see if there are any problems with the site.

Updating DNS When Moving a Live Site

If your site is already live in another location, then you will need to update DNS to point your site's hostname to your new OIT Web Hosting account.  You will need to know your hosting account's server name - to get this, just look in your browser's address bar while logged into your Web Hosting account's Plesk control panel.  The server will be web-plesk##.oit.gatech.edu, where # is a number.  Either update your existing site's hostname to point to this Plesk server, or if you don't have that kind of access, ask your local IT support staff to make the change for you.  If you don't have anyone in your unit who can update DNS, you can always open a support request with OIT.

A Word on Migrating a Development Site to Live Production

If you are developing your site somewhere else and then moving it to an OIT Web Hosting account (or any other server where the DNS hostname for the site will be different from what it was in development), then you need to take special care to make sure that your internal links do not break.

When setting the URL paths for page links, inline images, attachment files, etc., make sure to enter those URLs as relative paths.  A regular (called 'absolute') URL looks like this:

  http://your-site-host-name/path/to/my/file.xyz

The relative version of that path looks like this:

  /path/to/my/file.xyz

Relative paths will continue to work even after you change the hostname of the website.  Absolute paths will cause the user's web browser to try to follow the link back to the development site.  This can cause all kinds of problems, ranging from links not working and images not showing as soon as the new site goes live, to problems that aren't detected until someone shuts down the development site months after the production site went live.

The command line savvy developer may want to search through his/her SQL database dump for the hostname of the development server before uploading that dump file to the new OIT Web Hosting account.  This is a great way of catching any absolute URL links that are still lingering about somewhere in the site.

Importing a Migrated Site into Installatron

Installatron is a service available in OIT Web Hosting that (among other things) can keep the core of your Drupal site automatically updated with security patches. To import a migrated Drupal site into Installatron, please refer to the Installatron documentation provided by OIT's Web Hosting team and watch the video tutorial on this page.

Please note that by default, Installatron does not enable automatic updating of Drupal core when importing a Drupal website into Installatron. To turn on automatic update:

1. From the front page of the Plesk control panel, look for the Installatron Applications Installer link on the right-hand side of the page.
2. In the section that gives details about your Drupal installation, select the blue wrench icon button.
3. Under Automatic Update, select 'Create a backup and update to new minor versions and security releases. (Recommended)'.
4. Select Save All. 

Play Video

Before you take a Georgia Tech Drupal site live, it is a good idea to go through the following checklist of best practices to make sure your site is secure and streamlined for production use. This checklist is designed for Drupal 7 sites on OIT's Web Hosting, but will generally apply to other environments and later versions of Drupal as well.

Within the Drupal Application

Helpful Tip: The admin interface can be accessed via the black admin toolbar at the top of any page when logged in with administrator rights.

Make Sure Core, Module, and Theme Updates Get Applied When Needed

Enable the Update manager using the following settings so that you and your team will be notified of important available updates.  Then, make sure those updates get applied in a timely fashion (but be sure to back up your site before doing so: more information on backup is below, in case anything goes wrong).

If you are using Drupal 8 or higher (considered modern Drupal), the site now needs the Composer CLI tool to manage installation and updates for Drupal core and any modules, due to more complex project dependencies.

Recommended "Available updates" Settings

Located at: Reports -> Available Updates -> Settings (admin/reports/updates/settings)

• Check for updates: Weekly
• Check for updates of disabled modules and themes: Yes (unless on a multi-site, where only 1 site should check this)
• E-mail addresses to notify when updates are available: At least TWO (2) email addresses (preferably some office-wide emails).
• E-mail notification threshold: Only security updates

Limit Access to Your Site

Avoid giving out any more access than necessary

• Make sure you have a suitable user account role for content managers that does not let them install modules, change themes, adjust low-level Drupal settings, etc.
• Ideally, only trained IT and/or web development staff should have administrator or super administrator privileges

Review your User Account List Regularly

Remove (or block) accounts of users no longer working in your unit; blocking is often the better option, as that maintains tracking of what those users did. Removing the account will require all content changes to be attributed to the "anonymous" user.

Review your Role Permissions Regularly

Roles are what map Drupal access permissions to individual users.  Review the list (found at People -> Permissions) to make sure roles do not have unnecessary permissions that put your site at risk.

Recommended "Account settings" Settings

Located at: Configuration -> People -> Account settings (admin/config/people/accounts)

• Anonymous users - Name: Visitor
• Administrator role: Super Administrator (for Drupal Express sites only; for all other sites: Administrator)
• Who can register accounts?: Administrators only
• Require e-mail verification when a visitor creates an account: Yes.
• When cancelling a user account: Disable the account and keep its content.
• Personalization
  • Enable signatures: No
  • Enable user pictures: No

Enable GT Account Authentication

• Most Georgia Tech Sites should use GT Account Authentication, which is provided by the CAS (cas) module
• Drupal Express has the CAS module already installed
• For all other sites, see the Installing CAS section for installation and configuration instructions

Recommended "Text formats" Settings

Located at: Configuration -> Content authoring -> Text formats (admin/config/content/formats)

• Order matters: place "basic text editor" at the top/first, then "minimal HTML", etc.
• "Plain text" is the only format to which Anonymous users should have access.
• If "PHP code" is present, DO NOT allow anyone to use it!

Configure Error Logging Securely

Drupal and PHP error messages shown to regular users could reveal sensitive details about your site, and just look unprofessional as well.  Use the following settings to hide error and warning messages from site visitors and keep them from overflowing your site's database.

Note: Do not enable the core syslog module if you are using OIT Web Hosting. According to the syslog module documentation, it is not appropriate for shared hosting. You should be able to find most useful debugging information by going to the Logs section in the OIT Web Hosting Control Panel and looking at the error logs.

Recommended "Logging and errors" Settings

Located at: Configuration -> Development -> Logging and errors (admin/config/development/logging)

• Error messages to display: None. 
• Database log messages to keep: 100

Enable Caching to Improve Site Performance

Recommended "Performance " Settings

Located at: Configuration -> Development -> Performance (admin/config/development/performance)

• Caching
  • Cache pages for anonymous users: Yes.
  • Cache blocks: (Depends on how often your blocks change)
  • Minimum cache lifetime: (Depends on how much dynamic content you have)
  • Expiration of cached pages: (Only matters if you are using an external cache like Varnish)
• Bandwidth optimization
  • Aggregate and compress CSS files: Yes
  • Aggregate JavaScript files: Yes

Protect Web Forms and Collected Data

Note: You should try using non-Drupal solutions for forms, such as Qualtrics, whenever possible. Keeping forms and general data out of Drupal is more secure and makes it easier to manage and later upgrade your Drupal site.

In general, do not use Drupal to store sensitive data of any kind: FERPA protected, HIPAA protected, DoD protected, or personal identity information (SSNs, birthdates, etc.)!  The exception to this rule is if your Drupal site is for internal use only and is firewalled properly to prevent access from off-campus.  Even then, you should apply all possible security protections to prevent internal hacking of your sensitive data.

If you still need to have a form on a Drupal site, use the latest version of WebForm, and install some type of anti-spam / anti-bot protection, as forms get hit by bots quickly and regularly once they are made public.

• Look at modules like Honeypot, Spamicide and BOTCHA to fend off bots
• Avoid CAPTCHA (especially the early versions) if at all possible, as it will greatly irritate your users; the latest version is more acceptable, as it does not "quiz" the site visitor as strongly as the earlier versions
• If you're resorting to CAPTCHA, consider whether or not the form can instead be locked down to just the Georgia Tech Campus only

Recommended "Site information" Settings

Located at: Configuration ->  System -> Site information

"E-mail address" is the address from which emails are sent by the site, so it should be generic, rather than the address of a real person.  Note: this must be an @gatech.edu email address for the campus email servers to accept messages from your website!

Note that the Georgia Tech web theme does not display the "Site name" set here, but rather has it's own site title fields on the theme configuration page.  However, "Site name" is used for the name shown in a web browser tab and any page bookmarks in a browser, so it needs to be set to something meaningful, and ideally identical to what you set on the theme configuration page.

Module and Library Safety Tips

• Where possible, sign up for alerts about updates to libraries being used (such as CKEditor, phpCAS, Flexslider, etc), especially security vulnerability alerts.  Drupal does not give any notifications about out-of-date libraries!
• Always turn off the following (unless you really need them):
  • PHP filter
  • Tracker
  • Comments
• Review your modules regularly and disable any that are not being used
  • Disabled modules should be uninstalled and then removed from the Drupal filesystem (move them to the /private folder if you are on OIT Web Hosting)
  • If Drupal reports that a module has been removed from its repository on the Drupal.org website, there's usually a good reason.  Remove any such modules from your site ASAP!
• Avoid keeping development-only modules on live sites. If you really need any, keep them turned off when not in use.
• Avoid alpha/beta release modules and anything that is poorly supported or not supported at all.
  • When evaluating new modules, look at the last date of a release (be wary if more than a year ago), number of sites reporting usage of the module, reputation of the module's maintainer(s), and the number of open issues in the development queue.

Check Your Site's Health

• Check the Status report (found at Reports -> Status report) and correct any problems listed
• Use the Security Review module to scan your installation for common security problems

Custom Code and the Drupal Filesystem

General Rules of Thumb

• Always write secure code!
• Never hack the core Drupal code or any third party modules!
  • Hacks will likely get overwritten when updates are applied later on.
  • Instead, look for ways to extend or adjust the code through a custom module.
• Avoid using unsupported modules, libraries or themes.
• Test anything new or uncertain in a separate instance of Drupal.  Never develop on your live site!
• Don't bother trying to hide the fact that you're running Drupal - it's really not worth the time and effort.

Drupal Filesystem Maintenance

• Avoid putting anything but Drupal related code in or under the main Drupal directory
  • Adding other files or applications complicates the upgrade process, which can result in those other files or applications disappearing unexpectedly.
    • Drupal version 8 and beyond does not support running any other applications from within or under the main Drupal directory.
  • If you manually install modules or themes, don't leave their archive files within the Drupal directory tree.  Move them to the /private directory if you want to keep them around.

OIT Plesk Web Hosting Control Panel

General Hosting Account Configuration

Owner/Administrator

• Avoid giving out hosting account access unless it is absolutely needed; only those who need to perform Drupal code upgrades should have hosting account access - content managers should never be given access to the hosting account.
• Regularly check that the administrators of a site are correct (and remove any former maintainers).

Notification Email Address for Website

Only one email address is allowed, so set to the address of a mailing list or alias that forwards to all of your site administrators.

Installatron Applications Installer

• If you are using Drupal 8 or higher (considered modern Drupal), the site now needs the Composer CLI tool to manage installation and updates for Drupal core and any modules, due to more complex project dependencies.

• The Installatron tool on Plesk does not support Composer-managed updates, and is not recommended for managing a modern Drupal site. Installatron will update Drupal core without checking dependencies, and there is a high risk of updates eventually breaking any site that includes additional modules, as most Drupal sites do.

  Plesk now offers the PHP Composer UI tool to provide limited Composer support via a site's control panel. However, updates have to be manually prompted, and the tool is limited use.

• How do I get started with Drupal on Plesk?
• Is Drupal the right choice of CMS for my site?

PHP Composer UI Tool

• While it's strongly recommended to use Composer CLI to develop and manage your site projects locally, the PHP Composer tool on Plesk provides some helpful options for managing Composer applications from your site control panel.
• How do I use the Plesk PHP Composer extension? 

SSL Configuration

Follow the guide to SSL configuration to run your site with SSL encryption (via an https:// URL).

Plesk Backup / Restoration Manager

• Before any major update or smaller update, it is recommended that you create a full backup of your site following the instructions before performing any changes/upgrade on your site.
• In case that you need to restore the site back from unsuccessful change/upgrade:
  Please note that Drupal upgrade process tends to add new files to the system.  
  
  Restoring from backup will not delete files that were added after the backup was created. Therefore, it is suggested to do a "clean" restore to avoid new files created during the unsuccessful upgrade interfering the configuration of your site before the backup.  
  
  How to do a "clean" restore with Plesk Backup Manager (under About Restoration Behavior section)

Scheduled Tasks (cron)

• Follow the guide to setting up cron so that your Drupal site will refresh content and check for security updates.

Directory structure (multi-site vs. solo site, single system per virtual host, etc.)

• This will vary depending on your site setup, but we no longer recommend using "contrib" and "custom" subfolders in the sites/all/modules folder.

URL Redirects

• These are usually created in your .htaccess file (always keep a copy of the latest in your /private directory).
• Check that your redirects did not get overwritten when your site's Core code was late updated.

Additional ideas can be found in the following:

• Securing Your Drupal Site (Last updated in 2016)
• List of security-related contrib modules (Last updated in 2016)
• Supporting Drupal Over the Long Run (BadCamp 2012)
• Performance for Site Builders (2012)

Updates patch Drupal to add new features and protect against discovered vulnerabilities, keeping your sites working optimally. Always test new updates on a development site before applying them to your live, production site.

Drupal 9 has a different method of doing updates.  Please see the soon-to-be-added pages for Drupal 9 update instructions.

Drupal Updates Sub-Topics

Most Drupal 10 installations on campus will be hosted on OIT Web Hosting and managed through composer (not Installatron as was used for Drupal 7 and earlier).  Updating Drupal 10 under composer is relatively straightforward, but does involve several steps:

1. For good measure, open the site in a web browser window, log in, and put the site in maintenance mode.  Leave this window open so that you can return to it as needed.
2. In a separate browser tab/window, log into the site's Plesk Control Panel through OIT Web Hosting.
3. While all OIT Hosting Accounts now have automatic updates enabled, it doesn't hurt to run a full manual backup to capture the most recent changes, just in case something goes wrong while updating.
   1. Go to the Backup & Restore button in the right-hand sidebar on your site's Plesk control panel
   2. Select the Backup button and follow the prompts
4. With your backup complete, go to the PHP Composer tool in your site's Plesk Control Panel
   1. Under Package Dependencies you should see an Update button.  Select this button.
   2. You should get a pop-up modal showing the update progress.  This may take a little while, so please be patient.
5. When the updates are finished, return to your first browser window (the one that is logged into your Drupal site) and select the Drupal icon in the administrative toolbar for your site, then select Run updates to run database schema updates.
   1. If you have any trouble here, you can try going to the URL path of your site's home page with "/updates.php" added to the end of the URL.
6. When the database schema updates are complete, test your site and make sure it still functions as expected.
7. Disable maintenance mode to make the site open to the public again.

The following information is currently targeted to those site admins who have a site built on a custom theme implementation or have written custom modules for Drupal 9.

If you are using the standard Drupal 9 Drupal Express provided by Institute Communications, you should wait until they release a new version of the Georgia Tech theme package before trying to upgrade to Drupal 10.

A list of things to be watchful for when upgrading to Drupal 10 (to be expanded in the near future):

• There's a new 2.x version CAS module and 2.x version External Auth module that must be installed before upgrading.

• For that matter, use the Available Updates report to scrutinize all of your modules, even the ones that show up in green.  A module with a major version update can still render in green if you have the last release of the previous major version.

• If you are running a Composer manged site, install the Upgrade Status module to check your site for upgrade issues that need to be corrected.

• If you have your own custom modules, you'll need to go through all of them and check for Drupal 10 compatibility issues:

  • drupal_get_path() and drupal_get_filename() are removed from Drupal 10

  • \Drupal::entityQuery now requires an accessCheck() parameter to work

  • The themes Seven, Classy and Stable have been removed from Drupal 10 and need to be disabled before upgrading, unless you plan to use the contrib versions, in which case you must install those versions before upgrading.

    • The administration theme of choice is now 'Claro' - you should switch to Claro and uninstall Seven before trying to do an upgrade to Drupal 10.

    • NOTE: If a theme you are using has enabled Classy or Stable, you must use a hack to disable them, as they are hidden in the admin GUI by default.  See Drupal Issue #3328016 for more details.

      • Short summary: If a theme uses another theme as a base theme, the other theme gets enabled at install time.  However, Classy and Stable are hidden themes, so they don't show up in the admin GUI, thus you can't uninstall them through the GUI.  Unfortunately, Drupal 10's update.php script expects them to be uninstalled.  The hack involves modifying both theme's .info.yaml files to unhide them, allowing you to uninstall them.  Take note that even after unhiding a theme, you still won't be able to uninstall it if an active theme refers to it as a base theme.  Deal with those active themes first (uninstall them or update them to not rely on Classy or Stable), then flush caches and you should be able to uninstall Classy and Stable after unhiding them.

    • If you are using a theme based on Classy, you have two choices: install the contrib version of Classy, or merge everything from Classy into your theme.  Do note that Classy uses Stable as a base, and Stable has also been removed from Drupal 10, replaced with Stable9.  Stable9 does exist in Drupal 9.5.0, so you can port your theme over while still running under Drupal 9.  However, you'll have to use the hack in the previous bullet point to enable Stable9 before you can get another theme to use it as a base theme.  This is because Stable9 is also hidden, like Stable and Classy

  • Last but certainly not least, update the core_version_requirement setting in each custom theme and module's .info.yml file to include ^10

• Deprecated Modules: The following need to be fully uninstalled before upgrading, unless you are choosing to use the new contrib versions, in which case you need to install the corresponding contrib version before upgrading:

  • CKEditor 4 (if you're removing it, don't forget to remove all CKEditor 4 add-on modules as well)
  • Color
  • Quickedit
  • RDF
  • Aggregator
  • Hal

Migration, not upgrade

Drupal 8, released in November of 2015, was a major rewrite of the underlying Drupal code (Drupal's core engine and APIs). Because of the multitude of changes, there is no direct in-place upgrade path to go from any earlier version of Drupal to Drupal 8 or later. Instead, Drupal 7 and earlier sites must be migrated to Drupal 8 or later, which involves setting up a whole new Drupal 8 website and copying into it (manually or automatically) the content of the older website.

All Drupal 7 sites that are to remain on Drupal should be migrated to Drupal 10, the latest version of Drupal.

Requirements and Web Hosting Support

Drupal 10 requires a hosting environment running at least PHP 7.4 or later, which is available on OIT Web Hosting. OIT does not currently support the use of Drush or command line access to Composer. However, the Plesk control panel GUI allows for composer set up and management.

The easiest way to get started with the Georgia Tech branded version of Drupal 10 is to request an installation from OIT. You can select this option when requesting a new OIT Web Hosting account, which is usually the best way to go.  In short, you would set up a new site in a new hosting account using a temporary domain name, and then once you have copied over all of your existing content, you would shut down your old site and repoint your real domain name to the new hosting account. 

Note

If this sounds a little too technical for you, you should consult with your local IT support staff, who should be able to help you through anything concerning domain names and repointing them.

Georgia Tech Migration Roadmap

Beyond PHP support, each Georgia Tech unit website will need several extra components to be fully usable. The following table is an attempt to start tracking the status of the components needed for Georgia Tech Drupal 9 sites, and it will be updated as releases and additional information come available.

Complete Migration Process

Kevin Pittman has posted a guide to migrating from Drupal 7 to Drupal 10 that includes a lot of planning tips and technical details.

Notes, tips, and tricks for upgrading a Drupal 8 site to Drupal 9

Moving to Drupal 9 from Drupal 8 does not involve near as much planning and preparation work as previous major version upgrades thanks to changes the Drupal organization has made to the development process.  Instead of Drupal 9 introducing a new batch of features, new features have been added gradually over the major point releases of Drupal 8.  The key changes with the first release of Drupal 9 will be to remove deprecated (old and no longer used) code, and to upgrade the underlying Symfony framework.  On the surface, though, you should not see any notable differences between Drupal 8.9 and Drupal 9.0, assuming you have prepared your site properly.

Preparation

Basic Requirements

• Drupal 9 requires PHP 7.3 or higher (7.4 is preferred). If you are on OIT Web Hosting, you should be able to set your PHP version now via your site's Plesk Control Panel.

• Drupal 9 requires a settings.php change:
  • The line beginning with "$config_directories['sync'] =" has to be changed to "$settings['config_sync_directory'] ="

  • Note: You can do this before upgrading, as Drupal 8.9 will work with either version of the setting.

• To upgrade to Drupal 9, you must be on Drupal 8.9.0 or higher.
  • If you are already on 8.9, make sure you have the latest patch release to get the smoothest transition

  • If you are on anything earlier, upgrade to the latest patch release of 8.9 first, then upgrade to the latest 9.0 release.

• Drupal 9 requires all active themes and modules to declare Drupal 9 compatibility:
  • Compatibility is indicated by a line in the theme or module's .info.yml file that starts with "core_version_requirement:"
  • Check and update all custom and contrib modules.
• Drupal 9 (as did Drupal 8.9) uses CKEditor 4.14.0, but Drupal 9 seems to be stricter about CKEditor plugins. If you are using any add-on CKEditor plugins, check each one to see if there's a 4.14 specific version and upgrade as needed. Composer should maintain the compatible plugin version with a Drupal 9-compatible release.
  
  As an example, Balloon Panel, used by Accessibility Checker, was one that needs to be up-to-date to work in Drupal 9.

Checking Module / Theme Compatibility

There are several tools available that are supposed to check your site's modules and themes for Drupal 9 compatibility. The present options either require the ability to run PHP at the command line or require your site to be managed through Composer (such as Drupal Express websites).

Upgrade Status Module

The Upgrade Status module can perform a website audit to determine which modules, themes, and add-ons are Drupal 9 compatible.

Command Line

If you are comfortable with running simple commands at the Linux command line, you can get a quick overview of your modules declared compatibility by going to the main modules directory and running the following command:

  grep "core" */*info*

For any module where you do not see a line with "^9" near the end, you'll need to do some testing and research to see if the module will work with Drupal 9.  Check first for a new major version release, and if there is none, you could try the instructions given below for testing a previously Untested Release to see if it causes any problems.

Process

Once you've completed all of the preparatory steps, upgrading is the same as if you were upgrading to another point release of Drupal 8. 

As with any major update, make a full backup (filesystem and database) before you begin, just to be safe.

Afterward, test major website capabilities thoroughly, since a lot of old code has been removed and the underlying Symfony engine has received a major upgrade.

Institute Communications update process

Refer to Institute Communications' gt_installer Drupal 8 to Drupal 9 update process to update GT Theme, GT Tools, and GT Profile to their latest versions.

Issues

Semantic Numbering - New Major Releases

As more time goes by, more module developers will move to the new semantic numbering system that is not tied to a Drupal version number (e.g. 7.x-1.0). Typically, if a module was at say version "8.x-3.5" then the next major release done under the new numbering system would be "4.0.0". You'll have to check carefully for this change, as Drupal alerts major version releases (8.x-3.5 to 4.0, for example) as "Other versions available".

However, in the case of modules like Webform, you may find you are expected to upgrade to the next major version when you upgrade your site to Drupal 9. Module version updates to the next major version can be done easily if you manage your site with Composer. Otherwise, you'll have to do this by hand at the filesystem level (Drupal won't upgrade to a new major version via the GUI).

As with most major version upgrades, manually run schema updates (go to update.php after updating).

Known Problem Modules

• Devel has a new 4.0.0 release just for Drupal 9, but the popular Kint debugger sub-module is gone from 4.0.x. To get that functionality you have to use composer to install a Kint plugin for Devel 4.0.x or use the devel_kint_extras module. That's a big complication if your site is not set up to be managed by composer. As a workaround, you can download the PHAR version of Kint and manually include it in your site to get its functionality. Please note that the manual library process is not as streamlined an install as a prepackaged module.

• Webform 8.x-5 is not compatible with Drupal 9 at all and will actually break the update.php process. If you use Webform, do not attempt to upgrade to Drupal 9 until you have upgraded Webform to its new 6.0 release.