从读者多年前保存的一条引文开始。沿着链接打开文章，核对作者姓名、出版日期、期次和 PDF。这一小段阅读过程，比漂亮的新首页更适合用来验收期刊迁移。开放期刊系统（Open Journal Systems，OJS）是 Public Knowledge Project（PKP）开发的开源期刊平台，出版团队可以自主掌握所用的软件。[1] 要行使这份自主权，就得决定哪些内容必须在迁移后完整保留。

对于已有多年积累的期刊，有三件事值得分别梳理：已经发表的过刊、文章背后的编辑工作，以及读者查找文章时使用的地址。导入成功，只能解决其中一部分问题。着手迁移时，先把这些需要延续的内容和功能列成书面清单，再在非公开测试站上演练一次。

先确定导入要带走什么

PKP 的 3.5 版管理员指南将 Native XML 介绍为一种传输稿件、元数据和文件的格式，在 OJS 中还可传输期次元数据。指南也明确区分了版本：从 3.4 导出的 XML，不能直接导入 3.5。用户账户有单独的传输格式，与出版物关联的贡献者记录分开处理。少量过刊内容则可借助 QuickSubmit 手动录入。[2]

这些工作各有用途。文章上的作者署名回答谁写了文章，账户决定谁能进入系统；两者都不足以证明某位审稿人仍能查看分配给自己的那项审稿任务。选择工具之前，先记录源系统和目标系统的版本，并确定这次迁移涉及已发表内容、处理中的稿件，还是整套系统。

即便工具名叫 Full Journal Transfer，迁移范围也有明确限制。根据 2026 年 10 月 9 日核查的文档，Lepidus 的这款插件兼容 OJS 3.4.0 系列。它还会迁移审稿轮次、编辑决定和讨论记录，但历史编辑事件日志及已发送邮件日志不在迁移范围内。迁移还会改变数据库 ID；DOI 登记凭据不会随之转移，导入期间也不会安排 DOI 登记任务。[4]

对于仍在开展同行评审的期刊，上述区别会影响迁移计划。应选取实际采用的工作流程，用经过妥善保护的测试数据做一次演示，核对审稿任务、相关文件、编辑决定，以及有权查看这些内容的人员。如果必须保留的历史记录无法一并迁移，就要在停用源系统之前约定今后的查阅方式。导出包的名称无法替编辑作出这项决定。

用难处理的期次做演练

《OLA Quarterly》 的迁移提供了一份有参考价值的独立记录。俄勒冈州立大学的 Cara M. Key 在 2021 年发表于 《Code4Lib Journal》 的文章中，介绍了如何利用自定义 XSLT，将 Digital Commons 导出的元数据转换为 OJS Native XML。团队需要保留一些描述信息，而目标系统的字段难以直接容纳这些细节。[3]

例如，期次层面的关键词和客座编辑简介被合并进一个描述字段。读者仍能看到这些信息，但它们作为独立字段的区分有所减弱。团队起初选取不同时期的三个期次测试，在处理全部 93 个期次之前，先识别出各个时期描述信息的差异。他们还发现，通过模式校验的 XML，也仍有导入失败的情况。[3]

顺着这份经验选择样本，比只测“最新一期”更有价值。应挑出那些考验字段映射的记录：姓氏带重音符号的作者、多位作者、译文摘要、增刊、整期 PDF，以及日期信息缺漏的早期期次。这些项目是建议采用的测试用例，不能据此认定每个 OJS 版本都有相应缺陷。测试的目的是查清，这本期刊的记录在哪些地方难以适应此次转换。

源系统导出的数据应与字段映射表一同保存。逐项写明每个字段将进入目标系统的哪个位置，数据缺失时又如何处理。如果某个必填日期只知道年份，就应明确标注补入的月日，避免它悄然变成史实。把编辑采用的处理约定和日期的不确定性记录下来，日后的管理者才能分辨哪些来自证据，哪些是为适应系统要求所作的处理。

PKP 文档给出了具体的核对项：UTF-8 编码、YYYY-MM-DD 格式的日期，以及统一的栏目缩写。缩写拼写错误有时会让系统额外新建一个栏目。文件可以内嵌在 XML 中，也可以经由链接获取；内嵌文件较大时，命令行导入有时更便于处理。[2] 导入之后，要检查目标系统中的实际记录和下载后的文件。绿色的完成提示说明导入操作已经执行，期刊迁移的完整验收还需要进一步核查。

保留 DOI，更新它指向的地址

DOI（数字对象标识符）与文章的网页地址各有职责。网站迁移后，原有标识符应继续标识同一篇作品。Crossref 的指南明确反对仅因内容转移到新出版商，就另行分配 DOI 来替换原有标识符。[7] 同理，新安装一套 OJS，也没有理由让已经拥有 DOI 的文章再获得一个新的标识符。

Crossref 建议协调好重定向安排，因为一批 DOI 的目标地址无法在同一时刻全部更新。迁移有时还涉及文本与数据挖掘或 Similarity Check 所用的全文链接。迁移负责人必须确认谁有权更新记录，并防止原服务商继续覆盖这些记录。[5]

因此，测试要沿两条通道分别开展。一条是经由 DOI 解析服务，到达新的文章落地页；另一条是直接访问旧网站 URL。修好前一条通道，书签、教学大纲或图书馆网页中使用的旧链接仍有待核查。应保留旧文章地址、旧文件地址与预期目标之间的映射，并确认链接最终到达的是哪篇文章，仅凭 HTTP 响应成功还不足以验收。

更新操作本身还有一处隐患。Crossref 将批量更新解析目标 URL 与重新提交完整元数据区分开来。对于后者，必须提交完整的书目记录：新提交的数据替换旧数据时，遗漏的字段会有被清空的风险。[6] 因此，一次原本只为修复链接的迁移，若新导出的数据比原记录更少，就会有丢失既有元数据的风险。用新记录更新过刊之前，应先将待提交记录与现有登记记录逐项比对。

让编辑清楚交接如何完成

小型学会期刊可以这样分工：一名熟悉内容的编辑、一名了解元数据的人员，以及一名能够恢复服务的运维人员。同一个人也可以兼任数职。团队若缺少相应的运维能力，应先寻求机构支持或托管服务，再承担生产环境的恢复责任。

演练环境应与真实通知收件人及生产环境的 DOI 登记操作隔离。最终迁移前，先约定旧系统停止收稿和编辑变更的时间，制作可恢复的快照，并记录从何时起以哪套系统为准。新站一旦开始接收工作，回到较早的快照就必须妥善处理其后新增的稿件和编辑决定；仅把域名切回旧系统，无法让两边的记录重新一致。

培训也是交接的一部分。Mariya Maistrovskaya 和 Kaitlin Newson 在多伦多大学图书馆 OJS 升级的记录中，介绍了长达三个月的沙盒试用、培训和准备工作。尽管如此，上线后仍有编辑需要紧急协助。她们从中得到的经验是，变更前后都要预留支持人员和时间。[8] 即使版本和界面已经变化，这一经验仍有参考价值。

请一位编辑在目标系统中完成一项熟悉的工作，再退出管理员会话，以普通访问者的身份重走那条旧引文链接。读者能否找到正确的文章？编辑能否继续处理对应的稿件？团队能否说明另存于其他地方的历史记录如何查阅？这些问题得到回答，期刊才有了迁移的准备。到那时，再用改版后的首页庆祝也来得及。

来源

1. Public Knowledge Project，Open Journal Systems 代码仓库——项目宗旨、开源许可与部署文档。
2. Public Knowledge Project，《管理员指南 3.5》“导入与导出”——官方文档，涵盖 Native XML、版本兼容性、文件、QuickSubmit 和用户账户；核查日期为 2026 年 10 月 9 日。
3. Cara M. Key，“基于 XML 从 Digital Commons 迁移至 Open Journal Systems”，《Code4Lib Journal》第 52 期（2021 年 9 月 22 日）——独立的机构迁移记录，介绍元数据处理中的取舍与代表性样本测试。
4. Lepidus Tecnologia，Full Journal Transfer——文档列明的兼容范围、可迁移的工作流程记录、排除项、ID 变更和 DOI 登记限制；核查日期为 2026 年 10 月 9 日。
5. Crossref，“规划平台迁移”——服务商权限、重定向协调，以及既有 DOI 目标地址和相关 URL 的更新。
6. Crossref，“更新元数据”——重新提交完整记录、遗漏字段的处理，以及批量更新解析目标 URL。
7. Crossref，“期刊转移后更新承接的 DOI 元数据”——期刊责任主体变更时保留既有 DOI。
8. Mariya Maistrovskaya 和 Kaitlin Newson，“迁往 Open Journal Systems 3：让升级（大体上）少些麻烦的建议”，《Code4Lib Journal》第 43 期（2019 年 2 月 14 日）——沙盒准备、编辑培训与上线后的支持。
9. Public Knowledge Project 官方首页——2022 年哥伦比亚 Sprint 活动参与者照片的出处与内容说明。