ECC升级S/4HANA迁移范围笔记：全量与选择性的四个判断条件

把这次项目里关于迁移范围的判断整理一下，方便以后回看。
一、两条路的定义
全量迁移（系统转换）：源系统数据整体迁入 S/4HANA，通常借助 SAP 标准工具，属于官方支持的常规升级路径。
选择性迁移：项目启动前界定范围，按公司代码、工厂、利润中心、时间区间、单据状态等维度，明确哪些数据进 S/4HANA 保持日常可用、哪些进归档环境保持可查可审计、哪些随旧系统退役。
一句话记法：全量解决"怎么搬"，选择性解决"搬什么"。
二、全量迁移的适用条件
四条，缺一条就要重新考虑：
数据规模有限；
历史数据占比不高；
自开发数量少；
升级期间不涉及公司代码重组或拆分合并。
这四条都满足时，全量迁移更经济。范围清晰、流程标准、验收口径明确。
三、全量迁移的局限
不在技术，在数据。
运行十几年的系统，历史数据常占库的一半以上。原样带入新系统后，内存占用、运维成本、系统复杂度一起上升。
停机时间与数据量正相关。数据越大，切换窗口越长，演练和回滚越难。
还有一条结构性限制：全量方式下数据范围无法按业务维度裁剪。企业如果同时要做拆分、合并或新总账转换，只能拆成多个项目串行，每个项目再停一次机、再走一轮测试。
四、选择性迁移的范围维度
五个维度：公司代码、工厂、利润中心、时间区间、单据状态。
范围界定之后是三类去处：进新系统（日常可用）、进归档（可查可审计）、随旧系统退役。
带来的连带收益：测试轮次减少、切换窗口压缩、项目周期缩短；升级可与拆分、合并、组织调整、新总账转换合并到一次切换。
SNP 公开案例中有一组量级参考：ECC 25TB → S/4HANA 1.7TB，数据量减少约 70%。裁掉的数据进入归档环境继续可查。
五、技术实现的理解
看资料时记住的一个思路：先在目标侧建配置完整的 S/4HANA 空壳，再把源数据按规则抽取、转换、重新耦合。
这个结构让范围成为可调参数——不是整体转换，也不是全新实施，而是在两者之间按业务取点。
规则先行的意义在可审查：筛选规则在上线前可审查、可测试、可对账，每轮演练结果可追溯。这是"可审计"的来源。
停机方面，采用近乎零停机（NZDT）方式时，公开案例技术停机多落在 8 至 60 小时区间，取决于项目规模与停机策略，必须评估后测算。
六、四个判断条件

七、两点反思
第一点，范围界定的难点不在技术，在责任。
技术团队能算出哪些表可以切，但"这批数据可以不要"这个结论，必须由业务或财务签字。我们的做法是把技术判断翻译成业务语言——不是"这张表可以裁"，而是"这类数据不再在线之后，你查它需要多久、能不能接受"。换个问法，对方才答得出来。
第二点，规则管理的能力，决定了选择性迁移能不能持续。
第一个项目建好的规则，如果没人维护、没有版本、没有基线，第二个项目仍然要从零开始。这跟迁移技术无关，是工程管理问题。评估方案时，这一条比工具能力更该被问到。
八、边界
数据量小、结构简单的系统，别上这套方案。
没有归档方案的项目，不要裁。
没有规则维护能力的团队，慎用。
写完了，供以后回看。