Skip to Content
Author's profile photo Bernhard Hochreiter

Some hints for a smooth transition reg. SU25|upgrade to >=7.31

To avoid dataloss, unexpected results, some actions have to be performed as preparation already before starting the upgrade.

Before the Upgrade:

  • First repair any inconsistent data still in the old release: Use report SU24_AUTO_REPAIR with all available options (documentation can be found in SAP note 1539556).
  • Initialize timestamps with report SU25_INITIALIZE_TSTMP (SAP note 1599128)
  • Create a backup transport of SU24 data after each step (you can use SU25, step 3 for that creation of the transport) and export it
  • Make sure, that the authorizations of your roles are actual. That means, that the existing authorizations should ‘fit’ to the existing SU24-proposals (i.e. Authorizations with status ‘Standard’ and/or ‘Maintained’). To do that, start the ‘Expert Mode for Profile Generation’ in PFCG on the Authorizations tab and use the option ‘ Read old status and merge with new data’. This will start the merge function and will probably update the existing authorizations according the rules listed in note #113290. If you do not do that, you may be surprised about changes happening to existing authorizations after the upgrade during execution of SU25, where the merge function is used as well.
  • Create a backup transport of your roles and export it

Now after the Upgrade:

Apply all notes listed in note 440231. This note is kept actual with the latest notes.

Run SU25 2a-2c, alternatively you can use also the expert mode combining 2a and 2b by starting SU24->button ‘Default Values Comparison’. As of 7.40 this expert mode is included in the SU25 action-list after step 2b.

<start of update 3rd Sep.2014:

The expert mode button is available in SU25 as of sapkb73112 in the button line of SU25 on the top.

Timestamp of step 2a:

Using the Expert mode, no timestamp for 2a is written automatically (so 2b, 2c won’t work afterwards). Nevertheless you can set the timestamp with the corresponding button in the result list of the expert mode (as of note 2042284).

Attention: if you are using the ‘normal’ step 2a, do not leave the result screen with ‘cancel’ or closing the session, but rather use the back button to navigate to the su25 main screen. In some old correction levels no 2a-timestamp will be written, if you do not navigate back. (you can use the expert mode optne then mentioned above to set the timestamp then manually…)

end of update 3rd Sep.2014>

If everything is fine, create a final transport in step 3 of SU25 and transport the new proposals through your system landscape.

Then transport your already adapted roles as well.

Update June 19th, 2013:

If you have missed the first step of  ‘Before the Upgrade’ (SU24_AUTO_REPAIR ->Repair Modification flags), note #1850378 provides a correction which corrects at least the SU24-entries with incorrect modification flags. Missing modification flags cannot be repaired anymore at this moment, as the old SU22-content before Upgrade is required to repair the missing ones.

Update December, 2013:

Please see also KBA 1954558

Update August, 2015:

Additional point ‘Make sure, that the authorizations of your roles are actual.’  added to section Before the Upgrade’.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Thank you Bernhard!!

      Author's profile photo Matthias Hübner
      Matthias Hübner

      good and helpful



      Author's profile photo Karen Hurley
      Karen Hurley

      Clear and easy to follow steps. Thanks!

      Author's profile photo Felipe Fonseca
      Felipe Fonseca

      Thanks for writing Bernhard! It's really helpful!

      Author's profile photo Chris Obura
      Chris Obura

      Hi Bernhard, thank you for the details above. I have however noticed the report SU24_AUTO_REPAIR does not correct all corrupt SU24 entries. As an example I have a system which has corrupted SU24 entries as you can see in table below. In this case the object K_PCAR_REP has a proposed value of $KSTAR in the activity field. This is after I had run the SU24 repair program with all options selected. It corrected some entries but left some behind. Just thought I'd mention this in case there's an update that needs to be done on the program.



      Author's profile photo Former Member
      Former Member

      I am asking myself how those org.levels not into ACTVT in the first place? In my system these values are fine.



      Author's profile photo Chris Obura
      Chris Obura

      Hi Julius,

      I found the system in this state after ECC EHP5 upgrade was done. Not sure what steps were done at the time but there's an awful lot of these corrupted fields. I also suspect part of the problem occurred because a lot of roles have auth objects in changed and manual statuses and an inconsistency arose during upgrade or possibly the upgrade was aborted prematurely. The funny thing though is the auto repair program corrected some instances, maybe I'll debug the program later to see why it did a partial repair.



      Author's profile photo Former Member
      Former Member

      What is in the roles should have no affect on SU24.

      Perhaps some one tried to load auths maintained in roles (AGR_1251) back into SU24 (USOBT_C) directly? Or they fiddled with the download files and then uploaded them again? The internal function modules which update SU24 don't make these type of validations - at least not in earlier releases.

      I once found an SU24 proposal for an object which did not exist and was in lower-case. There is only one way that something like that gets into a table field which is converted to UPPER_CASE -> updates directly to the database.

      So also go to SE11 and from USOBT_C do a where-used-list search for Z-programs. Some invention might be hitting the table..



      Author's profile photo Chris Obura
      Chris Obura

      I checked if the table is being updated by any custom programs as you suggested but this is not the case. Thanks for your suggestions and input, I'll keep working at it.

      Author's profile photo Bernhard Hochreiter
      Bernhard Hochreiter
      Blog Post Author

      found some similar entries in an internal refernce system as well.... (but not for the tcodes of the above screenshot). As usobt kept alos that nonsense, the applications have to provide a solution.


      AB01L                      TR   A_B_ANLKL ACTVT  $BUKRS
      ABIFL                      TR   A_B_ANLKL ACTVT  $BUKRS
      CMM_PEV_WL                 TR   CMM_MEV_WL   ACTVT  $BUKRS
      FEB_BSPROC                 TR   F_FEBB_BUK   ACTVT  $BUKRS
      IDCNFB03                   TR   F_BKPF_BUK   ACTVT  $BUKRS
      IDCN_ADJDISP               TR   F_ADJ_DOC ACTVT  $BUKRS
      IDCN_ADJEDIT               TR   F_ADJ_DOC ACTVT  $BUKRS
      IDCN_ADJNEW                TR   F_ADJ_DOC ACTVT  $BUKRS
      J1INPRREV                  TR   J_1IEWTPR ACTVT  $BUKRS

      so just in case you find such values again in other systesms. Seems to be pretty old false data....

      b.rgds, Bernhard

      Author's profile photo Mike Driver
      Mike Driver


      We are preparing to upgrade from 7.31 to EHP8 7.50. After reviewing the notes above, it appears that SU25_INITIALIZE_TSTMP had been applied to our system during a previous upgrade to our environment. I have verified the tables mentioned in note 1599128 and they have been created and are populated.

      My question is, should we still execute all of the steps above including SU25_INITIALIZE_TSTMP even though it appears to have been run at one previously? Is there value in doing so or is this no longer required?

      Also, I noticed that when pulling up the report, there are two options. You can either "Set time stamp to initial val", or "Initialize time stamp". I can't seem to find good information providing my clarity as to what option should be selected if it is determined that we need to execute the report.

      Thank you in advance for any assistance,


      Author's profile photo Devaprakash Budati
      Devaprakash Budati

      Hi Bernhard,

      We are preparing for s4 hana conversion from ECC 6.0 basis release 700 to S4hana 1909. I see that the report SU25_INITIALIZE_TSTMP and tables USOBT_TSTMP and USOBX_TSTMP are not available in the basis release 700. So can we proceed further without executing this report?