旧系统退役是切换完成后的独立阶段，处理的是旧系统如何停止新增、收敛访问、归档数据并完成合同与资产收尾。本文按“冻结新增—只读收敛—权限回收—数据归档—许可与合同收尾—下线与复盘”六步展开，给出每步的输入、动作、输出与完成标志，并附角色分工、示例安排表和完成检查清单。退役计划与各项证据可在ONES中作为工作项和文档统一跟踪，具体用法以实际部署与配置为准。
要点总览（TL;DR）
- 旧系统退役从切换完成后开始，按“冻结新增—只读收敛—权限回收—数据归档—许可与合同收尾—下线与复盘”六步推进，每步都有输入、动作、输出和完成标志。
- 退役前先编制范围清单，覆盖系统、数据、接口与集成、账号四类对象，写清归属人和当前用途，并由业务负责人签署确认。
- 权限回收要覆盖人员账号、集成凭据、API密钥、定时任务账号和单点登录配置，回收后做一次反向检查确认无残留访问。
- 数据归档的可读性验证要在旧系统仍可访问时完成，归档包、校验记录与保管人一并登记；下线后保留回退窗口，写明触发条件与决策人。
- 退役是否结束按完成检查清单逐项核对：无新增写入、凭据全部回收、归档验证通过、合同资产结清、用户收到下线通知、回退窗口结束。
退役前先定范围：哪些系统、数据和接口要处理
退役范围含糊，最常见的后果是执行到一半发现还有团队在用、还有接口在调用、还有数据没归档，只能暂停重来。范围清单要在冻结新增之前完成，并由业务负责人确认。清单按系统、数据、接口与集成、账号四类对象编制，每类写明归属人和当前用途。
系统对象清单至少包含：系统名称、业务归属部门、当前使用团队、当前用途、是否仍有对外服务。同一业务可能由多个子系统或插件组成，清单要写到实际需要下线的部署单元，避免只登记主系统而漏掉附属模块。
数据范围要区分三类：需要长期保留的历史业务数据；需要归档的附件、日志与操作记录；可以随系统一并丢弃的临时数据、缓存和测试数据。每类数据写明保留期限依据、存放位置和责任人。保留期限取决于行业合规要求与内部制度，需由数据负责人对照确认，本文不给出统一年限。
接口与集成清单要覆盖上下游系统调用、定时任务、单点登录配置和Webhook。每一项写明调用方、调用方式、频率和停用影响。定时任务和Webhook容易被遗漏，建议由系统管理员导出配置逐条核对，而不是凭记忆登记。
还要划清与迁移切换的分界：切换窗口内的数据迁移、验证和回滚属于切换管理；本文的退役安排从切换完成、新平台已承接业务之后开始。分界写进范围清单，可以避免退役阶段重复处理切换遗留问题，也避免切换团队与退役团队互相等待。
六步退役流程：从冻结新增到正式下线
六步按顺序推进，前一步的完成标志是后一步的启动条件。每一步都要指定负责人并留下证据，证据形式可以是公告、截图说明、导出记录或签字确认。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 一、冻结新增 | 退役范围清单 | 停止在旧系统创建新需求、任务、文档；发布冻结公告并明确生效时间 | 冻结公告 | 公告已送达全部使用团队，生效时间已过，旧系统无新增业务数据 |
| 二、只读收敛 | 冻结公告与生效确认 | 将旧系统降为只读，保留查询能力，关闭写入入口 | 只读状态确认 | 抽查账号只能查询、无法提交或修改 |
| 三、权限回收 | 账号与集成清单 | 停用离职与转岗账号，回收集成凭据、API密钥、定时任务账号和单点登录配置 | 账号回收记录 | 清单内账号与凭据全部处理，无残留有效访问 |
| 四、数据归档 | 数据保留策略 | 按策略导出历史数据、附件与日志，在旧系统仍可访问时完成可读性验证 | 归档包与校验记录 | 归档包可打开、抽样数据与源系统一致，校验记录留存 |
| 五、许可与合同收尾 | 订阅与资产台账 | 处理订阅终止或到期不续、合同结算、资产登记变更 | 合同结清凭证、资产变更记录 | 无待续费项，资产台账已更新 |
| 六、下线与复盘 | 前五步完成证据 | 关闭访问入口，保留回退窗口，窗口结束后记录复盘结论 | 下线通知、复盘记录 | 入口关闭，回退窗口结束且无触发，复盘结论归档 |
冻结新增是整条主线的起点。公告要写清冻结对象、生效时间、替代入口和例外申请方式，例外申请应有明确审批人，否则冻结容易被临时需求逐步突破。只读收敛阶段保留查询能力，是为了让业务方在归档完成前仍能查历史记录，减少因突然断访问产生的数据索取压力。
权限回收的范围比人员账号更广。集成凭据、API密钥、定时任务账号和单点登录配置往往由技术团队持有，业务侧看不到，需要系统管理员按接口清单逐项核对。回收完成后做一次反向检查：用清单外的视角扫描旧系统仍有效的访问路径，确认没有遗漏。
数据归档的可读性验证要在旧系统仍可访问时完成，这样发现问题还能回到源系统重新导出。验证方式包括打开归档包、抽样比对关键字段和附件、确认日志时间范围完整。归档完成后，归档包的存放位置、访问权限和保管人一并登记。
下线不等于立即删除。关闭访问入口后保留一段回退窗口，写明触发条件与决策人，例如归档数据缺失或关键业务查询无法满足时启动回退。窗口期内旧系统保持可恢复状态，窗口结束且无触发，才进入正式下线与复盘。
角色与交付物：谁在哪个节点签字确认
退役过程常见的卡点是无人拍板：业务方说“应该没人用了”，技术方不敢关，采购方不知道合同何时终止。按角色明确交付物和确认节点，可以把这些判断落到具体的人。
| 角色 | 主要交付物 | 确认节点 |
|---|---|---|
| 业务负责人 | 退役范围确认、业务不再依赖旧系统的书面意见 | 冻结新增前签署范围；下线前确认无业务阻塞 |
| 系统管理员 | 冻结执行记录、只读状态确认、账号与凭据回收记录、入口关闭记录 | 第二、三、六步完成时确认 |
| 数据负责人 | 数据保留策略、归档包、可读性校验记录 | 归档完成时确认，未通过不得进入下线 |
| 采购或财务 | 订阅终止或到期不续确认、合同结清凭证、资产台账变更 | 第五步完成时确认 |
| 项目协调人 | 退役计划、节点跟踪、证据汇总、下线通知与复盘记录 | 全程维护，下线前汇总全部证据 |
确认节点要与流程步骤对齐，避免出现“都口头同意了但没有记录”的情况。业务负责人的范围签署是后续所有动作的前提；数据负责人的校验确认是下线的硬性条件；采购或财务的结清确认决定退役能否在合同层面收尾。项目协调人不做业务判断，负责让每个节点的证据可查、可追溯。
退役计划、冻结公告、回收记录、归档校验记录和完成检查可以放在同一处跟踪，让每个节点对应到具体工作项和文档状态。在ONES中，这类退役任务可以按工作项建立、按文档留存证据，评审与交接记录随任务流转，便于下线前统一核对。具体的工作项类型、文档目录和权限设置按团队实际配置确定。
示例：一个研发管理旧系统退役的安排表
以下为演示情景：某团队用新平台替换了旧研发管理系统，切换已完成，业务已在新平台运行，现进入退役阶段。时间按周排布，读者应根据自身系统数量、数据量和合规要求调整周期。
| 周次 | 动作 | 负责人 | 证据材料 |
|---|---|---|---|
| 第1周 | 确认退役范围，登记系统、数据、接口、账号四类对象；业务负责人签署 | 项目协调人、业务负责人 | 退役范围清单与签署记录 |
| 第1周末 | 发布冻结公告，明确生效时间与例外审批人 | 项目协调人 | 冻结公告及送达记录 |
| 第2周 | 旧系统降为只读，抽查账号写入能力 | 系统管理员 | 只读状态确认与抽查说明 |
| 第2至3周 | 停用离职转岗账号，回收集成凭据、API密钥、定时任务账号与单点登录配置 | 系统管理员 | 账号回收记录与反向检查结果 |
| 第3至4周 | 按保留策略导出数据、附件与日志，完成可读性验证 | 数据负责人 | 归档包、抽样比对与校验记录 |
| 第4周 | 处理订阅终止、合同结算与资产台账变更 | 采购或财务 | 合同结清凭证、资产变更记录 |
| 第5周 | 发布下线通知，关闭访问入口，启动回退窗口 | 系统管理员、项目协调人 | 下线通知、入口关闭记录 |
| 第7周 | 回退窗口结束，确认无触发，记录复盘结论 | 项目协调人 | 窗口期检查记录、复盘文档 |
示例中的回退窗口设为两周，触发条件写为两条：归档数据抽样比对发现缺失，或业务方提出旧系统独有的历史查询需求且新平台无法满足。触发后由业务负责人与项目协调人共同决定是否恢复访问，恢复动作和原因记入同一份退役记录。窗口期内旧系统保持可恢复状态，但不重新开放写入。
这份安排表可以直接改用的部分是结构：对象清单、周次、动作、负责人、证据五列。团队规模较小、系统较简单时，可以把第1至2周合并；数据量大或涉及合规归档时，应延长归档与验证周期，并把校验记录做得更细。
完成检查：退役可以宣告结束的判断标准
退役是否结束，按下列条目逐项核对，全部满足才可宣告完成。任何一项未通过，都应保留旧系统的可恢复状态，直到补齐。
- 旧系统无新增数据写入，已处于只读状态或访问入口已关闭。
- 人员账号、集成凭据、API密钥、定时任务账号和单点登录配置全部回收，反向检查未发现残留有效访问。
- 归档数据完成可读性验证，抽样比对通过，校验记录已留存并可查。
- 订阅、合同与资产事项已结清，或已明确处置方式与责任人。
- 全部使用团队已收到下线通知，支持渠道已切换到新平台，并有人负责接收后续问题。
- 回退窗口已结束，窗口期内无回退触发；如有触发，恢复动作与原因已记录。
- 复盘结论已归档，包含遗留事项、责任人和计划完成时间。
这份清单同时是证据核对表：每一条都应能指向具体记录，而不是停留在口头确认。把清单与退役计划放在同一处跟踪，下线评审时逐项对照，可以避免“系统已经关了但合同还在续费”或“入口关了但归档没验证”这类收尾遗漏。退役完成后，旧系统的资产状态、数据保管责任和支持渠道一并更新到团队现有的管理记录中，退役阶段才算真正结束。
常见问题
冻结公告发出后，仍有团队提出临时需求要写入旧系统，怎么处理？
冻结公告里应提前写明例外申请方式和审批人，临时需求走例外审批，而不是默认放行。审批人评估该需求能否在新平台完成；确实只能在旧系统处理的，记录申请原因、处理时限和补录安排，处理完立即恢复只读状态。例外记录要并入退役证据，供下线评审时核对。例外频繁出现，说明冻结前的沟通或替代入口说明不到位，应补充通知而不是放宽冻结。
归档数据验证发现缺失，但旧系统访问入口已经关闭，还能补救吗？
这正是回退窗口的作用。窗口期内旧系统保持可恢复状态，触发条件中应包含“归档抽样比对发现缺失”这一条，由业务负责人与项目协调人共同决定是否恢复访问。恢复后重新导出缺失部分并再次验证，恢复动作和原因记入退役记录。若窗口已经结束才发现问题，只能依据归档包和备份寻找补救路径，因此可读性验证务必安排在旧系统仍可访问时完成，未通过不进入下线。
合同还没到期，旧系统可以先下线吗？
可以分两步处理：系统层面按流程完成冻结、只读、权限回收、归档和入口关闭；合同层面由采购或财务确认终止方式、结算金额和最后服务期限，到期不续或提前终止按合同条款执行。两者不必等同步完成，但退役宣告结束前，订阅、合同与资产事项要已结清或明确处置方式与责任人，避免出现系统已关、费用仍在续的情况。
团队规模小、旧系统只有一个，六步流程可以简化吗？
可以合并周期和文档形式，不建议删减步骤。小团队可把范围确认与冻结公告放在同一周完成，角色由同一人兼任多个，但业务确认、数据校验和合同结清这三类判断仍要留下记录。简化的是排期和会议，保留的是每步的完成标志与证据，这样下线评审时仍能逐项对照。
退役完成后，旧系统的历史数据由谁负责保管？
归档完成时就要登记归档包的存放位置、访问权限和保管人，退役结束后保管责任延续到数据负责人或其指定接手人。保留期限依据行业合规要求与内部制度确定，到期后的处置方式（继续保留、迁移或销毁）也应提前写明。资产台账、数据保管责任和支持渠道一并更新到团队现有管理记录中，退役阶段才算真正收尾。
