Skip to Content

Although the SDN has excellent resource for most SAP stuff, I believe there is room for a developer’s point of view on a SAP technical upgrade. Now having worked through two upgrades myself I thought it would be a good idea to put forward the same. For someone who has never worked on an upgrade before, this article should go to some distance in giving the developer confidence to say that he/she knows more or less what to expect from the project.

SPAU, SPDD, ABAP Dump etc are some of the things an ABAP developer will come across in a SAP Upgrade project. I will try and give a small but comprehensive bulleted list of the various phases a ABAP developer may need to get involved in a logical and chorological sequence below.


Assuming that you have read the Wiki page above I will only summarize by saying that SPDD is the first Basis activity and lists all changes to SAP Data Dictionary objects from your current SAP version to the one you are upgrading to. Most of it should be taken care of by the Basis Team themselves but will require an ABAP developer to take a call on some repository objects being used or referenced in custom programs/repository objects. E.g. SAP change length of a domain say matnr from 18 to 15 characters. SAP will take care of all standard programs where they have referenced the domain matnr but as a ABAP developer it will be your call as to what impact the change will make to all your custom programs or tables where you have referenced the domain matnr. Depending on your analysis you may go ahead and accept the changes or keep the original version of the domain. The impact of not accepting the changes could be huge and out of the scope for me. The sensible decision should be to accept the changes and modify all your custom stuff accordingly. (Matnr is just an example I have used as it a common domain and should be known to most developers.)


  • SPAU – Again a good explanation of SPAU is


SPAU is another Basis activity immediately after SPDD. I would say that SPAU is an extension of SPDD to all SAP repository objects i.e. programs, function groups, OSS notes etc. In SPAU the developer has a larger role to play than in SPDD. Firstly the list is generally much bigger than SPDD and more importantly it requires some research on the impact of the changes in the SAP repository objects to the custom Repository objects. E.g. SAP changes the interface of a function module say CONVERSION_EXIT_ALPHA_INPUT. SAP will take care of all standard repository objects where they have referenced the Function Module but as an ABAP developer it will be your call as to what impact the change will make to all your custom programs made a call to CONVERSION_EXIT_ALPHA_INPUT. The impact of accepting or not accepting the changes is more or less as in the case of SPDD objects. (CONVERSION_EXIT_ALPHA_INPUT is just an example I have used as it a common function module and should be known to most developers.)


Now the system has been upgraded and is ready for testing by the functional or testing team.

  • The ABAP work coming out from here on is more like supporting a system. There will be lots of incidents and issues coming out of testing e.g. transactions not working as they did in the original SAP system or ABAP dumps. Solving them will involve lots of debugging and the same approach one uses for support incidents.



The above might look like a overly simplistic view but that’s what I feel an SAP technical upgrade is, a simple project with lots of support like issues and incidents for the ABAP developer. So if you have a good problem solving approach and have worked on support before, the SAP technical upgrade should be bread and butter for you.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Former Member
    I was very interested to know how developers see the process of an SAP Upgrade, as I am usually the technical resource performing the upgrade.
    The one issue I would take with your blog is that neither SPDD or SPAU are Basis tasks, you might have been lucky enough to have cross-skilled Basis resources who can take care of at least SPDD.
    But most Basis resources I know of are not capable of working with these lists – if they were then why would we need developers during an upgrade?
    I have always had access to a developer during these tasks in every upgrade project I have done, which is quite a few :-).


    1. Former Member
      I am currently working on technical upgrade again, so I was interested in reading this article to see what others think about this topic, but I must say in my opinion an Upgrade only starts with SPAU/SPDD and even if a lot of activities are solution specific, they can at least be mentioned in a generic fashion.

      Now it probably depends how you define a “development resource” – Yes probably you have 1 or 2 development resources that have hardly any knowledge of the solution and will only react to issues/defects – But I think there are a lot of proactive steps that a development resource can take which will make you a much better asset for the upgrade project.

      – Upgrade Landscape Strategy
      – Study Release Notes + OSS Messages
      – ASU Toolbox (Pre-Upgrade): Yes sometimes you have to store data in cluster prior to the upgrade. Afterwards the data is lot
      – Mass Activation of Application Forms (generation errors)
      – Build RICEWF (as cross reference for testing & other impacted functionality)
      – New mandatory customizing, number ranges
      – Understand/Test Migration Reports
      – Replace Obsolete Function Modules / BAPIS
      – Compare Customizing
      – Data Stored in new table (or new key – e.g. time dependency) – cross reference how Z-Reports read those tables.
      – Confirm custom fields on standard screens (BDT)
      – Compare/consolidate transports
      – Dual maintenance
      – Compile cut-over list

      This is just a short list that I could create out of my head. Most importantly study release notes. This will give you a very good idea of potentially impacted areas in which you should investigate further.

      Of course some of the tasks also depend how your upgrade project is organized, but these are the tasks I generally see with “technical” resources.

      1. Chris Kernaghan

        Some of the things you have put in there actually are Basis tasks, not developer tasks.
        – Upgrade Landscape Strategy
        (generation errors)
        – Compare/consolidate transports
        – Dual maintenance
        – Compile cut-over list

        Lets be clear a developer is not a technical resource, they do not work with the technical infrastructure of the system or the management of that infrastructure.

        1. Former Member
          Hey Chris – I think it heavily depends how your project/customer is organized.

          About the technical/developer resource – Maybe I am lost in translation (german). I just wanted to emphasise that the resource should be more than just an ABAP’er. He should have decent solution specific knowledge.

          – Upgrade Landscape Strategy: Heavily depends on running projects, general stability of the solution. In my projects Basis was responsible for all systems in the company. For the upgrade landscape we had to define towards them in which way systems have to be upgrade.

          – Compare/consolidate Transports: Even in a lot of organization Basis is responsible to carry out the transports, similar to SPAU they are usually not able to make any judgement. E.g. You setup your Dev. Upgrade environment. What to do with transports/developments between backup of Dev. & Availability of Upgraded Dev. This can be a case by case decision that Basis cannot perform.

          – Dual Maintenance: Probably also depends how you define this. I mean the task of keeping developments manually in sync between “break-fix” & upgraded environment. In my projects usually development was responsible for this.

          – Compile cut-over list: I agree – Definatly a Basis Activity, but there can also be a lot of manual/verification activities pre- and post upgrade that are solution specific. Usually Basis is not responsible (or comfortable) to run that kind of tasks.

          Again – I don’t think you are wrong. I only want to spur a valuable discusssion.

  2. Alberto Castillo

    As already mentioned by another person, and being myself involved in 6 upgrades as the technical consultant (Basis) who did the upgrade in those systems, SPDD and SPAU were not a Basis task.
    The Tech guy who did those two upgrades you were involved with is the exception and not the rule.

    Probably in a next upgrade, the project manager will ask you to do SPDD and SPAU work so don’t feel it is wrong.

    Have a nice day

  3. Former Member
    You have highlighted SPAU and SPDD as the major components of a technical upgrade. In my experience, after the SAP standard objects have been rectified for the new version, the actual task of the technical consultant starts. He has to take care of the huge repository of custom (Z) programs. Identifying the points impacted by the change and correcting the programs is actually the major portion. Sometimes transaction codes change (e.g ME21 to ME21N)or screens change, hence BDCs and other programs are affected. Sometimes, the enhancements or user-exits need a face-lift. All this is a major work for the technical resource.

    So huge is this portion, that several SIs have designed products and service offerings, to identify the precise points of impact in your system.

      1. Trond Stroemme
        Depends on how you define technical; as a developer I definitely see myself as a technical resource – as opposed to functional. Also, most developers are in the game in order to get their hands dirty and stick their noses into anything that can be tampered with… so, yes, I almost consider it an insult being classified as non-technical 🙂
  4. Former Member
    After the SPDD and SPAU adjustments the next thing you must do is to run the Code inspector for all the custom programs in the SCI transaction. If it has any errors in custom ptograms then it needs to be fixed
  5. Axel Biernat
    In addition to SPDD, which is integrated into the upgrade or patch process, and SPAU, which comes as post-activity, you should also run SPAU_ENH for enhancements you have implement. Especially if you are using implicit enhancements this step mandatory otherwise these are not longer in place for code which was changed.

  6. Trond Stroemme
    Agree fully that SPDD/SPAU is for developers, not basis.

    One phase not mentioned here is the post-SPDD activation phase: here, developer input may also be required. In this phase, any element failing to activate will show up; this could be due to inconsistent enhancement categories for include structures used in other DD structures, or tables where new indexes have been set up but not yet activated and so on.

    During this phase, I’ve also seen “shadow” references to tables and views that are deleted from DD, but still showing up with “activation errors”.

  7. Former Member Post author
    I am a basis person and  have done 7+upgrades and in of the projects I had to deal with SPDD but I always needed abaper to help me out with it. SPAU is certainly not a task of BASIS resource..though I have seen many ABAPer not having full understanding of SPDD and SPAU transaction and I had to teach them how to use it and how to include the transport for the next technical upgrade is still a challege for BASIS guys not for the Developers as they come in picture only for few hours…
  8. Former Member
    I was thinking about a “how does an upgrade work” or “what are SPDD and SPAU” for a long time. So i was pretty excited to see your blog. Thanks for doing it.

    But i also have to criticize you a bit. Lets have a look at this sentence:

    SPAU is another Basis activity immediately after SPDD.

    Other readers already said, neither SPDD nor SPAU is a basis activity. And SPAU does not happen anywhere near SPDD from a time perspective.

    SPDD has to be made quite a the beginning of the upgrade (before you import the new data into the tables) and SPAU is at the very end of it (after you imported the new repository objects).

    If you do a downtime minimized upgrade – and everybody does, then SPDD is early in the uptime phase.

  9. Former Member Post author
    Wondering if ABAPers ever get involved with the transaction /n/ASU/UPGRADE that is run after technical downtime but before we return the system to the users?  I know there’s a lot of functional ‘stuff’ in there that helps to organize their post-upgrade tasks, but I’m not sure if ABAPers even consider looking at it?

Leave a Reply