Move your journal to Open Journal Systems without losing its scholarly record
OJS migration is the controlled transfer of a journal website, article archive, issues, users, files, metadata, and publishing workflow from an existing platform or OJS installation to a new Open Journal Systems environment. A successful migration protects the journal's content and identity while giving editors a stable platform for future submissions and publication.
Migration is not simply copying a website folder. An academic journal contains relationships between volumes, issues, articles, authors, editors, reviewers, submission files, published galleys, DOI records, URLs, plugins, themes, email templates, and editorial history. GetOJS begins with a technical audit so the transfer scope and risks are understood before production data is changed.
What can be included in an OJS migration?
The available migration route depends on the source platform, database access, file access, metadata quality, OJS versions, custom code, and the condition of the existing website. After review, a migration may include:
- Journal title, description, policies, sections, languages, and navigation.
- Published volumes, issues, articles, abstracts, keywords, references, and publication dates.
- Author, editor, reviewer, and journal manager accounts where reliable source data is available.
- Article PDFs, supplementary files, cover images, and other publication galleys.
- DOI values, article landing-page URLs, citation details, and related metadata.
- Theme assets, essential plugins, email settings, scheduled tasks, and platform configuration.
- Redirect planning for important legacy URLs when the old and new URL structures differ.
Some source systems do not expose complete editorial history or passwords in a transferable form. These limitations are identified during the audit so the proposal distinguishes automated transfer, manual cleanup, reconfiguration, and information that cannot be migrated safely.
OJS-to-OJS migration and version changes
Moving between servers on the same compatible OJS version is different from upgrading an older OJS installation. When a version change is required, database upgrades, PHP compatibility, plugins, themes, custom code, locale files, and storage paths must be reviewed together. Large version jumps may require staged upgrades rather than a direct move.
GetOJS separates migration and upgrade decisions during planning. This makes it easier to identify whether a problem comes from the server transfer, application upgrade, custom theme, plugin compatibility, or source data. Journals that only need a version update can review the dedicated OJS upgrade service.
Migration process
- Discovery and access review: confirm the source platform, OJS version, hosting access, database, files, journal count, archive size, domain, email, plugins, theme, and customizations.
- Backup and migration plan: define the transfer method, staging environment, compatibility work, responsibilities, test criteria, redirect needs, and launch window.
- Staging migration: transfer a controlled copy to the target environment without interrupting the live journal.
- Content verification: compare issues, articles, authors, files, metadata, DOIs, dates, user roles, navigation, and essential settings against the source.
- Production cutover: take a final data copy where required, place the old site in a controlled state, switch the domain, and verify HTTPS and server behavior.
- Post-launch checks: test logins, submissions, email, search, PDFs, DOI resolution, OAI-PMH, redirects, analytics, scheduled tasks, and backups.
Protecting URLs, DOI links, and search visibility
A migration does not guarantee rankings or inclusion in any indexing database. It should, however, avoid unnecessary discovery problems. Important article URLs should remain stable where practical. When URLs must change, relevant old pages should return permanent redirects to the closest new article or issue page instead of redirecting every request to the homepage.
Canonical URLs, XML sitemaps, robots rules, public article pages, downloadable files, DOI destination URLs, and internal links should be checked after launch. Search engines and scholarly discovery systems may take time to recrawl changed pages, so the safest approach is to minimize avoidable URL and metadata changes during the move.
Information needed for an OJS migration quote
To prepare a realistic scope, share the current website URL, source platform and version, number of journals, approximate number of articles and users, archive size, available server or database access, required target version, preferred hosting route, theme or plugin customizations, DOI use, and desired launch window. Sensitive credentials should only be shared through an agreed secure channel after the project scope is accepted.
For a managed destination, review OJS hosting services. If the journal will remain on an institution-owned server, review OJS installation on your own hosting.
OJS Migration FAQ
Compare OJS Cost, Scope, and Service Options
Use these practical buyer guides to prepare a clearer project brief, budget, timeline, and provider comparison.