Planning a scholarly journal platform migration without losing continuity

Inventory before movement

A migration starts with evidence, not file copying. Every journal, issue, article, supplementary file, DOI, author identity, user role and active manuscript should be counted and mapped before a cutover date is chosen. The inventory must distinguish public archive content from confidential editorial records and identify missing files or inconsistent metadata while there is still time to resolve them.

Define field and workflow mappings

The old and new systems rarely use identical status names, permissions or metadata structures. A written mapping should explain where every field, role and workflow state will go. Active submissions need special treatment because reviewer invitations, deadlines, decisions and revision histories must remain understandable after transfer. Unknown or unsupported values should enter an exception report rather than being silently discarded.

Preserve public paths and identifiers

Existing article URLs, DOI landing pages and issue structures may already be present in citations, library catalogs and search indexes. A redirect plan maps every old public address to one stable destination and prevents chains or loops. Canonical links, language alternatives and sitemap entries are verified against the migrated record. Files must keep correct media types, access rights and durable links.

Rehearse and reconcile the cutover

A full trial migration should run on a protected staging environment. Automated counts compare journals, issues, articles, files, users and active tasks; sampled records are then reviewed by editors. The team tests sign-in, permissions, email, reviewer access, exports and search behavior. A documented rollback point and a short content freeze make the final cutover controlled rather than improvised.

Validate after launch

Completion is not defined by a successful import command. Monitoring should cover redirects, missing pages, download failures, metadata feeds, DOI resolution, email delivery and error logs. Editors need a clear route for reporting mismatches, and corrections must be tracked. Dijider treats migration as a continuity program: the new platform is accepted only when the archive, active editorial work and public scholarly record agree.