SAP Technical Upgrade and SAP EHP – A Functional Overview
SAP Technical Upgrade is a periodic project that is implemented across companies to upgrade their SAP system to the latest released version. Most of the upgrade activities are done by the technical team and the role of functional consultants is limited and mostly confined to regression testing. This article
tries to provide a functional overview about technical upgrade and also covers the evolution of SAP technical upgrade to Enhancement Packages concept.
Reasons for SAP Technical Upgrade :
Since technology and businesses evolve, companies need to maintain a technological infrastructure that can support that change. This is the major reason why companies should undertake a technical upgrade of their SAP system. Of course there are many secondary reasons, the significant one being the fact that like all software vendors SAP supports a released version of its software only for a limited period.
Technical Upgrade vs Functional Upgrade :
As the name implies, technical upgrade only upgrades the software to the latest version and the new functionalities that come with the new version are
not activated or implemented. Whereas in a functional upgrade, the functionalities offered by the new SAP version are also implemented in addition
to technically upgrading the software.
Steps in Technical Upgrade :
1. System preparation
As the first step, the latest SAP version is installed on the hardware and all the general patches up to the latest stack level are applied. All the
stack levels of various patches – Basis, ABAP, XI etc should be brought up to the latest level since otherwise it may cause issues during the upgrade or
2. SPDD Phase
Transaction codes SPDD and SPAU are the core of an upgrade project. In SPDD, the system compares all the ABAP dictionary objects (data elements, database tables, structures) of the latest system with the old system. Here we have the option to choose the latest version of the object (Reset to Original) or to keep the changes made in the previous system (Adapt Modification). Basically if the customer has made any modifications to the objects in the old system and wants to retain it, he will choose Adapt Modification. Else, by choosing Reset to Original, the system will overwrite the customer changes and will reset the objects to the latest standard version. Thus this is one of the most important steps in the upgrade project.
3. Upgrade of the System
After the SPDD activities are completed, the system is then upgraded – the old version is replaced by the new version.
4. SPAU Phase
Transaction SPAU is similar to SPDD but the objects involved here are the Repository objects (Programs, Function Modules, Screens, Interfaces, Documentation and text elements). Here also we have to choose between ‘Reset to Original’ or ‘Adapt Modification’. The SPAU activities can be done either immediately after SPDD activities or after the Upgrade of the system.
The major role for functional consultants in an upgrade project is during this Testing phase though their inputs are sought during SPDD and SPAU phases also. Testing strategy plays an important role in the success of an upgrade project. Since it is not possible to virtually test every single transaction or business process in the limited time available, care should be taken to test the critical processes so that the business continuity after the upgrade is ensured.
Typical issues encountered during testing are short dumps, performance issues, variants for reports missing, not printing the smart forms correctly, etc. For most of the issues there will be corresponding SAP notes detailing the solutions. In other cases the technical consultants may have to debug the corresponding program of the transaction or report not working correctly.
As a good practice, the old production system’s copy should be available till the new system stabilizes after upgrade. This will facilitate troubleshooting of issues by comparing how a transaction worked in the old system if it is not working correctly in the new system.
The number and size of custom modifications in the system determines the complexity of the upgrade project. Because many of the function modules and dictionary elements might have become obsolete and replaced by newer ones, the Z programs using the old functional modules and dictionary elements will not function correctly in the new system. Hence enough care should be taken to check and correct all the custom programs to ensure they are working as expected.
6. Post upgrade activities :
Some activities have to be executed manually in each system after upgrade since they cannot be included in a Transport Request. Eg. Regenerating ABAP queries after upgrade.
Terminologies used in SAP upgrade :
Other terminologies that are associated with an upgrade project are briefly explained below.
Freeze periods :
Change management is a critical challenge in an upgrade project. While the upgrade team is doing the remediations for the programs, tables, etc during the upgrade project, it becomes imperative that no fresh developments or changes occur in the system. But since an upgrade project can last several months based on the system complexity and other factors, it is impossible to avoid developments altogether for such a long period. Hence an appropriate change management strategy should be defined that will restrict and regulate the changes to the production system.
This phase extends from the start of the project till development system upgrade. Changes allowed during this phase are :
– Pre-approved corrections (to solve production problems)
– Complete the final few critical ongoing change requests
This phase covers the period from development system upgrade till User Acceptance Test signoff. Allowed changes during this phase are :
– Only critical production issue resolution (License To Operate (LTO) / Priority 1 business stoppage issues)
This phase covers the period from UAT signoff till Go-Live. Absolutely NO changes are allowed during this period.
Dual Maintenance :
During upgrade process, as described above, production support fixes and LTO’s should go through the landscape to the production system. But the upgraded development and test systems should not be disturbed since that would affect the upgrade fixes and testing carried out during the project. Hence the solution is to create a dual landscape to cater to this need.
When the development system is taken out for upgrade, it should be copied to a new client and handed over to production support team so that Priority 1 and LTO fixes can be done here and transported through to the production system. Transport path also needs to be changed accordingly.
Once the dual landscape is setup, care should be taken to maintain both landscapes in the same state till go live. Changes done in the old version landscape should be redone in the upgraded landscape also to ensure consistency between the systems.
Upgrade Strategy :
SAP offers different upgrade strategies to choose from. Upgrade project team should carefully evaluate the client specific technical considerations and business needs before finalising on the strategy.
i) Downtime-minimized strategy
- Shorter production downtime
- Higher demand on system resources
This is the preferred strategy if the business cannot afford longer downtimes and if sufficient hardware resources are available.
ii) Resource-minimized strategy:
- Lower demand on system resources
- Increased production downtime
This is the preferred strategy if the business has hardware resource constraints but can afford longer downtime.
Uptime and Downtime
It must be noted that the SAP system need not be down during the entire upgrade process. Most of the processing steps that are part of the upgrade can be performed while the system is running. This is called as uptime.
System is taken down only during that part of the upgrade process when live, running transactions have to be replaced by new functionality since there is a potential risk for data inconsistency.
Evolution of SAP Enhancement Packages
As we can see, SAP technical upgrade is a complex project and can last for months. Hence SAP has come up with the Enhancements Package concept since the release of its ECC 6.0 version.
Today’s enterprises do not wish to disturb the stability of their core processes often but they want to innovate very often. Also, they do not want their system to be down for upgrade for a long time. SAP’s Enhancement Package concept exactly meets this demand.
SAP now delivers evolutionary as well as breakthrough innovations in shipments that have minimal negative impact on the customer’s operation and
business. Smaller roundoffs to the existing applications will be delivered using the SAP Notes service or Support Packages and Innovations that are deeply
interwoven with the core applications will be delivered as enhancement packages or add-ons.
Thus the EHP concept reduces the conflict between Stability and Innovation. It delivers innovation on time without disrupting the stability.
- Innovation : Fast and easy introduction of business innovation at any time when needed
- Stability : Stable and robust business processes ; Routine deployment of support packages to sustain compliance
What are Enhancement Packages?
Optionally installed and activated software innovations for SAP ECC 6.0
- Software innovations include user interface simplifications, functional enhancements and Enterprise services
- SAP enhancement packages are built on top of each other; Installation of latest EHP will automatically get all functionalities delivered
with previous EHPs
- Enhancement packages are not support packages; Support Packages contain corrections and legal changes
- EHP’s initially introduced for ERP and the story continues…
Features of Enhancement Packages :
1. Selective Installation :
- Each enhancement package contains new versions of existing software components
- Customer can choose to update only those software components which are related to the functionality that he wants to use
- No user interface or process change until a Business Function is activated
- One common regression test for both Support Pack and Enhancement Package
2. Selective Activation
- New functionality must be explicitly switched on to become active in the system
- Changes are predictable, only well described changes in the activated areas
- Testing is simplified with templates, provided for every Business Function
Advantages of EHP
- Gain stability and access to innovation
- Upgrade only the enhancements applicable to your business
- Reduce risk and downtime
- Speedy implementation and less Testing. While the average project duration for an upgrade is 21 weeks, the average duration for EHP installation is only 7 weeks.
- Reduced training effort