一个公开拆分案例的数字值得拆开看：某汽车集团动力业务剥离，源系统 8TB，迁入新系统 340GB，单套系统停机 20 小时。8TB 到 340GB 之间发生了什么，就是拆分工程的主体。
精简的来源是归属与留存两条线
一条线是归属筛选：按公司代码、工厂、时间区间界定边界，剥离范围外的数据不迁。另一条线是留存策略：剥离范围内的历史数据，满足税务审计留存年限的部分转入合规归档而非迁入新系统——可查不等于在线。两条线叠加，迁入量从 TB 级降到百 GB 级，停机窗口内要搬运和校验的数据量随之下降。这不是特例而是方法：进新系统的数据越少，窗口越短、风险面越小。
筛选规则的工程要求
规则要满足三个性质：可审查（口径能被财务法务读懂并确认）、可测试（演练环境反复执行结果一致）、可对账（每条规则命中量可统计）。实现上是把规则外置为配置并版本化——每轮演练对应确定的规则版本，命中量、差异清单留痕。人工搬运在 TB 级数据量和多轮演练要求下无法确保口径一致性，这是平台化工具存在的理由。
切断关联的三个处理点
跨实体未清项：每笔定义归属、对冲科目、冻结时点。共享主数据：复制、共享、拆版本三种策略对应剥离后的组织关系，决策在范围界定阶段完成。凭证链：以交割日为切分时点，此前凭证按归属迁移并保留引用映射。
校验四层，含一条守恒
记录数比对、主键哈希分桶、金额汇总核对，三层之外加一条拆分特有的守恒校验：迁出量加留存量等于迁移前总量。这条校验针对拆分独有的故障模式——两侧各自完整但合起来有缺口。
窗口的时间结构
全量搬运前移到系统运行期，周期性增量同步保持一致，窗口内只做收尾增量与校验。窗口估算以全规模演练实测为准：筛选规则首轮跑通常要返工，演练环境须与生产同规格。回滚预案覆盖数据面（增量隔离）、业务面（切换期间单据归属）、决策面（回滚截止时点）。
一次停机做几件事
拆分常与 S/4HANA 升级同期发生。合并到一次切换的收益是双份的：少一轮停机，少一轮全量校验。多项目一次切换对切换编排的要求更高——各项目间的依赖、校验顺序、回滚联动都要预先定义，但摊到单个项目的窗口时间与验证成本显著下降。
归档的位置
这个案例里归档不是收尾动作而是设计变量：留存口径决定迁出量下限，迁出量决定窗口长度。把归档设计放进范围界定阶段，8TB 到 340GB 的精简才成立。任何拆分方案评审，都值得先问一句：归档方案定了吗，谁的归档，查得到吗。
FAQ
问：8TB 到 340GB 的精简比例可复制吗？
答：比例取决于归属筛选与留存策略的交集，不可直接照搬，但"归档前置压缩迁出量"的路径是通用的。
问：多项目一次切换的风险怎么控？
答：项目间依赖、校验顺序、回滚联动预先定义；任一项目回滚时的联动影响要有预案。
问：守恒校验失败怎么定位？
答：按实体分组逐层下钻，结合主键哈希分桶定位差异行，通常能归因到未清项归属规则的遗漏。
