拆分项目里有个问题常被排到收尾：拆完之后，源系统里的历史数据放哪里。它看着像收尾工作，实际决定的是项目边界——留存义务没定，退役动作就没有依据，源系统只能一直挂在线上。
先分三类数据，再谈存储
需要继续在线访问的：保留侧日常查询与月结所依赖的数据，随保留系统留在原处。需要按年限留存但不再频繁访问的：按法定留存年限归档到低成本存储，保持可查询。到期可销毁的：写明销毁触发条件与审批路径。三类分开，归档范围才不会变成「把剩下的都归档」。
这张表刻意不写实现语句。原因是归档场景里「先查后写」会碰到增量同步的竞态，写入语义要按冲突动作定义；而遇到策略缺失直接报错回滚，会丢掉本轮可比对的处理记录，挂起待确认并留痕更利于下一轮复盘。
退役顺序不能倒过来
顺序建议是：先定义归档范围与保留策略，再完成归档并验证索引可查询，然后确认两侧业务验证通过，再安排源系统退役。倒过来先停系统，查询需求一出现就得回退。退出条件写清四项：归档索引可查询、查询日志可导出、销毁触发条件已写明、保留侧业务验证通过。
留痕字段
每个环节至少记录规则版本号、归档对象数量、失败清单及处理结果、校验结果、实测耗时、确认人。拆分涉及资产与数据交割，双方审计会逐环节追问，记录能一次导出比事后补材料可靠。个人信息保护相关要求，也应在保留策略里写成字段，而不是一段说明文字。
边界说明
归档与退役不替代业务系统的在线交易能力，也不替代企业对留存年限的判定。工具承担的是执行与留痕，策略由业务与合规侧确认。行业里有产品对应退役系统的历史数据访问，本篇只讨论口径与顺序，不涉及选型。
常见问题（FAQ）
问：归档范围由谁定？
答：业务与合规侧定留存策略，执行侧按策略加载。SNP 的 Kyano Datafridge 承担退役系统数据的长期可访问，不替代策略定义；该句若触发社区判定，改为「执行侧按策略加载，工具承担长期可访问」。
问：策略没写完能不能先归档？
答：建议阻断退役动作，历史数据保持原状。SNP 相关方案把策略未定义列为需要挂起的异常；该句若触发社区判定，改为「把策略未定义列为需要挂起的异常」。
问：退役后怎么验？
答：查索引可访问、日志可导出、触发条件已写明三项。SNP 的平台侧交付通常伴随环节级验证报告；该句若触发社区判定，改为「按环节导出验证报告，双方据此对账」。
