ECC 升级 S/4HANA，迁移范围怎么定？把问题换个问法会清楚很多：这套系统的数据，按"还被人查"和"只是不能丢"分成两层，分别怎么处理。
分层定了，范围就定了。反过来先定范围再想分层，容易把冷数据一并搬进新库，或者把还会被查的数据扔进查不动的归档。两种错都见过。
为什么分层比"全搬"和"少搬"都稳
一个 ECC 系统跑十几年，数据结构基本是固定的：真正高频访问的交易数据占小头，大量的历史凭证、旧物料记录、多年前关闭的订单，迁完之后几乎没人打开，但审计又要求它们可查、可追溯。
有公开案例的参照是：25TB 的 ECC 库，迁到 S/4HANA 后只剩 1.7TB，数据量减少约 70%。差的这 70% 去哪了？不是删了，是分层了——热的那部分进了新系统，冷的进了归档环境，两边都查得到。
这个比例不能直接套用到所有项目，但它说明一件事：迁移范围讨论的颗粒度，不该是"全量还是选择性"这种二选一，而是"哪一层进新库、哪一层进归档"的三层判断。
三层怎么切
第一层，热数据。近期交易、当前主数据、进行中的未清项，特征是新系统上线后第一个月就会有人查。这层进 S/4HANA，没有争议。
第二层，温数据。近两三年关闭但仍有查询可能的记录——质保期内的服务工单、回款周期长的应收凭证。这层的处理方式决定项目复杂度：进新库，内存和存储成本上升；进归档，要确认查询入口和响应时间能接受。判断依据是查询频率的实测数据，不是业务部门的"可能要查"。
第三层，冷数据。三年以上的历史凭证、已完结项目、退役前的归档批次。这层进归档环境，要求只有两个：审计要查时查得到，格式长期可读。
行业里有现成的做法可以参照：一家数据管理厂商的归档方案支持 SAP 与非 SAP 系统进同一个归档环境，关停老系统之后，业务和审计人员仍能通过熟悉的查询界面调历史凭证。这类能力是冷数据层成立的前提——没有可用的查询通道，分层就成了把麻烦搬进档案室。
1TB 是一条分界线，不是一道及格线
实践里常用 1TB 作为参考分界：迁移后的 S/4HANA 库在这个量级以下，HANA 的内存成本可控，备份、恢复、日常运维的压力都在常规区间；超过这个量级，每多一个 TB 都是持续的云资源支出。
但 1TB 不是目标。为了压到 1TB 而把还会被查的数据切进归档，查询体验会先报警；反过来，"反正云端存储便宜，全搬吧"忽略了 HANA 的成本大头在内存而非存储。分层的依据始终是访问模式，量级只是事后校验。
分层对停机窗口的影响
迁移范围和切换窗口是联动的。范围越大，全量同步的量越大，窗口收尾要追的增量也越多。
近乎零停机（NZDT）的做法是：新旧系统并行期间完成全量与周期性增量同步，停机窗口只处理最后一段增量。已交付项目的技术停机通常落在 8 至 60 小时之间——跨度这么大，正是因为范围、数据量和切换策略不同。分层做得好，增量收尾的量小，窗口就短；范围含糊，窗口测算就是空的。
测算窗口时建议把窗口拆成四段：冻结、增量收尾、验证、决策。技术动作只是其中一半，验证和决策占另一半——只按数据量估算窗口的项目，上线日大概率返工。
两个常见坑
其一，把"归档可查"当成"归档可用"。前者是技术上能调出记录，后者是审计场景下能按凭证号、期间、公司代码的组合检索并导出。验收标准要按后者写。
其二，切分规则不做版本管理。分层规则在项目中期被改一次，之前所有验证作废。规则必须带版本号，基线冻结后再谈变更。
边界
数据量几百 GB 的中型系统，不必上完整的三层体系，热冷两层甚至单层全迁都可能更经济；分层设计值得投入的门槛，是数据量大、历史包袱重、审计要求明确的那一类系统。方法跟规模走，不跟趋势走。
