旧系统退役要按“先冻结、再降级、后关停”的顺序推进：先盘点旧系统承载的数据与流程，冻结新增写入；把仍在用的流程和未结事项迁到新平台并逐项核对；再按只读、限流、停写、下线逐级降级；最后撤销账号、权限、集成和订阅，保留归档与审计证据。本文从迁移切换完成后接手，讲清关什么、留什么、谁来做、做到什么程度可以正式关停。
要点总览（TL;DR）
- 退役按“冻结新增→核对清零→降级只读→撤销权限→下线归档”五阶段推进，上一阶段完成标志未达成不进入下一阶段。
- 退役前先列范围清单，把系统分为关停对象、只读保留对象和必须归档的数据三类，并记录关联集成，避免撤权时遗漏。
- 关停判定采用四项清零：无新增写入、无未结事项、无未迁移数据、无遗留账号，同时完成归档与审批签署。
- 业务负责人、平台管理员、数据负责人、合规/审计分别对清零清单、执行记录、归档校验和留存期限签字，关停审批单串联各方责任。
- 只读期内出现新的写入需求，说明核对有遗漏，应暂停降级、恢复处理，清零后重新走关停审批。
退役前先定边界：哪些要关、哪些要留
退役的第一步是列清单，把“关停对象、只读保留对象、必须归档的数据”分开标记。边界不清，后续冻结和降级就会反复：有人还在查历史记录，有人以为系统已经没人用。建议由平台管理员牵头，业务负责人逐条确认，形成一份旧系统退役范围清单。
清单至少记录四项信息：系统名、承载的业务流程、使用部门、关联集成。关联集成要写到具体对象，例如单点登录、消息通知、报表取数、工单同步，这些是撤权阶段最容易遗漏的部分。对每个系统再打三类标记：
- 关停对象：流程已全部迁走、无未结事项，按计划下线。
- 只读保留对象：仍有查询历史记录的需求，保留只读访问一段时间，到期再关停。
- 必须归档的数据：合同、审批记录、缺陷历史、审计日志等需要长期留存的数据，先导出归档再关停。
冻结口径要同步确定：从哪个时点起旧系统不再接受新增写入，谁有权批准例外。例外审批建议限定为“必须补录的历史事项”，并登记在案，避免冻结后仍持续产生新数据。冻结时点通常安排在迁移切换完成、新平台验证通过之后，与切换窗口分开管理——切换窗口内的数据迁移和验证由迁移工作负责，本文从切换完成后接手。
退役执行步骤：从冻结写入到正式关停
退役按五个阶段推进，每个阶段都有明确的输入、动作、输出和完成标志。阶段之间不跳步，上一阶段的完成标志未达成，不进入下一阶段。
| 阶段 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 一、冻结新增 | 退役范围清单、替代入口地址 | 关闭新增写入入口，发布停用公告，登记例外审批 | 冻结公告、例外审批记录 | 旧系统无新增数据产生 |
| 二、核对清零 | 未结事项清单、迁移对照表 | 逐项核对未结事项与未迁移数据，迁到新平台或确认关闭 | 核对记录、清零清单 | 无未结事项、无未迁移数据 |
| 三、降级只读 | 清零清单、只读访问名单 | 关闭写入功能，限制访问范围，观察使用情况 | 只读配置、访问名单 | 只读期内无写入需求、无异常反馈 |
| 四、撤销权限 | 关联集成清单、账号清单 | 撤销账号、权限、集成对接与订阅 | 撤权记录、集成下线确认 | 无遗留账号、无活跃集成 |
| 五、下线归档 | 归档数据、操作记录 | 停止服务，归档数据与操作日志，留存审计证据 | 归档包、关停记录 | 系统下线、归档可读可检索 |
阶段一：冻结新增。关闭旧系统的新建、编辑入口，同时公告停用时间和替代入口，公告要覆盖所有使用部门。冻结后仍收到的补录请求，走例外审批并登记，作为阶段二核对的输入。
阶段二：核对清零。把旧系统中未结的需求、工单、审批、缺陷逐条列出，与新平台的对应记录比对：已迁移的标记完成，未迁移的补迁或确认关闭。这一步的产出是一份逐项签字的清零清单，它是后续降级的前提。
阶段三：降级只读。关闭写入功能，把访问范围收缩到确需查询历史记录的人员，观察一段时间。只读期内如果出现新的写入需求，说明阶段二有遗漏，应暂停降级、回到核对环节处理。
阶段四：撤销权限。按清单撤销账号、角色权限、单点登录对接、消息通知、报表取数和订阅。集成类对象要逐个确认已停止调用，避免旧系统下线后接口报错影响其他系统。
阶段五：下线归档。停止服务，导出归档数据并校验完整性，保留操作记录和审批单据作为审计证据。归档完成后，旧系统才进入正式关停状态。
退役过程中的未结事项跟踪、关停审批和归档记录，可以在ONES中承载：把每条未结事项建成工作项，关联负责人和清零状态；关停审批单与验收记录作为文档挂在对应项目下，审批通过后状态流转到“已关停”。这样清零进度和审批证据在同一处可查，避免靠表格和邮件来回确认。
角色与交付物：谁签字、谁执行、谁验收
退役涉及四类角色，各自有明确的交付物和签署责任。责任悬空最常见的表现是“以为对方在跟”，所以每个交付物都要落到具体人和签字动作上。
| 角色 | 主要职责 | 交付物 | 签署责任 |
|---|---|---|---|
| 业务负责人 | 确认流程已迁走、未结事项清零 | 清零清单、流程迁移确认 | 签字确认清零结果 |
| 平台管理员 | 执行冻结、降级、撤权、下线 | 冻结公告、只读配置、撤权记录、关停记录 | 执行并记录各阶段动作 |
| 数据负责人 | 导出归档数据并校验完整性 | 归档包、完整性校验记录 | 签字确认归档可用 |
| 合规/审计 | 确认留存期限与证据齐全 | 留存期限确认、审计证据清单 | 签字确认合规 |
关停审批单建议由业务负责人发起，附清零清单和归档校验记录，平台管理员、数据负责人、合规/审计依次签署，最后由业务负责人确认关停。验收记录在关停后填写，记录实际下线时间、撤销的账号与集成数量、归档位置，作为本次退役的收尾凭证。留存期限因行业和数据类别而异，由合规/审计按适用要求确认，不在审批单中写统一期限。
示例：一个旧需求管理系统的退役过程
以下为演示情景，用于说明步骤如何落地，不代表真实项目数据。
背景。某团队原用一套旧需求管理系统承载需求提报与缺陷记录，已整体迁到新平台，切换窗口结束，进入退役阶段。旧系统仍保留登录入口，部分成员习惯上去查历史缺陷。
冻结写入与公告。平台管理员在周一关闭旧系统的新建需求与新建缺陷入口，在登录页和团队群发布公告：旧系统即日起停止新增，需求提报与缺陷记录统一到新平台，历史查询保留至下月底。冻结当周收到两条补录请求，均登记例外审批后由业务负责人在新平台补录。
核对与归档。业务负责人导出未结需求清单，共核对出若干条状态未更新的需求，逐条在新平台确认对应记录后标记关闭；历史缺陷由数据负责人整表导出，校验记录数与导出前一致，存入归档目录。清零清单经业务负责人签字。
只读期与关停。第二周旧系统降级为只读，访问范围收缩到需要查历史缺陷的成员，观察三周无新增写入需求、无异常反馈。随后平台管理员撤销账号与单点登录对接，确认消息通知和报表取数已停止调用，按审批单完成下线，归档包与操作记录一并留存。
关停后检查。撤权后复查账号列表为空、集成调用日志无新增请求，替代入口公告已覆盖全部使用部门，验收记录归档。整个过程的关键节点都留有签字记录，后续审计可直接调取。
完成检查：关停前必须逐项确认的清单
正式关停前，按下表逐项核对。任何一项未通过，都构成阻断条件，暂停降级或下线，处理完成后重新走审批。
| 检查项 | 确认内容 | 未通过时的处理 |
|---|---|---|
| 无新增写入 | 冻结后旧系统无新增数据，例外审批均已处理 | 延长冻结期，补录完成后重新核对 |
| 无未结事项 | 未结需求、工单、审批、缺陷均已迁移或关闭 | 暂停降级，回到核对清零环节 |
| 无未迁移数据 | 迁移对照表逐项核对完成 | 补迁数据并更新对照表 |
| 归档可用 | 归档数据可读、可检索，记录数与导出前一致 | 重新导出并校验，确认后再关停 |
| 留存期限明确 | 合规/审计已确认留存期限与证据清单 | 补充确认后再提交审批 |
| 账号与权限撤销 | 账号列表为空，角色权限已回收 | 逐项撤销并复查 |
| 集成与订阅撤销 | 单点登录、消息通知、报表取数、订阅均已停止 | 联系集成方确认下线，检查调用日志 |
| 替代入口已公告 | 公告覆盖全部使用部门，用户知晓新入口 | 补充公告并确认触达 |
出现未清事项时的回退方式要事先约定：只读期内发现遗漏，恢复写入或延长只读期，待清零后重新提交关停审批；已撤销的集成如需临时恢复，由平台管理员登记原因和恢复期限，处理完再次撤销。四项清零——无新增写入、无未结事项、无未迁移数据、无遗留账号——同时达成，并完成归档与审批签署，旧系统才可以正式关停。
常见问题
旧系统冻结写入后，仍有人要求补录历史数据，怎么处理？
把补录限定为例外审批：申请人说明补录原因和事项范围，由业务负责人批准后在新平台补录，并登记在例外审批记录中。冻结后产生的每条补录记录都作为核对清零阶段的输入，逐条确认处理结果。例外审批的口径建议只覆盖必须补录的历史事项，避免冻结后旧系统持续产生新数据，影响后续降级判断。
只读期要观察多久，期间发现遗漏怎么办？
只读期长度按历史查询的实际需求确定，以覆盖主要使用部门的查询高峰为宜，没有统一天数。观察期内如果出现新的写入需求或异常反馈，说明核对清零阶段有遗漏，应暂停降级，恢复写入或延长只读期，把遗漏事项迁到新平台或确认关闭，清零后重新提交关停审批。已撤销的集成如需临时恢复，由平台管理员登记原因和恢复期限，处理完再次撤销。
归档数据要保留多久，由谁决定？
留存期限因行业、数据类别和适用要求而异，由合规/审计角色按适用规定确认，并在关停审批单中记录确认结果，不设统一期限。数据负责人的交付物是归档包和完整性校验记录，需确认归档数据可读、可检索、记录数与导出前一致。归档可用和留存期限明确都是关停前的检查项，任一项未通过即构成阻断。
旧系统关联了单点登录和报表取数，下线时怎么避免影响其他系统？
在退役范围清单阶段就把关联集成写到具体对象，例如单点登录、消息通知、报表取数、工单同步。撤销权限阶段逐个确认集成已停止调用，检查调用日志无新增请求后再下线。旧系统下线后接口报错往往来自未清理的集成调用，因此集成下线确认要作为撤权阶段的完成标志之一，并在关停后复查调用日志。
关停审批单应该由谁发起、按什么顺序签署？
关停审批单建议由业务负责人发起，附清零清单和归档校验记录，平台管理员、数据负责人、合规/审计依次签署，最后由业务负责人确认关停。验收记录在关停后填写，记录实际下线时间、撤销的账号与集成数量、归档位置。签署顺序体现的是责任链：清零结果由业务确认，执行动作由平台管理员记录，归档可用由数据负责人签字，合规性由合规/审计签字。
