We are still running 3.1.2, but looking to upgrade soon to 3.2 and wondering how this might impact transferring journals between installations. We have a journal on a subdomain of its own, as well as another subdomain that has the rest of our journals on a single OJS installation. We want to move the isolated journal into the existing multi-journal installation, but have been having trouble figuring out how to move a journal from an existing instance of OJS to another of the same version. I’m aware of some good resources for migrating to an entirely new installation, as well as for upgrading across the OJS 2/3 barrier, but I don’t find much guidance specific to this situation.
Does the OJS 3.2 upgrade offer us any new approaches to this problem? Do we have an opportunity to finally move that lone journal in some way other than manually rebuilding it?
Hi @racemochridhe,
What you’re looking for is a way to transfer a complete journal from one OJS installation to another, and unfortunately we don’t have a good solution for that at the moment. For OJS 2.x there was a third-party tool to perform this, but it hasn’t been upgraded to work with OJS 3.x: GitHub - lepidus/fullJournalTransfer: OJS plugin for importing/exporting a journal with all its private information (e.g. submitted articles, reviews, editorial decisions, etc.)
There is an issue filed in Github to extend the kinds of entities included in the XML import/export, but it still needs work: Extend native import/export plugin to include additional entities · Issue #3261 · pkp/pkp-lib · GitHub
The fundamental problem is that the OJS data model is very large, and coding a toolset that recapitulates the entire data model in order to convert it into another format is a large and hard-to-maintain task. We’re considering other approaches, e.g. relying on the new SchemaDAO toolset and aligning the import/export process with the API, in order to accomplish both tasks using the same codebase rather than requiring a multiplying of code.
This unfortunately doesn’t solve your problem, but I hope it at least explains why…
Thanks,
Alec Smecher
Public Knowledge Project Team