对于将现有SAP ERP 6.0系统转换为SAP S/4HANA（内部部署）的系统，技术停机时间不仅受到应用程序表从源数据库迁移到SAP HANA数据库（如果源数据库尚未基于SAP HANA）的影响，也可以通过应用表的数据转换从旧的数据模型转换到新的数据模型。

系统转换的方法

我们将提供三种系统转换的方法：

标准使用软件更新管理器（SUM）优化停机时间使用SUM，并通过将数据转换部分转移到正常运行时间来减少停机时间客户特定方法作为咨询服务项目（NZDT），企业应用开发平台，允许进一步减少停机时间查看SAP Note 693168了解详细信息

本博客仅解释停机优化转换方法。

简介

该方法基于将停机活动（如从旧数据模型到新数据模型的数据转换）和数据库迁移（如果源系统在非HANA数据库上）移到SUM正常运行时间处理的思想。对于标准转换，FIN数据迁移必须在各IMG活动（如FI定制、FI数据迁移）完成总和后执行。停机时间优化方法甚至会将FI数据迁移（部分）转移到正常运行时间总和处理中。

正常运行时间期间应用程序表上的总和活动可能会干扰这些表上的用户活动。因此，终端用户对表的任何更改都由SUM记录，大数据平台，并由重播机制处理。此重播将考虑最终用户在表内容（例如已通过SUM转换）后发生的表更改。

下图显示了一般概念。

数据转换被移动到正常运行时间处理。如果源系统尚不在SAP HANA数据库上，则受影响表的数据库迁移也会在正常运行时间内完成，然后再进行数据转换。[受影响的表：属于SAP ERP旧数据模型的表，但不属于SAP S/4HANA新数据模型的表-表内容必须从旧表转换为新表]

此外，表KONV和VBFA的字段转换也移动到正常运行时间处理。这两个表仍保留在新的数据模型中，营销数据分析，但必须调整字段。

如果源系统尚未在SAP HANA数据库上，则可以将选定的大型应用程序表（不受新数据模型影响）的迁移移动到正常运行时间处理的总和。[这是停机时间优化的DMO方法，请参阅https://blogs.sap.com/2014/09/08/dmo-downlight-optimization-by-migrating-app-tables-during-uptime-preview/]

边界

"停机优化转换"目前可用于试点项目。此类项目由SAP同事驱动，需要注册。接受的项目得到SUM开发的直接支持。SAP Note 2293733中描述了要求、限制和注册过程。项目将由SAP consulting或SAP专门知识中心（CoE）为高级客户提供驱动。

项目方面

与标准转换不同，此方法不会用于您环境中的所有系统。通常它不用于DEV系统的转换，手机自助建站，因为与PRD系统转换相比，云免服务器购买，停机时间没有那么重要。然而，必须在PRD副本上执行几次停机优化运行。

停机优化转换运行将在正常运行时间内执行部分总和FI数据转换。要启用此功能，SUM需要FI自定义。因此，在停机优化运行之前，需要创建FI自定义的标准运行，并且必须将此自定义放入自定义请求中。然后，可以将此请求反馈到停机优化转换运行的总和中。

项目的重要调查将是对受影响表的更改率的估计。

该方法需要重新启动系统，以确保相关应用程序表（同步点）的状态一致。此重新启动是正常运行时间总和处理的一部分，通常在实际停机前一个周末进行计划。复制将运行到下个周末。

复制

应用程序表上的SUM活动需要考虑这些表上的任何最终用户活动。SUM使用自己的记录和重放技术。如果源系统尚未在SAP HANA数据库上，则列出SUM的活动：

重新启动系统以获得应用程序数据的同步点相关表从源数据库到SAP HANA数据库的初始迁移迁移其他表（如果选中）将迁移的数据还原到同步点所以之后只处理一个一致的集合迁移数据到新数据模型的转换相关表上更改的应用程序数据的增量迁移正常运行时间内终端用户活动引起的更改系统进入停机时间相关表delta的最终迁移最终用户的剩余更改将反映出来delta的剩余数据转换其他表的迁移剩余金额活动系统恢复正常运行时间

请记住，这种方法还不是普遍可用的。我们希望在未来提供，但无法预测何时提供，因为这取决于正在进行的试点项目的结果。

此博客可能会更新和/或扩展，请继续关注。

问候，

SUM产品经理Boris Rubarth