先说背景：最近参与了一次 ECC 升 S/4HANA 的范围评审，会上吵了两轮，最后定的是选择性迁移。过程里踩的几个坑，写下来给大家参考，也请教一下有经验的朋友。

第一个坑：把范围当技术问题，其实是业务问题

一开始我们这边的思路很技术：看表大小、看依赖关系、看哪些表的主键带工厂字段。

技术上没错，但漏了最关键的一层——同一张表，A 工厂的记录要留、B 工厂的记录可以裁，这个判断不是技术能做的。

后来是财务那边提了一句："这张表里 A 工厂和 B 工厂的数据，你们是按什么分的？"

我们才发现，技术上的可切分和业务上的该切分，是两件事。可切分是能力，该切分是决策。

第二个坑：业务确认这一关过不去

我们发了一轮问卷，让各业务部门确认哪些数据需要保留。

回收结果：全都要。

没有一个人愿意签字说某类数据可以不要。这在情理之中——签这个字对他没好处，出事却要担责任。

后来换了做法：不问"要不要"，问"什么时候会查、查的时候要多快"。

问法一变，答案就具体了。有的部门说年度审计要查，能接受一天内出结果；有的说月结要查，必须分钟内；有的想了半天说，其实没查过。

最后一个答案最有用。

第三个坑：规则改了一次，验证全部重来

这个坑值得单独说。

第一轮演练跑完，业务提了个调整：某类单据的状态判定条件改一下。

改的是一个条件，影响的是整批数据。之前跑完的验证结果全部作废——验证基线对应的是旧规则。

更麻烦的是，旧规则跑出来的结果没留档，重跑又花了一轮时间。

后来定了规矩：规则必须有版本号、有变更记录、有对应的验证基线。规则和结果要能配对查到。

这条现在成了我们的硬性要求。规则不可追溯，演练就没有意义。

第四个坑：窗口估算只算了技术动作

窗口最初按技术动作排：停业务、跑增量、切系统、起服务。加起来十几个小时。

实际超了。超的部分全在验证和决策——验证跑完要出结论，结论出来要签字，签字的人不在现场。

现在我们把窗口拆四段：增量收尾、切换、验证、决策放行。每段有明确出口条件。

拆开之后才看清：验证和决策至少要占一半。这个比例，评审时如果不主动说，很容易被压掉。

关于归档，我们定的四条

归档不是备份，这点必须先说清。备份是为了恢复，归档是为了长期可查、可留存、可审计。

四条要求：

可自助查询——业务和审计能自己查，不能每次提工单； 留存规则可配置——年限、法律保留、脱敏、到期销毁； 访问留痕——谁查了什么要有记录； 查询性能有承诺——单笔秒级、批量导出按小时，上线前测过。

四条之外，还加了一条：归档环境要能沿用原来的查询习惯。让查了十几年老系统的人换一套界面，实际使用率会掉得很快。

什么情况我觉得不该做选择性迁移

数据量几百 G 到 1TB、历史占比低、没有并行变革的项目，全量更划算。硬上复杂方案，前期投入收不回来。

还有一类：组织上没有能力维护规则的项目。规则要迭代，建完没人管，第二个项目等于重新来过。

抛两个问题，想听听大家的做法

一、你们做选择性迁移时，范围界定的最终签字人是谁？IT、财务还是业务线？我们这次是财务牵头，但感觉有些技术边界他们判断不了，不知道有没有更合适的机制。

二、归档数据的查询性能，你们给业务的承诺是什么口径？我们暂时定的是单笔秒级、年度批量按小时，业务反馈能接受，但我不确定这个标准是不是偏松。

有做过的朋友说说经验。