在SAP到S/4 HANA的SPAU阶段中，所有的自定义代码调整都是在前提下迁移的吗？

Question

从自定义代码的角度出发，我计划在迁移到S/4 HANA的前提下执行这些操作。到目前为止，中央ATC的设置是为了验证当前的SAP ECC代码，在迁移之前，我们已经可以在ABAP代码中实现大部分修复。

下一步是使用SUM进行系统升级的基础团队。他们告诉我，我必须在SPAU中实现其余的调整和修复，但据我所知，SPAU只用于调整标准的SAP对象，这些对象是用"access键“修改的，并且在升级过程中发生了更改。

我以前为更小的升级做过SPAU，情况是这样的，当然数据模型没有改变，标准对象也没有像S/4 HANA升级那样被废弃。

然后是用于自定义增强的SPAU_EHN，它可能会在升级期间受到标准对象的更改的影响。

但是当谈到ABAP对象的其他部分时，假设是一个完全独立的自定义程序、一个Z函数模块、自定义类等等。是对这些对象部分的调整，或者，如我所想，它们是否已经是升级完成后要执行的手动活动的一部分？

关于调整自定义对象的顺序，我的想法如下：

1. 用ATC验证来调整当前ECC中的所有可能
2. 带SUM的基础升级系统
3. 必要时调整SPAU中修改的标准对象
4. 必要时调整SPAU_ENH中的增强功能
5. 完全升级过程
6. 使用Fiori迁移应用程序、快速修复等调整其他自定义存储库对象，直到列表降到零为止。

按照这个顺序，我将对步骤3和步骤4使用1个传输请求，然后为步骤6使用尽可能多的传输请求。

Answer 1

你是对的。进行S/4迁移的通常方法是先进行升级，然后再进行自定义代码迁移。

首先使用SUM升级系统，然后使用SPDD、SPAU和SPAU_ENH修复标准修改和升级之间的冲突。但是这些事务只关心SAP标准代码，它是由您修改的，然后在升级过程中被SAP再次修改。他们忽略了对升级过程中未被触及的对象的修改，当然也不关心Z*和Y*命名空间中的任何内容。

因此，在技术升级完成后，您将拥有一个充满客户代码的S/4系统，因为它不符合S/4标准，因此出现故障和错误。

现在，您将使用ATC及其集成到for Eclipse中，以查找自定义代码中的所有破损部分并修复它们。这取决于您在系统中有多少自定义代码，它编写和记录得有多好，以及它与更改后的功能的交互程度如何，这需要几天到几个月的时间。这不是你自发做的事，很少有计划，就像你通常做的SPAU和解一样。

有关该过程的更多信息可以在SAP官方指南中找到。