Start with a citation someone saved years ago. Follow its link, open the article, and check the author names, publication date, issue, and PDF. That small journey makes a better acceptance test for a journal migration than a handsome new homepage. Open Journal Systems, the Public Knowledge Project's open-source journal platform, gives a publishing team control over its software.[1] Exercising that control means deciding what must survive the move.

For an established journal, three things deserve separate attention: the published backfile, the editorial work behind it, and the addresses by which readers find it. A successful import can settle only part of that problem. The useful starting point is a written inventory of those promises, followed by a rehearsal on a private test site.

Decide what the import is meant to carry

PKP's 3.5 administrator guide describes Native XML as a format for transferring submissions, metadata, files, and, in OJS, issue metadata. It also makes a crucial version distinction: an XML export from 3.4 cannot simply be imported into 3.5. User accounts have their own transfer format and are distinct from the contributor records attached to publications. QuickSubmit provides a manual route for a small amount of back content.[2]

Those are different jobs. A printed author credit answers who wrote an article; an account determines who can enter the system. Neither proves that a particular reviewer can still see the right assignment. Before choosing a tool, record the source and destination versions and identify whether the project concerns published content, ongoing submissions, or an entire installation.

Even a tool named Full Journal Transfer has explicit limits. The Lepidus plugin's documentation, checked October 9, 2026, lists compatibility within the OJS 3.4.0 line. It adds review rounds, decisions, and discussions to the transfer, but excludes historical editorial-event and sent-email logs. It also changes database IDs and does not transfer DOI-deposit credentials or schedule deposits during import.[4]

For a journal with active peer review, this distinction changes the plan. Require a demonstration using a real workflow pattern, with appropriately protected test data. Check the assignment, its files, the decision, and the people permitted to see them. If required history cannot be carried over, agree how it will remain accessible before retiring the source system. The name of an export package cannot make that decision for the editor.

Rehearse with the awkward issues

The migration of OLA Quarterly offers a useful independent account. In a 2021 Code4Lib Journal article, Oregon State University's Cara M. Key described converting a Digital Commons metadata export through custom XSLT into OJS Native XML. The team needed to preserve descriptive details that did not fit neatly into the destination's fields.[3]

Issue-level keywords and guest-editor biographies, for example, were combined into a description. Readers could still encounter the information, but its separate structure was diminished. The team initially tested three issues from different periods, exposing different descriptive practices before processing the full run of 93 issues. It also found that schema-valid XML could still fail at import.[3]

That experience suggests a better sample than “the newest issue.” Choose records that challenge the mapping: an accented surname, several authors, a translated abstract, a supplement, a whole-issue PDF, and an early issue with sparse dates. These are proposed test cases, not claims about defects in every OJS release. The purpose is to discover where this journal's records resist this particular conversion.

Keep the source export and a mapping sheet together. For each field, state where it will land and what happens when it is missing. If a required date is only known to the year, an invented day should not silently become a historical fact. Record the editorial convention and its uncertainty so a future custodian can distinguish evidence from accommodation.

PKP's documentation provides concrete checks: UTF-8 encoding, YYYY-MM-DD dates, and consistent section abbreviations. A mistyped abbreviation can create another section. Files may be embedded in XML or fetched through links; large embedded files may make command-line import more practical.[2] After import, inspect the destination's actual records and downloaded files. A green completion message is evidence about execution, not a complete assessment of the journal.

Keep the DOI; move its destination

A DOI and an article's website address have different responsibilities. When the site moves, the existing identifier should continue to identify the same work. Crossref's guidance explicitly rejects assigning replacement DOIs merely because content has transferred to a new publisher.[7] A fresh OJS installation likewise is no reason to give an already identified article a second identity.

Crossref advises coordinating redirects because updating a collection of DOI destinations does not happen at one instant. The move can also require changes to full-text links used for text and data mining or Similarity Check. The migration owner must establish who has permission to update the records and prevent the previous provider from continuing to overwrite them.[5]

There are therefore two routes to test. Follow the DOI through its resolver to the new landing page. Separately, follow the old website URL directly. Repairing the first route does not repair a bookmark, syllabus, or library page that used the second. Preserve a mapping from old article and file addresses to their intended destinations, and test the final article reached rather than accepting any successful HTTP response.

There is another trap in the update itself. Crossref distinguishes a bulk resolution-URL update from a full metadata redeposit. For the latter, it requires the complete bibliographic record: omitted fields can be cleared when the new deposit replaces the old one.[6] A move intended to fix links can therefore erase previously supplied metadata if the new export is thinner. Compare the outgoing record with the existing deposit before using it to update the backfile.

Give the editors a cutover they can explain

For a small society journal, a workable division of responsibility is an editor who recognizes the content, someone who understands its metadata, and an operator who can restore the service. One person may hold several roles. A team without that operational capacity should seek institutional or managed hosting support before taking responsibility for production recovery.

Keep the rehearsal isolated from real notification recipients and production DOI deposits. Before the final transfer, agree when submissions and editorial changes stop on the old system, take a restorable snapshot, and record which system becomes authoritative. If the new site begins accepting work, returning to an earlier snapshot requires accounting for those new submissions and decisions; changing the domain back alone cannot reconcile them.

Training is part of this handover. Mariya Maistrovskaya and Kaitlin Newson's account of the University of Toronto Libraries' OJS upgrade describes three months of sandbox access, training, and preparation. Some editors nevertheless needed urgent help after launch. Their lesson was to reserve support capacity after the change as well as before it.[8] That remains useful even when the versions and interfaces have changed.

Ask an editor to complete a familiar task on the destination, then repeat the old-citation test from outside the administrator's session. Can a reader reach the right work? Can an editor continue the right submission? Can the team explain any history retained elsewhere? Those are the answers that make a journal ready to move. The redesigned homepage can celebrate them afterward.

Sources

1. Public Knowledge Project, Open Journal Systems repository—project purpose, open-source licensing, and deployment documentation.
2. Public Knowledge Project, “Import and Export,” Administrator Guide 3.5—official documentation source covering Native XML, version compatibility, files, QuickSubmit, and user accounts; checked October 9, 2026.
3. Cara M. Key, “An XML-Based Migration from Digital Commons to Open Journal Systems,” Code4Lib Journal 52 (September 22, 2021)—an independent institutional migration account, including metadata compromises and representative testing.
4. Lepidus Tecnologia, Full Journal Transfer—documented compatibility, transferred workflow records, exclusions, changed IDs, and DOI-deposit limits; checked October 9, 2026.
5. Crossref, “Planning a platform migration”—provider permissions, coordinated redirects, and updates to existing DOI destinations and related URLs.
6. Crossref, “Updating your metadata”—complete-record redeposits, omitted fields, and bulk resolution-URL updates.
7. Crossref, “Updating metadata for inherited DOIs after a title transfer”—retaining existing DOIs when responsibility for a journal changes.
8. Mariya Maistrovskaya and Kaitlin Newson, “Making the Move to Open Journal Systems 3: Recommendations for a (mostly) painless upgrade,” Code4Lib Journal 43 (February 14, 2019)—sandbox preparation, editorial training, and support after launch.
9. Public Knowledge Project, official homepage—provenance and identification of the photograph of participants at the 2022 Colombia Sprint.