听会笔记：数据全生命周期管理，从S/4HANA升级讲到系统退役

10月29日在上海开的CSUA 2026年度会员大会，没能去现场，会后翻了分享材料。其中SNP的专场演讲《数据全生命周期管理：从升级到退役，释放每份数据的价值》信息密度不错，按自己的理解整理成笔记。
一、框架本身：把两端接起来
平时接触的资料，讲迁移的多，讲退役的少。这场演讲把两者放进同一个框架：数据的生命周期从分析洞察开始，经迁移与现代化，到监控、验证、测试、归档、退役结束。平台按此分三大模块——Foundation（分析）、Move（迁移）、Manage（管护）。
这个框架的合理之处在于承认了一个事实：数据的合规价值比系统的生命周期长。系统七八年换一代，数据要留十年以上，管理对象应该是数据，而不是承载它的系统。
二、选择性迁移的范围逻辑
方法论核心是"解耦"：数据迁移与系统现代化分开做。迁移范围不由系统边界决定，由业务与合规需要决定——需要的进新系统，其余转归档。
笔记记一个推论：范围是所有后续测算的分母。迁移量、验证面、窗口时长都从范围推出来。范围靠拍脑袋，后面的数字全部失真。
三、验证：一个口径的坑
演讲案例里"8.7TB选择性拆分、技术停机30小时内"这个数字，特意强调了口径是技术停机——纯迁移占用窗口，不含验证与决策环节。
这是一个容易踩的坑：很多方案报的时长口径不清，评审时以为是总停机，实际是技术停机，真到切换那天窗口根本不够。以后看任何迁移方案，第一句先问：这个时长含不含验证。
另外演讲提到验证环节的自动化与AI辅助（AI驱动的验证应用计划2026年Q4发布）。方向合理——验证里规则化的比对核对最适合自动化，人力应该留给异常判断。
四、退役的四个要素
道达尔能源的案例：17套ECC退役，100TB数据上云，退役后审计照常查询。拆解一下，退役方案要有的四个要素：

1. 冷存储＋独立可用的检索索引（数据冷了，查询不冷）；
2. 保留规则、法律保留、脱敏、到期销毁四项策略化；
3. 查询语义沿用原系统习惯，降低审计人员成本；
4. 全程留痕，可证明数据未被改动。
   五、两点反思
   反思一：我们做项目规划时，"历史数据怎么办"经常是范围说明书里的一句带过。听完这场，觉得它值得单独立项、单独预算——至少和升级方案一起评审。
   反思二：框架不是万能的。系统少、数据量小的公司，分层归档加对账就够了，别为方法论而方法论。工具跟规模走，需求跟合规走，这个先后顺序不能反。