云计算发展如今已经达到了新的阶段，很多企业在将核心企业应用程序(如基于AS/400的ERP系统)迁移到云端方面拥有丰富的经验。
在实际应用中，人们已经看到很多DevOps实践迁移到云中，其传统应用程序从整体转变为微服务。然而，这是人们发现的非常有趣的边缘项目。其中包括围绕数据摄取、物联网开发，以及大规模大型机和企业资源计划(ERP)系统的深度集成。
在过去的一年中，很多企业正在探索甚至开始将他们的一些遗留环境迁移到云中。例如，将部分或整个SAP生态系统迁移到谷歌云平台，或将整个Oracle生态系统迁移到云中。***，使用大规模IBM AS/400体系结构并将这些组件移动(或重构)到云中。
有几个原因可以解释为什么如此多的组织在迁移或现代化这些系统方面犹豫不决。其原因包括：
(1)恐惧、不确定和怀疑。事实上，这么做的人并不多。而且，将整个业务引擎迁移到云中可能会很可怕，因为没有很多用例，迁移这些平台可能非常危险。许多组织根本无力承担这项成本高达数百万美元的后果。
(2)复杂性。一些AS/400系统已经存在多年，甚至几十年。大规模的ERP系统也是如此。许多组织使用其SAP解决方案的想法根深蒂固，并仅限于内部部署。
(3)成本和投资。一些企业已经在他们的ERP和大型机系统上投入了数百万甚至数千万美元。他们多年来投资基础设施、合同、人员等等。企业需要显示一些真实的投资回报率，甚至考虑将这些系统迁移到云端。
现在有一些好消息。很多组织意识到要颠覆数字驱动的市场，他们自己必须被颠覆。这意味着打破传统的部署范例，并寻找将大型机甚至ERP系统迁移到云中的方法。或者，寻找强大的混合解决方案可以提供帮助。
云计算正在带来变化
很多企业通过ERP和大型机架构改变他们的工作方式，并与大型企业客户讨论这些解决方案。以下分享两个具体的例子：
例如，将超过600万行传统RPG/Synon代码迁移到与云计算部署兼容的面向服务的体系结构中。这是一个大规模的IBM AS/400系统的故事，对于一个正在寻求成为数字原生的组织来说，它根本就没有发挥作用。该项目规模庞大，但也具有很强的可行性和良好的规划。经过一些彻底的遗留代码分析，迁移了600多万行代码，重新编写了150多个集成点。这包括为审查RPG代码而开发的定制工具、绿色屏幕分析器，甚至利用X-2E工具对遗留代码进行可跟踪性审查和可视化。此外，它还包括从IBMDB2迁移到更灵活的Mariadb。
这是最重要的部分，一旦完成，迁移还包括DevOps实践，以允许客户继续创新和扩展。这很容易吗?这是否需要一些创造性思维和定制工具集?当然。但这值得吗?***相信值得。对于客户来说，迁移业务的这一部分意味着将多个业务线集成到一个数字框架中。而且，对于行业和客户来说，这确实让他们与众不同。
将SAP Hana和其他组件迁移到云中。将ERP系统迁移到云中可能是一个非常复杂的过程。此外，如果弄错了，可能会对业务造成严重后果。请记住，对于企业来说，像SAP这样的ERP解决方案确实是他们的整个业务引擎。一旦克服了这种恐惧，就会开始看到全局，并为未来设计一个方案。
最成功的迁移都是通过并行设计中的概念验证来完成的。例如，假设希望将SAP生态系统的一部分或全部移入谷歌云平台(GCP)。为此需要：
- 了解S/4HANA如何适应环境及其提供的具体优势。
- 确定业务需求中的主要差距
- 分析潜在的景观
- 创建目标云计算解决方案的愿景，并将SAP路线图概述为转型项目
在一个客户场景中，能够将大规模复杂的电子商务引擎与SAP和谷歌云平台集成。利用SAP HANA、Google BigQuery、Google DoubleClick和其他组件创建围绕混合云设施构建的整体设计。在那里，人们看到设计实际上可以利用强大的多云生态系统。因此，SAP混合营销已迁移到AWS，并且在谷歌云和AWS云平台之间集成了超过50个核心系统。其中包括SAP ERP(IS-R和AFS)、SAP Business Warehouse、Salesforce等。
这个项目的重点是采用一个非常谨慎的方法。提前做了一个概念验证。对系统进行了性能和集成功能测试，能够在将任何内容投入生产之前验证实际结果。
这需要考虑很多方面。但是，要知道已经存在一些用例和场景，其中一些***和最复杂的ERP甚至大型机系统正从传统的单一平台转移到高级数字解决方案中。所有这些都使集成变得更容易，促进了自己的开发过程，并使企业能够响应数字化和数据驱动的市场。
