3

I'm planning the actions to execute during the migration to S/4 HANA on-premise from the custom code point of view. So far the Central ATC is setup to validate the current SAP ECC code where we can already implement most of the fixes in the ABAP code before the migration.

The next step is the Basis team proceeding with the system upgrade using SUM. They tell me I have to implement the rest of adjustments and fixes in SPAU, but to my knowledge SPAU is only used to adjust standard SAP objects that were modified with an "access key" and have changed during the upgrade.

I did SPAU before for smaller upgrades and that was the case, of course the Data Model was not changed and standard objects were not deprecated like in the S/4 HANA upgrade.

Then there is SPAU_EHN for the custom enhancements that could be impacted by the changes in the standard objects during the upgrade.

But when it comes to the rest of ABAP objects, let's say a totally independent custom program, an Z function module, custom classes, etc. Are the adjustments to these objects part of SPAU or, as I think, are they already part of the manual activities to execute after the upgrade is completed?

My idea about the order to adjust the custom objects is the following:

  1. Adjust everything possible in the current ECC with ATC validations
  2. [BASIS] Upgrade system with SUM
  3. Adjust modified standard objects in SPAU if necessary
  4. Adjust enhancements in SPAU_ENH if necessary
  5. COMPLETE UPGRADE PROCESS
  6. Adjust the rest of custom repository objects using Fiori Migration App, Quick Fixes and so on till the list is down to zero.

Following this order, I would use 1 Transport Request for the steps 3 and 4, and then as many as necessary for step 6.

Sandra Rossi
  • 11,934
  • 5
  • 22
  • 48
RaTiO
  • 979
  • 2
  • 17
  • 33

1 Answers1

1

You are correct. The usual way to do an S/4 migration is to do the upgrade first and do the custom code migration afterwards.

First you use SUM to upgrade the system, then you use SPDD, SPAU and SPAU_ENH to fix any conflicts between standard modifications and the upgrade. But these transactions only care about SAP standard code which was modified by you and was then modified again by SAP during this upgrade. They ignore modifications to objects which weren't touched during the upgrade and they certainly don't care about anything in the Z* and Y* namespace.

So after the technical upgrade is completed, you have an S/4 system full of customer code which is broken and buggy because it isn't S/4 compliant.

Now you use ATC and its integration into the ABAP Development Tools for Eclipse to find all those broken sections in your custom code and fix them. Depending on how much custom code you have in the system, how well it's written and documented and how closely it interacts with the changed functionality, this is an effort which takes several days to several months. It's nothing you do spontaneously and with little planning like you usually do with a SPAU reconciliation.

More information on the procedure can be found in the official guide by SAP.

Philipp
  • 67,764
  • 9
  • 118
  • 153