研发工具切换上线后，旧系统何时可以退役，取决于一组可核验的条件是否全部满足，而不是切换日期过了多久。本文面向负责切换收尾的团队负责人和平台管理员，给出退役判定清单、分步操作流程、角色分工与下线前检查表，帮助团队把“什么时候关”变成“满足什么条件才关”。
要点总览（TL;DR）
- 旧系统退役以条件判定为准：数据承接、使用闭环、依赖清理、回退关闭四个维度全部通过，才进入退役操作。
- 退役按“冻结写入—只读观察—正式下线—账号与许可回收”四步推进，每步设完成标志，未达标志不进入下一步。
- 观察期长短由残留依赖清理进度和业务闭环情况决定，不用固定天数代替判定。
- 平台负责人、业务代表、数据管理员、IT运维与安全合规分工明确，判定表、观察记录、下线确认单与回收清单集中留存。
- 下线前用检查表逐项核对数据完整性、用户与流程闭环、外部依赖清理和回退关闭签认，任何一项未通过都构成阻断。
退役判定：先定条件，再定日期
旧系统退役的起点是一张判定表，而不是一个日历日期。建议从数据承接、使用闭环、依赖清理、回退关闭四个维度逐项判定，每个维度写明判定口径、证据来源和责任人。四个维度全部通过，才具备进入退役操作的前提；任一维度未通过，退役流程停在判定阶段，先解决缺口。
| 判定维度 | 判定口径 | 需要的证据 | 未通过时的处置方向 |
|---|---|---|---|
| 数据承接 | 旧系统中全部在用项目、工作项、状态、字段、附件与历史记录已在新平台可查、可检索，且与旧系统抽样比对一致 | 迁移范围清单、抽样比对记录、归档位置说明 | 补迁遗漏范围，或对不再使用的历史数据明确归档方式与检索入口 |
| 使用闭环 | 活跃用户与关键角色（需求、开发、测试、项目管理）已在新平台完成至少一个完整业务周期，包括创建、流转、评审与关闭 | 新平台活跃用户清单、关键流程实例记录 | 针对未迁移的角色补培训与陪跑，暂缓冻结写入 |
| 依赖清理 | 旧系统不再被其他系统、脚本、报表、集成接口或外部团队引用；插件与定制场景已逐项确认替代方式或保留期限 | 依赖清单、集成点排查记录、插件替代评估结论 | 逐项安排替代或设定临时保留期限，期限到期前不进入下线 |
| 回退关闭 | 回退窗口已到期，业务方确认不再需要回退到旧系统，回退方案标记失效 | 回退窗口说明、业务方确认记录 | 延长回退窗口，重新约定关闭时间与确认人 |
观察期时长由条件决定，不用固定天数代替判定。依赖清理进度慢、关键角色尚未完成闭环、外部集成仍在调用旧系统，都会拉长观察期；反之，条件提前满足也不必为了凑天数而等待。判定不通过时，处置方向应落到具体动作和责任人，例如“某报表仍读取旧库，由数据管理员在两周内切换数据源”，而不是笼统地“继续观察”。
判定记录本身需要可追溯。团队可以把四个维度拆成检查项，以工作项形式分派给责任人，用状态标记通过与否，并把比对记录、依赖清单等材料挂在对应工作项或文档下。ONES 的项目与 Wiki 能力可以承载这类判定记录和归档材料，使判定过程在切换收尾阶段保持可查。
退役分步操作：冻结、观察、下线、回收
判定通过后，退役按“冻结写入—只读观察—正式下线—账号与许可回收”四步推进。每一步设完成标志，未达标志不进入下一步，避免操作节奏被日历推着走。
| 步骤 | 输入 | 主要动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 冻结写入 | 判定表全部通过、冻结通知模板 | 提前通知全体用户冻结时间与替代入口；关闭旧系统新建与编辑权限，保留查询 | 冻结通知、权限变更记录 | 旧系统无新增写入，用户已知悉新入口 |
| 只读观察 | 冻结后的旧系统、观察项清单 | 按周检查访问日志、集成调用、用户反馈，记录残留依赖 | 观察记录 | 连续观察期内无新增写入、无阻塞性依赖、无未处理反馈 |
| 正式下线 | 观察记录、下线确认单 | 停止旧系统服务，保留数据备份与归档入口，通知相关方 | 下线确认单、备份记录 | 服务停止且备份可恢复验证通过，相关方签认 |
| 账号与许可回收 | 下线确认单、账号与许可清单 | 按顺序回收账号、许可、集成配置与域名 | 回收清单 | 清单逐项勾销，无遗留有效账号或指向旧系统的配置 |
冻结写入的触发条件是判定表全部通过，通知方式应覆盖全体用户和相关外部团队，并说明查询入口与问题反馈渠道。只读观察期的观察项包括：是否仍有用户尝试写入、是否有系统或脚本调用旧接口、是否有报表依赖旧数据、是否有用户反馈找不到历史内容。退出标准是观察期内无新增写入、无阻塞性依赖、反馈均已闭环。
正式下线前需完成备份与恢复验证，确认归档数据可检索，再停止服务。回收顺序建议为：先回收账号与访问权限，再回收许可，然后清理集成配置与定时任务，最后处理域名与证书。域名和证书放在最后，是因为在观察与下线阶段它们仍可能被用于访问归档或排查问题。
角色分工与各阶段交付物
退役过程涉及多个角色，责任悬空是常见风险。建议在判定阶段就明确每个角色的职责和每阶段的交付物，并由平台负责人统一汇总签认。
| 角色 | 主要职责 | 对应阶段 | 交付物 |
|---|---|---|---|
| 平台负责人 | 组织判定、汇总结论、发起冻结与下线、对外通知 | 全流程 | 判定表汇总、冻结通知、下线确认单 |
| 业务代表 | 确认关键流程闭环、确认不再需要回退 | 判定、回退关闭 | 流程闭环确认、回退关闭确认 |
| 数据管理员 | 核对数据承接完整性、组织归档与检索验证 | 判定、下线 | 抽样比对记录、归档与检索验证记录 |
| IT运维 | 执行冻结、观察监控、停服、账号与许可回收 | 冻结、观察、下线、回收 | 权限变更记录、观察记录、回收清单 |
| 安全合规 | 审核数据保留要求、确认回收无遗留访问入口 | 判定、回收 | 合规审核意见、回收复核记录 |
签认路径建议为：各维度责任人提交证据，平台负责人汇总判定表，业务代表与安全合规复核，最终由平台负责人签认进入冻结。观察期发现残留依赖时，由发现方登记问题、指定处理人，处理完成后更新观察记录；若依赖无法在约定时间内清理，升级到平台负责人决定延长观察期或调整下线范围。
这些交付物应集中留存，便于后续审计追溯。团队可以用工作项管理判定项与观察问题的处理状态，用文档承载判定表、通知与确认单，使每个阶段的产出都有明确归属和版本记录。
示例：一个研发团队的退役节奏
以下为演示情景，用于说明条件驱动的退役节奏，不代表任何真实客户的实施结果。
某研发团队将项目管理与知识库从旧系统切换到新平台，切换上线后两个月开始评估旧系统退役。约束条件有三：旧系统仍被一个周报脚本调用；部分测试人员尚未在新平台走完缺陷闭环；历史附件需要保留三年备查。
按条件逐项判定：数据承接维度，项目、工作项与附件已迁移，抽样比对发现两个已归档项目的附件缺失，由数据管理员补迁后通过；使用闭环维度，测试角色未完成闭环，判定不通过，安排陪跑两周后补验通过；依赖清理维度，周报脚本仍调用旧接口，由数据管理员将数据源切换至新平台后通过；回退关闭维度，业务代表确认回退窗口已到期，签认关闭。
判定全部通过后进入冻结写入，通知全体用户并保留查询权限。观察期第二周，运维发现一个外部团队的报表仍在读取旧库，登记为残留依赖，指定该团队在一周内切换数据源；切换完成后更新观察记录。观察期结束，无新增写入、无阻塞性依赖，进入正式下线：完成备份与恢复验证后停止服务，随后按账号、许可、集成配置、域名的顺序回收，回收清单逐项勾销，平台负责人签认结项。
完成检查：下线前必须确认的事项
正式下线前，用一张检查表逐项核对，任何一项未通过都构成阻断，不进入停服操作。
| 检查类别 | 检查项 | 通过标准 |
|---|---|---|
| 数据与附件 | 在用数据、附件、历史记录是否完整迁移并可检索 | 抽样比对一致，归档位置与检索方式已记录 |
| 数据与附件 | 备份是否完成并验证可恢复 | 恢复验证通过，备份保留期限符合要求 |
| 用户与流程 | 活跃用户是否已全部在新平台开展业务 | 活跃用户清单核对无遗漏，关键角色完成闭环 |
| 用户与流程 | 关键流程是否在新平台完整跑通 | 需求、开发、测试、发布等关键流程有实例记录 |
| 外部依赖 | 集成接口、脚本、报表是否已切换或停用 | 依赖清单逐项关闭，无调用旧系统的配置 |
| 外部依赖 | 外部团队与供应商是否已知悉下线 | 通知记录完整，无待确认方 |
| 回退与签认 | 回退方案是否已确认失效 | 业务代表签认不再回退，回退窗口关闭 |
| 回退与签认 | 下线确认单是否完成签认 | 平台负责人、业务代表、安全合规均已签认 |
检查表通过后执行停服，并在停服后复核账号与许可回收情况，确认没有遗留的有效访问入口。至此，旧系统完成退役，判定表、观察记录、下线确认单与回收清单共同构成完整的退役记录。
常见问题
旧系统已经冻结写入，但还有外部团队偶尔查询旧数据，可以正式下线吗？
不建议直接下线。冻结写入只解决了新增数据的问题，查询类依赖同样属于依赖清理维度。处理方式是先确认这些查询是否可以通过新平台或归档数据满足：能切换的，约定切换完成时间并登记处理人；确实需要保留查询的，明确保留期限和访问方式，期限到期前不进入正式下线。观察记录中应把这类调用逐项登记，直到无阻塞性依赖再推进。
观察期设多长比较合适？有没有推荐天数？
观察期时长由条件决定，不用固定天数代替判定。判断依据是观察期内是否出现新增写入尝试、是否有系统或脚本调用旧接口、是否有报表依赖旧数据、用户反馈是否已闭环。依赖清理快、关键角色已完成业务闭环的团队，观察期可以相应缩短；仍有外部集成在调用旧系统的，应延长观察期，直到依赖逐项关闭。
旧系统里的历史数据需要保留多久，归档后还要保证可检索吗？
保留期限取决于企业自身的合规要求和业务需要，应由安全合规角色在判定阶段给出结论，并写入归档说明。归档后仍需保证可检索，否则后续审计、问题追溯或历史项目查阅会缺少依据。下线前的检查表要求抽样比对一致、归档位置与检索方式已记录，备份完成并验证可恢复。
退役过程中发现某个插件或定制功能在新平台没有对应能力，怎么处理？
这类情况应在依赖清理阶段逐项评估，不能假设新旧系统功能一一对应。处理方向有两个：一是确认该功能是否仍被实际使用，不再使用的直接停用并记录；二是仍在使用且暂无替代方式的，明确临时保留期限和责任人，期限到期前不进入正式下线。评估结论应挂到对应判定项下，作为依赖清理维度的证据。
旧系统下线后，账号和许可应该按什么顺序回收？
建议先回收账号与访问权限，再回收许可，然后清理集成配置与定时任务，最后处理域名与证书。域名和证书放在最后，是因为在观察与下线阶段它们仍可能被用于访问归档数据或排查问题。回收完成后逐项勾销回收清单，并由安全合规复核确认没有遗留的有效访问入口。
