上篇说到，选择性迁移不是把多余数据删掉了事，而是先想清楚什么该带走、什么该归档、归档之后还能不能查。道理并不难懂，但真到了项目上，让人睡不着的还是那句话：万一数据丢了怎么办？

这个担心值得认真对待。

一 、数据丢失为何成为高敏感议题

多数企业的SAP系统已经运行了二十年甚至更久，里面装的不是"历史记录"四个字那么简单，而是支撑日常运营和长期决策的全量业务数据。

为何这类数据至关重要

时间越久，这些数据越难替代。

合规是重要的一条，法律、审计、税务，哪一个查下来都要能拿出东西，而且要求的是"随时能拿出来"，不是"理论上存在"。财务和运营报表也一样，跨周期、多时段的对比分析，靠的就是这些年的沉淀。业务用户看经营表现、看趋势走向，需要的是对比的基准线；管理层做决策，看的不只是当下的实时数据，更是完整的业务背景，三年前那次价格调整带来了什么后果，某个客户的历史履约情况如何，这些答案都在旧数据里。

尽早达成清晰认知

正因为如此，"全搬过去更保险"成了不少人的第一反应：把所有数据留在能正常使用的新系统里，不确定风险不就没了？

实际落地的时候，这种做法往往适得其反。它把简化系统环境的机会一并挡在了门外，还给S/4HANA塞进了大量用不上的复杂性——数据库更大、备份更慢、测试轮次更长、每次升级更笨重。省下的是一份心安，付出的是往后好几年的运维成本。

二 、当数据丢失成为现实风险时

这里要分清一件事：数据丢失不是选择性迁移的必然结果，而是迁移方案没设计好的结果。

范围界定不清、各方协同不足、缺少有效校验，这三样只要占一样，都可能出事。规划得周密，选择性迁移会形成一套规范有序的数据架构；规划得潦草，哪怕是全量迁移，一样会出断层。

数据缺失为何产生？

通常就这么几种情形：范围划得太窄，或者压根没征求业务团队的意见，IT自己拍脑袋定了取舍；没考虑合规要求，把历史数据或已结清数据直接剔掉了；自定义对象、非标准的数据表被漏掉——这类东西往往只有个别老员工清楚；数据校验、对账和文档记录做得不扎实，出了问题无从追溯。

共同点是：这些问题基本都在系统上线之后才暴露。到那时再回头补，代价就不是迁移阶段能比的了。所以根本原因从来不是选择性迁移这个方法本身，而是缺了一套界定清晰、管控到位的迁移方案。

三 、合理实施选择性数据迁移的价值

选择性数据迁移（SDT）的出发点，是强化管控而不是弱化管控。规划得当的话，它能在项目前、中、后给整个数据管理过程搭出一个清晰的框架。

真正做对的项目，靠的都是几件看起来朴素的事。

1. 业务驱动的数据范围界定

起点是业务需求，不是技术标准。项目一开始就要把数据分清楚：哪些是S/4HANA里必须日常可用的业务数据，哪些是用于报表和对比分析的历史数据，哪些是合规要求长期可查的监管数据。三类数据的处理方式并不相同，混在一起谈，就一定会出问题。

2. 透明化的数据筛选规则

哪些数据迁移、为什么迁移，规则必须明确——按时间切片、按组织单元、按单据状态，都可以，但逻辑得说得清、写得下。好处是这些规则能在上线之前就完成审查、测试和校验，而不是等切换那天才知道结果。

3. 数据校验与核对

迁移过来的数据是不是完整、一致、可审计，需要机制来保证，而且要IT和业务双方共同核验。Salling Group的项目是个典型：海量数据要在紧张的停机窗口内完成迁移，靠的就是严密的数据校验与核对流程，最终做到全程可审计、数据完整性不打折扣。

4. 迁移与留存策略相分离

不是所有数据都得在S/4HANA里在线跑。历史数据完全可以放在生产系统之外，既满足查询和合规要求，又随时能调出来。IBM的做法就是这样——核心数据迁移到S/4HANA，其余数据不必跟着进新系统，全球业务的复杂度因此没有被一并放大，系统照样完成了现代化升级。

四 、结语

选择性数据迁移给企业提供的是一条可落地的路：主动界定数据范围、把筛选规则讲透明、把"要继续跑的数据"和"只要能查到的数据"分开对待。做到这几点，新系统会更好运维、更好管控，也更容易在往后的迭代中持续演进。

至于"会不会丢数据"这个问题，答案不在方法里，在方案里。