What Happens When You Don’t Upgrade OJS
The risks of staying on an old OJS version, why waiting costs more, and how a safe move to OJS 3.5 works.
On this page
Plenty of journals run on the OJS version that was installed years ago. Articles still publish and reviews still come in, so upgrading never feels urgent. But an old installation becomes harder, riskier and more expensive to move with every year it’s left.
The current long-term support release is OJS 3.5. For version details, see the latest version of OJS.
“It still works” isn’t the same as “it’s fine”
An old OJS can look healthy while the problems build up underneath: security fixes it never received, a PHP version that no longer gets patches, plugins that no longer update. You usually find out when something breaks, at the worst possible time.
What goes wrong
Security holes stay open
Each OJS release fixes security problems, and once a fix is published, the weakness in older versions is public knowledge. OJS 2 gets no fixes at all, and OJS 3.1 and 3.2 are no longer maintained. More in common OJS security vulnerabilities.
Your hosting moves on without you
Hosts keep retiring old PHP versions. PKP lists PHP 7.3 to 8.2 for OJS 3.3, and PHP 8.2’s security support ends on 31 December 2026. When the host moves on, an outdated journal can stop working. OJS 3.5 runs on PHP 8.2 and later.
Plugins and integrations stop working
DOI registration, ORCID, statistics and indexing plugins are built for current versions. Old installations get stuck on old plugin versions, or lose features when outside services change their requirements.
Indexing and credibility suffer
Indexing services look at metadata quality and technical reliability. An outdated, slow or insecure site doesn’t help an application to DOAJ or Scopus, and broken pages or browser warnings put readers and authors off.
Mobile and accessibility fall behind
The OJS 2 default theme wasn’t built for phones; OJS 3’s default theme is responsive. Older OJS 3 versions also miss recent accessibility work, such as the rebuilt, more accessible submission wizard in OJS 3.4. Authors who struggle with the submission form may give up.
Help gets harder to find
PKP’s community and documentation focus on current versions. The older your version, the fewer people can fix it quickly.
The upgrade gets harder the longer you wait
The older the version, the bigger the job: more to check, more to test, and more plugins and theme work. Each year an old journal waits, the move gets larger.
| You’re on | What moving to OJS 3.5 involves |
|---|---|
| OJS 3.4 | Our quickest upgrade |
| OJS 3.3 | A standard upgrade; plan it before 2027 |
| OJS 3.2, 3.0 or 3.1 | A bigger upgrade, with more checks |
| OJS 2.4 | A migration to OJS 3, with a new theme |
| Older than OJS 2.4 | A migration project, quoted after a free check |
The work depends on your installation, plugins and theme, which is why every safe upgrade is tested on a copy of the site first. This guide is independent and not endorsed by PKP.
Custom changes add to the work. Edits made directly to OJS files, unmaintained plugins and heavily customised themes all have to be found and dealt with before an upgrade can go through cleanly.
How urgent is it for you?
| Your version | Urgency |
|---|---|
| OJS 2.x | Urgent: no security fixes for years |
| OJS 3.0 to 3.2 | High: unmaintained, and the upgrade grows every year |
| OJS 3.3 | Plan now: supported until at least 1 January 2027 |
| OJS 3.4 | Moderate: not a long-term support release; move to 3.5 |
| OJS 3.5 | Up to date: keep applying maintenance releases |
The real cost of waiting
Journals put off upgrades to save money and avoid disruption. Waiting usually costs more: a bigger upgrade, more custom code to untangle, and a higher chance of an emergency, such as a hack or a hosting change, forcing the upgrade on a deadline. A planned upgrade, tested on a copy first, is cheaper and calmer.
How a safe upgrade works
- A full backup: the database, the files folder and the OJS code.
- A check of the plugins, theme and any custom changes.
- The upgrade run and tested on a private copy: submissions, review, emails, DOIs and the public pages.
- The live upgrade at a quiet time, with the backup ready to restore.
Why have it done professionally
An upgrade that stops halfway can leave the journal offline, with a database neither version will open. Without a complete, tested backup there is no way back, and quiet problems such as emails that stop or DOI deposits that fail often go unnoticed for weeks.
Our OJS upgrade service handles the backup, the test run and the live upgrade, including OJS 2 migrations, at a fixed price with 14 days of free fixes; see the upgrade price in under a minute.
Questions
Can we upgrade OJS ourselves?
You can, if someone in your team knows OJS, PHP and databases well. The risk is real, though: an upgrade that fails halfway can take the journal offline, and without a full, tested backup there is no way back.
Can an OJS 2 journal move to OJS 3.5?
Yes, as a migration project with a new theme, tested on a copy first. See OJS 2 to OJS 3.5 migration.
How long is OJS 3.3 supported?
PKP supports OJS 3.3 until at least 1 January 2027. Plan your move to 3.5 before then.
Will we lose our articles or users when upgrading?
Not if it’s done properly: a full backup first, a test upgrade on a copy, and checks before going live.
Last updated on October 11, 2026