01
Start with a complete inventory
List the journal’s articles, issues, files, user roles, metadata, identifiers, site content, configuration, integrations and active workflow. The point is not to create paperwork; it is to identify what has to be represented, validated or consciously retired in the new environment.
02
Map the operation as well as the data
A migration can technically complete while the editorial office is unable to work. Document the current submission stages, decision routes, email templates, roles, production handoffs and publishing controls, then configure the new platform around the intended operating model.
03
Test against agreed acceptance criteria
A test migration should check more than page counts. Agree how content, metadata, files, identifiers, links, permissions, workflows and public presentation will be reviewed. Record exceptions, decide their resolution and identify who may accept the result.
04
Plan the move into routine delivery
Go-live needs communication, access arrangements, a defined support period and a route for issues found after launch. The journal should know who owns the new operation, not merely which platform it is on.