旧系统退役的关键环节在关停之后：团队能否稳定在新平台上完成日常工作。本文按“先定边界、再拆角色动作、用检查与例外审批维持采用、最后逐项验收”的顺序，给出可执行的步骤、角色动作对照表和完成检查表。范围限于替换后的采用与治理，新平台从零选型实施、迁移切换窗口内的数据迁移与验证不在本文展开。
要点总览（TL;DR）
- 旧系统退役从范围界定开始：列出系统、模块、接口、账号清单，确定数据保留与只读期限，并指定责任人签字确认。
- 退役后的采用任务要按角色拆成输入、操作、产出和完成标志，先启用新入口再关闭旧入口写入，避免两套入口并行的模糊期。
- 维持采用靠固定频率的使用检查和例外审批：检查关键流程是否在新平台留痕，例外写明用途与期限并到期复核。
- 退役完成以证据判定：旧系统访问与账号归零、关键流程在新平台闭环、例外清零或有结论、遗留问题与回退条件写明。
- 示例部分为演示情景，用于串联方法，不代表真实客户案例。
退役前先定边界：哪些系统关、哪些数据留、谁签字
退役工作的起点是范围界定。范围不清，后续的入口关闭、账号回收和数据处置都会反复。建议在正式停用前产出一份《旧系统退役范围与决策清单》，由业务负责人、IT负责人和合规或档案管理角色共同确认。
第一步是列退役对象清单。清单要细到可执行的程度，至少覆盖四类对象：
- 系统与模块：整体下线的系统，以及只停用部分模块的系统的具体模块名。
- 接口：与旧系统对接的内部接口和对外接口，标明调用方，避免关停后上游任务失败。
- 账号：个人账号、共享账号、服务账号、管理员账号，分别注明处置方式。
- 关联资产：定时任务、报表、邮件通知、单点登录配置等容易被遗漏的附属项。
第二步是确定数据保留与只读期限。做法是先按数据类别分组（业务记录、附件、日志、配置），再为每组确定保留时长、保留形态（归档库、只读实例、导出文件）和到期后的处置方式。期限的确定依据来自业务追溯需要、合同约定和行业合规要求；没有明确外部要求时，由业务负责人给出可解释的期限并记录理由，避免统一拍一个数字。
第三步是明确决策责任与签字确认。范围清单、数据保留方案、停用时间点三项分别指定责任人，签字确认后作为变更依据存档。签字的意义在于后续出现“这个接口还有人用”“这份数据还要查”的争议时，有明确的裁决入口，而不是每次重新讨论。
| 决策项 | 建议责任人 | 产出物 | 确认方式 |
|---|---|---|---|
| 退役对象清单 | 系统负责人 | 系统、模块、接口、账号清单 | 业务与IT双方签字 |
| 数据保留与只读期限 | 业务负责人＋合规/档案角色 | 分类保留方案 | 按类别逐项确认 |
| 停用时间点与入口关闭方式 | IT负责人 | 停用通知与操作记录 | 变更单审批 |
按角色拆解退役后的新平台操作步骤
范围确定后，采用任务要落到角色和动作上。只发一封“请改用新平台”的通知，团队往往不知道自己的哪一步工作要换地方做。有效做法是为每类角色写清输入、操作、产出和完成标志，形成角色动作对照表。
入口顺序上，先启用新入口并完成一轮可用性确认，再关闭旧入口的写入能力，最后按数据保留方案把旧系统转为只读。这样安排可以避免出现两套入口都能写入的模糊期，也避免旧入口先关、新入口还没准备好的空档。
| 角色 | 关键动作 | 输入 | 操作 | 产出 | 完成标志 |
|---|---|---|---|---|---|
| 研发 | 需求与任务承接、代码关联、提交评审 | 需求单、任务拆分 | 在新平台创建工作项并关联代码提交，发起评审 | 工作项状态更新、评审记录 | 本周任务全部在新平台有对应工作项 |
| 测试 | 用例管理与缺陷流转 | 版本计划、测试范围 | 在新平台维护用例、提交并跟踪缺陷 | 测试报告、缺陷闭环记录 | 缺陷从提交到关闭全程在新平台可查 |
| 项目管理 | 计划编排、进度跟踪、评审组织 | 里程碑、资源安排 | 在新平台排期、更新状态、发起评审 | 计划视图、评审结论 | 周报数据直接取自新平台 |
| 运维 | 变更与故障记录、发布配合 | 变更申请、告警信息 | 在新平台登记变更与故障，关联发布记录 | 变更单、故障复盘文档 | 变更与故障记录不再出现在旧系统 |
对照表写完后，逐角色做一次短时演练：让每个人用自己的真实任务在新平台走一遍完整流程，记录卡点。演练中暴露的权限缺失、字段不全、流程断点，应在旧入口关闭前修完，而不是留到全面推广后再补。
在承载这些动作时，ONES可用于把工作项、需求文档与评审记录放在同一处管理，使研发、测试和项目管理的动作有统一的记录位置，便于后续检查采用情况。具体配置方式需结合团队现有流程确定。
用使用检查与例外审批维持退役后的采用
旧入口关闭后，团队回流旧习惯的方式通常很隐蔽：把文件存在本地、在聊天工具里口头确认、用表格代替正式工作项。治理机制的作用是让这些偏离尽早可见，并有明确的处理路径。
使用检查建议按固定频率执行，检查项围绕“关键流程是否在新平台留下记录”设计：
- 本周新建工作项数量与活跃人数，对照团队名册看覆盖情况。
- 关键流程的闭环率，例如需求从提出到验收、缺陷从提交到关闭是否全程在新平台。
- 旧系统访问记录，包括账号登录和接口调用，确认是否仍有实际使用。
- 文档与附件的存放位置抽查，识别仍在使用本地或旧目录的情况。
检查频率可与团队节奏对齐，例如每周一次轻量检查、每月一次完整复盘。检查结果要反馈到流程调整：如果某类任务普遍绕开新平台，先判断是流程设计不适配还是习惯问题，前者调整配置或流程，后者进入辅导和提醒。
例外审批用于处理确有特殊需要的情况，例如历史数据查询、外部合作方仍依赖旧接口。例外申请应写明用途、期限和替代方案，由系统负责人审批并登记；到期自动复核，能关闭的及时关闭。例外清单本身也是退役进度的观察窗口，例外数量不下降，说明退役尚未真正完成。
一个研发团队的退役落地示例
以下为演示情景，用于串联前述方法，不代表真实客户案例。
某研发团队约四十人，旧系统同时承担需求、任务和缺陷管理，新平台已完成部署。退役范围确定为：旧系统全部模块停用，历史需求与缺陷数据保留只读两年，三个对外接口保留六个月，账号在停用后一周内回收。
第1周：完成范围清单与签字，发布停用通知，明确只读期限和例外申请入口。同期在新平台按角色配置权限，用两个真实迭代做演练，修完权限和字段问题。
第2周：启用新入口，旧系统停止写入、转为只读。研发和测试按对照表在新平台承接任务与缺陷，项目管理从新平台取周报数据。运维开始在新平台登记变更。
第3至4周：每周执行使用检查。发现两处问题：一是部分历史缺陷查询仍走旧系统，按例外审批登记并限定查询用途；二是某小组习惯在聊天工具里确认需求变更，检查后把变更确认改为在新平台工作项中留痕。
第5周起：例外清单逐项复核，能关闭的关闭；对外接口在保留期满后按计划下线。月度复盘确认关键流程闭环率稳定，旧系统访问量降至零。
退役完成的检查项与判定标准
退役是否结束，以可核验的证据判定，而不是以通知发出或系统下线的时间点判定。建议按下表逐项核对，全部满足才宣布完成。
| 检查项 | 判定标准 | 证据 |
|---|---|---|
| 旧系统访问归零 | 连续一个检查周期内无个人账号登录、无业务接口调用 | 访问日志、接口调用记录 |
| 账号回收 | 个人、共享、服务账号按清单完成停用或转移 | 账号处置记录 |
| 关键流程闭环 | 需求、任务、缺陷、变更等关键流程在新平台全程可查 | 流程实例与状态记录 |
| 数据保留落实 | 只读数据可按方案查询，到期处置方式已登记 | 保留方案与查询验证记录 |
| 例外清零或有结论 | 例外申请全部关闭，或保留项有明确期限与责任人 | 例外清单 |
| 遗留问题处理 | 遗留问题有处理结论，回退条件写明触发情形与决策人 | 问题清单与回退预案 |
回退条件需要提前写明：例如只读数据查询失败、关键流程在新平台无法闭环时，由谁在多长时间内决定是否临时恢复旧系统访问。回退预案的存在不意味着退役未完成，它让完成判定有兜底，也避免问题出现时临时争论。
常见问题
旧系统停用后，团队仍偶尔登录旧系统查数据，这种情况怎么处理？
先区分用途。如果是为了查询历史数据，把它纳入例外审批：写明查询用途、涉及的数据范围、使用期限和替代方案（如只读库或导出文件），由系统负责人审批并登记，到期复核。如果是为了继续办理日常业务，说明新平台对应流程存在断点或习惯未改，应回到角色动作对照表排查，修完流程再关闭这条路径。例外清单数量长期不下降，本身就是退役未完成的信号。
数据保留期限定多长合适？
没有统一数值。做法是按数据类别分组（业务记录、附件、日志、配置），分别确定保留时长、保留形态和到期处置方式。期限依据来自业务追溯需要、合同约定和行业合规要求；没有明确外部要求时，由业务负责人给出可解释的期限并记录理由。期限确定后写入退役决策清单，避免后续反复讨论。
新平台已经上线，但部分小组还在聊天工具里确认需求变更，怎么纠正？
先判断是流程不适配还是习惯问题。查看这类变更在新平台上是否有对应的轻量入口，如果提交变更需要填大量字段，团队自然会绕开，此时应简化配置；如果入口顺畅仍不使用，则通过使用检查把“变更确认是否在新平台留痕”列为检查项，在周度检查中点名反馈，并把变更确认动作纳入角色动作对照表的完成标志。
退役完成判定中，旧系统访问归零按什么口径核验？
建议同时看三类记录：个人账号登录日志、服务账号与接口调用记录、业务侧的实际使用反馈。判定标准可设为连续一个检查周期内无个人账号登录、无业务接口调用。口径要在退役前写进完成检查表，明确统计周期和数据来源，避免验收时对“归零”理解不一致。
回退预案会不会让退役判定变得模糊？
不会，前提是把回退条件写清楚。回退预案应写明触发情形（如只读数据查询失败、关键流程在新平台无法闭环）、决策人和决策时限。它的作用是让问题出现时有兜底路径，而不是保留旧系统日常使用的可能。完成判定仍以访问归零、流程闭环等证据为准，回退预案作为遗留问题处理的一部分登记在案。
