最近在跟一个剥离项目的前期评估，把 SAP 系统拆分（Carve out）的方案选型资料整理了一遍，发出来大家讨论。先给我的核心结论： 源系统数据必须删除的场景，是方案选型里最容易被低估的变量。
背景：两种实现方式
选择性数据迁移（SNP 称之为 Bluefield® 方案）：依据既定的业务与组织规则，仅迁移目标环境所需的数据，整体迁移过程中支持数据转换以及组织架构调整。
复制后删除（Clone-and-delete）：完整复制源系统环境，再删除不属于目标系统的数据。原理简单，但如果项目还涉及大量架构重构或数据转换，除基础拆分外需要投入额外工作量。
为什么源端清除是个大变量
部分剥离场景受法规、合同条款或资产剥离协议约束，不仅要把数据导入新系统，还必须从源系统中删除对应数据。
用复制后删除的思路，删除是一个独立工程：识别删除范围、设计删除逻辑、执行删除、校验删除后源系统的完整性 ——每一环都有工作量。
用选择性迁移，定义迁移范围的业务规则同样可以用来识别源系统中需要删除的数据。一套规则，两端使用。
当然这只是理论上"占优"，实际项目里还要结合其他要素综合评估。
完整的七个要素，贴出来供对照
1. 数据量并非决定性因素：转型目标、数据质量要求、合规义务和停机容忍度往往更重要；即便大部分数据保留，目标环境需要重组、转换或变更数据范围时，选择性迁移仍可能更具优势。
2. 系统物理部署位置：同一数据中心两种方案都可行；跨数据中心/跨区域迁移（资产剥离、合资项目常见）是选择性迁移的优势区。
3. 是否同步完成多项转型：科目表调整、新增公司代码、公司间往来重构、主数据标准化，可纳入选择性迁移的同一流程。
4. 源系统是否也需要清除数据：如上所述。
5. 业务需求复杂程度：简单场景用传统 SAP 迁移和系统复制；涉及流程重设计、组织重构、上云、S/4HANA 迁移时，选择性迁移可整合为一个项目。
6. 可预测性要求：预先分析源数据、定义迁移规则，范围明确、过程可复现；复制删除方案规划受制于源系统规模与复杂度。
7. 停机容忍度：两方案都可适配短窗口；选择性迁移切换期传输量小，更利于严苛目标。实际停机取决于架构、数据量、复杂度和实施方案。
参照案例
SNP 公开资料：卡尔玛（Kalmar，货物装卸与搬运解决方案提供商）通过选择性数据迁移实现业务拆分；PTTEP（石油天然气行业）通过选择性数据拆分完成资产并购。
顺带一提：剥离项目也是梳理系统环境、消减技术债、推进 S/4HANA 升级、落地干净核心的机会，别只把它当搬数据。
抛两个问题
1. 大家做过的拆分项目里，源端清除义务是怎么落实的？有没有独立设计删除方案的？
2. 多项转型（拆分+上云+S/4HANA）合并一次切换，实际项目里 coordination 成本到底怎么样？欢迎有实战经验的同学聊聊。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/70050834/viewspace-3186542/ ，如需转载，请注明出处，否则将追究法律责任。
