OJS Upgrade & Migration Service

OJS upgrades and migrations, done carefully

An OJS upgrade looks simple on paper: replace the code, run the upgrade script, log in. In practice, upgrades fail because of things the release notes cannot know about: a custom theme, an abandoned plugin, an old database character set, or a host that has quietly switched PHP versions.

OJS Academy plans, tests and runs OJS upgrades and migrations for journals worldwide. The work is led by an academic-publishing professional with 10+ years of experience who has supported 80+ academic journals, so we test what matters to editors and authors, not just whether the homepage loads.

• Version upgrades: OJS 3.3 to 3.4 or 3.5, OJS 3.4 to 3.5, and newer builds within the same version.
• Legacy migrations: OJS 2.x to OJS 3 through PKP's supported intermediate versions.
• Server and hosting moves: shared hosting to a VPS, one provider to another, or onto our managed OJS hosting.
• Platform migrations: moving back issues from another publishing system into OJS, scoped case by case.

Starting a brand-new journal rather than upgrading? See our OJS installation service or the step-by-step guide on how to install OJS.

Why upgrade OJS?

Still on OJS 3.3? Plan the move now, while it still receives fixes, rather than in a hurry after a security incident.

Supported OJS upgrade paths

You cannot always jump straight from an old version to the latest release. PKP's official upgrade guide sets out the supported route, and each step is a separate, complete upgrade run:

Upgrading OJS 3.3 to 3.4 or 3.5

Both are supported direct upgrades. For most journals on 3.3, we recommend going straight to 3.5, PKP's current LTS line, if your server can run PHP 8.2 or newer. Choose 3.4 only if a plugin or theme you rely on has no 3.5 release yet. Your team will notice the new submission screens, DOI interface and email composer, so a short training refresher helps editors settle in.

OJS 2 to OJS 3 migration

Moving from OJS 2.x is more a migration than an upgrade: OJS 3 has a different interface, workflow, theme system and plugin architecture. PKP's upgrade scripts carry across articles, issues, users and submission history, but:

• Your OJS 2 theme cannot be reused and must be rebuilt (see our OJS theme design service).
• OJS 2 plugins do not work in OJS 3 and must be replaced with OJS 3 equivalents.
• Some content, such as supplementary files, is handled differently in OJS 3, so we check it after each step.
• The intermediate versions need different PHP versions, so we work on a staging server where PHP can be switched between steps.

What can break during an OJS upgrade, and how we check first

These issues turn a routine upgrade into an emergency. We look for each of them before the live upgrade is scheduled.

Our compatibility review

• Every installed plugin is matched to a release for your target version, or a replacement.
• Your code is compared with the original release package to find edited core files and templates.
• PHP, database version, charset and table engine are checked against the OJS system requirements and the target release's README.
• The files directory and config.inc.php settings are verified.

Our OJS upgrade process, step by step

1. Full backup

   A database dump, the files directory (all submissions and review files), the public/ folder (logos and uploaded images), config.inc.php and any custom plugins or themes. Backups are stored off the server, and we confirm they restore.

2. Staging copy

   We restore the backup to a separate staging site running the target PHP version. Your live journal keeps working as normal.

3. Compatibility review

   Plugins, theme, custom code, server and database are checked as described above. We agree with you what to update, replace or retire.

4. Run the upgrade on staging

   We install the new release package, carry config.inc.php across and compare it with the new configuration template, then run PKP's command-line upgrade tool. The command line avoids browser timeouts on large journals.

5. Test what your journal depends on

   A test submission, reviewer assignment, editorial decision, email delivery, DOI registration, statistics, search, the theme on desktop and mobile, and Google Scholar meta tags on article pages.

6. Production upgrade in a quiet window

   At an agreed time, the live site shows a maintenance message, scheduled tasks and background jobs are stopped, a fresh backup is taken and the tested procedure is repeated.

7. Monitoring and rollback plan

   For the following days we watch error logs, scheduled tasks and email delivery. A rollback to the pre-upgrade backup is planned before we start, so a serious problem never leaves the journal stranded.

The upgrade commands in PKP's upgrade guide for OJS 3.x look like this. Always check that guide and the documentation of your release, as details can change between versions:

# 1. Confirm the installed and new versions
php tools/upgrade.php check

# 2. Run the upgrade and keep a log
php -d memory_limit=2048M tools/upgrade.php upgrade | tee -a upgrade.log

OJS migration to a new server or hosting provider

To migrate OJS to a new server, four things must move together: the OJS code, the database, the files directory and the public/ folder, plus the config.inc.php settings that connect them. Our usual sequence:

1. Prepare the new server

   Matching PHP version and extensions, database, SSL certificate, SMTP email and the cron job for scheduled tasks.

2. Copy and restore

   Restore the database and files, then update the database details, files_dir and, if needed, base_url in config.inc.php.

3. Test before the switch

   We test the new server privately (hosts-file entry or temporary address) while the old one stays live.

4. DNS cut-over

   We lower the DNS TTL in advance, pause editorial activity briefly, do a final sync of the database and files, then point the domain to the new server.

5. Keep a fallback

   The old server stays untouched for a few days in case anything needs to be compared or recovered.

Keeping URLs, DOIs and Google Scholar indexing intact

If the domain and journal paths stay the same, every article URL stays the same. DOIs keep resolving and Google Scholar sees no change. If the domain must change, for example when moving a journal onto a university domain, we:

• Set up permanent 301 redirects from every old URL (articles, PDFs, issues) to its new address.
• Re-deposit your DOIs with Crossref so they resolve to the new URLs. The DOIs themselves do not change.
• Update Google Search Console and submit the new sitemap.
• Keep the clean URL setting (with or without index.php) consistent, because changing it also changes every article address.

Migrating to OJS from another platform

Journals on a custom website, WordPress or other journal software can move to OJS. Depending on how structured the old data is, back issues can be imported with OJS's Native XML import, entered with the QuickSubmit plugin, or converted with a custom script. Every source is different, so we start with a sample and agree what will move (metadata, PDFs, authors, DOIs, redirects for old URLs) before committing to a plan, and we tell you upfront if something cannot move automatically.

Pre-upgrade checklist for OJS

Whether you upgrade OJS yourself or with us, check these points first:

Frequently Asked Questions