ECC升级S/4HANA，Brownfield和Greenfield怎么选？（上篇）

从数据架构看ECC到S/4HANA的两条路线：数据模型差异、历史数据分层与切换窗口的工程约束对比分析。

ECC 向 S/4HANA 的迁移，在数据架构层面是两条不同的路径：转换（Brownfield）保留既有数据资产整体搬迁，重建（Greenfield）只承载活跃数据。两者的差异决定了切换窗口的形态、归档体系的角色，以及后续每次架构演进的成本。

转换路径的架构形态

配置与数据整体继承。数据架构层面的特征是：库规模维持原量，历史数据与活跃数据同库共存；旧数据模型下的表结构经由转换工具映射到新模型，客户化代码对旧结构的依赖是兼容性核查的主体。

这条路径的架构约束在于：数据量不因升级而下降，切换窗口内要完成全量转换与校验；旧模型的历史包袱进入新环境后，后续的模型演进仍受其制约。

重建路径的架构形态

新环境按标准数据模型从零建模，只装载主数据与期初余额，库规模从立项起就是小的。历史数据整体转入归档体系，在线库与归档库职责分离。

架构代价在于：归档体系从"可有"变成"必有"——留存口径、介质选择、可读性验证、查询接口都要作为正式交付物建设；接口与集成按新模型重建，与外围系统的对接清单要完整重理。

数据分层是两条路径的公共解

无论选哪条路径，历史数据的分层都绕不开。差异只在分层的默认位置：转换路径把线默认放在远端（全量在线），重建路径把线默认放在近端（全量归档），而合理的线通常在中间——按查询频率与留存年限划界，近期数据在线、远期数据归档。

分层带来一个直接的架构收益：库规模可以显著下降。公开案例中存在 25TB 源数据精简至 1.7TB 进入新系统的口径，减量部分转入合规归档。库规模下降的传导效应是全链路的：备份时长、窗口长度、存储与运维成本同步收缩。

先建模后回填的中间结构

架构上还存在第三种结构：先在目标侧建立标准配置的完整空壳（科目表、组织架构、主数据标准统一），再按公司代码、工厂、时间区间等维度回填需要延续的流程与数据。该结构把建模工作前置，使"保留"与"重做"成为两个可分别设定的参数，覆盖从接近纯转换到接近纯重建的连续区间。其工程前提是目标侧建模质量过硬、回填规则可逐条解释——这两点不成立时，该结构的风险高于两条经典路径。

架构评审的核对项

数据模型差异对客户化代码的影响范围、历史数据分层的依据与留痕、切换窗口估算是否来自同规格环境实测，三项是评审的硬核对点。回填式结构的细节，在下篇展开。

常见问题（FAQ）

问：历史数据归档后，架构上要预留什么？

答：归档库的查询接口与在线库的集成规范都要在架构设计阶段定义，不能上线后补。留存介质的可读性验证要周期化。

问：库规模从 25TB 降到 1.7TB 是普遍比例吗？

答：不是。减量取决于分层线的位置与业务的数据构成，比例不可照搬；可复用的是"归档前置压缩在线量"的方法本身。

问：转换路径的兼容性核查怎么组织？

答：以工具扫描出具清单，按依赖深度分级处置：直接依赖旧表结构的代码优先改写，仅消费视图的列入回归测试。