1. 课程导入与迁移全景
S/4HANA 数据迁移不是一次“把表拷过去”的技术动作，而是一项横跨业务、财务、主数据与技术平台的工程。它要解决的核心矛盾是：旧系统（ECC 或更早版本）中沉淀了十几年的历史数据、配置与未清业务，而 S/4HANA 用全新的数据模型（如 ACDOCA 通用日记账、业务伙伴 BP、物料账合并）重新组织了这些信息。因此迁移的本质是数据重构 + 业务切换，而非简单的数据搬运。
一、驱动因素：为什么要迁
企业启动迁移通常由四类因素叠加触发。第一是版本与维护压力：SAP 对 ECC 的主流维护在 2027 年结束，继续运行意味着安全补丁、合规支持和硬件兼容性逐步缺失。第二是业务价值诉求：S/4HANA 的实时合并、物料账与财务一体化、Fiori 体验、嵌入式分析，只有在数据完成新模型转换后才能生效。第三是数据质量倒逼：多年运行后主数据重复、客户与供应商多套编码、未清项堆积，迁移正好是一次强制清理的窗口。第四是合规与审计：数据保留年限、GDPR 类隐私要求、审计可追溯性，都要求迁移过程本身可记录、可回溯。
理解驱动因素的意义在于：它决定了迁移的范围与深度。如果只是为了“不停机升级”，可以走系统转换（System Conversion）；如果同时要重构流程、清理组织架构，则应选择新建实施（New Implementation）或选择性数据迁移（Selective Data Transition）。
二、典型场景：三种迁移路径
业界通常归纳为三条路径，其差异直接体现在工作量、风险和业务中断时间上。
| 路径 | 核心做法 | 适用情形 | 主要风险 |
|---|---|---|---|
| 系统转换 | 在原系统就地升级，保留全部数据与配置 | 流程稳定、历史数据必须全留 | 历史包袱重，清理空间小 |
| 新建实施 | 全新搭建 S/4HANA，只迁必要数据 | 流程重构、组织变革、多系统合并 | 周期长、业务中断大 |
| 选择性迁移 | 按公司代码/年度/对象选择性搬迁 | 集团分批上线、历史数据分层保留 | 边界划分与对账复杂 |
选择路径时，最实用的判断依据是三个问题：历史数据是否必须在线可查？现有流程是否要大幅调整？能否接受一次较长的业务停摆？三问的答案基本能锁定路径。
三、项目阶段划分：从准备到上线后验证
无论哪条路径，数据迁移工作都可归入六个阶段，且与整体项目节奏并行推进。
- 准备与范围界定：确定迁移对象清单（主数据、未清项、余额、历史凭证）、数据保留策略（在线/归档/不迁）、目标数据模型映射原则。
- 分析与映射：梳理源系统表结构与字段，建立“源字段 → 目标字段 → 转换规则”的映射表，识别需要合并、拆分或重新编码的对象（如客户/供应商合并为 BP）。
- 开发与单元测试：用迁移工具（LTMC/LTMOM、Migration Cockpit、BAPI、IDoc 或自开发程序）实现抽取、转换、加载逻辑，并对小样本数据验证。
- 集成测试与模拟：在接近生产数据量的环境中做多轮模拟迁移，重点验证余额一致性、未清项匹配、编号连续性。
- 切换与正式加载：在停机窗口内完成增量捕获、最终加载、余额结转与系统开账。
- 上线后验证与对账：核对总账余额、往来余额、库存数量与金额、资产原值与折旧，形成签字确认的对账报告。
需要强调的是，验证不是最后一步才做的事。从映射阶段起就应定义好每类数据的对账口径与容差，否则上线后无法判断“差异是迁移错误还是业务本身如此”。
四、关键角色与职责
迁移失败最常见的原因不是技术，而是职责不清。一个可运转的组织通常包含以下角色：
- 项目发起人/指导委员会：批准范围、预算与上线决策，裁决跨部门争议。
- 迁移负责人（Migration Lead）：统筹计划、资源、风险，对迁移整体结果负责。
- 数据架构师/建模专家：负责源到目标的模型映射，尤其是 ACDOCA、BP、物料账等新模型转换规则。
- 业务数据所有者（Data Owner）：财务、采购、销售、生产各自对本领域数据的完整性、准确性签字负责。
- 开发与工具工程师：实现抽取转换加载程序，处理性能与增量逻辑。
- 测试与对账人员：设计对账报表、执行模拟、记录差异并跟踪闭环。
- 业务用户与关键用户（Key User）：提供业务规则、验证样例数据、参与上线后确认。
五、全景关系图
下图把驱动因素、迁移路径、阶段与角色放在同一视图中，帮助建立整体认知：驱动因素决定路径选择，路径决定阶段重点，角色贯穿始终并对各阶段产出负责。
六、从全景到执行：先立规则，再动数据
把上述内容落到可执行层面，项目启动初期最该产出的不是程序，而是三份文件：迁移对象清单（迁什么、不迁什么、保留多久）、字段映射与转换规则表（源字段、目标字段、转换逻辑、责任人）、对账口径与容差说明（每类数据用什么报表核对、允许差异是多少、超差如何处理）。
以财务为例，一个常见的对账口径是：源系统某公司代码下所有未清客户应收余额合计，应等于迁移后 BP 客户未清项合计，容差设为 0.01 元（仅用于四舍五入）。若差异为 0，说明映射与加载正确；若差异为某几个客户，则需回到映射表检查是否发生了客户合并或信用范围重分配。库存同理：源系统物料库存数量与金额，应与目标系统物料账数量、金额一致，差异往往来自计量单位转换或批次拆分规则。