产品功能下线时，最需要确认的是：仍在使用它的人，接下来怎样完成原来的任务。隐藏菜单只解决入口问题，旧链接、历史数据、周期性使用者和自动化调用仍可能依赖旧功能。下线计划应把用户迁移、数据去向、旧入口与支持安排一起处理。
下线可以是彻底停止，也可以是旧功能被新版替代。两种情况下都应先说明决定范围：停止新增记录、停止修改、保留只读，还是整个服务不再提供。用户要采取的行动，以及团队需要完成的工作，会因此不同。
使用人数少，不代表可以直接关闭
功能是否继续投入，需要结合使用情况、维护成本、替代方案、产品方向与已经作出的承诺判断。最近一个月没有登录，可能只是这个功能按季度结算时才使用；少量客户也可能依赖它完成重要流程。下线证据应覆盖实际业务周期，避免仅凭短期活跃数字作决定。
可以先整理三类材料：谁在什么任务中使用，继续维护承担什么成本，新路径能否满足同一个任务。若问题只是入口难找、故障导致无法使用，低使用量并不能直接说明需求已经消失。上游判断可结合产品规划与持续反馈的方法。
GOV.UK的服务退役指南强调，停止服务时仍要考虑用户需要与过渡路径。商业产品可以借鉴这个思路，但不能把英国政府服务的具体政策、期限或操作要求直接当作自己的制度。
找出仍然依赖旧功能的人和系统
不要只列最近访问过旧页面的人。旧功能可能把结果交给别人，也可能被链接、定时任务或客服流程间接使用。迁移清单应覆盖这些关系，并注明证据来自使用记录、已确认客户反馈还是尚待核查的线索。
| 受影响对象 | 容易遗漏的依赖 | 需要确认 |
|---|---|---|
| 直接使用者 | 低频但固定周期的业务任务 | 下次使用时间与替代路径 |
| 查看历史结果的人 | 旧报告、分享链接、附件和书签 | 下线后在哪里读取同一结果 |
| 管理员与支持人员 | 代用户处理、培训与故障排查 | 新的操作说明与问题接收方式 |
| 自动化或集成使用者 | 定时导出、接口调用、嵌入页面 | 替换成本、负责人和迁移验证 |
| 内部下游团队 | 报表、对账或分析流程 | 数据口径和交付方式是否变化 |
每个对象都应对应一位能推进迁移的人。“已通知客户”不是完成状态；管理员看到了通知，并不等于实际使用者已经更改书签或自动任务。重要依赖应记录收到确认、开始迁移、验证通过等能核查的状态。
把停止新建、只读过渡与彻底关闭分开
有些功能可以直接切换，有些需要分阶段。以下以“旧版报表导出被新版报表替代”为教学情境说明，并不预设任何通用宽限天数。阶段日期要依据真实使用周期、迁移工作量及组织要求确认。
| 阶段 | 用户仍能做什么 | 进入下一阶段的条件 |
|---|---|---|
| 说明与迁移准备 | 继续使用旧版，了解并验证新版 | 替代路径可用，受影响对象与通知渠道明确 |
| 停止旧版新建 | 查看既有报告；新报告转到新版创建 | 关键使用者完成新建流程迁移，异常有负责人 |
| 历史结果只读 | 按约定查看或导出仍需保留的历史报告 | 需要的结果已妥善安排，旧入口去向已确认 |
| 关闭旧服务 | 从说明页或映射入口找到可用去向 | 接口、任务、支持与数据安排完成核对 |
日期与完成条件应同时存在。如果关键用户在预定关闭日前仍无法迁移，就需要明确决定延期、提供例外支持还是接受特定影响，不能默默把计划表改成“已完成”。反过来，例外也要有范围、责任和复查时间，不能让旧功能无限期留下无人维护的分支。
通知要让用户知道自己该做什么
“为了提供更好的体验，旧版即将下线”几乎没有行动信息。通知应明确哪些功能变化、何时影响当前用户、新路径在哪里、旧数据怎样处理，以及遇到问题找谁。若某些任务没有一对一替代，也要直接说明。
下面是可替换字段的通知框架。填写前应确认每个日期和处理方式，不要把尚在讨论的方案写成承诺。
标题：旧版［功能名］将于［日期］停止［新建/修改/服务］ 您受到的影响：［当前使用方式与变化］ 继续完成任务：请在［日期或业务节点］前使用［新入口］完成［动作］。 历史内容：［哪些内容保留、在哪里访问、是否需要主动导出］。 暂不支持的情况：［新版差异及可行替代］。 需要帮助：［明确支持入口、应提供的对象或任务信息］。 查看详细安排：［说明页］
通知渠道要对应实际触达路径：旧页面可以放持续说明，管理员可收到组织层面的提醒，集成使用者需要技术负责人能看到的迁移资料。团队也应核对帮助文档和客服说明，避免产品已经通知停用，支持人员仍在教用户创建旧版任务。
旧链接应该把人带到相关结果
菜单关闭后，用户仍可能打开收藏、分享和历史邮件里的地址。将所有旧链接跳到首页，通常无法解释发生了什么，也无法帮助用户找到原来的报告。更有用的是按入口类型安排去向。
- 旧功能首页：进入简短说明与新入口，交代为何不再提供旧操作。
- 具体历史报告：若存在一一对应结果，进入相应可访问页面；没有映射则明确说明查找或获取方式。
- 创建入口：停止新建后引导到新版，但先说明字段或规则变化，避免用户误以为只是换了皮肤。
- 接口与自动任务：由研发按约定提供清楚的停用反馈和迁移说明，不能只依赖网页提示。
跳转到新版后仍要检查访问权限。旧链接能够打开某份报告，不代表访问者自动拥有新版整个目录的权限；原有查看者也不应无故失去已承诺的访问路径。这些权限映射需要在迁移验证中逐项确认。
历史数据的去向，要能被用户理解
“数据已备份”并不能回答用户能否继续读取、导出或使用它。应区分在线只读、用户自行导出、迁移到新版和组织内部归档，并确认各自的访问方式、负责人和保留安排。期限应依据真实承诺与组织制度决定，本文不设统一时长。
对于报表迁移，还应注意新旧指标口径可能不同。旧报告是当时按旧规则生成的结果，不能在迁移后无说明地重新计算成新版数值。必要时保留报告生成时间、使用口径或版本标识，让后来查看的人知道两份结果为何不同。
迁移检查可以抽取代表性对象，核对数量、关键字段、附件和可访问性；涉及全部数据时，应由工程流程完成对应核对，不能用几张看起来正常的页面证明所有数据已迁移。发现差异后记录受影响范围、修复人和处理结论。
关闭前，留出一次“从旧入口开始”的走查
在墨刀白板中可将受影响对象、时间线、旧入口去向和未完成事项放在同一画布，给每项保留负责人及确认记录。需要检查用户是否理解迁移时，再用墨刀原型连接旧页面、停用说明、新版入口与历史结果页。
评审者可以分别扮演仍用旧功能的人、只查看报告的人和负责组织设置的管理员。从各自的旧链接出发，尝试完成原来的任务：能否知道变化，能否找到替代，能否取得历史结果。原型验证信息与路径，真实数据、权限和接口迁移仍需要系统层面的检查。
最终关闭记录应包括已迁移范围、仍存在的例外、已停用的自动任务、旧入口处理、支持安排及后续观察责任。关闭后的反馈也要有人接收；发现仍有关键任务无法完成时，团队需要能够定位对象并给出处理方案，而不是只回复“此功能已下线”。
