OJS setup and hosting: a step-by-step implementation guide for journals

Step 1: Define the scope of the project

Before any technical decision, answer three questions. Is this a new journal, or an existing one that publishes today on another system, such as a custom site, WordPress or an old OJS version, and needs to migrate? How many back issues must be brought into the new system, and in what state are their files and metadata? Will the institution run one journal or several, given that OJS can host multiple journals in one installation, each with its own domain or subdomain?

The answer to the second question changes the project the most. A new journal with no back catalog is implemented in weeks. A journal with fifteen years of published issues that must be loaded with correct metadata is, in practice, a data migration project with a software component on top. If you are still getting to know the platform, start with what OJS is and how it works.

Step 2: Choose the OJS version and check requirements

Versions matter. The Public Knowledge Project alternates long-term support (LTS) and short-term support (STS) releases, and "supported" means bug fixes and security patches, not new features.

OJS 3.5 requires PHP 8.2 or later with the mbstring, xml and intl extensions enabled, and runs on MySQL, MariaDB or PostgreSQL. The files directory must sit outside the web root, so uploaded manuscripts are never reachable by URL, and since OJS 3.4 long-running tasks are processed as background jobs, so a production server also needs scheduled tasks and job processing configured. Start from the latest LTS release, never from an old branch: installing a version whose end of life is already set means starting the project with scheduled technical debt.

If you are upgrading rather than installing, follow the PKP upgrade guide. OJS 2.x installations must first move to the latest 2.4.8 build, then to 3.2.1, and from 3.2.1 to 3.3 or later. Between LTS releases, 3.3 can go straight to 3.5 without stopping at 3.4. PKP's advice is to rehearse every upgrade in a test environment first and to back up the database and both the private and the public files directories.

Step 3: Choose your OJS hosting option

Where OJS runs determines who keeps it patched, backed up and upgraded. These are the realistic options:

Whatever the option, some requirements are constant: a domain or subdomain for each journal, an HTTPS certificate, storage sized for the files (original submission files usually weigh more than the published galleys), and a backup policy for both the database and the files. Both are equally critical: losing one without the other leaves the system in an inconsistent state.

BiblioLabTech works both ways: managed hosting on its own infrastructure, or installation in the institution's data center, where the IT team keeps control. When the hosting is ours, support covers incident response, server maintenance and backups, planned version upgrades, functional help for the editorial team and periodic review of the DOI and indexing configuration.

Step 4: Install and configure the journal

With the infrastructure ready, OJS is installed and the journal's core data is configured: title, abbreviation, ISSN or e-ISSN if one exists, primary contact, technical support contact and publication languages. The section structure is defined too, such as original articles, reviews, book reviews and editorials, and the theme is customized with the journal's identity.

This is also when users are created and assigned roles: journal manager, editors, section editors and, if already known, the regular pool of reviewers. In our projects, this stage often reveals that the journal had never formalized its own roles (who decides, who assigns reviewers, who approves the final version), and those have to be defined before they are configured in the system, not the other way around.

Step 5: Migrate back issues, if there are any

This is the step most underestimated when budgeting an OJS project. There is no automatic way to turn a custom site or a collection of loose PDFs into correctly structured issues inside OJS. The real routes are:

• Structured import. If metadata is organized in a format such as CSV or XML (title, abstract, authors, volume and issue of each article), much of the loading can be automated.
• Migration from another OJS installation. If the journal already used OJS in another version or on another server, migration carries over articles, issues, users and submission history far more directly than starting from scratch.
• Manual loading with Quick Submit. When there is no structured metadata, each back issue is loaded straight into production without going through a review workflow that was completed years ago in the old system.

When BiblioLabTech implements OJS for a journal with a long history, the first deliverable of this stage is not software but an inventory: which issues exist, what format their files are in and how complete their metadata is. That inventory decides whether the migration takes two weeks or two months. DOIs already registered are kept, their target URLs are updated in Crossref if the domain changes, and permanent redirects keep links published in other articles working.

Step 6: Configure the editorial workflow

With the journal installed and the back catalog resolved, configure the pieces that run the day-to-day: the review form reviewers will see, default deadlines for each review, automatic email templates for each stage (submission acknowledgment, review invitation, editorial decision) and each role's permissions across the four workflow stages: submission, review, copyediting and production. If the journal will use double-anonymous (double-blind) review, enable it here and test it with a trial submission before opening the real call for papers.

Step 7: Set up DOIs with Crossref

If the journal will assign DOIs, this step requires work outside OJS first. The journal must become a Crossref member, either directly, paying an annual fee tiered by revenue or expenses plus a one-off fee per registered DOI, or through a sponsor, and it needs its own DOI prefix in the 10.xxxx format. With those credentials, enable the Crossref plugin in OJS, configure the prefix, choose when each article receives its DOI (usually on reaching copyediting or on publication) and enter the deposit credentials. From then on, deposits can be automatic with each publication or manual, reviewing article by article before sending them to Crossref.

Prepare this during initial configuration, even if the first issue will not carry DOIs yet: activating the plugin and validating the prefix before the first publication avoids having to reassign identifiers later. The same goes for ORCID, so authors can connect their verified iDs from the first submission.

Step 8: Prepare for indexing and preservation

If the journal aims for indexes such as DOAJ, SciELO or Latindex, resolve some items during implementation rather than afterward, because they are formal requirements OJS can display in an orderly way if configured in time. Latindex, in its Catálogo 2.0 for online journals, requires the journal's own institutional website and assesses 38 characteristics in five blocks, with an 80% pass threshold. DOAJ asks, among other things, that the open-access policy and the peer review process be visible on the journal's public site, which OJS exposes when its configuration fields are completed properly. Funders following Plan S also expect DOAJ registration, persistent identifiers and deposit with a long-term preservation program; OJS can deposit content in the PKP Preservation Network, which is worth enabling from the first issue. None of these applications is decided by the software, because they depend on the journal's editorial merit, but configuring the public information correctly from the start saves rebuilding it article by article later.

Step 9: Run a pilot and publish the first issue

Before announcing the journal, run a full cycle with a test submission: a fictitious manuscript, or a real low-risk one, that goes through all four stages to verify that notifications arrive, forms work and the final galley looks as expected. Once that is resolved, publish the first real issue and open the public call for submissions.

Realistic OJS setup timelines

These ranges reflect effective work, not calendar time. In calendar terms, a new journal typically takes six to ten weeks, and two to four months when there is a large back catalog or several journals to configure, mostly because of the availability of the people who must take editorial decisions, not because of the software.

Common mistakes in OJS setup and hosting

Three mistakes recur among journals that come to us after a failed first attempt. The first is installing a version of OJS without current support, usually because a generic online tutorial was out of date; the result is a system without security patches from day one. The second is configuring the editorial workflow before the journal has its own written policies, which forces forms and deadlines to be redone several times along the way. The third, and the most expensive, is underestimating the migration: treating the back catalog as a weekend task when it is really hundreds of records whose metadata must be reviewed one by one.

What the journal must bring

No provider can do all of this alone. Before or during the implementation, the journal has to define its editorial policies (anonymous or open review, deadlines, rejection criteria), who takes each role in the workflow and, if there is a back catalog, who has the authority to decide how to resolve incomplete or ambiguous metadata in old issues. BiblioLabTech takes care of the infrastructure, the technical configuration and the data migration; the underlying editorial decisions always belong to the journal.

If your university also needs a home for theses and reports, that is a different platform, covered in our guide to the institutional repository. To implement OJS with support for back-catalog migration and Crossref configuration, see our OJS implementation and hosting service.