全球有55000家公司需要迁移到SAP S/4HANA——对大多数公司来说，迁移是具大的进步。 但是项目到底有多复杂，在迁移过程中应该考虑哪些方面？ 在这篇文章中将带给您答案。
为什么企业需要迁移到S/4 HANA?
随时数字化市场的需求竞争日益激烈，传统ERP已经无法满足实时变化更新的数字化市场，紧跟时代变革开启智慧企业商业模式，确保您的企业实现卓越运营。智慧企业始于数字化核心，数据整合、核心流程自动化，以及持续优化的产品与服务，全都依赖智慧ERP。SAP S/4HANA是IT体系结构的数字核心，它可以支持公司应对挑战以及灵活、快速、信息时代的数字化机遇，使业务流程更加精益安全。SAP S4 HANA不仅仅是旧SAP企业软件的继承者，他的迁移远比单纯的软件升级复杂，公司面临着一场全面的转型升级，并将具有巨大的创新和优化潜力。
公司如何将数据迁移到S/4 HANA?
许多决策者都在考虑哪条迁移路径更适合公司的状况和未来的发展战略。在过去有二种迁移路径，全新实施或者全部数据迁移。这二种方法都使公司将面临翻新不同的遗留问题，并增加巨大工作量。云迁移正在帮助企业加速SAP S/4 HANA的引入，作为其数字化转型的一部分。由CrystalBridge数据转换平台赋能的Bluefield方法论，促使数据在独立项目中被迁移和更新，这使公司更节省时间和预算。
为什么选择SNP BLUEFIELD迁移方案？
灵活 简单 安全 可靠
SNP BLUEFIELDTM 方法通过高端软件极大的加快了数据迁移的速度，使项目的实施更为高效。通过以CrystalBridge为核心的BLUEFIELDTM 实施方法论，企业可以：
根据市场的需求随时对业务进行调整
遵循公司战略创建一个灵活的IT架构
根据实时数据情况，做出明智的决策
创造更多的潜在业务
识别系统环境中存在于IT与数据安全中潜在的风险
SNP 迁移：完整路线图
通过SNP RESC工具将SAP技术升级转换和数据传输进行解耦，创建一个不带主数据和业务数据的空壳系统，随后可以在空壳系统中使用SAP标准的升级方案，例如需要升级到S/4HANA就可以使用标准的适合SUM和DMO的升级转换方案将不带数据的空壳系统转换到客户想要的S/4HANA版本， 升级成功后，再做一些增量配置以及相应的代码调整。
传统的方法从本地迁移到云端面临着一个较大的挑战，即停机时间和次数的问题，传统的方案中必须要在本地先升级转换到S/4HANA了之后再做一个到云端的迁移。而SNP Bluefield方案可以在创建空壳系统时直接将空壳系统搭建在云端，随后在云端实现整个系统升级转换到S/4HANA，最后通过TF模块将数据从本地迁移到云端。使用SNP Bluefield方案，整个的技术升级转换与调整都是在空壳系统中完成，和当前正在运行的生产系统没有任何关联，同时可以优化停机时间。
优势：
•源系统全程无变更，天然回退方案
•合并转型多个系统为一个
•保留当前系统的开发和修改
•灵活性较高
•多个项目，包含技术前提条件一步完成
•快速，可靠，经过审计认证的项目方案
•范围可选择，比如. POC
为什么要优化停机时间？
与停机时间相关的预期业务中断，以及希望尽可能缩短中断时间（成本/罚款）
预期停机时间超过了业务可接受的停机时间
规避停机时间在意料之外延长的风险
停机时间优化方法
标准迁移方法(停机时间无优化)
除了标准迁移方法（宕机时间无优化）、SNP针对不同的转型业务场景设计了多种接近零停机的方案，如果是纯系统迁移，可以使用基于表的接近零停机方法。如果是同时涉及到拆分、合并、标准化等别的业务场景。可以使用基于规则的零停机方案，针对从ECC到S/4HANA，SNP专门设计了一种同时结合了基于技术表，基于规则，基于组织的混合迁移接近零宕机方法，大大减少系统上线的停机时间。
基于表的接近零停机：
•将技术停机时间降低为几个小时
•主迁移的过程中源系统保持正常运行
•SNP Transformation Backbone迁移的两个阶段：主迁移与多次增量迁移
•源系统在SNP T-Bone迁移过程中发生的所有变更都会被记录
•切换：
源系统隔离：锁定用户，停止Batch作业
最终增量迁移
基于规则的零停机方法：
•历史数据可迁移
•支持多系统迁移、合并、协调
•任意复杂性的业务规则
•使用触发器跟踪将捕获所有更改
•停机时间与数据总量无关，仅由变化率决定
•源系统上几乎为零的停机时间
•如果将目标系统视为另一个源系统并建立协调规则集，则目标系统上的停机时间可能接近零
•可结合其它方法与表选择进行组合
混合迁移接近零停机方法：
•根据对停机时间的影响，可以决定对每个表使用的方法
•通过对尽可能多的表使用更简单的方法来降低复杂性
•只有具有复杂规则集的表才由不同的方式处理
•所涉及方法的优势仍然存在
