开馆首日 8:58，与其查看 Koha 能否显示馆里最普通的一本小说，更有用的测试是扫描一本情况棘手的书：馆藏归属在一家分馆，却在另一家归还；它已经预约给下一位读者，一笔补购费用仍在复核，书名还含有变音符号。接着观察工作人员界面、读者账户、预约队列、转运单、通知系统和审计轨迹分别作何反应。

这一笔交易触及的集成图书馆系统环节，远多于一次干净利落的导入计数。Koha 迁移的成功，体现为馆员能够提供正确的服务，系统也记录下预期状态。旧系统的表行刚好装进新表，只说明导入完成了一部分。因此，这份迁移笔记以流通台为起点：先定义有代表性的柜台服务故事，再映射讲述这些故事所需的数据，并在开门前预演后续影响。

Koha 是一个仍在积极维护的替代方案，选择它的理由远超避开许可证账单。2026 年 5 月发布的 26.05.00 大版本横跨广泛的业务范围，记录了 2 项新功能、214 项增强和 365 项缺陷修复。[1] 这份维护信号让人放心，也在提醒迁移团队：Koha 有自己明确的数据模型，不能视作一套配有网页表单的空数据库。记录、复本、读者、分馆、规则、队列和权限都按特定方式组织。迁移团队要把一所图书馆转译到这些模型中。

题图拍下了 Aude Charillon 在 KohaCon 2023 上与 Koha 用户讨论读者数据保留的现场。[8] 它放在文章开头，因为迁移正是一个少见的时刻：每个继承而来的字段都会显露为一项决定。“以前就存着”不能充当数据保留政策。

先写流通台演练，再做字段映射

先向真正负责开馆、闭馆、上架、编目、接听电话和处理例外情况的人收集十到二十个简短的服务故事。除了询问他们使用哪些界面，还要了解哪些业务会让他们停下来仔细判断。

一套实用的演练材料可以包括：

• 首次办证的读者，只采集图书馆确有需要的最低限度身份信息；
• 一名儿童，其保证人、消息接收权限和隐私期待都与成人有别；
• 一件只能在馆内使用、禁止外借的参考馆藏；
• 一件归还后应当满足另一家分馆预约的馆藏；
• 一件报失后又寻回的馆藏，并提前写明预期的收费与退款处理；
• 一个拥有多件复本、多个分卷或多期连续出版物的题名，各件仍须彼此可辨；
• 一笔自助借还或离线交易，在实时书目已经变化之后才传入系统；
• 一周之中遇到闭馆日时发出的逾期通知；
• 一名读者，其过往借阅记录按政策留在旧系统中。

为每个故事写明初始事实、工作人员操作、预期可见结果，以及应当改变的记录或消息。再指定一位能够确认结果是否正确的馆员。这些内容就是用日常语言写成的验收测试，让编目员、流通工作人员、迁移开发人员和托管服务商共同关注同一种服务，免得四方各自拿着一套“数据看起来没问题”的标准。

Koha 自己的实施清单把员工练习、上线前的最终数据提取、URL 切换和备份都列入上线规划。[2] 演练材料把这类概括性建议变成证据。先在旧系统中运行一次，记录当前行为；再对测试迁移运行一次；最后对正式上线候选版本再运行一次。把结果与截图作为迁移记录保存下来；一次会议中所有人都记得演示“看着还行”，证据分量远远不够。

装载数据之前，先给图书馆中的各项代码正名

转换工作的第一份产物应当是一份代码台账，导入脚本排在其后。Koha 要求机构先定义图书馆、馆藏类型、读者类别和授权值，再映射旧系统数据。这些授权值包括 CCODE、LOC 等馆藏与排架代码，也包括遗失、禁止外借、损坏和注销馆藏的状态。自定义读者字段则依赖明确启用的 ExtendedPatronAttributes 系统偏好。[2]

对于旧系统中的每个代码，台账都应注明：

• 来源值及其通俗含义；
• 目标 Koha 代码和标签；
• 映射会保留、合并、拆分还是舍弃来源类别；
• 数量统计和若干真实样例；
• 批准这项含义的馆员。

迁移团队常在这里发现，REF、R 和空白馆藏地点原来都曾表示“参考馆藏”，只有一家分馆还用空白值表示未编目资料的库房。看似无关紧要的分馆更名也会在这里暴露风险：一旦公开名称、机构身份和简短的系统代码被当成同一项内容，报表便会出错。

这些区别要明确保留下来。分馆代码是稳定的关联键，显示名称可以变化。读者类别会参与政策计算，不能只当作人口属性标签。馆藏类型可以决定流通行为；若仅因“设备”“课程指定参考资料”和“图书”都是实体物品便合并三者，服务规则也会随之改变。代码台账应与转换脚本、样例导出文件一同纳入版本管理。它是一份可读的契约，连接图书馆政策与具体实施。

同时看住题名与复本

Koha 以 MARC21 或 UNIMARC 保存书目描述信息，再把馆藏记录，也就是每件可流通的实体复本，附在相应的书目记录上。[3] 因此，一个显示漂亮的题名页也会掩盖迁移失败：小说确实存在，某家分馆的复本、条码、索书号、状态或采访备注却已经脱离记录，或出现重复。

当前的编目工作流有意把记录导入分为两个阶段。文件先暂存到记录池，由操作人员选择字符编码、格式、可选的 MARC 转换、匹配规则，以及遇到匹配项时的处理方式。审核这批记录之后，才会把它导入目录。对于 MARC21 书目文件，嵌入的馆藏数据可以放在 952 字段中传入。替换馆藏时，Koha 会优先以 itemnumber 匹配，其次才是条码。[3]

暂存区是一道审核关口，逐页点击通过只会把它降成进度界面。每批试迁移都应完成以下工作：

• 核对来源、暂存、匹配、新增、更新、忽略和拒绝的数量；
• 检查各种文字系统和各主要资料类型的记录，尤其关注题名中带变音符号的记录；
• 抽查只有一件复本的题名、拥有多件复本的题名，以及复本分布在不同分馆的题名；
• 查看匹配项的差异，并调查每一个预料之外的重复项；
• 确认旧系统内部编号没有误放到会被 Koha 视为现有 itemnumber 的位置；
• 直接扫描演练材料中的实体条码，电子表格里复制出来的值只作对照。

目标是逐类解释每一条警告的处置结果。舍弃一条过时备注可以是正确决定；一件没有归属馆、只被标记为“忽略”的馆藏，则意味着馆藏状态有所缺失。

读者迁移要从人出发，第二份 CSV 只是载体

读者导入面对的是另一类风险。Koha 的导入工具使用 CSV，并要求提供 cardnumber、surname，以及通过 BorrowerMandatoryField 配置的所有字段。覆盖现有记录时，传入 CSV 中的空白列会用空值覆盖原有内容；手册明确建议删除没有使用的空白列。[4] 这种行为值得单独设置回归测试样例，因为一次显示“成功”的读者更新依然会抹掉联系信息。

另建一份读者映射，并在其中规定最少数据原则。清点导出的每个字段，写明保留它的服务理由或法律依据，再指定负责人和保留期限。凭据处理优先采用新的流程，例如连接身份提供方或重置密码；可重复使用的密码不应随迁移文件顺手搬运。Koha 可以在导入时接收明文密码，再将其转换为 bcrypt 哈希值，[4] 但这项能力仍不足以让明文凭据文件成为合理的迁移默认选项。

历史记录也要接受同样的审视。工作人员会看重旧流通记录在报表或阅读咨询中的价值，读者则有充分理由期待自己的借阅记录不会变成一份永久档案。题图所示的 KohaCon 会议讨论了 AnonymousPatron、batch_anonymise.pl cron 任务和假名化，借此把报表价值与实名借阅历史分开。[8] 合适的保留期限取决于当地法律与政策；迁移团队要在复制历史记录之前写清这条界线，旧系统能够导出数据不能用来推定读者同意。

读者数据测试应由熟悉真实例外情况的人参与。两名家庭成员能否共用一个电子邮件地址，同时保持各自独立的账户？过期借书证是否仍为过期状态？只供工作人员查看的备注是否依旧受到限制？读者看到的消息是否正确，同时也看不到他人的历史记录？成功导入的记录旁边，也要保留删除与匿名化测试记录。只验证创建，覆盖的生命周期便只有一半。

把政策改写成一笔笔交易

Koha 解析流通规则时，会从图书馆、读者类别和馆藏类型的最具体组合开始，逐步转向范围更广的默认规则。CircControl 和 HomeOrHoldingBranch 还会决定规则选择采用哪一个图书馆上下文。[5] 这套优先顺序很有用，也会让接近完整的规则矩阵在空隙处出错：某个无人留意的组合落入默认规则，或者新类别出现时找不到可用的默认项。

把规则矩阵改写到流通台故事中。每个故事都要检查到期日、续借次数、预约资格、取书分馆、收费、退款、转运和工作人员的例外操作。随后每次只改变一个条件：读者所属分馆、馆藏所属分馆、当前柜台、馆藏类型或日历。相比阅读一张很宽的管理表，这种方法更容易显出优先级错误。

后台任务也应进入迁移演练。实施清单列出了预约队列、通知、罚款、遗失馆藏处理、暂停预约和自动续借等定期任务。[2] 数据迁移若脱离这些任务单独测试，下午 4 点显示正确的结果，到了夜间任务跑完后就会出错。在演练环境中，把电子邮件和短信转送到测试接收端，以安全方式推进时钟，执行实际任务，再检查由此产生的队列和账户状态。迁移测试的逾期通知绝对不能发给真实读者。

柜台外设也要纳入同一场演练。条码扫描器常以键盘方式工作，收据打印机、标签版式、RFID 或自助借还连接、支付流程和身份验证集成却各有账户与时序要求。Koha 的开放性让这些接合处可供检查；各类外设仍需逐一验证兼容性。为每项集成指定负责人、受支持的配置，以及一个贯穿全程的柜台服务故事。

演练最糟的一小时

设想周六最繁忙的一小时里 Koha 或网络突然中断，工作人员该怎么做。“我们有离线流通”仍只是一项能力声明，离完整的处置方案还有距离。当前手册注明，Koha 内置的网页版离线模块从 23.11 版起已弃用，Firefox 插件和 Windows 工具才是受支持的方式。离线交易可以作为 .koc 文件上传；使用多台工作站时，必须先合并记录，再按时间顺序处理。离线操作无法获知实时系统中的每一项事实：文档特别提醒，要留意归还馆藏上已经出现的预约，以及工具离线期间借书证到期的读者。[6]

图书馆可以根据实际情况选择受支持的离线工具、严格管理的纸质日志，或者暂时停止流通。分馆数量、中断频率、交易量和员工处理能力共同决定具体选择。无论采用哪一种，都要实际模拟。断开测试柜台，在两台工作站上借出并归还馆藏，同时在线修改一项预约，随后恢复服务并核对所有事件。演练结束时应产出一份责任清楚的异常清单；文件成功上传只能算过程记录。

恢复流程也要实测。完整的备份策略包括把数据库和应用配置恢复到隔离环境，由实际人员打开工作人员界面，再运行一遍流通台演练材料。因此，自托管 Koha 除了一台 Linux 服务器，还要有人负责升级、监控、备份、隐私、邮件投递、检索行为和事件响应。缺少这类能力的小型图书馆仍可通过支持服务商采用 Koha；开放源代码保留了运营方的选择权，运行维护本身依然要有人负责。

让最终切换保持短暂，并且全程可观察

匹兹堡大学 Barco Law Library 的一项独立案例研究很有参考价值，原因正在于它划定了清晰范围。一支专门的馆员团队使用 OpenOffice Calc、MarcEdit 和 Koha 等免费工具，在不到两个月内迁移了 48,000 多条记录。作者把这条路线定位为尤其适合小型图书馆的参考，时间范围也只属于这一特定案例。[7] 这个案例留下的长期启示是：只要工作过程可供检查，领域专家就能够掌握迁移逻辑。

最终切换时，只在提取最后一份权威数据并核对变更所需的时段冻结旧系统。记录导出的开始与结束时间、文件哈希值、数据行与记录数量、脚本版本、映射台账修订版，以及批准每一批数据的人员。保留旧系统的只读状态，直至数据保留期和回退期结束。双系统并行录入的阶段应尽量缩短：每天核对两个实时事实来源，等于每天再做一次迁移。

正式开馆前，用实际生产 URL、分馆上下文、员工角色、定时任务、打印机和测试消息接收端运行流通台演练材料。上线或暂停上线的决定应清楚可查：

• 每一种来源记录都已找到说明清楚的目标位置，或有据可查地排除在外；
• 书目记录与馆藏记录分别完成核对；
• 读者最少数据与历史记录保留决定已经批准；
• 有代表性的流通规则在不同分馆上下文中表现正确；
• 后台任务与通知已经实际运行；
• 值班人员亲自执行过中断与恢复流程；
• 即使迁移负责人不在旁指导，工作人员也能完成那些棘手的交易。

Koha 的发布历史表明这是一个活跃的项目；它的分阶段导入、可配置规则、权限和任务都是有力的工具。[1][3][5] 这些功能无法判定旧代码曾经表达什么、哪些读者历史应当保留，也无法替馆员决定怎样从断网的柜台恢复工作。这些决定要由机构自己完成，也是整套系统中属于机构的部分。

所以，先扫描那些棘手的书。它们把一项关于软件的迁移承诺变成公共服务演练，也让余下的不确定因素在尚有时间修正时显露出来。

来源

1. Koha Community，“Koha 26.05.00 发布”（2026 年 5 月 26 日）——大版本范围、维护活动与发布说明。
2. Koha Community，Koha Manual，“实施清单”——来源值到代码的映射、迁移检查、定时任务、员工练习、最终提取、URL 切换和备份。
3. Koha Community，Koha Manual，“编目”——书目与馆藏分离、MARC21 和 UNIMARC 支持、分阶段导入、匹配行为、952 字段中的馆藏数据，以及批次审核。
4. Koha Community，Koha Manual，“工具”——读者 CSV 要求、覆盖行为、必填字段和密码导入处理。
5. Koha Community，Koha Manual，“管理”——流通规则的优先顺序，以及 CircControl 与 HomeOrHoldingBranch 的影响。
6. Koha Community，Koha Manual，“流通”——当前离线工具状态、.koc 处理、交易顺序与离线状态的限制。
7. Christopher R. Todd，“Librarian as data migrator: a functional pathway from Millennium to Koha”，Digital Library Perspectives 34(1)，2018——独立的小型图书馆迁移案例研究。
8. Alex Buckley，“KohaCon 2023 Day Three Highlights”，Catalyst IT（2023 年 8 月 18 日）——关于读者数据保留的会议记录，以及 Aude Charillon 照片的来源页。