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
thereafter.
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.
5. Testing
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.
Z- Programs
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.
Soft Freeze
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
Hard Freeze
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)
Deep Freeze
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
This is the preferred strategy if the business cannot afford longer downtimes and if sufficient hardware resources are available.
ii) Resource-minimized strategy:
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.
© SAP
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.
© SAP
Thus the EHP concept reduces the conflict between Stability and Innovation. It delivers innovation on time without disrupting the stability.
What are Enhancement Packages?
Optionally installed and activated software innovations for SAP ECC 6.0
© SAP
Features of Enhancement Packages :
1. Selective Installation :
After installation:
2. Selective Activation
If activated:
© SAP
Advantages of EHP
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
6 | |
5 | |
4 | |
4 | |
3 | |
3 | |
3 | |
3 | |
2 | |
2 |