Upgrading OJS Safely: A Practical Checklist for Journal Managers

By /

Many journals keep running an old Open Journal Systems release because upgrading feels risky. Staying put is riskier: older releases stop receiving security fixes, hosting providers eventually drop old PHP versions, and editors miss improvements to the workflow and DOI handling. The good news is that a planned upgrade is routine. This is the checklist we follow for every OJS upgrade.

1. Record where you are

  • Note the current OJS version (Administration → System Information), PHP version and database server.
  • List every installed plugin and whether it is bundled with OJS or third-party.
  • Note any customised theme, template changes or core file edits made by a previous developer.
  • Check the size of the database and the uploaded-files directory.

2. Read the upgrade notes for your target release

PKP publishes upgrade documentation and release notes for each version. Confirm the supported upgrade path from your current version, the required PHP and database versions, and any steps that need special attention. Very old installations sometimes need to pass through an intermediate version.

3. Back up everything — and test the backup

  • A full database dump
  • The OJS installation folder, including config.inc.php and the public folder
  • The uploaded-files directory (the files_dir set in your config file)

Restore the backup somewhere else to prove it works. A backup that has never been restored is only a hope.

4. Rehearse on a staging copy

Restore your journal on a separate staging server or sub-domain with the target PHP version. Upload the new OJS release, carry over your settings into the new configuration file, and run the upgrade from the command line with OJS’s upgrade tool (php tools/upgrade.php check, then php tools/upgrade.php upgrade). Note every warning and error.

5. Fix plugins and the theme on staging

  • Update plugins through the Plugin Gallery where versions for the new release exist.
  • Disable or replace plugins that are no longer maintained.
  • Test the theme. Heavily modified themes often break; rebuilding them as a child theme makes future upgrades much easier.

6. Test like an editor, an author and a reader

  • Log in with each role and complete a test submission, review and decision.
  • Open random articles from old and new issues; check PDFs and HTML galleys.
  • Confirm emails are delivered, statistics load and scheduled tasks run.
  • Check DOIs resolve, the OAI-PMH endpoint responds and article pages still show Google Scholar meta tags.

7. Upgrade the live journal

  • Choose a quiet time and tell your editors in advance.
  • Take a fresh backup immediately before you start.
  • Repeat exactly the steps that worked on staging.
  • Clear the data and template caches from the administration area afterwards.
  • Keep the old files and backup until you are sure everything works.

8. After the upgrade

Monitor error logs and editor feedback for a few weeks, re-check scheduled tasks and email delivery, and update your internal documentation. Then plan to keep OJS updated regularly — small, frequent updates are far easier than a big jump every few years. Managed OJS hosting takes care of this for you.

Want us to handle it?

We audit your installation for free, rehearse the upgrade on staging and upgrade your live journal with a rollback plan. Request an OJS upgrade quote.

Scroll to Top