最近好几个项目都跟 ECC 6.0 升 S/4HANA 有关，把路径整理一下，顺便抛几个问题听听大家的做法。

先给结论：这事不是版本更新，是四件性质不同的事叠一起 ——数据库要换、数据模型要变、定制代码要改、数据范围要重新界定。难点不在某个技术步骤，在几件事要在同一个项目里协调完成。

一、数据库这关怎么过

ECC 6.0 能跑 Oracle、DB2、SQL Server 好几种库，S/4HANA 只认 HANA。不在 HANA 上的，两条路：

先迁 HANA 形成中间状态，风险分两段消化；或者用 SUM 的 DMO，一次维护窗口把数据库迁移和 S/4HANA 转换一起做，总工期短但单次窗口长。

两条路我都见过项目走，没有绝对优劣，看窗口约束和风险偏好。你们倾向哪条？

二、就绪检查是所有排期的地基

第一步就绪检查要产出一份清单：系统版本与增强包级别、数据库类型与容量、简化项影响范围、自开发对象数量与风险等级、Add-on 兼容性、接口清单。

工具是现成的：SAP Readiness Check 加简化项检查。

我的体会：这份清单的准确性直接决定排期是否可信。清单里简化项范围和自开发对象数量不准，后面的排期全是自欺欺人。

三、五步流程

就绪检查之后：目标架构与方案设计（目标版本、部署形态 ——本地、私有云、RISE with SAP 或公有云、数据范围、迁移方式）→ 前置转换（Unicode、新总账、新资产会计、主数据口径统一、历史数据瘦身归档）→ 转换与迁移执行（按规则转换，上线前多轮全规模演练与数据对账）→ 切换与上线后（运行期全量与周期性增量同步、停机窗口只处理最后一段增量、上线后数据校验、稳定期后旧系统退役归档）。

前置转换做得越充分，切换越简单，这条我百分百同意。

演练次数是项目质量最直观的指标 ——只做一轮的项目，问题集中出现在切换当天。这条大家应该都有体会。

四、四个容易低估的坑

1. 新资产会计。S/4HANA 不支持传统资产会计，必须转换前完成迁移，涉及历史数据重新组织。工作量经常被低估，我见过的项目里这几乎是重灾区。

2. 业务伙伴（BP）。客户和供应商主数据统一到 BP 模型，维护方式、权限、接口都要动。

3. 自开发代码。Native SQL、直接访问池表簇表、依赖失效对象的程序，用 ATC 批量识别，但识别完的改造排期经常不够。

4. 报表与输出。模型变了，基于原表结构的报表要重写或替换；输出管理从 NAST 向 BRF+ 过渡也要评估。

这些在就绪检查阶段就能识别出来，关键是预留工作量，不是留到切换前。同意的扣 1。

五、停机窗口

传统方式窗口按天算。近零停机的思路是前移：运行期间全量加周期性增量同步，窗口只留最后一段增量，压到小时级。

参照：巴西化肥企业 Cibra，拆分与升级同步推进，SNP 支持下 5TB 迁移 26 小时完成，比计划快约 40%，业务没中断。

SNP 的 BLUEFIELD 方案由 Kyano 平台承接：分析摸依赖和数据构成、转换按时间切片和组织单元与单据状态定范围、切换近零停机、验证自动对账出可审计报告、上线后旧系统归档退役。数据量大、窗口紧、拆分合并一起做的项目，比全盘转换好控。

抛两个问题

1. 简化项里的强制项，你们一般怎么排期？是跟转换一起做，还是前置转换阶段就消化掉？

2. BP 转换踩过坑的兄弟说说，主数据口径统一这块，业务配合度怎么拉起来的？

我先说我们的：强制项放前置转换阶段消化，切换窗口里不做任何"第一次"的事。对不对大家评判。