Website Design & Development
We create stunning, user-friendly websites that drive growth.
Many journals run on OJS versions installed years ago, never updated since initial setup. While the software continues functioning, running outdated OJS creates compounding problems that grow more serious over time. Understanding these risks helps publishers make informed decisions about platform maintenance.
The False Comfort of "It Still Works" #
Journals often delay upgrades because their current installation seems functional. Articles publish, reviewers submit feedback, the site loads—everything appears normal. This apparent stability masks underlying problems that worsen with each passing month.
Software doesn't age like wine; it ages like milk. What worked acceptably three years ago increasingly conflicts with modern browsers, security standards, and user expectations. The gap between outdated installations and current best practices widens continuously.
Security Vulnerabilities Accumulate #
Every software release includes security patches addressing discovered vulnerabilities. When journals skip updates, they remain exposed to every vulnerability fixed in subsequent releases. Attackers specifically target known vulnerabilities in outdated software because exploitation is straightforward.
The Public Knowledge Project regularly publishes security advisories for OJS. Running old versions means running software with publicly documented security holes—essentially an open invitation for exploitation. Compromised journal sites can distribute malware, send spam, or expose sensitive author and reviewer data.
OJS 2.x versions are particularly concerning because PKP no longer releases security updates for this branch. Journals on OJS 2.x operate without any security net, relying on luck rather than protection.
Browser Compatibility Degrades #
Web browsers evolve constantly. Chrome, Firefox, Safari, and Edge update frequently, sometimes deprecating features that older websites depend upon. OJS installations built for browsers of 2018 increasingly malfunction in browsers of 2024.
Users encounter display problems, broken functionality, and error messages. Authors struggle to submit manuscripts. Reviewers can't access assigned papers. Editors find administrative interfaces unresponsive. Each browser update risks breaking something else in outdated OJS installations.
Mobile Experience Deteriorates #
Older OJS versions, particularly the 2.x series, weren't designed for mobile devices. They display poorly on smartphones and tablets, requiring pinching, zooming, and horizontal scrolling. Given that significant portions of web traffic now come from mobile devices, this limitation excludes substantial audiences.
Authors may abandon submission attempts when forms don't work on their phones. Readers may skip articles that display illegibly on mobile screens. Search engines may penalise sites that don't provide adequate mobile experiences.
Running an Outdated OJS Version?
Upgrading becomes more complex the longer you wait. Professional upgrade services ensure safe migration without data loss or extended downtime.
Plugin Incompatibility Grows #
OJS plugins extend functionality—DOI registration, ORCID integration, usage statistics, enhanced metadata. Plugin developers build for current OJS versions. As your installation ages, fewer plugins work correctly, and new plugins won't install at all.
Journals needing Crossref DOI registration, for example, may find the plugin incompatible with their old OJS version. Upgrading the plugin requires upgrading OJS first. The journal faces either abandoning needed functionality or undertaking the upgrade they've been avoiding.
Indexing Opportunities Disappear #
Indexing services expect certain technical standards. Modern metadata formats, specific XML exports, and proper machine-readable markup may be absent in older OJS versions. Google Scholar, DOAJ, and other services may not properly index content from outdated installations.
Some indexing applications now consider platform currency as an evaluation factor. Running severely outdated software suggests inadequate technical management—not the impression journals want to make during Scopus or DOAJ evaluations.
The Upgrade Becomes Harder #
Perhaps the most insidious consequence of delay: upgrades become progressively more difficult. Moving from OJS 3.2 to 3.3 is straightforward. Moving from OJS 2.4 to 3.4 involves complex data migration, theme replacement, and workflow reconfiguration.
Each skipped version adds complexity to eventual migration. Journals waiting years between upgrades face substantially more work—and risk—than those updating incrementally. Some journals delay so long that clean migration becomes nearly impossible without extensive manual intervention.
Technical Debt Compounds #
Outdated installations often accumulate workarounds—patches, hacks, and modifications applied to address specific problems without proper updating. These workarounds create "technical debt" that complicates future maintenance.
When upgrade finally becomes unavoidable, technicians discover layers of modifications that must be understood, documented, and properly addressed. What might have been a routine upgrade becomes an archaeological excavation through years of accumulated fixes.
Support Availability Decreases #
Finding help for outdated software grows difficult over time. PKP community forums focus on current versions. Developers familiar with OJS 2.x retire or move on. Documentation for old versions becomes harder to locate. Expertise concentrates on current platforms.
When problems arise—and they will—journals running ancient OJS versions find fewer resources for resolution. Issues that would take hours to fix on current versions may take days on obsolete ones, if solutions exist at all.
Performance Degrades #
Newer OJS versions include performance optimizations absent in older releases. Database queries run more efficiently. Caching works more effectively. Code executes faster. Running old versions means running slower software than necessary.
Additionally, older OJS versions may not support current PHP versions, forcing hosting environments to run outdated PHP. This compounds performance problems and creates additional security vulnerabilities at the server level.
Recognizing Upgrade Urgency #
Some situations demand immediate attention:
OJS 2.x: Any journal still on OJS 2.x faces urgent upgrade needs. This version family receives no security updates and lacks modern functionality essential for contemporary publishing.
Versions More Than Two Years Old: Even within OJS 3.x, running versions released more than two years ago means missing significant improvements and security patches.
Known Security Issues: If your version appears in PKP security advisories, upgrade priority is critical.
Visible Problems: Display issues, broken features, or error messages indicate systems struggling with age-related incompatibilities.
The Cost of Waiting #
Journals delay upgrades hoping to avoid cost and disruption. Ironically, delay typically increases both. Upgrade complexity grows with time. Security incidents create far more disruption than planned upgrades. Lost indexing opportunities have long-term consequences. Accumulated technical debt eventually demands payment with interest.
Planned upgrades on reasonable schedules cost less and risk less than emergency interventions forced by security breaches or system failures.
